Images UML - PART II

UML
Unified Modeling Language (UML) is a standardized specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.
UML is officially defined at the Object Management Group (OMG) by the UML metamodel, a Meta-Object Facility metamodel (MOF). Like other MOF-based specifications, the UML metamodel and UML models may be serialized in XMI. UML was designed to specify, visualize, construct, and document software-intensive systems.
UML is not restricted to modeling software. UML is also used for business process modeling, systems engineering modeling, and representing organizational structures. The Systems Modeling Language (SysML) is a Domain-Specific Modeling language for systems engineering that is defined as aUML 2.0 profile.
Behavioral Modeling Diagrams Use Case Diagrams A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML). Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals—represented as use cases—and any dependencies between those use cases. OMG's UML standard defines a graphical notation for diagramming use cases, but no format for describing use cases. While the graphical notation and descriptions are important, they are documentation of the use case—a purpose that the actor can use the system for. The true value of a use case lies in two areas: The written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems. The position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team. More formally, a use case is made up of a set of scenarios. Each scenario is a sequence of steps that encompass an interaction between a user and a system. The use case brings scenarios together that accomplish a specific goal of the user. There’s no rocket science to it at all: a usage case is simply a reason to use a system. For example, a bank card holder might need to use an ATM to get cash out of their account. It’s as simple as that. A use case can be specified by textually describing the steps required and any alternative actions at each step. For example, the use case for withdrawing cash from an ATM machine might be shown as: Customer enters the Card ATM checks for validity of card, ask card holder to enter PIN Customer enters PIN. ATM validates the PIN. and so on.... Alternative: Search Failed If the search fails at 3, then the user is redirected back to the search screen at step 1 Actor The use case diagram allows a designer to graphically show these use cases and the actorsthat use them. An actor is a role that a user plays in the system. It is important to distinguish between a user and an actor (better thought of as a role). A user of the system may play several different roles through the course of his, her or its job (since an actor may be another system). Examples of actors are salesperson, manager, support person, and web store system. It is possible that the same person may be a sales person and also provide support. When creating a use case model, we are not concerned with the individuals, only the roles that they play. 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 Cash" use case. 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 conditionspecifies 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. 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. Behavioral Modeling Diagrams Sequence Diagrams Once the use cases are specified, and some of the core objects in the system areprototyped on class diagrams, we can start designing the dynamic behavior of the system. The Message Sequence Chart technique has been incorporated into the Unified Modeling Language (UML) diagram under the name of Sequence Diagram. Typically, an interaction diagram captures the behavior of a single case by showing the collaboration of the objects in the system to accomplish the task. These diagrams show objects in the system and the messages that are passed between them. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. Let's start with the simple example above: a user logging onto the system. The Logon use case can be specified by the following step: Logon dialog is shown User enters user name and password User clicks on OK or presses the enter key The user name and password are checked and approved The user is allowed into the system Alternative: Logon Failed - if at step 4 the user name and password are not approved, allow the user to try again. Now that we have a simple Use Case to work with, we can specify some of the classes involved in the interaction. 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. Aninteraction 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. Behavioral Modeling Diagrams Activity Diagrams In the Unified Modeling Language, an activity diagram represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. 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 localpre- 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 asingle 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. Behavioral Modeling Diagrams State Diagrams State diagrams are used to graphically represent finite state machines. State transition tables are another possible representation. There are many forms of state diagrams, which differ slightly and have different semantics. When to Use: State Diagrams? Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case. State diagrams are other combined with other diagrams such as interaction diagramsand activity diagrams. State Diagram The state diagram shows the change of an object through time. Based upon events that occur, the state diagram shows how the object changes from start to finish. States are represented as a rounded rectangle with the name of the state shown. Optionally you can include an activity that represents a longer running task during that state. Connecting states together are transitions. These represent the events that cause the object to change from one state to another. The guard clause of the label is again mutually exclusive and must resolve itself to be either true or false. Actions represent tasks that run causing the transitions. Actions are different from activities in that actions cannot be interrupted, while an activity can be interrupted by an incoming event. Both ultimately represent an operation on the object being studied. For example, an operation that sets an attribute would be considered an action, while a long calculation might be an activity. The specific separation between the two depends on the object and the system being studied. Like activity diagrams, state diagrams have one start and one end from at which the state transitions start and end respectively. How to Draw: State Diagrams State diagrams have very few elements. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state. The activity section of the state symbol depicts what activities the object will be doing while it is in that state. All state diagrams being with an initial state of the object. This is the state of the object when it is created. After the initial state the object begins changing states. Conditions based on the activities can determine what the next state the object transitions to. Below is an example of a state diagram might look like for an Order object. When the object enters the Checking state it performs the activity "check items". After the activity is completed the object transitions to the next state based on the conditions [all items available] or [an item is not available]. If an item is not available the order is canceled. If all items are available then the order is dispatched. When the object transitions to the Dispatching state the activity "initiate delivery" is performed. After this activity is complete the object transitions again to the Delivered state. State diagrams can also show a super-state for the object. A super-state is used when many transitions lead to the a certain state. Instead of showing all of the transitions from each state to the redundant state a super-state can be used to show that all of the states inside of the super-state can transition to the redundant state. This helps make the state diagram easier to read. Behavioral Modeling Diagrams Communication Diagrams In the Unified Modeling Language (UML) 2.0, a communication diagram is a simplified version of the UML 1.x collaboration diagram. A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structureand dynamic behavior of a system. However, communication diagrams use the free-form arrangement of objects and links as used in Object diagrams. In order to maintain the ordering of messages in such a free-form diagram, messages are labeled with a chronological number and placed near the link the message is sent over. Reading a communication diagram involves starting at message 1.0, and following the messages from object to object. 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 diagramthat 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. Behavioral Modeling Diagrams Timing Diagrams Timing diagrams (UML 2.0) are a specific type of interaction diagram, where the focus is on timing constraints. Timing diagrams are used to explore the behaviors of objects throughout a given period of time. A timing diagram is a special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are reversed so that the time is increased from left to right and the lifelines are shown in separate compartments arranged vertically. Timing diagrams are used to show changes and their relationship to clock times. It provides a visual representation of objects changing state and interacting over time. Timing diagrams can be used for defining hardware-driven or embedded software components. The X-axis of the timing diagram normally has the time units with the Y-axisshowing the objects and their states. States are normally changed by some sort of event that causes the state change. Timing diagrams can be drawn from a value or time based point of view. Example: Time-based timing diagram Example: Value-based timing diagram