9 UML DIAGRAMS - Hokusei Gakuen Universityz00102/SeminarI/2010/Lecture7/… · · 2010-05-31UML...

Copyright © 1998-2010 No Magic, Inc.472

9 UML DIAGRAMS

In software development, the diagram is the equivalent of a blueprint. To meet the various needs of many par-ties, 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 MagicDraw UML DiagramsUse Case Diagram Use Case Diagrama

a. The Package Diagram is provided for use with Use Case, Class, and Imple-mentation Diagrams

Class DiagramClass Diagrama

Object Diagram

Composite Structure Diagram Composite Structure Diagram

State Machine Diagram State Machine Diagram

Protocol State Machine Dia-gram

Protocol State Machine Dia-gram

Activity Diagram Activity Diagram

Interaction Overview Diagram Interaction Overview Diagram

Sequence Diagram Sequence Diagram

Communication Diagram Communication Diagram

Component DiagramImplementation Diagrama

Deployment Diagram

UML DIAGRAMSArchitectural Views9

473 Copyright © 1998-2010 No Magic, Inc..

Architectural ViewsUML 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. Occasion-ally 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 iden-tifies all of the business entities and how these entities are related to each other. Usually entities are repre-sented 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 soft-ware 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, Activ-ity, 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 par-ticular 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.

UML DIAGRAMSClass Diagram

474

9

Copyright © 1998-2010 No Magic, Inc.

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 dia-gram. Inner parts of the component can be represented with the Composite structure diagrams. The implemen-tation 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 MagicDrawTM UML.

Class DiagramA 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), depen-dent (one class depends/uses another class), specialized (one class is a subtype of another class), or pack-aged (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).

UML DIAGRAMSClass Diagram9


Class diagram elements

Model element Button (hot key)

Notation

ClassA descriptor for a set of objects with similar struc-tures, behaviors, and relationships.

(C)

EnumerationA user-defined data type whose instances are a set of user-specified named enumeration liter-als. The literals have a relative order but no alge-bra is defined on them.

(K)

Class by Pattern

(SHIFT+P)

Signal

Data Type

Primitive Type

InterfaceThe description of a visi-ble behavior of a class, a component or a package. Attributes and opera-tions inside the Interface can be suppressed.

(I)


476

9


PackageA group of classes and other model elements.

(P)

ModelA model is an abstraction of a physical system from a particular point of view. A model contains a hier-archy of packages/sub-systems and other model elements that describe the system.

(M)

GeneralizationA 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.

(G)

AssociationA connection among classes, which also means a connection among objects of those classes.

(S)

Directed Association

Non-navigable Association


Notation



N-ary associationAn association among two or more classes (a single class may appear more than once).

(O)

Association ClassThe Association Class is a declaration of a seman-tic relationship between Classifiers. The Associa-tion Class, which has a set of features of its own, is both an Association and a Class.

Aggregation An aggregation is an association that repre-sents a whole-part rela-tionship.

(A)

Directed Aggregation

CompositionA composition is a form of aggregation with a stronger ownership and coincident lifetime of part with the whole.

(F)

Directed Composition


Notation


478

9


Interface RealizationA relationship is usually used between an inter-face and an implementa-tion class.Note: Choose a different Interface Realization direction from the toolbar to draw a line with an opposite arrow end.

(R)

RealizationA relationship between a specification and its implementation.

(E)

SubstitutionA substitution is a rela-tionship between two classifiers.

UsageA usage is a relationship in which one element requires another ele-ment (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.

AbstractionAn abstraction is a dependency relationship that relates two elements or sets of elements that represent the same con-cept at different levels of abstraction or from differ-ent viewpoints.

Template BindingA binding is a relationship between a template and a model element gener-ated from the template. (B)


Notation



Package MergeA package merge is a directed relationship between two packages that indicates that the contents of the two pack-ages are to be combined.

Package ImportA package import is defined as a directed relationship that identifies a package whose mem-bers are to be imported by a namespace.

Element ImportAn element import is defined as a directed relationship between an importing namespace and a packageable ele-ment.

Instance

(SHIFT+O)

LinkA connection between two or more objects.

(SHIFT+L)

Profiling Mechanism Toolbar

StereotypeA stereotype is an exten-sion mechanism that defines a new and more specialized element of the model based on an existing element.

(SHIFT+S)

MetaClassA class whose instances are classes. Meta-classes are typically used to construct metamodels.

ExtensionAn extension is used to indicate that the proper-ties of a metaclass are extended through a ste-reotype, and gives the ability to flexibly add (and later remove) stereotypes to classes.


Notation

UML DIAGRAMSUse Case Diagram

480

9


Use Case DiagramA 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.

ProfileA Profile is a kind of Package that extends a reference metamodel.

Profile ApplicationA profile application is used to show which pro-files have been applied to a package.


Notation

UML DIAGRAMSUse Case Diagram9


Use Case diagram elements

Element Button (hot key)

Notation

Actor

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 particu-lar facet (that is, "role") of some enti-ties that is relevant to the specification of its associated use cases.

(A)

Use CaseA use case is a kind of behavior-related classifier that represents a declaration of an offered behavior. Each use case specifies a particular behavior, possibly including the vari-ants 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.

(U)

PackageA group of classes and other model elements. A package may contain other packages. (P)

SubsystemA subsystem is treated as an abstract single unit. It groups model elements by representing the behav-ioral unit in a physical system.

(Y)

System BoundaryAnother 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)

