Sparx Systems

99 Albert Street
P: +61 3 5345 1140
F: +61 3 5345 1104
Sparx Systems specializes in high performance and scalable visual modeling tools for the planning, design and construction of software intensive systems. A Contributing Member of the Object Management Group (OMG), Sparx Systems is committed to realizing the potential of model-driven development based on open standards. The company’s flagship product, Enterprise Architect, has received numerous accolades since its commercial release in August, 2000. Enterprise Architect is the design tool of choice for over 740,000 registered users worldwide.

Diagram Filters allow you to tailor the presentation of diagrams and conduct meaningful comparisons. Dynamic Visual Filtering lets you highlight diagram elements based on selected properties such as Author, Status, Stereotype and Version. Diagram Filters are ideal for comparing 'as-is' and 'to-be' architectures. They can also be used to visualize changes to a model diagram after a given date.

This tutorial will teach you a visual approach for generating Business Process Execution Language (BPEL) code from your model. Using a “Hello World” example, we illustrate how Enterprise Architect can automatically generate BPEL code for you.

Enterprise Architect provides a number of code templates that specify the transformation from UML elements to the various parts of a given programming language. The following tutorial demonstrates how to modify a base code template to add support for generating DoxyGen comments.

Monday, 12 October 2009 00:56

RTF Documentation

Rich Text Format Documentation
Rich text reports are documents produced by Enterprise Architect in Rich Text Format (RTF), a format common to many word processors. In particular it is targeted at Microsoft Word™, which provides the ability to link together a number of rich text documents into a single master document.

Typically you will create a Word master document, then some Enterprise Architect RTF reports. These are linked back into sub-sections of the master document and refreshed as required during project development. In this way the project document becomes an easy to manage and feature-rich work product.

By adding tables of contents, figure tables, header & footers and sections you can manage a complex document with relative ease. Simply update the Enterprise Architect RTF reports then refresh the links in MS Word.

Enterprise Architect v5.0 has introduced a new fully-featured RTF Document generator. Some of the features include:

  • Powerful WYSIWYG RTF template editor support allowing:
    • Headers and Footers
    • Images
    • Indexes
    • Tabular Sections
    • Nested Sections
    • All model elements, connectors, diagrams and their properties
    • Template import and export using XML
    • Basic templates supplied for customization
  • New document generator:
  • New embedded RTF viewer
    • View RTF documents generated in EA directly within EA
Sunday, 11 October 2009 23:21

The Physical Model

The Physical/Deployment Model provides a detailed model of the way components will be deployed across the system infrastructure. It details network capabilities, server specifications, hardware requirements and other information related to deploying the proposed system.

Deployment View

Deployment View

PM01: Physical Model

The physical model shows where and how system components will be deployed. It is a specific map of the physical layout of the system. A deployment diagram illustrates the physical deployment of the system into a production (or test) environment. It shows where components will be located, on what servers, machines or hardware. It may illustrate network links, LAN bandwidth & etc.

Physical Model

A node is used to depict any server, workstation or other host hardware used to deploy components into the production environment. You may also specify the links between nodes and assign stereotypes (such as TCP/IP) and requirements to them. Nodes may also have performance characteristics, minimum hardware standards, operating system levels & etc. documented. The screen below illustrates the common properties you can set for a node.



Sunday, 11 October 2009 23:04

The Logical Model

A logical model is a static view of the objects and classes that make up the design/analysis space. Typically, a Domain Model is a looser, high level view of Business Objects and entities, while the Class Model is a more rigorous and design focused model. This discussion relates mainly to the Class Model


The Class Model

A Class is a standard UML construct used to detail the pattern from which objects will be produced at run-time. A class is a specification - an object an instance of a class. Classes may be inherited from other classes (that is they inherit all the behavior and state of their parent and add new functionality of their own), have other classes as attributes, delegate responsibilities to other classes and implement abstract interfaces.

The Class Model is at the core of object-oriented development and design - it expresses both the persistent state of the system and the behavior of the system. A class encapsulates state (attributes) and offers services to manipulate that state (behavior). Good object-oriented design limits direct access to class attributes and offers services which manipulate attributes on behalf of the caller. This hiding of data and exposing of services ensures data updates are only done in one place and according to specific rules - for large systems the maintenance burden of code which has direct access to data elements in many places is extremely high.

