Enterprise Architect UML Tutorials

21.02.
2013
Enterprise Architect - UML Tutorials

Searc h... Sparx Sys tems E A U s er G uide
Products
Resources
Trainers
Forum
Support
Services
Registered Users
UML Tutorial
A bout Us
View / Checkout
Enterprise A rchitect Resources Current Release V ers ion 1 0 , Build 1 0 0 6 3 1 - J anuary- 2 0 1 3 E nterpris e A rc hitec t T rial Tutorials
Tutorials
The Unified Modeling Language (UML) is the de-facto standard for building Object-Oriented software. These tutorials provide a technical overview of UML and Enterprise Architect. If you are a beginner, our UML Tutorial Part 1 is a recommended starting point.
Resources M D G T ec hnologies White paper Repos itory D emons trations U M L D atabas e modeling M apping U s e C as es RT F D oc umentation I mage L ibrary M D A Res ourc es XM L Sc hema G eneration E xtra U M L Res ourc es Team Modeling Resources D BM S Repos itory Sc ripts U s er Sec urity Key WA N O ptimizer Developers A utomation I nterfac e U M L P atterns U M L P rofiles MDA Style Transf orms Built- in T rans formations Writing T rans formations UML Tutorials U M L T utorial U M L T utorial - P art 2 U M L 2 .0 T utorial E A D emons trations U M L M odels Bus ines s P roc es s M odel C us tom M odel D ynamic M odel L ogic al M odel P hys ic al M odels U s e C as e M odel Enterprise A rchitect Tutorials Res ourc e M anagement T es ting Support T rac eability U s e C as e M etric s
UML Tutorials
Enterprise Architect Tutorials
UML Tutorials UML 2 Tutorial
Description This tutorial de scribe s e ach of the UML diagram type s that are supporte d by Ente rprise Archite ct.
UML Tutorial - Part 1 Intro
A brie f introduction and te chnical ove rvie w of UML.
UML Tutorial - Part 2 Intro
Illustrate s how the UML can be use d to de fine , build and support a software de ve lopm e nt proje ct.
The Busine ss Proce ss Mode l
A high-le ve l ove rvie w of Busine ss Proce ss Mode ling, including BPMN and the Erik sson-Pe nk e r Busine ss Mode ling Profile .
The C om pone nt Mode l
Discusse s the role of com pone nt m ode ling as re pre se nte d in UML
The Dynam ic Mode l
Discusse s the role of the dynam ic m ode l in de scribing syste m be havior.
The Logical Mode l
Introduce s the logical m ode l as re pre se nte d in UML.
The Physical Mode l
De scribe s how to re pre se nt the physical m ode l in UML.
The Use C ase Mode l
Discusse s the role of the use case m ode l and its basic conce pts such as Actors, Use C ase Sce narios, R e lationships and Se que nce Diagram s.
UML Database Mode ling
Discusse s how to re pre se nt re lational database sche m as using the UML C lass m ode l.
Products E nterpris e A rc hitec t E c lips e I ntegration V is ual Studio I ntegration U P D M T ec hnology Sys M L T ec hnology D D S T ec hnology D O O RS L ink A dditional A ddins
UML at a Glance UML U M L T ools P H P U M L M odeling Bus ines s P roc es s M odeling M odel D riven A rc hitec ture Requirements M anagement Software D evelopment
Solutions C orporate G overnment Small/M edium E nterpris e I T P rofes s ionals T rainers A c ademic
Resources U M L 2 .0 T utorial M D G T ec hnologies C orporate Res ourc es D eveloper Res ourc es M edia Res ourc es
Support O nline M anual U s er Forum Report a Bug Feature Reques t C hange Y our E mail
Global Partners T rainers V alue A dded Res ellers Res ellers Sis ter C ompanies T ec hnic al P artners Standards O rganizations
2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.
L egal
P rivac y
Site map
www.sparxsystems.com/resources/tutorial_home/index.html
1/1
21.02.2013
Business Process Modelling using Enterprise Architect

Products
Resources
Trainers
Forum
Support
Services
Registered Users
UML Tutorial
A bout Us
View / Checkout
Enterprise A rchitect Resources Current Release V ers ion 1 0 , Build 1 0 0 6 3 1 - J anuary- 2 0 1 3 E nterpris e A rc hitec t T rial Tutorial The Business Process Model
The Business Process Model