UML DIAGRAMSCommunication Diagram

482

9


Communication DiagramThe Communication diagram illustrates the various static connections between objects, and models their inter-actions. 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.

IncludeAn 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.

(C)

Extend A relationship from an extending use case to an extended use case that specifies how and when the behav-ior 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.

(E)

AssociationThe participation of an actor in a use case, i.e. instances of the actor and instances of the use case communi-cate with each other. This is the only relationship between actors and use cases.

(S)

GeneralizationA relationship between a more gen-eral and a more specific element.Note: Choose a different General-ization direction from the toolbar to draw a line with an opposite arrow end.

(G)


Notation

UML DIAGRAMSCommunication Diagram9


Communication Diagram elements


Notation

LifelineA lifeline represents an indi-vidual participant in the Inter-action. The Lifelines represent only one interact-ing entity.

(O)

ConnectorSpecifies a link that enables communication between two or more lifelines. Each con-nector may be attached to two or more connectable ele-ments, each representing a set of lifelines.

(C)

Connector to SelfSelf connector for self-calls. It begins and ends on the same lifeline.

(S)

Message to RightMessage to LeftA Message defines a particu-lar communication between the Lifelines of an Interac-tion. It implies that one object uses the services of another object, or sends a message to that object. A communica-tion 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

UML DIAGRAMSSequence Diagram

484

9


Sequence DiagramA 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 participat-ing 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.

Reply Message to Right

Reply Message to Left

Create Message to Right

Create Message to Left

Deleta Message to Right

Delete Message to Left


Notation

UML DIAGRAMSSequence Diagram9


Sequence diagram elements

Model elements Button (hot key)

Notation

LifelineRepresents the existence of an object at a particular time.

Activation BarFocus of control. Shows the period during which an object is performing an action either directly or through a subordi-nated procedure.

(O)

Alternatives

(SHIFT+A)

Loop

(SHIFT+L)

Option

(SHIFT+O)

Parallel

(SHIFT+P)

Break

(SHIFT+B)

Negative

(SHIFT+G)


486

9


Critical Region

(SHIFT+R)

Consider

(SHIFT+C)

Ignore

(SHIFT+I)

Weak Sequencing

(SHIFT+W)

Strict Sequencing

(SHIFT+S)

Assertion

(SHIFT+R)

Interaction UseA reference to interactions, communication diagram, sequence diagram, and time diagram can be created.

(SHIFT+T)

Message A communication between objects that conveys informa-tion with the expectation that an action will ensue. The receipt of a message is one type of event.

(M)

Call Message

(A)


Notation



Send Message

(E)

Reply Message

(R)

Create Message

(C)

Delete Message

(T)

Diagonal MessageRequires some time to arrive, during which another action occurs. (D)

Message to Self

(S)

Recursive messageA connected set of messages can be enclosed and marked as iteration. (U)

Duration ConstraintA duration defines a value specification that specifies the temporal distance between two time instants.


Notation


488

9


Sequence diagram improvements

State Invariant

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.

Time ConstraintSpecifies the combination of min and max timing interval values.

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".


Notation



Figure 336 -- State Invariant in a Sequence diagram


490

9


Lost / Found Messages

Figure 337 -- Lost Message in a Sequence diagram

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.”

UML DIAGRAMSState Machine Diagram9


Figure 338 -- Found message in a Sequence diagram

State Machine DiagramThe behavior of objects of a class can be described in terms of states and events, using a state machine con-nected 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 behav-ior 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 use-cases, actors, subsystems, operations, or methods.

A state diagram is a graph that represents a state machine. States and various other types of vertices (pseu-dostates) 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 subdi-agrams 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.

UML DIAGRAMSState Machine Diagram

492

9


The state diagram concerns with internal object changes (as opposed to the external object interaction in col-laboration). 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 elementsNOTE If a black arrow is placed on a button, right-click the button, to open other available buttons.


Notation

StateA 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 per-forming some behavior.s

(SHIFT+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.

(SHIFT+C)

Orthogonal StateAn orthogonal state is a composite state with at least 2 regions. (C)

UML DIAGRAMSState Machine Diagram9


Submachine StateThe submachine state specifies the insertion of the specification of a sub-machine 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)

