In software development, the diagram is the equivalent of a blueprint. To meet the various needs of many parties, we often need several different blueprints of the same system. Furthermore, every system is described by many different aspects. For example: Functional (static structure and dynamic interactions) Nonfunctional (timing requirements, reliability, and deployment) Organizational (work organization and mapping to code modules) MagicDraw supports the following diagrams that are defined in UML 2: UML Diagrams Use Case Diagram Class Diagram Object Diagram Composite Structure Diagram State Machine Diagram Protocol State Machine Diagram Activity Diagram Interaction Overview Diagram Sequence Diagram Communication Diagram Component Diagram Deployment Diagram MagicDraw UML Diagrams Use Case Diagram a Class Diagram a Composite Structure Diagram State Machine Diagram Protocol State Machine Diagram Activity Diagram Interaction Overview Diagram Sequence Diagram Communication Diagram Implementation Diagram a a. The Package Diagram is provided for use with Use Case, Class, and Implementation Diagrams 472
Architectural Views Architectural Views UML defines 13 diagrams that describe 4+1 architectural views: Figure 334 -- Architectural Views Several kinds of diagrams provide a visual notation for the concepts in each view. Use Case View The use case view represents the functionality and behavior of a system or subsystem as it is perceived by external users. This view is targeted mainly at customers, designers, developers, and testers. The use case view usually is presented as a number of use cases and actors in Use Case diagrams. Occasionally it is used in Activity and Sequence diagrams. The use case view is central because the contents drive the development of the other views. It is also used for project planning. Every single use case unit is deemed as a manageable unit during the project execution. Structural View The structural view represents structural elements for implementing a solution for defined requirements. It identifies all of the business entities and how these entities are related to each other. Usually entities are represented as classifiers and their instances in class and object diagrams in multiple abstraction levels. System decomposition to different layers can be displayed using Package diagrams. A Composite structure diagram can be used to represent the classifier inner structure. The system structural view artifacts are created by software architects and represent the system implementation design solutions. Behavioral View The dynamic behavior of the system is displayed on the Interaction (sequence and collaboration), State, Activity, Interaction overview, and Timing diagrams. It focuses mainly on the interactions that occur between objects inside a system, activities and work performed by the various parts of a system, and state changes within a particular object or collaboration. Rather than defining the participants of the system, it defines how particular use cases are executed, which provides value for the external user. The dynamic view is concerned about what is happening inside the system and how those actions impact other participants. 473
Class Diagram Implementation view The implementation view describes the implementation artifacts of logical subsystems defined in the structural view. It may include the intermediate artifacts used in a system construction (code files, libraries, data files, etc.) This view defines dependencies between the implementation components and their connections by the required and provided interfaces. Components and their relationships are displayed on the Component diagram. Inner parts of the component can be represented with the Composite structure diagrams. The implementation view helps analyze system parts and their dependencies in a higher component level. Environment view The environment view represents the physical arrangement of a system, such as computers and devices (nodes) and how they are connected to each other. In contrast to the component view, the deployment view is concerned with the physical structure of the system and the location of the software modules (components) manifested by artifacts within the system. The environment view is displayed on the deployment diagram that is called the implementation diagram in MagicDraw TM UML. Class Diagram A class diagram is a graphic representation of the static structural model. It shows classes and interfaces, along with their internal structure and relationships. The classes represent types of objects that are handled in a system. A class diagram does not show temporal information, it describes only the classification. The instances of those types (objects) are instantiated only on the runtime and are represented by an object and the interaction diagrams. The classes can be related to each other in a number of ways: associated (connected to each other), dependent (one class depends/uses another class), specialized (one class is a subtype of another class), or packaged (grouped together as a unit package). A class diagram does not express anything specific about the relationships of a given object, but it does abstractly describe the potential relationships of one object with other objects. A system typically has a number of class diagrams not all classes are inserted into a single class diagram. A class may have multiple levels of meaning and participate in several class diagrams. A class diagram is the logical map of an existing or future source code. The classes can be grouped into packages. The packages can be nested within other packages. A package, as an entity, may have all the relationships that can be drawn for a class. Those relationships are derived from the classes or packages that are nested within two particular packages (i.e., the relationship between packages reflects a set of relationships between classes placed in those packages). 474
Class Diagram Class diagram elements Model element Class A descriptor for a set of objects with similar structures, behaviors, and relationships. Button (hot (C) Enumeration A user-defined data type whose instances are a set of user-specified named enumeration literals. The literals have a relative order but no algebra is defined on them. Class by Pattern (K) Signal (SHIFT+P) Data Type Primitive Type Interface The description of a visible behavior of a class, a component or a package. Attributes and operations inside the Interface can be suppressed. (I) 475
Class Diagram Model element Package A group of classes and other model elements. Button (hot (P) Model A model is an abstraction of a physical system from a particular point of view. A model contains a hierarchy of packages/subsystems and other model elements that describe the system. Generalization A relationship between a more general and a more specific element. (M) (G) Note: Choose a different Generalization direction from the toolbar to draw a line with an opposite arrow end. Association A connection among classes, which also means a connection among objects of those classes. Directed Association (S) Non-navigable Association 476
Class Diagram Model element N-ary association An association among two or more classes (a single class may appear more than once). Button (hot (O) Association Class The Association Class is a declaration of a semantic relationship between Classifiers. The Association Class, which has a set of features of its own, is both an Association and a Class. Aggregation An aggregation is an association that represents a whole-part relationship. (A) Directed Aggregation Composition A composition is a form of aggregation with a stronger ownership and coincident lifetime of part with the whole. (F) Directed Composition 477
Class Diagram Model element Interface Realization A relationship is usually used between an interface and an implementation class. Note: Choose a different Interface Realization direction from the toolbar to draw a line with an opposite arrow end. Realization A relationship between a specification and its implementation. Button (hot (R) (E) Substitution A substitution is a relationship between two classifiers. Usage A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. Note: Choose a different Usage direction from the toolbar to draw a line with an opposite arrow end. Abstraction An abstraction is a dependency relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. Template Binding A binding is a relationship between a template and a model element generated from the template. (B) 478
Class Diagram Model element Package Merge A package merge is a directed relationship between two packages that indicates that the contents of the two packages are to be combined. Package Import A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace. Element Import An element import is defined as a directed relationship between an importing namespace and a packageable element. Instance Button (hot Link A connection between two or more objects. (SHIFT+O) (SHIFT+L) Profiling Mechanism Toolbar Stereotype A stereotype is an extension mechanism that defines a new and more specialized element of (SHIFT+S) the model based on an existing element. MetaClass A class whose instances are classes. Metaclasses are typically used to construct metamodels. Extension An extension is used to indicate that the properties of a metaclass are extended through a stereotype, and gives the ability to flexibly add (and later remove) stereotypes to classes. 479
Use Case Diagram Model element Profile A Profile is a kind of Package that extends a reference metamodel. Button (hot Profile Application A profile application is used to show which profiles have been applied to a package. Use Case Diagram A use case is a description of the functionality (a specific usage of a system) that a system provides. The use case descriptions may exist in a textual form (a simple table), where the use case diagram provides additional information about the relationship between the use cases and the external users. The diagram also allows a definition of the system's boundary. The Use cases are described only in terms of how they appear when viewed externally by the user (a system's behavior as the user perceives it), and do not describe how the functionality is provided inside the system. The Use cases are not object-oriented, but they are included in the UML to simplify the approach of the project's lifecycle -- from the specification to the implementation. Figure 335 -- The schematic view of the use cases in the system. 480
Use Case Diagram Use Case diagram elements Element Actor Button (hot Actors represent roles played by human users, external hardware, and other subjects. An actor does not necessarily represent a specific physical entity but merely a particular facet (that is, "role") of some entities that is relevant to the specification of its associated use cases. Use Case A use case is a kind of behaviorrelated classifier that represents a declaration of an offered behavior. Each use case specifies a particular behavior, possibly including the variants that the subject can perform in collaboration with one or more actors. The subject of a use case could be a physical system or any other element that may initiate a behavior, such as a component, a subsystem, or a class. Package A group of classes and other model elements. A package may contain other packages. (A) (U) (P) Subsystem A subsystem is treated as an abstract single unit. It groups model elements by representing the behavioral unit in a physical system. (Y) System Boundary Another representation of a package. A system boundary element consists of use cases related by Exclude or Include (uses) relationships, which are visually located inside the system boundary rectangle. (B) 481
Communication Diagram Element Include An include (uses) relationship from use case A to use case B indicates that an instance of the use case A will also contain the behavior as specified by B. Button (hot (C) Extend A relationship from an extending use case to an extended use case that specifies how and when the behavior defined in the extending use case can be inserted into the behavior defined in the extended use case. The extension takes place at one or more specific extension points defined in the extended use case. Note: Choose a different Extend direction from the toolbar to draw a line with an opposite arrow end. Association The participation of an actor in a use case, i.e. instances of the actor and instances of the use case communicate with each other. This is the only relationship between actors and use cases. Generalization A relationship between a more general and a more specific element. Note: Choose a different Generalization direction from the toolbar to draw a line with an opposite arrow end. (E) (S) (G) Communication Diagram The Communication diagram illustrates the various static connections between objects, and models their interactions. It also presents a collaboration that contains a set of instances as well as their required relationships given in a particular context, and includes an interaction that defines a set of messages. These messages specify the interaction between the classifier roles within a collaboration that will serve to achieve the desired result. A Communication diagram is given in two different forms: at the instance level or at the specification level. 482
Communication Diagram Communication Diagram elements Element Lifeline A lifeline represents an individual participant in the Interaction. The Lifelines represent only one interacting entity. Connector Specifies a link that enables communication between two or more lifelines. Each connector may be attached to two or more connectable elements, each representing a set of lifelines. Connector to Self Self connector for self-calls. It begins and ends on the same lifeline. Button (hot (O) (C) (S) Message to Right Message to Left A Message defines a particular communication between the Lifelines of an Interaction. It implies that one object uses the services of another object, or sends a message to that object. A communication can be formed by e.g. raising a signal, invoking an Operation, creating or destroying an Instance. Click on the arrow to expand the toolbar and choose an appropriate message type. Call Message to Right Call Message to Left Send Message to Right Send Message to Left 483
Sequence Diagram Element Reply Message to Right Button (hot Reply Message to Left Create Message to Right Create Message to Left Deleta Message to Right Delete Message to Left Sequence Diagram A sequence diagram shows the interaction information with an emphasis on the time sequence. The diagram has two dimensions: the vertical axis that represents time and the horizontal axis that represents the participating objects. The time axis could be an actual reference point (by placing the time labels as text boxes). The horizontal ordering of the objects is not significant to the operation, and you may rearrange them as necessary. 484
Sequence Diagram Sequence diagram elements Model elements Lifeline Represents the existence of an object at a particular time. Button (hot (O) Activation Bar Focus of control. Shows the period during which an object is performing an action either directly or through a subordinated procedure. Alternatives Loop (SHIFT+A) Option (SHIFT+L) Parallel (SHIFT+O) Break (SHIFT+P) Negative (SHIFT+B) (SHIFT+G) 485
Sequence Diagram Model elements Critical Region Button (hot Consider (SHIFT+R) Ignore (SHIFT+C) Weak Sequencing (SHIFT+I) Strict Sequencing (SHIFT+W) Assertion (SHIFT+S) Interaction Use A reference to interactions, communication diagram, sequence diagram, and time diagram can be created. (SHIFT+R) (SHIFT+T) Message A communication between objects that conveys information with the expectation that an action will ensue. The receipt of a message is one type of event. (M) Call Message (A) 486
Sequence Diagram Model elements Send Message Button (hot Reply Message (E) Create Message (R) Delete Message (C) Diagonal Message Requires some time to arrive, during which another action occurs. (T) (D) Message to Self (S) Recursive message A connected set of messages can be enclosed and marked as iteration. (U) Duration Constraint A duration defines a value specification that specifies the temporal distance between two time instants. 487
Sequence Diagram Model elements Time Constraint Specifies the combination of min and max timing interval values. Button (hot Sequence diagram improvements State Invariant Term The OMG UML specification (UML 2.2: Superstructure) states: "A StateInvariant is a runtime constraint on the participants of the interaction. It may be used to specify a variety of different kinds of constraints, such as values of attributes or variables, internal or external states, and so on". State invariant element support is added in sequence diagram: In the Figure 336 on page 489, the State Invariant element is presented in two cases: 1. State Invariant with a assigned mystate State. 2. State Invariant with a defined constraint Y.p=15. 488
Sequence Diagram Figure 336 -- State Invariant in a Sequence diagram 489
Sequence Diagram Lost / Found Messages Terms The OMG UML specification (UML 2.2: Superstructure) states: "A lost message is a message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret this to be because the message never reached its destination." "A found message is a message where the receiving event occurrence is known, but there is no (known) sending event occurrence. We interpret this to be because the origin of the message is outside the scope of the description. This may for example be noise or other activity that we do not want to describe in detail. Figure 337 -- Lost Message in a Sequence diagram 490
State Machine Diagram Figure 338 -- Found message in a Sequence diagram State Machine Diagram The behavior of objects of a class can be described in terms of states and events, using a state machine connected to the class under construction. The state machine is a specification of the sequence of states through which an object or an interaction goes in response to events during its life, together with its responsive actions. The state machine may represent the sequence of states of a particular collaboration (i.e. collection of objects) or even the whole system (which is also considered a collaboration). The abstraction of all possible states defined in a state machine is similar to the way class diagrams are abstracted: all possible object types (classes) of a particular system are described. Objects that do not present a very pronounced reactive behavior may always be considered to stay in the same state. In such a case, their classes do not possess a state machine. State diagrams (also called Statechart diagrams) represent the behavior of entities capable of dynamic behavior by specifying its response to the receipt of event instances. Typically, the state diagrams describe the behavior of classes, but the statecharts may also describe the behavior of other model entities such as usecases, actors, subsystems, operations, or methods. A state diagram is a graph that represents a state machine. States and various other types of vertices (pseudostates) in the state machine graph are rendered by the appropriate state and pseudostate symbols, while transitions are generally rendered by directed arcs that inter-connect them. The states may also contain subdiagrams by physical containment or tiling. Note that every state machine has a top state, which contains all the other elements of the entire state machine. The graphical rendering of this top state is optional. The states are represented by the state symbols, while the transitions are represented by arrows connecting the state symbols. 491
State Machine Diagram The state diagram concerns with internal object changes (as opposed to the external object interaction in collaboration). Do not attempt to draw them for all classes in the system, because they are used only for modeling a complex behavior. The state diagram shows all the possible states that objects or collaborations may have, and the events that cause the state to change. An event can be another object that sends a message to it: for example, that a specified time has elapsed or that some conditions have been fulfilled. A change of a state is called a transition. A transition may also have an action connected to it that specifies what should be done in connection with the state transition. State Machine Diagram elements NOTE If a black arrow is placed on a button, right-click the button, to open other available buttons. Model elements State A state models a situation during which some (usually implicit) invariant conditions holds. The invariant may represent a static situation such as an object waiting for some external events to occur. However, it can also model dynamic conditions such as the process of performing some behavior.s Composite State A composite state either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint subvertices and a set of transitions. Button (hot (SHIFT+S) (SHIFT+ C) Orthogonal State An orthogonal state is a composite state with at least 2 regions. (C) 492
State Machine Diagram Model elements Submachine State The submachine state specifies the insertion of the specification of a submachine state machine. The Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse. Button (hot (A) Initial Denotes an initial state when an object is created. Final State Denotes an object destruction or the end of a collaboration. Terminate (I) (F) Entry Point The entry point connection points a reference as the target of a transition. This implies that the target of the transition is the entry point pseudostate as defined in the submachine of the submachine state. Exit Point The exit point connection points a reference as the source of a transition. This implies that the source of the transition is the exit point pseudostate as defined in the submachine of the submachine state that has the exit point connection point defined. (R) (Y) (U) 493
State Machine Diagram Model elements Connection Point Reference The Connection point references of a submachine state can be used as the sources/targets of the transitions. They represent entries into or exits out of the submachine state machine referred by the submachine state. Deep History Represents the most recent active configuration of the composite state that directly contains the pseudostate; e.g. the state configuration that was active when the composite state was last exited. Shallow History Represents the most recent active substate of its containing state (but not the substates of that substate). A composite state can have at most one shallow history vertex. Junction The junction vertices are semantic-free vertices that are used to chain together multiple transitions. They are used to construct the compound transition paths between states. Button (hot (Z) (P) (SHIFT+R ) (J) Choice The choice points are used to split transition paths. In the dynamic choice point, a decision corncerning which branch to take is only made after the transition from State1 is taken and the choice point is reached. (O) 494
Protocol State Machine Diagram Model elements Fork/Join Vertical Helps to control parallel actions. Fork/Join Horizontal Helps to control parallel actions. Transition The starting time for a relative time event may only be omitted for a time event that is the trigger of a state machine. Button (hot (G) (D) (T) Transition to Self When an object returns to the same state after the specified event occurs. (E) Protocol State Machine Diagram A protocol state machine is always defined in the context of a classifier. It specifies which operations of the classifier can be called, in which state, and under which condition, thus specifying the allowable call sequences on the classifier s operations. The protocol state machine presents the possible and permitted transitions on the instances of its context classifier, together with the operations that carry the transitions. In this manner, an instance lifecycle can be created for a classifier, by specifying the order in which the operations can be activated and the states through which the instance progresses during its existence. The Protocol State Machine Diagram is created for use with the Protocol State Machine and the Protocol Transitions. Protocol State Machine Diagram elements NOTE 495
Protocol State Machine Diagram If a black arrow is placed on a button, right-click the button to open other available buttons. Model elements State The states of the protocol state machines are exposed to the users of their context classifiers. A protocol state represents an exposed stable situation of its context classifier: When an instance of the classifier is not processing any operation, the user of this instance can always know its configuration state. Composite State A composite state either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint subvertices and a set of transitions. Button (hot (SHIFT+S) (SHIFT+ C) Orthogonal State An orthogonal state is a composite state with at least 2 regions. (C) Submachine State A submachine state specifies the insertion of the specification of a submachine state machine. The submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse. (A) Initial Denotes an initial state when an object is created. (I) 496
Protocol State Machine Diagram Model elements Final State Denotes an object destruction or the end of a collaboration. Terminate Button (hot (F) Entry Point The entry point connection points a reference as the target of a transition. This implies that the target of the transition is the entry point pseudostate as defined in the submachine of the submachine state. Exit Point The exit point connection points a reference as the source of a transition. This implies that the source of the transition is the exit point pseudostate as defined in the submachine of the submachine state that has the exit point connection point defined. Connection Point Reference The connection point references of a submachine state that can be used as the sources/targets of the transitions. They represent entries into or exits out of the submachine state machine referenced by the submachine state. Junction The junction vertices are semantic-free vertices that are used to chain together multiple transitions. They are used to construct the compound transition paths between states. (R) (Y) (U) (Z) (J) 497
Activity Diagram Model elements Choice The choice points are used to split transition paths. In the dynamic choice point, a decision on which branch to take is only made after the transition from State1 is taken and the choice point is reached. Button (hot (O) Fork/Join Vertical Helps to control parallel actions. Fork/Join Horizontal Helps to control parallel actions. Protocol Transition A protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for an operation. Transitions of the protocol state machines have the following information: a pre condition (guard), on trigger, and a post condition. Every protocol transition is associated to zero or one operation that belongs to the context classifier of the protocol state machine. Protocol Transition to Self When an object returns to the same state after the specified event occurs. (G) (D) (T) (E) Activity Diagram An activity graph is a variation of a state machine. In the state machine, the states represent the performance of actions or subactivities, while the transitions are triggered by the completion of the actions or subactivities. It represents a state machine of a procedure itself. The entire activity diagram is attached (through the model) to a class, such as a use case, or to a package, or to the implementation of an operation. The purpose of this diagram is to focus on flows driven by the internal processing (as opposed to external events). You should use the activity diagrams in situations where all or most of the events represent the completion of internally-generated 498
Activity Diagram actions (that is, procedural flow of control). You should use the ordinary state diagrams in situations where asynchronous events occur. An activity diagram is a variant of a state diagram. Organized according to actions, the activity diagrams are mainly targeted towards the representation of the internal behavior of a method (the implementation of an operation) or a use case. Though activity diagrams are often classified alongside the interaction diagrams, they actually focus on the work performed by a system instead of an object interaction. An activity diagram captures actions and displays their results. A state diagram may also represent this sequencing of steps. However, given the procedural nature of the implementation of the operations in which most events simply correspond to the end of the preceding activity it is not necessary to distinguish states, activities, and events systematically (i.e. state changes and external events have less importance inside the method). It is therefore beneficial to have a simplified representation for directly displaying activities. The activity diagram provides a convenient way to describe complex algorithms, parallel operations, and business processes. Together with the collaboration and sequence diagrams, they are used to relate use cases. 499
Activity Diagram Activity Diagram elements Element Action An action is a named element that is the fundamental unit of an executable functionality. The execution of an action represents some transformations or processing in the modeled system. When the action is to be executed or what its actual inputs are is determined by the concrete action and the behaviors in which it is used. Call Operation Action An action that transmits an operation call request to the target object, where it may cause the invocation of the associated behavior. The argument values of the action are available to the execution of the invoked behavior. Opaque Action An opaque action is introduced for implementing specific actions or for use as a temporary placeholder before some other actions are chosen. Any Action This element is introduced in order to maintain any other desirable action element with an appropriate metaclass stereotype applied. Object Node The Activity nodes are introduced to provide a general class for the nodes connected by activity edges. The ActivityNode replaces the use of the StateVertex and its children for activity modeling in UML. Button (hot (B) (O) (SHIFT+B) 500
Activity Diagram Element Data Store A data store node is a central buffer node for a nontransient information. A data store keeps all tokens that enter it, copies them when they are chosen to move downstream. Incoming tokens containing a particular object replace any tokens in the object node containing that object. Activity Parameter Node It is an object node for inputs and outputs to the activities. The Activity parameters are object nodes at the beginning and end of the flows, to accept inputs to an activity and provide outputs from it. Button (hot (SHIFT+D) Input Expansion Node An expansion node is an object node used to indicate a flow across the boundary of an expansion region. A flow into a region contains a collection that is broken into its individual elements inside the region, which is executed once per element. Output Expansion Node A flow out of a region combines individual elements into a collection for use outside the region. Object Flow Is an activity edge that can have objects or data passing along it. An object flow models the flow of values to or from the object nodes. (SHIFT+F) 501
Activity Diagram Element Button (hot Control Flow Is an edge that starts an activity node after the previous one is finished. Objects and data cannot pass along the control flow edge. Send Signal Action Is an action that creates a signal instance from its inputs, and transmits it to the target object, where it may trigger the state machine transition or the execution of an activity. Accept Event Action Is an action that waits for the occurrence of an event that meets the specified conditions. The Accept event actions handle event occurrences detected by the object owning the behavior. Initial Node An initial node is a starting point for executing an activity. It has no incoming edges. (F) (SHIFT+S) (E) (T) Activity Final An activity final node is a final node that stops all flows in an activity. (D) Flow Final The Final node that terminates a flow and destroys all tokens that arrive at it. It has no impact on other flows in the activity. (L) 502
Activity Diagram Element Decision Decision is a control node that chooses between outgoing flows. A decision node has one incoming edge and multiple outgoing activity edges. Button (hot (G) Merge A merge node is a control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows but it is used to accept one among several alternate flows. Fork/Join Horizontal Helps to control parallel actions. Fork/Join Vertical Helps to control parallel actions. Exception Handler An exception handler is an element that specifies a body to execute in case the specified exception occurs during the execution of the protected node. Structured Activity Node A structured activity node is an executable activity node that may have an expansion into the subordinate nodes. The structured activity node represents a structured portion of the activity that is not shared with any other structured node, except for nesting. (G) (K) (SHIFT+K) (P) 503
Activity Diagram Element Conditional Node A conditional node is a structured activity node that represents an exclusive choice among alternatives. Button (hot Sequence Node A sequence node is a structured activity node that executes its actions in order. Loop Node A loop node is a structured activity node that represents a loop with the setup, test, and body sections. Expansion Region An expansion region is a structured activity region that executes multiple times corresponding to the elements of an input collection. Time Event A time event specifies a point of time by an expression. The expression might be absolute or might be relative to some other points of time. 504
Activity Diagram Element Input Pin An input pin is a pin that holds input values to be consumed by an action. They are object nodes that receive values from other actions through object flows. Output Pin A pin that holds output values produced by an action. Output pins are object nodes that deliver values to other actions through object flows. Value Pin A value pin is an input pin that provides a value to an action that does not come from an incoming object flow edge. Swimlanes Swimlanes are used to organize responsibility for actions and subactivities according to the class, dividing an activity diagram. Button (hot (SHIFT+I) (SHIFT+O) (SHIFT+V) (SHIFT+W) Smart Activity Diagram layout Dynamic centerlines The centerlines are displayed only when a center of the shape that was moved or newly drawn is located near the center of another shape that already exists in the diagram. These lines help to draw diagram with aligned shapes easily. 505
Activity Diagram When the center of the shape that was moved coincides with a center of any shape that is placed to its right or left, a horizontal centerline is displayed. When the center of the shape is close to any center of a shape that is located above or below it, a vertical centerline is displayed. Figure 339 -- Dynamic vertical centerline To switch off the dynamic centerlines Diagram orientation Click the Show Centerlines button in the diagram toolbar or press C. From the Options main menu, select Environment. In the open dialog box, click the Diagram node and clear the Show centerlines in flow diagrams check box in the Display properties group. The diagram orientation is used to assign the correct rectilinear path breaks and draw paths betweenthe activity diagram shapes. The paths can be drawn from from side to side, or from the lower to the upper shape borders. Example: For a vertical diagram orientation - in this case if two shapes are not in the same centerline, the paths will be connected from the lower border of the first shape to the upper border of the next shape, adding break points: 506
Implementation Diagram For a horizontal diagram orientation - in this case the paths will be connected from the side border of the first shape to the next side border of the second shape, adding break points: To change the diagram orientation From the Options main menu, select Project. In the open dialog box, expand Diagram group and in the right side properties list, change the value for the Diagram Orientation property. From the diagram pane shortcut menu, select Diagram Properties and change the value for the Diagram Orientation property. For applying the Activity diagram layout tool, see Activity Diagram Layout Tool on page 193. Implementation Diagram The Implementation diagrams help developers describe the logical software structure inside a computer system or across a large distributed system. They show aspects of the physical implementation, including the structure of components and the run-time deployment system. They come in two forms: 1. Component diagrams that show the structure of the components, including the classifiers that specify them and the artifacts that implement them; and 2. Deployment diagrams that show the structure of the nodes on which the components are deployed. These diagrams can also be applied in a broader way on the business modeling where the components represent the business procedures and artifacts, and the deployment nodes represent the organization units and resources (human and otherwise) of the business. Component diagram overview A component diagram represents a physical structure of a code (as opposed to the class diagram, which portrays the logical structure) in terms of code components and their relationships within the implementation environment. A component can be a source code component, a binary component, or an executable component. A component contains information about the logical class or classes that it implements, thus creating a mapping from a logical view to a component view. Dependencies between the components are shown, making it easy to analyze how a change in one component affects the others. The components may also be shown with any of the interfaces that they expose. They, as with almost any other model elements, can be grouped into packages, much like classes or use cases. The component diagrams are used in the later phases of the software development, when there is a need to divide up classes among different components. When working with the CASE facilities, the components are used for file-class mapping during code generation, reverse engineering, and round-trip engineering operations. 507
Implementation Diagram Deployment diagram overview The Deployment diagrams show the physical layout of the various hardware components (nodes) that compose a system as well as the distribution of executable programs (software components) on this hardware. The Deployment diagrams are crucial when dealing with distributed systems. You may show the actual computers and devices (nodes), along with the connections they have to each other, thus specifying a system topology. Inside the nodes, the executable components and objects are located in a way that it shows where the software units are residing and on which nodes they are executed. You may also show dependencies between the components. 508
Implementation Diagram Implementation Diagram elements Element Component The Component may be used to define the requirements for each physical software element. Component Instance An instance of a component. Button (hot (K) (A) Port Ports represent interaction points between a classifier and its environment. A port has the ability to specify that any requests arriving at this port are handled. Node A Node is a physical object that represents a processing resource, generally having at least a memory and often the processing capability as well. (SHIFT+R) (O) Execution Environment The element that is used to indicate that a node is the execution environment. Device A physical computational resource with the processing capability upon which artifacts may be deployed for an execution. 509
Implementation Diagram Element Node Instance An instance of a node. Button (hot (T) Execution Environment Instance The element that is used to indicate that a node is an instance of the execution environment. Device Instance Package A group of classes and other model elements. (P) Artifact An artifact represents a physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An Artifact may constitute the implementation of a deployable component. Deployment Specification It indicates a set of properties that defines how a component should be deployed. (B) 510
Implementation Diagram Element Artifact Instance Button (hot Deployment Specification Instance Interface All functionalities implemented by a particular component. Interface Realization The classifier at the tail of the arrow implements the interface that is located at the arrow head or uses that interface. Note: Choose a different Interface Realization direction from the toolbar to draw a line with an opposite arrow end. Realization A realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. Usage A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. Usage is also used to create required interface. Note: Choose a different Usage direction from the toolbar to draw a line with an opposite arrow end. (F) (R) (E) (U) 511
Implementation Diagram Element Instance An instance specifies the existence of an entity in a modeled system and completely or partially describes the entity. It has a unique name, state, and classifier as the type of the identifier. Assembly Connector An assembly connector is a connector between two components that defines that one component provides the services that another component requires. Button (hot (SHIFT+O) Delegation Connector A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component s parts. Deployment A deployment is the allocation of a deployment target to an artifact or artifact instance. 512