Download PDF version
Introduction
Traditionally, the UML has been associated more with software engineering and systems design than with analysis and modeling of business processes. However, standard UML 2.x provides a rich set of behavioral models which are very useful in modeling the processes, activities, people and information critical to every business. Beyond the standard UML notation, two well respected and proven UML extensions exist which further enhance the capturing of business process and related constructs. The first is Business Process Modeling Notation (BPMN), which has gained enormous popularity and is rapidly becoming a new standard for modeling and designing business processes. The second is the EricssonPenker profile which has less popularity, but still provides a unique and powerful means of visualizing and communicating business processes and the necessary flow of information within an organization. This paper provides a very high-level introduction to both of these extensions, showing how they can be used in Enterprise Architect and some of the common modeling constructs they use.
Business Process Modeling Notation (BPMN)

BPMN defines a Business Process Diagram (BPD), which is based on a flowcharting technique tailored for creating graphical models of business process operations. It is a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. A BPMN model consists of simple diagrams with a small set of graphical elements.
Fl ow El ements
1. Activities. An activity is work that is performed within a business process and is represented by a rounded rectangle. 2. Events. An event is something that happens during the course of a business process which affects the sequence or timing of activities of a process. Events are represented as small circles with different boundaries to distinguish start events (thin black line), intermediate events (double line) and end events (thick black line). Events can show icons within their shape to identify the trigger or result of the event. 3. Gateways. Gateways are used to control how sequence flows converge and diverge within a process. Gateways can represent decisions, where one or more paths are disallowed, or they can represent concurrent forks. 1. Sequence flows. A sequence flow is used to show the order in which activities are performed within a process. A sequence flow is represented by a line with a solid arrowhead. 2. Message flows. A message flow is used to show the flow of messages between two entities, where pools are used to represent entities. A message flow is represented by a dashed line with a light-colored circle at the source and arrowhead at the target. 3. Associations. An association is used to associate information and artifacts with flow objects. An association is represented by a dashed line which may or may not have a line arrowhead at the target end if there is a reason to show directionality.
Swi ml a nes (P a rti ti ons)
1. Pools. A pool represents a participant in a process, where a participant may be a business entity or role. It is represented as a partition of the process. 2. Lanes. A lane is a sub-division of a pool and is used to organize and categorize activities within the pool.
Arti f a cts
1. Data objects. A data object does not have a direct affect on a process but does provide information relevant to the process. It is represented as a rectangle with the top corner folded over. 2. Groups. A group is an informal means for grouping elements of a process. It is represented as a rectangle with a dashed line border. 3. Annotations. An annotation is a mechanism for the BPMN modeler to provide additional information to the audience of a BPMN diagram. It is represented by an open rectangle containing the annotation text.
B P MN Exa mpl es
Example 1:
www.sparxsystems.com/business_process_model.html
1/4
21.02.2013
The above diagram illustrates a number of key features of BPMN, specifically the ability to create hierarchical decomposition of processes into smaller tasks, the ability to represent looping constructs and the ability to have external events interrupt the normal process flow. "Upstream Activities" and "Downstream Activities" are link-triggered intermediate events; in other words, off-page connectors. "Repeat for Each Supplier" is a looping activity, which repeats its three contained activities either once for each supplier or until a time limit is exceeded. The intermediate event mounted on the lower edge of the activity is a time-triggered event.
Example 2:
The above diagram shows a process being initiated by an event - in this case a message-triggered start event which notifies the process that the working group is active. The diagram also shows a loop being controlled by a timer event, and it shows a decision gateway (in this case, an XOR decision gateway) controlling when the loop is terminated.
Example 3:
This diagram illustrates the use of pools to show interacting processes and the way that messages are passed between pools using message flow connectors.
Eriksson-Penker Business Modeling Profile

This section provides an introduction to the terminology and icons used in the Business Process Model, and gives a quick introduction to some Unified Modeling Language (UML) concepts and how they are applied in Enterprise Architect's Business Process Model. A business process: 1. Has a Goal 2. Has specific inputs
2/4
21.02.2013
3. 4. 5. 6. 7.

