11 Uniﬁed 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


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


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.


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


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


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


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.


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:


(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


Engineering. http://www.rational.com/uml, 1997.

[6] Rational Software, Microsoft, Oracle etc. UML Extension for BusinessModeling. http://www.rational.com/uml, 1997.

11 Uniﬁed Modeling Language

Documents

Transcript of 11 Uniﬁed Modeling Language