Final StateDenotes an object destruc-tion or the end of a collabo-ration. (F)

Terminate

(R)

Entry PointThe 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 sub-machine state.

(Y)

Exit PointThe 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 con-nection point defined.

(U)


Notation

UML DIAGRAMSState Machine Diagram

494

9


Connection Point ReferenceThe Connection point refer-ences of a submachine state can be used as the sources/targets of the tran-sitions. They represent entries into or exits out of the submachine state machine referred by the submachine state.

(Z)

Deep History Represents the most recent active configuration of the composite state that directly contains the pseu-dostate; e.g. the state con-figuration that was active when the composite state was last exited.

(P)

Shallow HistoryRepresents the most recent active substate of its con-taining state (but not the substates of that substate). A composite state can have at most one shallow history vertex.

(SHIFT+R)

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.

(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)


Notation

UML DIAGRAMSProtocol State Machine Diagram9


Protocol State Machine DiagramA 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 clas-sifier, 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 opera-tions 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 Tran-sitions.

Protocol State Machine Diagram elementsNOTE

Fork/Join Vertical Helps to control parallel actions.

(G)

Fork/Join Horizontal Helps to control parallel actions.

(D)

TransitionThe starting time for a rela-tive time event may only be omitted for a time event that is the trigger of a state machine.

(T)

Transition to SelfWhen an object returns to the same state after the specified event occurs.

(E)


Notation

UML DIAGRAMSProtocol State Machine Diagram

496

9


If a black arrow is placed on a button, right-click the button to open other available buttons.


Notation

StateThe states of the protocol state machines are exposed to the users of their context classifiers. A protocol state represents an exposed stable situa-tion 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.

(SHIFT+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.

(SHIFT+C)

Orthogonal StateAn orthogonal state is a composite state with at least 2 regions. (C)

Submachine StateA submachine state speci-fies the insertion of the specification of a subma-chine 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)

UML DIAGRAMSProtocol State Machine Diagram9


Final StateDenotes an object destruc-tion or the end of a collabo-ration. (F)

Terminate

(R)

Entry PointThe 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 sub-machine state.

(Y)

Exit PointThe 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 con-nection point defined.

(U)

Connection Point ReferenceThe connection point refer-ences 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.

(Z)

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.

(J)


Notation

UML DIAGRAMSActivity Diagram

498

9


Activity DiagramAn 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 dia-gram 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

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.

(O)


(G)

Fork/Join Horizontal Helps to control parallel actions.

(D)

Protocol TransitionA protocol transition (transi-tion 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 trig-ger, 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.

(T)

Protocol Transition to SelfWhen an object returns to the same state after the specified event occurs. (E)


Notation

UML DIAGRAMSActivity Diagram9


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 busi-ness processes. Together with the collaboration and sequence diagrams, they are used to relate use cases.


500

9


Activity Diagram elements


Notation

Action An action is a named ele-ment that is the fundamen-tal 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 deter-mined by the concrete action and the behaviors in which it is used.

(B)

Call Operation ActionAn action that transmits an operation call request to the target object, where it may cause the invocation of the associated behav-ior. The argument values of the action are available to the execution of the invoked behavior.

(O)

Opaque ActionAn opaque action is intro-duced for implementing specific actions or for use as a temporary place-holder before some other actions are chosen.

Any ActionThis element is introduced in order to maintain any other desirable action ele-ment with an appropriate metaclass stereotype applied.

Object NodeThe 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 chil-dren for activity modeling in UML.

(SHIFT+B)



Data StoreA data store node is a cen-tral buffer node for a non-transient information. A data store keeps all tokens that enter it, copies them when they are chosen to move downstream. Incom-ing tokens containing a particular object replace any tokens in the object node containing that object.

(SHIFT+D)

Activity Parameter NodeIt 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.

Input Expansion NodeAn expansion node is an object node used to indi-cate 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 NodeA flow out of a region com-bines individual elements into a collection for use outside the region.

Object FlowIs 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)


Notation


502

9


Control FlowIs an edge that starts an activity node after the pre-vious one is finished. Objects and data cannot pass along the control flow edge.

(F)

Send Signal ActionIs 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.

(SHIFT+S)

Accept Event ActionIs 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.

(E)

Initial NodeAn initial node is a starting point for executing an activity. It has no incoming edges.

(T)

Activity FinalAn activity final node is a final node that stops all flows in an activity. (D)

Flow FinalThe Final node that termi-nates a flow and destroys all tokens that arrive at it. It has no impact on other flows in the activity.

(L)


Notation



DecisionDecision is a control node that chooses between out-going flows. A decision node has one incoming edge and multiple outgo-ing activity edges.

(G)

MergeA 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.