Has specific outputs Uses resources Has a number of activities that are performed in some order May affect more than one organizational unit. Horizontal organizational impact C reates value of some kind for the customer. The customer may be internal or external.
P rocess Model s
A business process is a collection of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how the work is done within an organization, in contrast to a product's focus on what a process is. Thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs, outputs and a structure for action. Supply link from object Information. A supply link indicates that the information or object linked to the process is not used up in the processing phase. For example, order templates may be used over and over to provide new orders of a certain style the templates are not altered or exhausted as part of this activity. Input link from object Resource . An input link indicates that the attached object or resource is consumed in the processing procedure. As an example, as customer orders are processed they are completed and signed off, and typically are used only once per unique resource (order). Goal link to object Goal. A goal link indicates the attached object to the business process describes the goal of the process. A goal is the business justification for performing the activity. Object flow link to object Output Object flow link from event Event. An object flow link indicates some object is passed into a business process. It captures the passing of control to another entity or process, with the implied passing of state or information from activity to activity.
Goa l
A business process has some well defined goal. This is the reason the organization does this work, and should be defined in terms of the benefits this process has for the organization as a whole and in satisfying the business needs. Goals link to Processes. A Goal link indicates the attached object to the business process describes the goal of the process. A goal is the business justification for performing the activity.
I nf orma ti on
Business processes use information to tailor or complete their activities. Information, unlike resources, is not consumed in the process rather it is used as part of the transformation process. Information may come from external sources, from customers, from internal organizational units and may even be the product of other processes. Information items link to Business Processes. A Supply link indicates that the information or object linked to the process is not used up in the processing phase. For example, order templates may be used over and over to provide new orders of a certain style the templates are not altered or exhausted as part of this activity.
Output
A business process will typically produce one or more outputs of value to the business, either for internal use of to satisfy external requirements. An output may be a physical object (such as a report or invoice), a transformation of raw resources into a new arrangement (a daily schedule or roster) or an overall business result such as completing a customer order. An output of one business process may feed into another process, either as a requested item or a trigger to initiate new activities.
R esource
A resource is an input to a business process, and, unlike information, is typically consumed during the processing. For example, as each daily train service is run and actuals recorded, the service resource is 'used up' as far as the process of recording actual train times is concerned. Resources link to Business Processes. An Input link indicates that the attached object or resource is consumed in the processing procedure. As an example, as customer orders are processed they are completed and signed off, and typically are used only once per unique resource (order).
Additional Resources
Enterprise A rchitect Resources
Enterprise Architects Reviewers Guide: http://www.sparxsystems.com/downloads/whitepapers/EAReviewersGuide.pdf
3/4
21.02.2013

Enterprise Architect video walk-through: http://www.sparxsystems.com/resources/demos/eaoverview/index.html
L egal
P rivac y
Site map
4/4
21.02.2013
The UML Component Model by Sparx Systems

Products
Resources
Trainers
Forum
Support
Services
Registered Users
UML Tutorial
A bout Us
View / Checkout
Enterprise A rchitect Resources Current Release V ers ion 1 0 , Build 1 0 0 6 3 1 - J anuary- 2 0 1 3 E nterpris e A rc hitec t T rial Tutorial The Component Model
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. C omponents 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. C omponents 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.
Interfaces
C omponents 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.
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.
www.sparxsystems.com/resources/tutorial/component_model.html
1/3
21.02.2013
Requirements
C omponents 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.
Constraints
C omponents 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
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.
Traceability
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
2/3
21.02.2013

The security components diagram shows how security software such as the C ertificate Authority, Browser, Web server and other model elements work together to assure security provisions in the proposed system.
L egal
P rivac y
Site map
3/3
21.02.2013
Sparx Systems UML Tutorials - The Dynamic Model

Products
Resources
Trainers
Forum
Support
Services
Registered Users
UML Tutorial
A bout Us
View / Checkout
Enterprise A rchitect Resources Current Release V ers ion 1 0 , Build 1 0 0 6 3 1 - J anuary- 2 0 1 3 E nterpris e A rc hitec t T rial Tutorial The Dynamic Model
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 C ases 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 C ontroller icon. The Object labelled users is shown using the Entity icon.
Activity Diagrams
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.
www.sparxsystems.com/resources/tutorial/dynamic_model.html
1/3
21.02.2013
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.
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.
2/3
21.02.2013
L egal
P rivac y
Site map
3/3
21.02.2013
Enterprise Architect - Logical Model

Products
Resources
Trainers
Forum
Support
Services
Registered Users
UML Tutorial
A bout Us
View / Checkout
Enterprise A rchitect Resources Current Release V ers ion 1 0 , Build 1 0 0 6 3 1 - J anuary- 2 0 1 3 E nterpris e A rc hitec t T rial Tutorial The Logical Model
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 C lass Model is a more rigorous and design focused model. This discussion relates mainly to the C lass Model
The Class Model