The class is represented as below:

Simple Class

Note that the class has three distinct areas:

1. The class name (and stereotype if applied)
2. The class attributes area (that is internal data elements)

The behavior - both private and public

Attributes and methods may be marked as

- Private, indicating they are not visible to callers outside the class
- Protected, they are only visible to children of the class

Public, they are visible to all

Class inheritance is shown as below: an abstract class in this case, is the parent of two children, each of which inherits the base class features and extends it with their own behavior.

Class Inheritance

Class models may be collected into packages of related behavior and state. The diagram below illustrates this.

Behavior and State


Sunday, 11 October 2009 22:55

The Dynamic Model

The dynamic model is used to express and model the behaviour of the system over time. It includes support for activity diagrams, state diagrams, sequence diagrams and extensions including business process modelling.


Sequence Diagrams

Sequence diagrams are used to display the interaction between users, screens, objects and entities within the system. It provides a sequential map of message passing between objects over time. Frequently these diagrams are placed under Use Cases in the model to illustrate the use case scenario - how a user will interact with the system and what happens internally to get the work done. Often, the objects are represented using special stereotyped icons, as in the example below. The object labelled Login Screen is shown using the User Interface icon. The object labelled SecurityManager is shown using the Controller icon. The Object labelled users is shown using the Entity icon.




Activity diagrams are used to show how different workflows in the system are constructed, how they start and the possibly many decision paths that can be taken from start to finish. They may also illustrate the where parallel processing may occur in the execution of some activities.


State Charts

State charts are used to detail the transitions or changes of state an object can go through in the system. They show how an object moves from one state to another and the rules that govern that change. State charts typically have a start and end condition.

State Chart

Process Model

A process model is a UML extension of an activity diagram used to model a business process - this diagram shows what goal the process has, the inputs, outputs, events and information that are involved in the process.



Sunday, 11 October 2009 22:37

The Component Model

The component model illustrates the software components that will be used to build the system. These may be built up from the class model and written from scratch for the new system, or may be brought in from other projects and 3rd party vendors. Components are high level aggregations of smaller software pieces, and provide a 'black box' building block approach to software construction.

Component Notation

A component may be something like an ActiveX control - either a user interface control or a business rules server. Components are drawn as the following diagram shows:


The Component Diagram

The component diagram shows the relationship between software components, their dependencies, communication, location and other conditions.


Components may also expose interfaces. These are the visible entry points or services that a component is advertising and making available to other software components and classes. Typically a component is made up of many internal classes and packages of classes. It may even be assembled from a collection of smaller components.


Expose Interface

Components and Nodes

A deployment diagram illustrates the physical deployment of the system into a production (or test) environment. It shows where components will be located, on what servers, machines or hardware. It may illustrate network links, LAN bandwidth & etc.



Components may have requirements attached to indicate their contractual obligations - that is, what service they will provide in the model. Requirements help document the functional behaviour of software elements.


Components may have constraints attached which indicate the environment in which they operate. Pre-conditions specify what must be true before a component can perform some function; post-conditions indicate what will be true after a component has done some work and Invariants specify what must remain true for the duration of the components lifetime.


Scenarios are textual/procedural descriptions of an object's actions over time and describe the way in which a component works. Multiple scenarios may be created to describe the basic path (a perfect run through) as well as exceptions, errors and other conditions.


You may indicate traceability through realisation links. A component may implement another model element (eg. a use case) or a component may be implemented by another element (eg. a package of classes). By providing realisation links to and from components you can map the dependencies amongst model elements and the traceability from the initial requirements to the final implementation.

An Example
The following example shows how components may be linked to provide a conceptual/logical view of a systems construction. This example is concerned with the server and security elements of an on-line book store. It includes such elements as the web server, firewall, ASP pages & etc.

Server Components

This diagram illustrates the layout of the main server side components that will require building for an on-line book store. These components are a mixture of custom built and purchased items which will be assembled to provide the required functionality.



Security Components

The security components diagram shows how security software such as the Certificate Authority, Browser, Web server and other model elements work together to assure security provisions in the proposed system.


Sunday, 11 October 2009 22:19

Business Process Modeling

Page 22 of 28