11 Unified Modeling Language
Transcript of 11 Unified Modeling Language
11 Unified Modeling Language
Abstract The Unified Modeling Language (UML) is the most widely usedmodeling methods for software. It includes various views and diagrams fordifferent purposes and usages. Now, it is the core technique of Model DrivenArchitecture. the UML is also used to form conceptual models for variouskinds of objectives. The syntax and semantics of the UML for the object-oriented design are introduced in this chapter. A structured approach forUML models development is also discussed.
11.1 Introduction to UML
The Unified Modeling Language (UML) is a general-purpose graphic model-ing language. The purposes of UML include [1]:• To specify, visualize, construct, and document the artifacts of a software
system.• To understand, design, browse, configure, maintain, and control informa-
tion about software systems.• To be used with all development methods, lifecycle stages, application
domains, and media.UML unifies existing modeling techniques with current best practices of
software design and development, to form a standard approach. It includessemantic concepts, notation, and guidelines, which can support most existingobject-oriented development processes.
Similar to IDEF4, UML captures information about the static structureand dynamic behavior of a system.• The static structure defines objects and relationships among objects.• The dynamic behavior defines the history of objects over time and the
communications among objects.UML models a system from several separate but related viewpoints for dif-
ferent purposes. UML also provides a mechanism to arrange models into pack-ages, so that software development teams can divide large systems into work-able pieces, understand and control dependencies among the packages, andmanage the version of model units in a complex development environment[1].
UML is not a programming language, although various tools can pro-vide code generators from UML into programming languages. UML is not a
210 11 Unified Modeling Language
highly formal language for theorem proving and reasoning. It does not modelcontinuous systems. UML is a universal general-purpose modeling languagefor discrete systems (e.g., software, firmware, or digital logic, etc.).
11.2 Syntax and Semantics of UML 1©
UML defines a series of concepts, symbols and rules for object-oriented mod-eling. It also provides a mechanism to develop, optimize and implement rel-ative models. Views of UML include static view, design view, use case view,state machine view, activity view, interaction view, deployment view, modelmanagement view and profile with relative diagrams, as listed in Table 1.1.
11.2.1 Static View
Static View is the foundation of UML, which describes object structure. Inobject-oriented system, data structure and behavioral features are unifiedinto a single object structure. This view includes all concepts of traditionaldata structure, as well as operations on the data.
The key elements of the static view are classifiers and their relationships.Classifiers of static view include classes, interfaces, use cases, signals and soforth, as shown in Fig. 11.1. Relationships among classifiers are association,generalization, and various kinds of dependency, including realization andusage(see Fig. 11.2). Package is used to manage the contents of a model.
Similar to IDEF4, class in UML represents a discrete concept for a par-ticular kind of things (e.g., physical things, business things, logical things,application things, computer things, or behavioral things). An object is adiscrete entity with identity, state, and behavior. A class represents a set ofobjects with similar structure, behavior, and relationships. The notation fora class is a rectangle with compartments for the name of the class, attributes,and operations, as shown in Fig. 11.3.
The association relationship describes semantic connections amongindividual objects, with which objects of different classes can interact. Thenotation for an association is a line connecting the participating classes. Theassociation name is located along the line with the role name and multiplicityat each end, as shown in Fig. 11.4.
An aggregation represents a part-whole relationship. It is shown by ahollow-diamond symbol on the end of the line attached to the aggregate class.A composition is an association in which the composite has sole responsibilityfor managing its parts, such as their allocation and de-allocation [1]. It is
1©The structure, content and examples of the section reference Rumbaugh, Jacobson,and Booch’s book —The Unified Modeling Language Reference Manual (Second Edi-tion) —published by Addison-Wesley in 2004.
11.2 Syntax and Semantics of UML 211
Fig. 11.1. Kinds of Classifiers
Fig. 11.2. Kinds of relationships
Fig. 11.3. Class notation
shown by a filled-diamond symbol on the end of the line. Fig. 11.5 showsexamples of aggregation and composition.
The generalization relationship connects parent classifiers (superclasses)to child classifiers (subclasses), with which features inherited from superclassto its subclasses. Generalization and inheritance permit different classifiersto share the attributes, operations, and relationships. A generalization isdrawn as an arrow from the child to the parent, with a large hollow triangle
212 11 Unified Modeling Language
Course 0..*0..*
previous courses
next courses
Priority
Student
0..*
participant
selection
0..*
Association Name
Reflexive Association
Multiplicity
Binary Association
Participating Class
Rolename
Fig. 11.4. Association notation
Fig. 11.5. Aggregation and composition
on the end connected to the parent (see Fig. 11.6).
Fig. 11.6. Generalization notation
The realization relationship relates a specification to an implementation(see Fig. 11.7). It connects a model element, such as a class, to another modelelement, such as an interface, that supplies its behavioral specification butnot its structure or implementation [1].
An interface realized by a class is called a provided interface, because theclass provides the services of the interface to outside callers. This relationshipis shown by attaching a small circle to the class rectangle by a line; the circle
11.2 Syntax and Semantics of UML 213
Fig. 11.7. Realization relationship
is labeled with the name of the interface. An interface that a class usesto implement its internal behavior is called a required interface, which isshown by attaching a small semicircle to the class rectangle by a line [1]. SeeFig. 11.8.
Fig. 11.8. Provided and required interfaces
The dependency relationship relates classes whose behavior or implemen-tation affects other classes. There are several kinds of dependency, includingtrace dependency, refinement, usage, and binding. A dependency is drawnas a dashed arrow from the client to the supplier, with a stereotype keywordto distinguish its kind, as shown in Fig. 11.9.
Fig. 11.9. Dependencies
11.2.2 Design View
The design view shows decomposition of a system. It shows the reusableunits of the system, named components. A component has a set of externalinterfaces and a hidden, internal implementation.
A component is drawn as a rectangle with a small component icon in itsupper right corner. The name of the component is placed in the rectangle.A provided interface is drawn as a small circle connected to the componentby a line. A required interface is drawn as a small semicircle connected tothe component by a line. Fig. 11.10 shows an example.
214 11 Unified Modeling Language
Fig. 11.10. Component with interfaces
A port is an interaction point with a well-defined interface. The port maybe connected to internal parts, or connected directly to the main behaviorof the classifier. Each port has a set of provided interfaces and requiredinterfaces that define its external interactions. Messages received by a portare automatically forwarded to the part or behavior. Fig. 11.11 shows theports and interfaces for a projector.
Fig. 11.11. Structured class with ports
11.2.3 Use Case View
The use case view describes the behavior of a system, subsystem, class, orcomponent as it appears to an outside user (actor). The units of interactivefunctionality are named use cases. Actors include humans, other computersystems and processes.
A use case is drawn as an ellipse with its name inside. It is connected bysolid lines to actors that communicate with it.
A use case diagram describes an interaction with actors as a sequence ofmessages between the system and one or more actors. Fig. 11.12 shows a usecase diagram for a service platform system.
11.2.4 State Machine View
The state machine view describes the dynamic behavior of objects over timeby modeling the lifecycles of objects of each class.
A state is a set of object values for a given class that have the samequalitative response to events that occur [1]. A state machine describes a
11.2 Syntax and Semantics of UML 215
Fig. 11.12. Use case diagram
sequence of states that an object may hold. For each state, the state machinespecifies the consequences of receiving each kind of event as an effect and achange to a new state [1]. A state is shown as a rectangle with roundedcorners (see Fig. 11.13).
A state machine is a diagram of states and transitions. It is a model ofall possible life histories of an object of a class. In a state machine, a set ofstates is connected by transitions.
Fig. 11.13. State
A transition leaving a state defines the response of an object in the stateto the occurrence of an event. In general, a transition has an event trigger, aguard condition, an effect, and a target state. Fig. 11.14 is an example aboutlamp turning on and off.
11.2.5 Activity View
An activity is a diagram of nodes and flows that shows the flow of control(and optionally data) through the steps of a computation. Execution of stepscan be both concurrent and sequential.
An activity node is shown as a box with rounded corners containing adescription of the activity. A control flow is shown as an arrow. Branches
216 11 Unified Modeling Language
Fig. 11.14. State machine
are shown as guard conditions on control flows or as diamonds with multiplelabeled exit arrows. A fork or join of control is shown by multiple arrowsentering or leaving a heavy synchronization bar (see Fig. 11.15).
Fig. 11.15. Activity diagram
11.2 Syntax and Semantics of UML 217
11.2.6 Interaction View
Objects interact to implement behavior. This interaction can be describedin two ways: focused on individual objects or focused on a set of cooperatingobjects.
A sequence diagram displays an interaction as a two-dimensional chart.The vertical dimension is the time axis; time proceeds down the page. Thehorizontal dimension shows the roles that represent individual objects in thecollaboration. Each role is represented by a vertical column containing a headsymbol and a vertical line — a lifeline. During the time an object exists, itis shown by a dashed line. During the time an execution specification ofa procedure on the object is active, the lifeline is drawn as a double line.A message is shown as an arrow from the lifeline of one object to that ofanother. The arrows are arranged in time sequence down the diagram.
Fig. 11.16 shows a typical sequence diagram. In general, a sequencediagram shows only sequences of messages and not exact time intervals. Forunderstanding the semantics of interactions, sequence diagrams are usuallysufficient.
Fig. 11.16. Sequence diagram
A communication diagram models the objects and links involved in aninteraction. Messages among roles are shown as labeled arrows attachedto connectors. Each message has a sequence number, an optional guardcondition, a name and argument list, and an optional return value name. Thesequence number includes the (optional) name of a thread. All messages inthe same thread are sequentially ordered. Fig. 11.17 shows a communicationdiagram.
Communication diagrams and sequence diagrams both show interactions,but they emphasize different aspects. Sequence diagrams show time sequencesclearly but they do not show object relationships. Communication diagramsshow object relationships clearly, but time sequences must be obtained from
218 11 Unified Modeling Language
Fig. 11.17. Communication diagram
sequence numbers. Sequence diagrams are useful for showing scenarios; com-munication diagrams are useful for showing detailed design of procedures.
11.2.7 Deployment View
The deployment view shows the physical arrangement of nodes. A node isa run-time computational resource, such as computers or other applications.A node type is shown as a cube with its name. A node instance is shown asa cube with an underlined name string (includes a name and node type) (seeFig. 11.18).
11.2.8 Model Management View
A large system should be divided into smaller units so that designers canwork with a limited amount of information at one time and do not interferewith each other’s work. Model management consists of packages (includingspecial kinds of packages) and dependency relationships among packages.
A package is a part of a model. Every part of a model should belong toone package. Dependencies among packages summarize dependencies amongelements in them. That is, package dependencies are derivable from thedependencies among individual elements.
Packages are drawn as rectangles with tabs on them (desktop “folder”icons). Dependencies are shown as dashed arrows, as shown in Fig. 11.19.
11.2 Syntax and Semantics of UML 219
220 11 Unified Modeling Language
Fig. 11.19. Packages and their relationships
11.2.9 Profiles
UML provides several extension mechanisms to make extensions withoutmodifying the modeling language. Extensions are organized into profiles.A profile is a set of extensions applicable to a given domain or purpose. Theextensibility mechanisms are stereotype, tagged values, and constraints.
A stereotype is a kind of model element defined in the model itself. Itdefines tagged values to store additional characteristics that are not sup-ported by the base element. Stereotypes are shown as text strings surroundedby signs ( ) placed in or near the symbol for the base model element, asshown in Fig. 11.20.
A tag definition is a definition of an attribute for a modeling elementitself. It has a name and a type. A tag definition is owned by a stereotype.
A profile is a package that identifies a subset of an existing base meta-model and defines stereotypes and constraints that may be applied to theselected meta-model subset. It is intended to make limited extensions toUML to tailor it to a specific domain, technology, or implementation.
11.3 Structured Approach of UML 221
Fig. 11.20. Stereotypes
11.3 Structured Approach of UML
UML is an object-oriented modeling language. It is mainly applied in thefield of software engineering and is the main modeling tool for software design.However, UML can also play a key role in other domains.
Based on UML, Ivar Jacobson, James Rumbaugh and Grady Booch—thefounders of UML —developed a gyroidal, iterative, augmental methodologynamed Rational Unified Process (RUP).
RUP divides the software lifecycle into 4 sequential phases: inceptionstage, elaboration stage, construction stage and transition stage.
(1) Inception stageThe target of this stage is to form the business case for the system and
determine the boundary of the project. In order to fulfill the purpose, it isnecessary to identify all of the external entities interrelated with the systemand define the property of the interrelation in the high level.
(2) Elaboration stageThe target of this stage is to analyze the target domain, form the infras-
tructure, make the plan and avoid the highest risk of the project. In order toget to the goal, it is necessary to make decision on system framework basedon the understanding of the whole system, including case development, andthe forming of template, criteria and tools.
(3) Construction stageDevelop all components and applications’ functions, and integrate them
to release a product. All functions will be tested in detail. This stage isa producing process, it focuses on resource management, operation control,and optimization of cost, schedule and quality.
(4) Transition stageThis stage emphasize that the software is available for the finial users.
Transition has several iterative activities, including product testing andadjustment based on customers’ feedback.
RUP consists of 9 key workflows, in which 6 are the core process workflowsand 2 are the core supporting workflows. The stages in the iterative pattern isdifferent from that of water fall pattern, these workflows will be visited againand again along the project lifecycle with different emphases and intensity.The 9 key workflows are listed as follows:
222 11 Unified Modeling Language
(1) Business modeling(2) Requirements(3) Analysis and design(4) Implementation(5) Test(6) Deployment(7) Configuration and change management(8) Project management(9) EnvironmentIn each stage of RUP, it is connotative what kind of UML views and
models are used.Except for software development, UML is frequently used to embody the
meta-model of a system. Fig. 11.21 is the meta-model of IDEF3 syntax andsemantics and Fig. 11.22 is the meta-model of a modeling application for anall-purpose modeling task.
Fig. 11.21. Meta-model of IDEF3
References 223
Fig. 11.22. Meta-model of a modeling application
References
[1] Rumbaugh J, Jacobson I, Booch G. The Unified Modeling LanguageReference Manual, Second Edition. Addison-Wesley, 2004.
[2] Rational Software etc. UML Summary. http://www.rational.com/uml, 1997.
[3] Rational Software etc. UML Semantics. http://www.rational.com/uml,1997.
[4] Rational Software etc. UML Notation Guide. http://www.rational.com/uml,1997.
[5] Rational Software etc. UML Extension for Objectory Process for Software
224 11 Unified Modeling Language
Engineering. http://www.rational.com/uml, 1997.
[6] Rational Software, Microsoft, Oracle etc. UML Extension for BusinessModeling. http://www.rational.com/uml, 1997.