A C lass 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. C lasses 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 C lass 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:
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) 3. 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 C lass 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.
C lass models may be collected into packages of related behavior and state. The diagram below illustrates this.
www.sparxsystems.com/resources/tutorial/logical_model.html
1/2
21.02.2013
Enterprise Architect - Logical Model
L egal
P rivac y
Site map
www.sparxsystems.com/resources/tutorial/logical_model.html
2/2
21.02.2013
Enterprise Architect - Physical Model

Products
Resources
Trainers
Forum
Support
Services
Registered Users
UML Tutorial
A bout Us
View / Checkout
Enterprise A rchitect Resources Current Release V ers ion 1 0 , Build 1 0 0 6 3 1 - J anuary- 2 0 1 3 E nterpris e A rc hitec t T rial Tutorial The Physical Model
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
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.
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 TC P/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.
www.sparxsystems.com/resources/tutorial/physical_models.html
1/2
21.02.2013
Enterprise Architect - Physical Model
L egal
P rivac y
Site map
www.sparxsystems.com/resources/tutorial/physical_models.html
2/2
21.02.2013
Enterprise Architect - Use Case Model

Products
Resources
Trainers
Forum
Support
Services
Registered Users
UML Tutorial
A bout Us
View / Checkout
Enterprise A rchitect Resources Current Release V ers ion 1 0 , Build 1 0 0 6 3 1 - J anuary- 2 0 1 3 E nterpris e A rc hitec t T rial Tutorial The Use Case Model
The Use Case Model

A Use C ase Model describes the proposed functionality of a new system. A Use C ase represents a discrete unit of interaction between a user (human or machine) and the system. This interaction is a single unit of meaningful work, such as C reate Account or View Account Details. Each Use C ase describes the functionality to be built in the proposed system, which can include another Use C ase's functionality or extend another Use C ase with its own behavior.
A Use C ase description will generally includes: General comments and notes describing the use case. Requirements - The formal functional requirements of things that a Use C ase must provide to the end user, such as <ability to update order>. These correspond to the functional specifications found in structured methodologies, and form a contract that the Use C ase performs some action or provides some value to the system. C onstraints - The formal rules and limitations a Use C ase operates under, defining what can and cannot be done. These include: Pre-conditions that must have already occurred or be in place before the use case is run; for example, <create order> must precede <modify order> Post-conditions that must be true once the Use C ase is complete; for example, <order is modified and consistent> Invariants that must always be true throughout the time the Use C ase operates; for example, an order must always have a customer number. Scenarios Formal, sequential descriptions of the steps taken to carry out the use case, or the flow of events that occur during a Use C ase instance. These can include multiple scenarios, to cater for exceptional circumstances and alternative processing paths. These are usually created in text and correspond to a textual representation of the Sequence Diagram. Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios but graphically portrayed. Additional attributes, such as implementation phase, version number, complexity rating, stereotype and status.
Actors
Use C ases are typically related to 'actors', which are human or machine entities that use or interact with the system to perform a piece of meaningful work that helps them to achieve a goal. The set of Use C ases an actor has access to defines their overall role in the system and the scope of their action.
Includes and Extends relationships between Use Cases

One Use C ase could include the functionality of another as part of its normal processing. Generally, it is assumed that the included Use C ase is called every time the basic path is run. For example, when listing a set of customer orders to choose from before modifying a selected order, the <list orders> Use C ase would be included every time the <modify order> Use C ase is run. A Use C ase can be included by one or more other Use C ases, so it helps to reduce duplication of functionality by factoring out common behavior into Use C ases that are re-used many times. One Use C ase can extend the behavior of another, typically when exceptional circumstances are encountered. For example, if a user must get approval from some higher authority before modifying a particular type of customer order, then the <get approval>
www.sparxsystems.com/resources/tutorial/use_case_model.html
1/3
21.02.2013