(G)

Fork/Join HorizontalHelps to control parallel actions.

(K)


(SHIFT+K)

Exception HandlerAn exception handler is an element that specifies a body to execute in case the specified exception occurs during the execu-tion of the protected node.

(P)

Structured Activity NodeA structured activity node is an executable activity node that may have an expansion into the subordi-nate nodes. The structured activity node represents a structured portion of the activity that is not shared with any other structured node, except for nesting.


Notation


504

9


Conditional NodeA conditional node is a structured activity node that represents an exclu-sive choice among alter-natives.

Sequence NodeA sequence node is a structured activity node that executes its actions in order.

Loop NodeA loop node is a structured activity node that repre-sents a loop with the setup, test, and body sec-tions.

Expansion RegionAn expansion region is a structured activity region that executes multiple times corresponding to the elements of an input col-lection.

Time EventA time event specifies a point of time by an expres-sion. The expression might be absolute or might be relative to someother points of time.


Notation



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.

Input PinAn 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.

(SHIFT+I)

Output PinA pin that holds output val-ues produced by an action. Output pins are object nodes that deliver values to other actions through object flows.

(SHIFT+O)

Value PinA value pin is an input pin that provides a value to an action that does not come from an incoming object flow edge.

SwimlanesSwimlanes are used to organize responsibility for actions and subactivities according to the class, dividing an activity dia-gram.

(SHIFT+V)

(SHIFT+W)


Notation


506

9


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

• 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.

Diagram orientation

The diagram orientation is used to assign the correct rectilinear path breaks and draw paths betweenthe activ-ity diagram shapes. The paths can be drawn from from side to side, or from the lower to the upper shape bor-ders.

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:

UML DIAGRAMSImplementation Diagram9


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 DiagramThe 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 repre-sent 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 por-trays the logical structure) in terms of code components and their relationships within the implementation envi-ronment. 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 map-ping 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 opera-tions.

UML DIAGRAMSImplementation Diagram

508

9


Deployment diagram overview

The Deployment diagrams show the physical layout of the various hardware components (nodes) that com-pose 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 com-puters 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.



Implementation Diagram elements


Notation

ComponentThe Component may be used to define the requirements for each physical software ele-ment.

(K)

Component InstanceAn instance of a compo-nent.

(A)

PortPorts represent interac-tion points between a classifier and its envi-ronment. A port has the ability to specify that any requests arriving at this port are handled.

(SHIFT+R)

NodeA Node is a physical object that represents a processing resource, generally having at least a memory and often the processing capability as well.

(O)

Execution EnvironmentThe element that is used to indicate that a node is the execution environment.

DeviceA physical computa-tional resource with the processing capability upon which artifacts may be deployed for an execution.


510

9


Node InstanceAn instance of a node.

(T)

Execution Environment InstanceThe element that is used to indicate that a node is an instance of the execution environ-ment.

Device Instance

PackageA group of classes and other model elements.

(P)

ArtifactAn artifact represents a physical piece of infor-mation that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An Arti-fact may constitute the implementation of a deployable component.

(B)

Deployment SpecificationIt indicates a set of prop-erties that defines how a component should be deployed.


Notation



Artifact Instance

Deployment Specification Instance

InterfaceAll functionalities imple-mented by a particular component. (F)

Interface RealizationThe classifier at the tail of the arrow imple-ments the interface that is located at the arrow head or uses that inter-face.Note: Choose a differ-ent Interface Realization direction from the tool-bar to draw a line with an opposite arrow end.

(R)

RealizationA realization signifies that the client set of ele-ments are an implemen-tation of the supplier set, which serves as the specification.

(E)

UsageA usage is a relation-ship in which one ele-ment requires another element (or set of ele-ments) for its full imple-mentation or operation.Usage is also used to create required inter-face.Note: Choose a differ-ent Usage direction from the toolbar to draw a line with an opposite arrow end.

(U)


Notation


512

9


InstanceAn instance specifies the existence of an entity in a modeled sys-tem and completely or partially describes the entity. It has a unique name, state, and classi-fier as the type of the identifier.

(SHIFT+O)

Assembly ConnectorAn assembly connector is a connector between two components that defines that one compo-nent provides the ser-vices that another component requires.

Delegation ConnectorA delegation connector is a connector that links the external contract of a component (as speci-fied by its ports) to the internal realization of that behavior by the component’s parts.

DeploymentA deployment is the allo-cation of a deployment target to an artifact or artifact instance.


Notation

9 UML DIAGRAMS - Hokusei Gakuen Universityz00102/SeminarI/2010/Lecture7/… · · 2010-05-31UML...

Documents

Transcript of 9 UML DIAGRAMS - Hokusei Gakuen Universityz00102/SeminarI/2010/Lecture7/… · · 2010-05-31UML...