UML

UML Tutorial The Unified Modeling Language (UML) has quickly become the de-facto standard for building Object-Oriented software. This tutorial provides a technical overview of the 13 UML diagrams supported by Enterprise Architect. UML 2 semantics are explained in detail in the new UML 2.0 tutorial. To become familiar with the concepts of UML, we recommend newcomers look this tutorial first. Firstly... What is UML? The OMG specification states: "The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components." The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process. UML defines the notation and semantics for the following domains: - The User Interaction or Use Case Model - describes the boundary and interaction between the system and users. Corresponds in some respects to a requirements model. The Interaction or Communication Model - describes how objects in the system will interact with each other to get work done. The State or Dynamic Model - State charts describe the states or conditions that classes assume over time. Activity graphs describe the workflows the system will implement. The Logical or Class Model - describes the classes and objects that will make up the system. The Physical Component Model - describes the software (and sometimes hardware components) that make up the system. The Physical Deployment Model - describes the physical architecture and the deployment of components on that hardware architecture. We have established in Part 1 that the UML is a language for specifying the artifacts and interactions of a software system. We have also seen that it deals with 6 major domains - from Use Case models, through dynamic and logical models to the final physical deployment model - and that extension mechanisms have been included to allow for specialised additions to the model notation. So... How do you use the UML? The UML is typically used as a part of a software development process, with the support of a suitable CASE tool, to define the requirements, the interactions and the elements of the proposed software system. The exact nature of the process depends on the development methodology used. An example process might look something like the following: 1. Capture a Business Process Model. This will be used to define the high level business activities and processes that occur in an organization and to provide a foundation for the Use Case model. The Business Process Model will typically capture more than a software system will implement (ie. it includes manual and other processes). 2. Map a Use Case Model to the Business Process Model to define exactly what functionality you are intending to provide from the business user perspective. As each Use Case is added, create a traceable link from the appropriate business processes to the Use Case (ie. a realisation connection). This mapping clearly states what functionality the new system will provide to meet the business requirements outlined in the process model. It also ensures no Use Cases exist without a purpose. 3. Refine the Use Cases - include requirements, constraints, complexity rating, notes and scenarios. This information unambiguously describes what the Use Case does, how it is executed and the constraints on its execution. Make sure the Use Case still meets the business process requirements. Include the definition of system tests for each use case to define the aceptance criteria for each use case. Also include some user acceptance test scripts to define how the user will test this functionality and what the acceptance criteria are. 4. From the inputs and outputs of the Business Process Model and the details of the use cases, begin to construct a domain model (high level business objects), sequence diagrams, collaboration diagrams and user interface models. These describe the 'things' in the new system, the way those things interact and the interface a user will use to execute use case scenarios. 5. From the domain model, the user interface model and the scenario diagrams create the Class Model. This is a precise specification of the objects in the system, their data or attributes and their behaviour or operations. Domain objects may be abstracted into class hierarchies using inheritance. Scenario diagram messages will typically map to class operations. If an existing framework or design pattern is to be used, it may be possible to import existing model elements for use in the new system. For each class define unit tests and integration tests to thoroughly test i) that the class functions as specified internally and that ii) the class interacts with other related classes and components as expected. 6. As the Class Model develops it may be broken into discrete packages and components. A component represents a deployable chunk of software that collects the behaviour and data of one or more classes and exposes a strict interface to other consumers of its services. So from the Class Model a Component Model is built to define the logical packaging of classes. For each component define integration tests to confirm that the component's interface meets the specifcation given it in relation to other software elements. 7. Concurrent with the work you have already done, additional requirements should have been captured and documented. For example - Non Functional requirements, Performance requirements, Security requirements, responsibilities, release plans & etc. Collect these within the model and keep up to date as the model matures. 8. The Deployment model defines the physical architecture of the system. This work can be begun early to capture the physical deployment characteristics - what hardware, operating systems, network capabilities, interfaces and support software will make up the new system, where it will be deployed and what parameters apply to disaster recovery, reliability, back-ups and support. As the model develops the physical architecture will be updated to reflect the actual system being proposed. 9. Build the system: Take discrete pieces of the model and assign to one or more developers. In a Use Case driven build this will mean assigning a Use Case to the development team, having them build the screens, business objects, database tables, and related components necessary to execute that Use Case. As each Use Case is built it should be accompanied by completed unit, integration and system tests. A Component driven build may see discrete software components assigned to development teams for construction. 10. Track defects that emerge in the testing phases against the related model elements - eg. System test defects against Use Cases, Unit Test defects against classes & etc. Track any changes against the related model elements to manage 'scope creep'. 11. Update and refine the model as work proceeds - always assessing the impact of changes and model refinements on later work. Use an iterative approach to work through the design in discrete chunks, always assessing the current build, the forward requirements and any discoveries that come to light during development. 12. Deliver the complete and tested software into a test then production environment. If a phased delivery is being undertaken, then this migration of built sofware from test to production may occur several times over the life of the project. Note that the above process is necessarily brief in description, leaves much unsaid and may not be how you work or follow the process you have adopted. It is given as an example of how the UML may be used to support a software development project. UML 2.1 Tutorial UML 2.1 advances the successful UML 2.0 specification, and is quickly becoming the accepted standard for specifying, documenting and visualizing software systems. The Unified Modeling Language (UML) is also used for the modeling of non-software systems, and is extensively implemented in most industry sectors including finance, military and engineering. If you are new to the Unified Modeling Language, our Introduction to UML is a recommended starting point. UML 2 defines thirteen basic diagram types, divided into two general sets: 1. Structural Modeling Diagrams Structure diagrams define the static architecture of a model. They are used to model the 'things' that make up a model the classes, objects, interfaces and physical components. In addition, they are used to model the relationships and dependencies between elements. - Package diagrams are used to divide the model into logical containers, or 'packages', and describe the interactions between them at a high level. - Class or Structural diagrams define the basic building blocks of a model: the types, classes and general materials used to construct a full model. - Object diagrams show how instances of structural elements are related and used at run-time. - Composite Structure diagrams provide a means of layering an element's structure and focusing on inner detail, construction and relationships. - Component diagrams are used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface. - Deployment diagrams show the physical disposition of significant artifacts within a real-world setting. 2. Behavioral Modeling Diagrams Behavior diagrams capture the varieties of interaction and instantaneous states within a model as it 'executes' over time; tracking how the system will act in a real-world environment, and observing the effects of an operation or event, including its results. - Use Case diagrams are used to model user/system interactions. They define behavior, requirements and constraints in the form of scripts or scenarios. - Activity diagrams have a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process. - State Machine diagrams are essential to understanding the instant to instant condition, or "run state" of a model when it executes. - Communication diagrams show the network, and sequence, of messages or communications between objects at run-time, during a collaboration instance. - Sequence diagrams are closely related to communication diagrams and show the sequence of messages passed between objects using a vertical timeline. - Timing diagrams fuse sequence and state diagrams to provide a view of an object's state over time, and messages which modify that state. - Interaction Overview diagrams fuse activity and sequence diagrams to allow interaction fragments to be easily combined with decision points and flows. UML 2 Package Diagram Package Diagrams Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the namespaces. The most common use for package diagrams is to organize use case diagrams and class diagrams, although the use of package diagrams is not limited to these UML elements. The following is an example of a package diagram. Elements contained in a package share the same namespace. Therefore, the elements contained in a specific namespace must have unique names. Packages can be built to represent either physical or logical relationships. When choosing to include classes in specific packages, it is useful to assign the classes with the same inheritance hierarchy to the same package. There is also a strong argument for including classes that are related via composition, and classes that collaborate with them, in the same package. Packages are represented in UML 2.1 as folders and contain the elements that share a namespace; all elements within a package must be identifiable, and so have a unique name or type. The package must show the package name and can optionally show the elements within the package in extra compartments. Package Merge A «merge» connector between two packages defines an implicit generalization between elements in the source package, and elements with the same name in the target package. The source element definitions are expanded to include the element definitions contained in the target. The target element definitions are unaffected, as are the definitions of source package elements that don't match names with any element in the target package. Package Import The «import» connector indicates that the elements within the target package, which in this example is a single class, use unqualified names when being referred to from the source package. The source package's namespace gains access to the target classes; the target's namespace is not affected. Nesting Connectors The nesting connector between the target package and source packages shows that the source package is fully contained in the target package. UML 2 Class Diagram Class Diagrams The class diagram shows the building blocks of any object-orientated system. Class diagrams depict a static view of the model, or part of the model, describing what attributes and behavior it has rather than detailing the methods for achieving operations. Class diagrams are most useful in illustrating relationships between classes and interfaces. Generalizations, aggregations, and associations are all valuable in reflecting inheritance, composition or usage, and connections respectively. The diagram below illustrates aggregation relationships between classes. The lighter aggregation indicates that the class "Account" uses AddressBook, but does not necessarily contain an instance of it. The strong, composite aggregations by the other connectors indicate ownership or containment of the source classes by the target classes, for example Contact and ContactGroup values will be contained in AddressBook. Classes A class is an element that defines the attributes and behaviors that an object is able to generate. The behavior is described by the possible messages the class is able to understand, along with operations that are appropriate for each message. Classes may also have definitions of constraints, tagged values and stereotypes. Class Notation Classes are represented by rectangles which show the name of the class and optionally the name of the operations and attributes. Compartments are used to divide the class name, attributes and operations. In the diagram below the class contains the class name in the topmost compartment, the next compartment details the attributes, with the "center" attribute showing initial values. The final compartment shows the operations setWidth, setLength and setPosition and their parameters. The notation that precedes the attribute, or operation name, indicates the visibility of the element: if the + symbol is used, the attribute, or operation, has a public level of visibility; if a - symbol is used, the attribute, or operation, is private. In addition the # symbol allows an operation, or attribute, to be defined as protected, while the ~ symbol indicates package visibility. Interfaces An interface is a specification of behavior that implementers agree to meet; it is a contract. By realizing an interface, classes are guaranteed to support a required behavior, which allows the system to treat non-related elements in the same way – that is, through the common interface. Interfaces may be drawn in a similar style to a class, with operations specified, as shown below. They may also be drawn as a circle with no explicit operations detailed. When drawn as a circle, realization links to the circle form of notation are drawn without target arrows. Tables Although not a part of the base UML, a table is an example of what can be done with stereotypes. It is drawn with a small table icon in the upper right corner. Table attributes are stereotyped «column». Most tables will have a primary key, being one or more fields that form a unique combination used to access the table, plus a primary key operation which is stereotyped «PK». Some tables will have one or more foreign keys, being one or more fields that together map onto a primary key in a related table, plus a foreign key operation which is stereotyped «FK». Associations An association implies two model elements have a relationship - usually implemented as an instance variable in one class. This connector may include named roles at each end, cardinality, direction and constraints. Association is the general relationship type between elements. For more than two elements, a diamond representation toolbox element can be used as well. When code is generated for class diagrams, named association ends become instance variables in the target class. So, for the example below, "playsFor" will become an instance variable in the "Player" class. Generalizations A generalization is used to indicate inheritance. Drawn from the specific classifier to a general classifier, the generalize implication is that the source inherits the target's characteristics. The following diagram shows a parent class generalizing a child class. Implicitly, an instantiated object of the Circle class will have attributes x_position, y_position and radius and a method display(). Note that the class "Shape" is abstract, shown by the name being italicized. The following diagram shows an equivalent view of the same information. Aggregations Aggregations are used to depict elements which are made up of smaller components. Aggregation relationships are shown by a white diamond-shaped arrowhead pointing towards the target or parent class. A stronger form of aggregation - a composite aggregation - is shown by a black diamond-shaped arrowhead and is used where components can be included in a maximum of one composition at a time. If the parent of a composite aggregation is deleted, usually all of its parts are deleted with it; however a part can be individually removed from a composition without having to delete the entire composition. Compositions are transitive, asymmetric relationships and can be recursive. The following diagram illustrates the difference between weak and strong aggregations. An address book is made up of a multiplicity of contacts and contact groups. A contact group is a virtual grouping of contacts; a contact may be included in more than one contact group. If you delete an address book, all the contacts and contact groups will be deleted too; if you delete a contact group, no contacts will be deleted. Association Classes An association class is a construct that allows an association connection to have operations and attributes. The following example shows that there is more to allocating an employee to a project than making a simple association link between the two classes: the role the employee takes up on the project is a complex entity in its own right and contains detail that does not belong in the employee or project class. For example, an employee may be working on several projects at the same time and have different job titles and security levels on each. Dependencies A dependency is used to model a wide range of dependent relationships between model elements. It would normally be used early in the design process where it is known that there is some kind of link between two elements, but it is too early to know exactly what the relationship is. Later in the design process, dependencies will be stereotyped (stereotypes available include «instantiate», «trace», «import», and others), or replaced with a more specific type of connector. Traces The trace relationship is a specialization of a dependency, linking model elements or sets of elements that represent the same idea across models. Traces are often used to track requirements and model changes. As changes can occur in both directions, the order of this dependency is usually ignored. The relationship's properties can specify the trace mapping, but the trace is usually bi-directional, informal and rarely computable. Realizations The source object implements or realizes the destination. Realizations are used to express traceability and completeness in the model - a business process or requirement is realized by one or more use cases, which are in turn realized by some classes, which in turn are realized by a component, etc. Mapping requirements, classes, etc. across the design of your system, up through the levels of modeling abstraction, ensures the big picture of your system remembers and reflects all the little pictures and details that constrain and define it. A realization is shown as a dashed line with a solid arrowhead. Nestings A nesting is connector that shows the source element is nested within the target element. The following diagram shows the definition of an inner class, although in EA it is more usual to show them by their position in the project view hierarchy. UML 2 Object Diagrams Object Diagrams An object diagram may be considered a special case of a class diagram. Object diagrams use a subset of the elements of a class diagram in order to emphasize the relationship between instances of classes at some point in time. They are useful in understanding class diagrams. They don’t show anything architecturally different to class diagrams, but reflect multiplicity and roles. Class and Object Elements The following diagram shows the differences in appearance between a class element and an object element. Note that the class element consists of three parts, being divided into name, attribute and operation compartments; by default, object elements don’t have compartments. The display of names is also different: object names are underlined and may show the name of the classifier from which the object is instantiated. Run Time State A classifier element can have any number of attributes and operations. These aren’t shown in an object instance. It is possible, however, to define an object’s run time state, showing the set values of attributes in the particular instance. Example Class and Object Diagrams The following diagram shows an object diagram with its defining class diagram inset, and it illustrates the way in which an object diagram may be used to test the multiplicities of assignments in class diagrams. The car class has a 1-to-many multiplicity to the wheel class, but if a 1-to-4 multiplicity had been chosen instead, that wouldn’t have allowed for the t 3-wheeled car shown on left UML 2 Composite Structure Diagram Composite Diagrams A composite structure diagram is a diagram that shows the internal structure of a classifier, including its interaction points to other parts of the system. It shows the configuration and relationship of parts, that together, perform the behavior of the containing classifier. Class elements have been described in great detail in the section on class diagrams. This section describes the way classes can be displayed as composite elements exposing interfaces and containing ports and parts. Part A part is an element that represents a set of one or more instances which are owned by a containing classifier instance. So for example, if a diagram instance owned a set of graphical elements, then the graphical elements could be represented as parts; if it were useful to do so, to model some kind of relationship between them. Note that a part can be removed from its parent before the parent is deleted, so that the part isn't deleted at the same time. A part is shown as an unadorned rectangle contained within the body of a class or component element. Port A port is a typed element that represents an externally visible part of a containing classifier instance. Ports define the interaction between a classifier and its environment. A port can appear on the boundary of a contained part, a class or a composite structure. A port may specify the services a classifier provides as well as the services that it requires of its environment. A port is shown as a named rectangle on the boundary edge of its owning classifier. Interfaces An interface is similar to a class but with a number of restrictions. All interface operations are public and abstract, and do not provide any default implementation. All interface attributes must be constants. However, while a class may only inherit from a single super-class, it may implement multiple interfaces. An interface, when standing alone in a diagram, is either shown as a class element rectangle with the «interface» keyword and with its name italicized to denote it is abstract, or it is shown as a circle. Note that the circle notation does not show the interface operations. When interfaces are shown as being owned by classes, they are referred to as exposed interfaces. An exposed interface can be defined as either provided or required. A provided interface is an affirmation that the containing classifier supplies the operations defined by the named interface element and is defined by drawing a realization link between the class and the interface. A required interface is a statement that the classifier is able to communicate with some other classifier which provides operations defined by the named interface element and is defined by drawing a dependency link between the class and the interface. A provided interface is shown as a "ball on a stick" attached to the edge of a classifier element. A required interface is shown as a "cup on a stick" attached to the edge of a classifier element. Delegate A delegate connector is used for defining the internal workings of a component's external ports and interfaces. A delegate connector is shown as an arrow with a «delegate» keyword. It connects an external contract of a component as shown by its ports to the internal realization of the behavior of the component's part. Collaboration A collaboration defines a set of co-operating roles used collectively to illustrate a specific functionality. A collaboration should only show the roles and attributes required to accomplish its defined task or function. Isolating the primary roles is an exercise in simplifying the structure and clarifying the behavior, and also provides for re-use. A collaboration often implements a pattern. A collaboration element is shown as an ellipse. Role Binding A role binding connector is drawn from a collaboration to the classifier that fulfils the role. It is shown as a dashed line with the name of the role at the classifier end. Represents A represents connector may be drawn from a collaboration to a classifier to show that a collaboration is used in the classifier. It is shown as a dashed line with arrowhead and the keyword «represents». Occurrence An occurrence connector may be drawn from a collaboration to a classifier to show that a collaboration represents (sic) the classifier. It is shown as a dashed line with arrowhead and the keyword «occurrence». UML 2 Component Diagram Component Diagrams Component diagrams illustrate the pieces of software, embedded controllers, etc., that will make up a system. A component diagram has a higher level of abstraction than a Class Diagram - usually a component is implemented by one or more classes (or objects) at runtime. They are building blocks so a component can eventually encompass a large portion of a system. The diagram above demonstrates some components and their inter-relationships. Assembly connectors "link" the provided interfaces supplied by "Product" and "Customer" to the required interfaces specified by "Order". A dependency relationship maps a customer's associated account details to the required interface; "Payment", indicated by "Order". Components are similar in practice to package diagrams, as they define boundaries and are used to group elements into logical structures. The difference between package diagrams and component diagrams is that Component Diagrams offer a more semantically rich grouping mechanism. With component diagrams all of the model elements are private, whereas package diagrams only display public items. Representing Components Components are represented as a rectangular classifier with the keyword «component»; optionally the component may be displayed as a rectangle with a component icon in the right-hand upper corner. Assembly Connector The assembly connector bridges a component’s required interface (Component1) with the provided interface of another component (Component2); this allows one component to provide the services that another component requires. Components with Ports Using Ports with component diagrams allows for a service or behavior to be specified to its environment as well as a service or behavior that a component requires. Ports may specify inputs and outputs as they can operate bi-directionally. The following diagram details a component with a port for online services along with two provided interfaces order entry and tracking as well as a required interface payment. UML 2 Deployment Diagram Deployment Diagrams A deployment diagram models the run-time architecture of a system. It shows the configuration of the hardware elements (nodes) and shows how software elements and artifacts are mapped onto those nodes. Node A Node is either a hardware or software element. It is shown as a three-dimensional box shape, as shown below. Node Instance A node instance can be shown on a diagram. An instance can be distinguished from a node by the fact that its name is underlined and has a colon before its base node type. An instance may or may not have a name before the colon. The following diagram shows a named instance of a computer. Node Stereotypes A number of standard stereotypes are provided for nodes, namely «cdrom», «cd-rom», «computer», «disk array», «pc», «pc client», «pc server», «secure», «server», «storage», «unix server», «user pc». These will display an appropriate icon in the top right corner of the node symbol Artifact An artifact is a product of the software development process. That may include process models (e.g. use case models, design models etc), source files, executables, design documents, test reports, prototypes, user manuals, etc. An artifact is denoted by a rectangle showing the artifact name, the «artifact» keyword and a document icon, as shown below. Association In the context of a deployment diagram, an association represents a communication path between nodes. The following diagram shows a deployment diagram for a network, depicting network protocols as stereotypes, and multiplicities at the association ends. Node as Container A node can contain other elements, such as components or artifacts. The following diagram shows a deployment diagram for part of an embedded system, depicting an executable artifact as being contained by the motherboard node. UML 2 Use Case Diagram Use Case Model The use case model captures the requirements of a system. Use cases are a means of communicating with users and other stakeholders what the system is intended to do. Actors A use case diagram shows the interaction between the system and entities external to the system. These external entities are referred to as actors. Actors represent roles which may include human users, external hardware or other systems. An actor is usually drawn as a named stick figure, or alternatively as a class rectangle with the «actor» keyword. Actors can generalize other actors as detailed in the following diagram: Use Cases A use case is a single unit of meaningful work. It provides a high-level view of behavior observable to someone or something outside the system. The notation for a use case is an ellipse. The notation for using a use case is a connecting line with an optional arrowhead showing the direction of control. The following diagram indicates that the actor "Customer" uses the "Withdraw" use case. The uses connector can optionally have multiplicity values at each end, as in the following diagram, which shows a customer may only have one withdrawal session at a time, but a bank may have any number of customers making withdrawals concurrently. Use Case Definition A use case typically Includes:  Name and description  Requirements  Constraints  Scenarios  Scenario diagrams  Additional information. Name and Description A use case is normally named as a verb-phrase and given a brief informal textual description. Requirements The requirements define the formal functional requirements that a use case must supply to the end user. They correspond to the functional specifications found in structured methodologies. A requirement is a contract or promise that the use case will perform an action or provide some value to the system. Constraints A constraint is a condition or restriction that a use case operates under and includes pre-, post- and invariant conditions. A precondition specifies the conditions that need to be met before the use case can proceed. A post-condition is used to document the change in conditions that must be true after the execution of the use case. An invariant condition specifies the conditions that are true throughout the execution of the use case. Scenarios A Scenario is a formal description of the flow of events that occur during the execution of a use case instance. It defines the specific sequence of events between the system and the external actors. It is normally described in text and corresponds to the textual representation of the sequence diagram. Including Use Cases Use cases may contain the functionality of another use case as part of their normal processing. In general it is assumed that any included use case will be called every time the basic path is run. An example of this is to have the execution of the use case to be run as part of a use case . Use Cases may be included by one or more Use Case, helping to reduce the level of duplication of functionality by factoring out common behavior into Use Cases that are re-used many times. Extending Use Cases One use case may be used to extend the behavior of another; this is typically used in exceptional circumstances. For example, if before modifying a particular type of customer order, a user must get approval from some higher authority, then the use case may optionally extend the regular use case. Extension Points The point at which an extending use case is added can be defined by means of an extension point. System Boundary It is usual to display use cases as being inside the system and actors as being outside the system. UML 2 Activity Diagram Activity Diagrams In UML, an activity diagram is used to display the sequence of activities. Activity diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity. They may be used to detail situations where parallel processing may occur in the execution of some activities. Activity diagrams are useful for business modelling where they are used for detailing the processes involved in business activities. An Example of an activity diagram is shown below. The following sections describe the elements that constitute an activity diagram. Activities An activity is the specification of a parameterized sequence of behaviour. An activity is shown as a round-cornered rectangle enclosing all the actions, control flows and other elements that make up the activity. Actions An action represents a single step within an activity. Actions are denoted by round-cornered rectangles. Action Constraints Constraints can be attached to an action. The following diagram shows an action with local pre- and post-conditions. Control Flow A control flow shows the flow of control from one action to the next. Its notation is a line with an arrowhead. Initial Node An initial or start node is depicted by a large black spot, as shown below. Final Node There are two types of final node: activity and flow final nodes. The activity final node is depicted as a circle with a dot inside. The flow final node is depicted as a circle with a cross inside. The difference between the two node types is that the flow final node denotes the end of a single control flow; the activity final node denotes the end of all control flows within the activity. Objects and Object Flows An object flow is a path along which objects or data can pass. An object is shown as a rectangle. An object flow is shown as a connector with an arrowhead denoting the direction the object is being passed. An object flow must have an object on at least one of its ends. A shorthand notation for the above diagram would be to use input and output pins. A data store is shown as an object with the «datastore» keyword. Decision and Merge Nodes Decision nodes and merge nodes have the same notation: a diamond shape. They can both be named. The control flows coming away from a decision node will have guard conditions which will allow control to flow if the guard condition is met. The following diagram shows use of a decision node and a merge node. Fork and Join Nodes Forks and joins have the same notation: either a horizontal or vertical bar (the orientation is dependent on whether the control flow is running left to right or top to bottom). They indicate the start and end of concurrent threads of control. The following diagram shows an example of their use. A join is different from a merge in that the join synchronizes two inflows and produces a single outflow. The outflow from a join cannot execute until all inflows have been received. A merge passes any control flows straight through it. If two or more inflows are received by a merge symbol, the action pointed to by its outflow is executed two or more times. Expansion Region An expansion region is a structured activity region that executes multiple times. Input and output expansion nodes are drawn as a group of three boxes representing a multiple selection of items. The keyword "iterative", "parallel" or "stream" is shown in the top left corner of the region. Exception Handlers Exception Handlers can be modelled on activity diagrams as in the example below. Interruptible Activity Region An interruptible activity region surrounds a group of actions that can be interrupted. In the very simple example below, the "Process Order" action will execute until completion, when it will pass control to the "Close Order" action, unless a "Cancel Request" interrupt is received, which will pass control to the "Cancel Order" action. Partition An activity partition is shown as either a horizontal or vertical swimlane. In the following diagram, the partitions are used to separate actions within an activity into those performed by the accounting department and those performed by the customer. UML 2 State Machine Diagram State Machine Diagrams A state machine diagram models the behaviour of a single object, specifying the sequence of events that an object goes through during its lifetime in response to events. As an example, the following state machine diagram shows the states that a door goes through during its lifetime. The door can be in one of three states: "Opened", "Closed" or "Locked". It can respond to the events Open, Close, Lock and Unlock. Notice that not all events are valid in all states; for example, if a door is opened, you cannot lock it until you close it. Also notice that a state transition can have a guard condition attached: if the door is Opened, it can only respond to the Close event if the condition doorWay->isEmpty is fulfilled. The syntax and conventions used in state machine diagrams will be discussed in full in the following sections. States A state is denoted by a round-cornered rectangle with the name of the state written inside it. Initial and Final States The initial state is denoted by a filled black circle and may be labeled with a name. The final state is denoted by a circle with a dot inside and may also be labeled with a name. Transitions Transitions from one state to the next are denoted by lines with arrowheads. A transition may have a trigger, a guard and an effect, as below. "Trigger" is the cause of the transition, which could be a signal, an event, a change in some condition, or the passage of time. "Guard" is a condition which must be true in order for the trigger to cause the transition. "Effect" is an action which will be invoked directly on the object that owns the state machine as a result of the transition. State Actions In the transition example above, an effect was associated with the transition. If the target state had many transitions arriving at it, and each transition had the same effect associated with it, it would be better to associate the effect with the target state rather than the transitions. This can be done by defining an entry action for the state. The diagram below shows a state with an entry action and an exit action. It is also possible to define actions that occur on events, or actions that always occur. It is possible to define any number of actions of each type. Self-Transitions A state can have a transition that returns to itself, as in the following diagram. This is most useful when an effect is associated with the transition. Compound States A state machine diagram may include sub-machine diagrams, as in the example below. The alternative way to show the same information is as follows. The notation in the above version indicates that the details of the Check PIN sub-machine are shown in a separate diagram. Entry Point Sometimes you won’t want to enter a sub-machine at the normal initial state. For example, in the following sub-machine it would be normal to begin in the "Initializing" state, but if for some reason it wasn’t necessary to perform the initialization, it would be possible to begin in the "Ready" state by transitioning to the named entry point. The following diagram shows the state machine one level up. Exit Point In a similar manner to entry points, it is possible to have named alternative exit points. The following diagram gives an example where the state executed after the main processing state depends on which route is used to transition out of the state. Choice Pseudo-State A choice pseudo-state is shown as a diamond with one transition arriving and two or more transitions leaving. The following diagram shows that whichever state is arrived at, after the choice pseudo-state, is dependent on the message format selected during execution of the previous state. Junction Pseudo-State Junction pseudo-states are used to chain together multiple transitions. A single junction can have one or more incoming, and one or more outgoing, transitions; a guard can be applied to each transition. Junctions are semantic-free. A junction which splits an incoming transition into multiple outgoing transitions realizes a static conditional branch, as opposed to a choice pseudo-state which realizes a dynamic conditional branch. Terminate Pseudo-State Entering a terminate pseudo-state indicates that the lifeline of the state machine has ended. A terminate pseudo-state is notated as a cross. History States A history state is used to remember the previous state of a state machine when it was interrupted. The following diagram illustrates the use of history states. The example is a state machine belonging to a washing machine. In this state machine, when a washing machine is running, it will progress from "Washing" through "Rinsing" to "Spinning". If there is a power cut, the washing machine will stop running and will go to the "Power Off" state. Then when the power is restored, the Running state is entered at the "History State" symbol meaning that it should resume where it last left-off. Concurrent Regions A state may be divided into regions containing sub-states that exist and execute concurrently. The example below shows that within the state "Applying Brakes", the front and rear brakes will be operating simultaneously and independently. Notice the use of fork and join pseudo-states, rather than choice and merge pseudo-states. These symbols are used to synchronize the concurrent threads. UML 2 Communication Diagram Communication Diagrams A communication diagram, formerly called a collaboration diagram, is an interaction diagram that shows similar information to sequence diagrams but its primary focus is on object relationships. On communication diagrams, objects are shown with association connectors between them. Messages are added to the associations and show as short arrows pointing in the direction of the message flow. The sequence of messages is shown through a numbering scheme. The following two diagrams show a communication diagram and the sequence diagram that shows the same information. Although it is possible to derive the sequencing of messages in the communication diagram from the numbering scheme, it isn’t immediately visible. What the communication diagram does show quite clearly though, is the full set of messages passed between adjacent objects. UML 2 Sequence Diagram Sequence Diagrams A sequence diagram is a form of interaction diagram which shows objects as lifelines running down the page, with their interactions over time represented as messages drawn as arrows from the source lifeline to the target lifeline. Sequence diagrams are good at showing which objects communicate with which other objects; and what messages trigger those communications. Sequence diagrams are not intended for showing complex procedural logic. Lifelines A lifeline represents an individual participant in a sequence diagram. A lifeline will usually have a rectangle containing its object name. If its name is "self", that indicates that the lifeline represents the classifier which owns the sequence diagram. Sometimes a sequence diagram will have a lifeline with an actor element symbol at its head. This will usually be the case if the sequence diagram is owned by a use case. Boundary, control and entity elements from robustness diagrams can also own lifelines. Messages Messages are displayed as arrows. Messages can be complete, lost or found; synchronous or asynchronous; call or signal. In the following diagram, the first message is a synchronous message (denoted by the solid arrowhead) complete with an implicit return message; the second message is asynchronous (denoted by line arrowhead), and the third is the asynchronous return message (denoted by the dashed line). Execution Occurrence A thin rectangle running down the lifeline denotes the execution occurrence, or activation of a focus of control. In the previous diagram, there are three execution occurrences. The first is the source object sending two messages and receiving two replies; the second is the target object receiving a synchronous message and returning a reply; and the third is the target object receiving an asynchronous message and returning a reply. Self Message A self message can represent a recursive call of an operation, or one method calling another method belonging to the same object. It is shown as creating a nested focus of control in the lifeline’s execution occurrence. Lost and Found Messages Lost messages are those that are either sent but do not arrive at the intended recipient, or which go to a recipient not shown on the current diagram. Found messages are those that arrive from an unknown sender, or from a sender not shown on the current diagram. They are denoted going to or coming from an endpoint element. Lifeline Start and End A lifeline may be created or destroyed during the timescale represented by a sequence diagram. In the latter case, the lifeline is terminated by a stop symbol, represented as a cross. In the former case, the symbol at the head of the lifeline is shown at a lower level down the page than the symbol of the object that caused the creation. The following diagram shows an object being created and destroyed. Duration and Time Constraints By default, a message is shown as a horizontal line. Since the lifeline represents the passage of time down the screen, when modelling a real-time system, or even a time-bound business process, it can be important to consider the length of time it takes to perform actions. By setting a duration constraint for a message, the message will be shown as a sloping line. Combined Fragments It was stated earlier that sequence diagrams are not intended for showing complex procedural logic. While this is the case, there are a number of mechanisms that do allow for adding a degree of procedural logic to diagrams and which come under the heading of combined fragments. A combined fragment is one or more processing sequence enclosed in a frame and executed under specific named circumstances. The fragments available are:  Alternative fragment (denoted “alt”) models if…then…else constructs.  Option fragment (denoted “opt”) models switch constructs.  Break fragment models an alternative sequence of events that is processed instead of the whole of the rest of the diagram.  Parallel fragment (denoted “par”) models concurrent processing.  Weak sequencing fragment (denoted “seq”) encloses a number of sequences for which all the messages must be processed in a preceding segment before the following segment can start, but which does not impose any sequencing within a segment on messages that don’t share a lifeline.  Strict sequencing fragment (denoted “strict”) encloses a series of messages which must be processed in the given order.  Negative fragment (denoted “neg”) encloses an invalid series of messages.  Critical fragment encloses a critical section.  Ignore fragment declares a message or message to be of no interest if it appears in the current context.  Consider fragment is in effect the opposite of the ignore fragment: any message not included in the consider fragment should be ignored.  Assertion fragment (denoted “assert”) designates that any sequence not shown as an operand of the assertion is invalid.  Loop fragment encloses a series of messages which are repeated. The following diagram shows a loop fragment. There is also an interaction occurrence, which is similar to a combined fragment. An interaction occurrence is a reference to another diagram which has the word "ref" in the top left corner of the frame, and has the name of the referenced diagram shown in the middle of the frame. Gate A gate is a connection point for connecting a message inside a fragment with a message outside a fragment. EA shows a gate as a small square on a fragment frame. Diagram gates act as off-page connectors for sequence diagrams, representing the source of incoming messages or the target of outgoing messages. The following two diagrams show how they might be used in practice. Note that the gate on the top level diagram is the point at which the message arrowhead touches the reference fragment - there is no need to render it as a box shape. Part Decomposition An object can have more than one lifeline coming from it. This allows for inter- and intra-object messages to be displayed on the same diagram. State Invariant / Continuations A state invariant is a constraint placed on a lifeline that must be true at run-time. It is shown as a rectangle with semi-circular ends. A continuation has the same notation as a state invariant, but is used in combined fragments and can stretch across more than one lifeline. UML 2 Timing Diagram Timing Diagrams UML timing diagrams are used to display the change in state or value of one or more elements over time. It can also show the interaction between timed events and the time and duration constraints that govern them. State Lifeline A state lifeline shows the change of state of an item over time. The X-axis displays elapsed time in whatever units are chosen, while the Y-axis is labelled with a given list of states. A state lifeline is shown below. Value Lifeline A value lifeline shows the change of value of an item over time. The X-axis displays elapsed time in whatever units are chosen, the same as for the state lifeline. The value is shown between the pair of horizontal lines which cross over at each change in value. A value lifeline is shown below. Putting it all Together State and value Lifelines can be stacked one on top of another in any combination. They must have the same X-axis. Messages can be passed from one lifeline to another. Each state or value transition can have a defined event, a time constraint which indicates when an event must occur, and a duration constraint which indicates how long a state or value must be in effect for. Once these have all been applied, a timing diagram may look like the following. UML 2 Interaction Overview Diagram Interaction Overview Diagrams An interaction overview diagram is a form of activity diagram in which the nodes represent interaction diagrams. Interaction diagrams can include sequence, communication, interaction overview and timing diagrams. Most of the notation for interaction overview diagrams is the same for activity diagrams. For example, initial, final, decision, merge, fork and join nodes are all the same. However, interaction overview diagrams introduce two new elements: interaction occurrences and interaction elements. Interaction Occurrence Interaction occurrences are references to existing interaction diagrams. An interaction occurrence is shown as a reference frame; that is, a frame with "ref" in the top-left corner. The name of the diagram being referenced is shown in the center of the frame. Interaction Element Interaction elements are similar to interaction occurrences, in that they display a representation of existing interaction diagrams within a rectangular frame. They differ in that they display the contents of the references diagram inline. Putting it all Together All the same controls from activity diagrams (fork, join, merge, etc.) can be used on interaction overview diagrams to put the control logic around the lower level diagrams. The following example depicts a sample sale process, with sub-processes abstracted within interaction occurrences. Modeling Tools for Software Development and Engineering “Software Development is a complex and often difficult process requiring the synthesis of many disciplines. From modeling and design to code generation, project management, testing, deployment, change management and beyond, a UML based modeling tool like Enterprise Architect has become an essential part of managing that complexity.” If you need to:  Manage Requirements  Enhance your software modeling  Model and analyze business processes  Build design and behavioral models  Generate and import source code in a variety of languages  Generate and import database schema  Generate and import XSD  Create component and deployment models  Track changes  Manage tests  Confirm traceability from requirements through to deployment  Document your software development  Communicate and develop team based software engineering projects  Rapid modeling/engineering of your software's development Then Enterprise Architect has the power and features you need! Code Editing in EA Custom Tags Eclipse Link Database Modeling Software development has come a long way in the last decade, and modeling tools form an important component of today's development environment. Demands on the industry have increased many times over, particularly in the areas of robustness, portability and reusability, and by harnessing the power of UML 2.1 and MDA technologies you can keep up with those demands. Languages The UML is primarily a language for describing object-oriented systems independent of any specific programming language. It is simple to learn, yet highly flexible, and consistent from planning to deployment. Benefits of using UML include enhanced traceability, intelligibility among users and greatly simplified maintainability. Enterprise Architect supports UML 2.1 standard, and Sparx Systems have available customisable extensions to the UML for the purposes of modeling Business Processes, XSD Schema and more. The MDA framework enhances the UML's capabilities by providing model-to-model transformations, giving you the ability to maintain platform-independent models of a system, and to generate and maintain synchronized platform-specific models, across a variety of platforms concurrently. Methodologies There are a great range of development practices, for instance methods like the Unified Process and Agile Development. No particular practice is the best, as requirements can vary greatly from project to project, which is why EA facilitates a broad range of methodologies. The Role of Enterprise Architect plays in Software Engineering The goal of Enterprise Architect is to bring all these elements together in an environment that is both coherent and flexible. Comprehensive support for UML 2.1 notation combines with process management tools that let you decide on a software development methodology. Enterprise Architect supports the full range of UML 2.1 diagrams, enabling you to model almost any system, from web applications to embedded systems. Generation of UML Diagrams is quick and easy, and the graphics engine produces crisp, highly readable diagrams. The project browser makes navigating the documents. Combine MDA Transforms with the Code Generation features of EA Professional and Corporate editions and you have a powerful workspace in which to plan, software models a simple affair, and EA's comprehensive documentation features enable you to easily generate, customize, and maintain complete system model and realize complex systems. The optional MDG Links provide the potential to integrate directly with Visual Studio .NET or Eclipse for a complete development solution, making it a very effective software modeling tool. The Use Case Model A Use Case Model describes the proposed functionality of a new system. A Use Case 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 Create Account or View Account Details. Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behavior. A Use Case description will generally includes:  General comments and notes describing the use case.  Requirements - The formal functional requirements of things that a Use Case must provide to the end user, such as . These correspond to the functional specifications found in structured methodologies, and form a contract that the Use Case performs some action or provides some value to the system.  Constraints - The formal rules and limitations a Use Case operates under, defining what can and cannot be done. These include: o Pre-conditions that must have already occurred or be in place before the use case is run; for example, must precede o o Post-conditions that must be true once the Use Case is complete; for example, Invariants that must always be true throughout the time the Use Case 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 Case 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 Cases 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 Cases 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 Case could include the functionality of another as part of its normal processing. Generally, it is assumed that the included Use Case 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 Use Case would be included every time the Use Case is run. A Use Case can be included by one or more other Use Cases, so it helps to reduce duplication of functionality by factoring out common behavior into Use Cases that are re-used many times. One Use Case 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 Use Case could optionally extend the regular Use Case. 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 Case '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 Case scenario. The messages that pass between objects become class operations in the final model. Implementation Diagram A Use Case is a formal description of functionality that the system will have when constructed. An implementation diagram is typically associated with a Use Case to document which design elements (for example, components and classes) implement the Use Case 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 Cases 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. Business Process Modelling 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 Ericsson-Penker 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. Flow Elements 1. 2. Activities. An activity is work that is performed within a business process and is represented by a rounded rectangle. 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. 2. 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. 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. Swimlanes (Partitions) 1. 2. 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. Lanes. A lane is a sub-division of a pool and is used to organize and categorize activities within the pool. Artifacts 1. 2. 3. 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. Groups. A group is an informal means for grouping elements of a process. It is represented as a rectangle with a dashed line border. 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. BPMN Examples Example 1: 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. 2. Has a Goal Has specific inputs 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 Creates value of some kind for the customer. The customer may be internal or external. Process Models 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 and outputs: 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.  Supply 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. Goal 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. Information 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. Resource 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). Database Modeling in UML Introduction When it comes to providing reliable, flexible and efficient object persistence for software systems, today's designers and architects are faced with many choices. From the technological perspective, the choice is usually between pure Object-Oriented, Object-Relational hybrids, pure Relational and custom solutions based on open or proprietary file formats (eg. XML, OLE structured storage). From the vendor aspect Oracle, IBM, Microsoft, POET and others offer similar but often-incompatible solutions. This article is about only one of those choices, that is the layering of an object-oriented class model on top of a purely relational database. This is not to imply this is the only, best or simplest solution, but pragmatically it is one of the most common, and one that has the potential for the most misuse. We will begin with a quick tour of the two design domains we are trying to bridge: firstly the object-oriented class model as represented in the UML, and secondly the relational database model. For each domain we look only at the main features that will affect our task. We will then look at the techniques and issues involved in mapping from the class model to the database model, including object persistence, object behaviour, relationships between objects and object identity. We will conclude with a review of the UML Data Profile (as proposed by Rational Software). Some familiarity with object-oriented design, UML and relational database modelling is assumed. The Class Model in the UML is the main artefact produced to represent the logical structure of a software system. It captures the both the data requirements and the behaviour of objects within the model domain. The techniques for discovering and elaborating that model are outside the scope of this article, so we will assume the existence of a well designed class model that requires mapping onto a relational database. The Class Model The class is the basic logical entity in the UML. It defines both the data and the behaviour of a structural unit. A class is a template or model from which instances or objects are created at run time. When we develop a logical model such as a structural hierarchy in UML we explicitly deal with classes. When we work with dynamic diagrams, such as sequence diagrams and collaborations, we work with objects or instances of classes and their inter-actions at run-time. The principal of data hiding or encapsulation is based on localisation of effect. A class has internal data elements that it is responsible for. Access to these data elements should be through the class's exposed behaviour or interface. Adherence to this principal results in more maintainable code. Behaviour Behaviour is captured in the class model using the operations that are defined for the class. Operations may be externally visible (public), visible to children (protected) or hidden (private). By combining hidden data with a publicly accessible interface and hidden or protected data manipulation, a class designer can create highly maintainable structural units that support rather than hinder change. Relationships and Identity Association is a relationship between 2 classes indicating that at least one side of the relationship knows about and somehow uses or manipulates the other side. This relationship may by functional (do something for me) or structural (be something for me). For this article it is the structural relationship that is most interesting: for example an Address class may be associated with a Person class. The mapping of this relationship into the relational data space requires some care. Aggregation is a form of association that implies the collection of one class of objects within another. Composition is a stronger form of aggregation that implies one object is actually composed of others. Like the association relationship, this implies a complex class attribute that requires careful consideration in the process of mapping to the relational domain. While a class represents the template or model from which many object instances may be created, an object at run time requires some means of identifying itself such that associated objects may act upon the correct object instance. In a programming language like C++, object pointers may be passed around and held to allow objects access to a unique object instance. Often though, an object will be destroyed and require that it be re-created as it was during its last active instance. These objects require a storage mechanism to save their internal state and associations into and to retrieve that state as required. Inheritance provides the class model with a means of factoring out common behaviour into generalised classes that then act as the ancestors of many variations on a common theme. Inheritance is a means of managing both re-use and complexity. As we will see, the relational model has no direct counterpart of inheritance, which creates a dilemma for the data modeller mapping an object model onto a relational framework. Navigation from one object at run time to another is based on absolute references. One object has some form of link (a pointer or unique object ID) with which to locate or re-create the required object. The Relational Model The relational data model has been around for many years and has a proven track record of providing performance and flexibility. It is essentially set based and has as its fundamental unit the 'table', which is composed of a set of one or more 'columns', each of which contains a data element. Tables and Columns: a relational table is collection of one or more columns each of which has a unique name within the table construct. Each column is defined to be of a certain basic data type, such as a number, text or binary data. A table definition is a template from which table rows are created, each row being an instance of a possible table instance. The relational model only offers a public data access model. All data is equally exposed and open to any process to update, query or manipulate it. Information hiding is unknown. Behaviour The behaviour associated with a table is usually based on the business or logical rules applied to that entity. Constraints may be applied to columns in the form of uniqueness requirements, relational integrity constraints to other tables/rows, allowable values and data types. Triggers provide some additional behaviour that can be associated with an entity. Typically this is used to enforce data integrity before or after updates, inserts and deletes. Database stored procedures provide a means of extending database functionality through proprietary language extensions used to construct functional units (scripts). These functional procedures do not map directly to entities, nor have a logical relationship to them. Navigation through relational data sets is based on row traversal and table joins. SQL is the primary language used to select rows and locate instances from a table set. Relationships and Identity The primary key of a table provides the unique identifying value for a particular row. There are two kinds of primary key that we are interested in: firstly the meaningful key, made up of data columns which have a meaning within the business domain, and second the abstract unique identifier, such as a counter value, which have no business meaning but uniquely identify a row. We will discuss this and the implications of meaningful keys later. A table may contain columns that map to the primary key of another table. This relationship between tables defines a foreign key and implies a structural relationship or association between the two tables. Summary From the above overview we can see that the object model is based on discrete entities having both state (attributes/data) and behaviour, with access to the encapsulated data generally through the class public interface only. The relational model exposes all data equally, with limited support for associating behaviour with data elements through triggers, indexes and constraints. You navigate to distinct information in the object model by moving from object to object using unique object identifiers and established object relationships (similar to a network data model). In the relational model you find rows by joining and filtering result sets using SQL using generalised search criteria. Identity in the object model is either a run-time reference or persistent unique ID (termed an OID). In the relational world, primary keys define the uniqueness of a data set in the overall data space. In the object model we have a rich set of relationships: inheritance, aggregation, association, composition, dependency and others. In the relational model we can really only specify a relationship using foreign keys. Having looked at the two domains of interest and compared some of the important features of each, we will digress briefly to look at the notation proposed to represent relational data models in the UML. The UML Data Model Profile The Data Model Profile is a proposed UML extension (and currently under review - Jan 2001) to support the modelling of relational databases in UML. It includes custom extensions for such things as tables, data base schema, table keys, triggers and constraints. While this is not a ratified extension, it still illustrates one possible technique for modelling a relational database in the UML. Tables & Columns A table in the UML Data Profile is a class with the «Table» stereotype, displayed as above with a table icon in the top right corner. Database columns are modelled as attributes of the «Table» class. For example, the figure above shows some attributes associated with the Customer table. In the example, an object id has been defined as the primary key, as well as two other columns, Name and Address. Note that the example above defines the column type in terms of the native DBMS data types. Behaviour So far we have only defines the logical (static) structure of the table; in addition we should describe the behaviour associated with columns, including indexes, keys, triggers, procedures & etc. Behaviour is represented as stereotyped operations. The figure below shows our table above with a primary key constraint and index, both defined as stereotyped operations: Note that the PK flag on the column 'OID' defines the logical primary key, while the stereotyped operation "«PK» idx_customer00" defines the constraints and behaviour associated with the primary key implementation (that is, the behaviour of the primary key). Adding to our example, we may now define additional behaviour such as triggers, constraints and stored procedures as in the example below: The example illustrates the following possible behaviour: 1. A primary key constraint (PK); 2. A Foreign key constraint (FK); 3. An index constraint (Index); 4. A trigger (Trigger); 5. A uniqueness constraint (Unique); 6. A stored procedure (Proc) - not formally part of the data profile, but an example of a possible modelling technique; and a 7. Validity check (Check). Using the notation provided above, it is possible to model complex data structures and behaviour at the DBMS level. In addition to this, the UML provides the notation to express relationships between logical entities. Relationships The UML data modelling profile defines a relationship as a dependency of any kind between two tables. It is represented as a stereotyped association and includes a set of primary and foreign keys. The data profile goes on to require that a relationship always involves a parent and child, the parent defining a primary key and the child implementing a foreign key based on all or part of the parent primary key. The relationship is termed 'identifying' if the child foreign key includes all the elements of the parent primary key and 'non-identifying' if only some elements of the primary key are included. The relationship may include cardinality constraints and be modelled with the relevant PK - FK pair named as association roles. The illustration below illustrates this kind of relationship modelling using UML. The Physical Model UML also provides some mechanisms for representing the overall physical structure of the database, its contents and deployed location. To represent a physical database in UML, use a stereotyped component as in the figure below: A component represents a discrete and deployable entity within the model. In the physical model, a component may be mapped on to a physical piece of hardware (a 'node' in UML). To represent schema within the database, use the «schema» stereotype on a package. A table may be placed in a «schema» to establish its scope and location within a database. Mapping from the Class Model to the Relational Model Having described the two domains of interest and the notation to be used, we can now turn our attention as to how to map or translate from one domain to the other. The strategy and sequence presented below is meant to be suggestive rather than proscriptive - adapt the steps and procedures to your personal requirements and environment. 1. Model Classes Firstly we will assume we are engineering a new relational database schema from a class model we have created. This is obviously the easiest direction as the models remain under our control and we can optimise the relational data model to the class model. In the real world it may be that you need to layer a class model on top of a legacy data model - a more difficult situation and one that presents its own challenges. For the current discussion will focus on the first situation. At a minimum, your class model should capture associations, inheritance and aggregation between elements. 2. Identify persistent objects Having built our class model we need to separate it into those elements that require persistence and those that do not. For example, if we have designed our application using the Model-View-Controller design pattern, then only classes in the model section would require persistent state. 3. Assume each persistent class maps to one relational table A fairly big assumption, but one that works in most cases (leaving the inheritance issue aside for the moment). In the simplest model a class from the logical model maps to a relational table, either in whole or in part. The logical extension of this is that a single object (or instance of a class) maps to a single table row. 4. Select an inheritance strategy. Inheritance is perhaps the most problematic relationship and logical construct from the object-oriented model that requires translating into the relational model. The relational space is essentially flat, every entity being complete in its self, while the object model is often quite deep with a well-developed class hierarchy. The deep class model may have many layers of inherited attributes and behaviour, resulting in a final, fully featured object at run-time. There are three basic ways to handle the translation of inheritance to a relational model: a. Each class hierarchy has a single corresponding table that contains all the inherited attributes for all elements - this table is therefore the union of every class in the hierarchy. For example, Person, Parent, Child and Grandchild may all form a single class hierarchy, and elements from each will appear in the same relational table; b. Each class in the hierarchy has a corresponding table of only the attributes accessible by that class (including inherited attributes). For example, if Child is inherited from Person only, then the table will contain elements of Person and Child only; c. Each generation in the class hierarchy has a table containing only that generation's actual attributes. For example, Child will map to a single table with Child attributes only There are cases to be made for each approach, but I would suggest the simplest, easiest to maintain and less error prone is the third option. The first option provides the best performance at run-time and the second is a compromise between the first and last. The first option flattens the hierarchy and locates all attributes in one table - convenient for updates and retrievals of any class in the hierarchy, but difficult to authenticate and maintain. Business rules associated with a row are hard to implement, as each row may be instantiated as any object in the hierarchy. The dependencies between columns can become quite complicated. In addition, an update to any class in the hierarchy will potentially impact every other class in the hierarchy, as columns are added, deleted or modified from the table. The second option is a compromise that provides better encapsulation and eliminates empty columns. However, a change to a parent class may need to be replicated in many child tables. Even worse, the parental data in two or more child classes may be redundantly stored in many tables; if a parent's attributes are modified, there is considerable effort in locating dependent children and updating the affected rows. The third option more accurately reflects the object model, with each class in the hierarchy mapped to its own independent table. Updates to parents or children are localised in the correct space. Maintenance is also relatively easier, as any modification of an entity is restricted to a single relational table also. The down side is the need to re-construct the hierarchy at run-time to accurately re-create a child class's state. A Child object may require a Person member variable to represent their model parentage. As both require loading, two database calls are required to initialise one object. As the hierarchy deepens, with more generations, the number of database calls required to initialise or update a single object increases. It is important to understand the issues that arise when you map inheritance onto a relational model, so you can decide which solution is right for you. 5. For each class add a unique object identifier In both the relational and the object world, there is the need to uniquely identify an object or entity. In the object model, non-persistent objects at run-time are typically identified by direct reference or by a pointer to the object. Once an object is created, we can refer to it by its run-time identity. However, if we write out an object to storage, the problem is how to retrieve the exact same instance on demand. The most convenient method is to define an OID (object identifier) that is guaranteed to be unique in the namespace of interest. This may be at the class, package or system level, depending on actual requirements. An example of a system level OID might be a GUID (globally unique identifier) created with Microsoft's 'guidgen' tool; eg. {A1A68E8E-CD92-420b-BDA7-118F847B71EB}. A class level OID might be implemented using a simple numeric (eg. 32 bit counter). If an object holds references to other objects, it may do so using their OID. A complete run-time scenario can then be loaded from storage reasonably efficiently. An important point about the OID values above is that they have no inherent meaning beyond simple identity. They are only logical pointers and nothing more. In the relational model, the situation is often quite different. Identity in the relational model is normally implemented with a primary key. A primary key is a set of columns in a table that together uniquely identify a row. For example, name and address may uniquely identify a 'Customer'. Where other entities, such as a 'Salesperson', reference the 'Customer', they implement a foreign key based on the 'Customer' primary key. The problem with this approach for our purposes is the impact of having business information (such as customer name and address) embedded in the identifier. Imagine three or four tables all have foreign keys based on the customer primary key, and a system change requires the customer primary key to change (for example to include 'customer type'). The work required to modify both the 'customer' table and the entities related by foreign key is quite large. On the other hand, if an OID was implemented as the primary key and formed the foreign key for other tables, the scope of the change is limited to the primary table and the impact of the change is therefore much less. Also, in practice, a primary key based on business data may be subject to change. For example a customer may change address or name. In this case the changes must be propagated correctly to all other related entities, not to mention the difficulty of changing information that is part of the primary key. An OID always refers to the same entity - no matter what other information changes. In the above example, a customer may change name or address and the related tables require no change. When mapping object models into relational tables, it is often more convenient to implement absolute identity using OID's rather than business related primary keys. The OID as primary and foreign key approach will usually give better load and update times for objects and minimise maintenance effort. In practice, a business related primary key might be replaced with: 1. A uniqueness constraint or index on the columns concerned; 2. Business rules embedded in the class behaviour; 3. A combination of 1 and 2. Again, the decision to use meaningful keys or OID's will depend on the exact requirements of the system being developed. 6. Map attributes to columns In general we will map the simple data attributes of a class to columns in the relational table. For example a text and number field may represent a person's name and age respectively. This sort of direct mapping should pose no problem - simply select the appropriate data type in the vendor's relational model to host your class attribute. For complex attributes (ie. attributes that are other objects) use the approach detailed below for handling associations and aggregation. 7. Map associations to foreign keys More complex class attributes (ie. those which represent other classes), are usually modelled as associations. An association is a structural relationship between objects. For example, a Person may live at an Address. While this could be modelled as a Person has City, Street and Zip attributes, in both the object and the relational world we are inclined to structure this information as a separate entity, an Address. In the object domain an address represents a unique physical object, possibly with a unique OID. In the relational, an address may be a row in an Address table, with other entities having a foreign key to the Address primary key. In both models then, there is the tendency to move the address information into a separate entity. This helps to avoid redundant data and improves maintainability. So for each association in the class model, consider creating a foreign key from the child to the parent table. 8. Map Aggregation and Composition Aggregation and composition relationships are similar to the association relationship and map to tables related by primary-foreign key pairs. There are however, some points to bear in mind. Ordinary aggregation (the weak form) models relationships such as a Person resides at one or more Addresses. In this instance, more than one person could live at the same address, and if the Person ceased to exist, the Addresses associated with them would still exist. This example parallels the many-to-many relationship in relational terminology, and is usually implemented as a separate table containing a mapping of primary keys from one table to the primary keys of another. A second example of the weak form of aggregation is where an entity has use or exclusive ownership of another. For example, a Person entity aggregates a set of shares. This implies a Person may be associated with zero or more shares from a Share table, but each Share may be associated with zero or one Person. If the Person ceases to exist, the Shares become un-owned or are passed to another Person. In the relational world, this could be implemented as each Share having an 'owner' column which stored a Person ID (or OID) . The strong form of aggregation, however, has important integrity constraints associated with it. Composition, implies that an entity is composed of parts, and those parts have a dependent relationship to the whole. For example, a Person may have identifying documents such as a Passport, Birth Certificate, Driver's License & etc. A Person entity may be composed of the set of such identifying documents. If the Person is deleted from the system, then the identifying documents must be deleted also, as they are mapped to a unique individual. If we ignore the OID issue for the moment, a weak aggregation could be implemented using either an intermediate table (for the many-to-many case) or with a foreign key in the aggregated class/table (one-to-many case). In the case of the many-to-many relationship, if the parent is deleted, the entries in the intermediate table for that entity must also be deleted also. In the case of the one-to-many relationship, if the parent is deleted, the foreign key entry (ie. 'owner') must be cleared. In the case of composition, the use of a foreign key is mandatory, with the added constraint that on deletion of the parent the part must be deleted also. Logically there is also the implication with composition that the primary key of the part forms part of the primary key of the whole - for example, a Person's primary key may composed of their identifying documents ID's. In practice this would be cumbersome, but the logical relationship holds true. 9. Define relationship roles For each association type relationship, each end of the relationship may be further specified with role information. Typically, you will include the Primary Key constraint name and the Foreign Key Constraint name. Figure 6 illustrates this concept. This logically defines the relationship between the two classes. In addition, you may specify additional constraints (eg. {Not NULL}) on the role and cardinality constraints (eg. 0..n). 10. Model behaviour We now come to another difficult issue: whether to map some or all class behaviour to the functional capabilities provided by database vendors in the form of triggers, stored procedures, uniqueness and data constraints, and relational integrity. A non-persistent object model would typically implement all the behaviour required in one or more programming languages (eg. Java or C++). Each class will be given its required behaviour and responsibilities in the form of public, protected and private methods. Relational databases from different vendors typically include some form of programmable SQL based scripting language to implement data manipulation. The two common examples are triggers and stored procedures. When we mix the object and relational models, the decision is usually whether to implement all the business logic in the class model, or to move some to the often more efficient triggers and stored procedures implemented in the relational DBMS. From a purely object-oriented point of view, the answer is obviously to avoid triggers and stored procedures and place all behaviour in the classes. This localises behaviour, provides for a cleaner design, simplifies maintenance and provides good portability between DBMS vendors. In the real world, the bottom line may be scaling to 100's or 1000's of transactions per second, something stored procedures and triggers are purpose designed for. If purity of design, portability, maintenance and flexibility are the main drivers, localise all behaviour in the object methods. If performance is an over-riding concern, consider delegating some behaviour to the more efficient DBMS scripting languages. Be aware though that the extra time taken to integrate the object model with the stored procedures in a safe way, including issues with remote effects and debugging, may cost more in development time than simply deploying to more capable hardware. As mentioned earlier, the UML Data Profile provides the following extensions (stereotyped operations) with which you can model DBMS behaviour: - Primary key constraint (PK); - Foreign key constraint (FK); - Index constraint (Index); - Trigger (Trigger); - Uniqueness constraint (Unique); - Validity check (Check). 11. Produce a physical model In UML, the physical model describes how something will be deployed into the real world - the hardware platform, network connectivity, software, operating system, dll's and other components. You produce a physical model to complete the cycle - from an initial use case or domain model, through the class model and data models and finally the deployment model. Typically for this model you will create one or more nodes that will host the database(s) and place DBMS software components on them. If the database is split over more than one DBMS instance, you can assign packages («schema») of tables to a single DBMS component to indicate where the data will reside. Conclusion This concludes this short article on database modelling using the UML. As you can see, there are quite a few issues to consider when mapping from the object world to the relational. The UML provides support for bridging the gap between both domains, and together with extensions such as the UML Data Profile is a good language for successfully integrating both worlds. Mapping Use Cases to Activity Diagrams Often, early analysis of business processes will result in a collection of activity diagrams which describe how work is carried out within an organization. This may include dividing the diagram up into logical streams using 'swim lanes' as in the image below. After this initial analysis work, it can be convenient to group activities into logical Use Cases. Enterprise Architect provides a convenient method of overlaying Use Cases onto activity diagrams while maintaining readability. In the example below, the Use Case 'Login to System' has been overlayed onto the previous diagram. The Red bordered areas above are linked to existing Use Cases by setting the classifier. These 'Use Case Instances' then can be overlayed onto the associated Activities to indicate how particular business process is going to be implemented in the proposed system. Mapping Use Cases onto Activity Diagrams provides a good means of visualizing the overlay of system behavior onto business process.