Use C ase could optionally extend the regular <modify order> Use C ase.
Sequence Diagrams
Sequence diagrams provide a graphical representation of object interactions over time. These typically show a user or actor, and the objects and components they interact with in the execution of a use case. One sequence diagram typically represents a single Use C ase 'scenario' or flow of events. Sequence diagrams are an excellent way of documenting usage scenarios and both capturing required objects early in analysis and verifying object use later in design. The diagrams show the flow of messages from one object to another, and as such correspond to the methods and events supported by a class/object. The following example of a sequence diagram shows the user or actor on the left initiating a flow of events and messages that correspond to the Use C ase scenario. The messages that pass between objects become class operations in the final model.
Implementation Diagram
A Use C ase is a formal description of functionality that the system will have when constructed. An implementation diagram is typically associated with a Use C ase to document which design elements (for example, components and classes) implement the Use C ase functionality in the new system. This provides a high level of traceability for the system designer, the customer and the team that will actually build the system. The list of Use C ases that a component or class is linked to documents the minimum functionality that must be implemented by the component.
The example above shows that the use case 'Login' implements the formal requirement '1.01 Log On to the website'. It also shows that the 'Business Logic' component and 'ASP Pages' component implement some or all of the 'Login' functionality. A further refinement is to show the 'Login' screen (a web page) as implementing the 'Login' use case. These implementation or realization links define the traceability from the formal requirements, through use cases on to components and screens.
Products E nterpris e A rc hitec t E c lips e I ntegration V is ual Studio I ntegration
UML at a Glance UML U M L T ools P H P U M L M odeling
Solutions C orporate G overnment Small/M edium E nterpris e
Resources U M L 2 .0 T utorial M D G T ec hnologies C orporate Res ourc es
Support O nline M anual U s er Forum Report a Bug
Global Partners T rainers V alue A dded Res ellers Res ellers
2/3
21.02.2013
U P D M T ec hnology Sys M L T ec hnology D D S T ec hnology D O O RS L ink A dditional A ddins Bus ines s P roc es s M odeling M odel D riven A rc hitec ture Requirements M anagement Software D evelopment T rainers A c ademic

I T P rofes s ionals D eveloper Res ourc es M edia Res ourc es Feature Reques t C hange Y our E mail Sis ter C ompanies T ec hnic al P artners Standards O rganizations
L egal
P rivac y
Site map
3/3

Enterprise Architect UML Tutorials

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Enterprise Architect UML Tutorials

Uploaded by

Copyright:

Available Formats

21.02.

Enterprise Architect - UML Tutorials

Enterprise Architect Tutorials

UML Tutorials UML 2 Tutorial

UML Tutorial - Part 1 Intro

A brie f introduction and te chnical ove rvie w of UML.

UML Tutorial - Part 2 Intro

The Busine ss Proce ss Mode l

The C om pone nt Mode l

The Dynam ic Mode l

Discusse s the role of the dynam ic m ode l in de scribing syste m be havior.

The Logical Mode l

Introduce s the logical m ode l as re pre se nte d in UML.

The Physical Mode l

De scribe s how to re pre se nt the physical m ode l in UML.

The Use C ase Mode l

UML Database Mode ling

2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.

Business Process Modelling using Enterprise Architect

The Business Process Model

Business Process Modeling Notation (BPMN)

Business Process Modelling using Enterprise Architect

Eriksson-Penker Business Modeling Profile

Business Process Modelling using Enterprise Architect

Enterprise Architects Reviewers Guide: http://www.sparxsystems.com/downloads/whitepapers/EAReviewersGuide.pdf

Business Process Modelling using Enterprise Architect

2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.

The UML Component Model by Sparx Systems

The Component Model

The Component Diagram

Components and Nodes

The UML Component Model by Sparx Systems

The UML Component Model by Sparx Systems

2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.

Sparx Systems UML Tutorials - The Dynamic Model

The Dynamic Model

Sparx Systems UML Tutorials - The Dynamic Model

Sparx Systems UML Tutorials - The Dynamic Model

2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.

Enterprise Architect - Logical Model

The Logical Model

The Class Model

Enterprise Architect - Logical Model

2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.

Enterprise Architect - Physical Model

The Physical Model

Enterprise Architect - Physical Model

2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.

Enterprise Architect - Use Case Model

The Use Case Model

Includes and Extends relationships between Use Cases

Enterprise Architect - Use Case Model

Products E nterpris e A rc hitec t E c lips e I ntegration V is ual Studio I ntegration

UML at a Glance UML U M L T ools P H P U M L M odeling

Solutions C orporate G overnment Small/M edium E nterpris e

Resources U M L 2 .0 T utorial M D G T ec hnologies C orporate Res ourc es

Support O nline M anual U s er Forum Report a Bug

Global Partners T rainers V alue A dded Res ellers Res ellers

Enterprise Architect - Use Case Model

2 0 0 0 - 2 0 1 3 Sparx Systems Pty Ltd. A ll rights Res erved.

You might also like