Unified Modeling Language (UML)

Rajesh Shakya 2007

What is UML?
UML = Unified Modeling Language A language for visualizing, specifying, constructing and documenting artifacts of software-intensive systems. Examples of artifacts: requirements, architecture, design, source code, test cases, prototypes, etc. UML is suitable for modeling various kinds of systems: 1) enterprise information systems, 2) distributed web-based, 3) real-time embedded system, etc.
2

UML Building Blocks

Three basic building blocks: 1) elements: main citizens of the model 2) relationships: relationships that tie elements together 3) diagrams: mechanisms to group interesting collections of elements and relationships They will be used to represent complex structures.

Elements
Can be classified in two categories: 1) elements used in structural diagrams 2) elements used in behavioral diagrams

Structural Elements
1) Artifact 2) Class 3) Collaboration 4) Collaboration Occurrence 5) Component 6) Deployment Specification 7) Interface 8) Node 9) Object 10) Package 11) Part 12) Port 13) Qualifiers
5

Behavioral Elements
1) Action 2) Activity 3) Actor 4) Boundary 5) Choice 6) Decision 7) Exception 8) Join 9) Lifeline 12) Use Case 10) Object 11) Package
6

Structural Elements
a) static part of the model to represent conceptual elements b) nouns of the model We illustrate: 1) class 2) interface 3) collaboration 4) component 5) node
7

Element 1: Class
1) description of a set of objects that share the same attributes, operations, relationships and semantics 2) implements one or more interfaces 3) graphically rendered as a rectangle usually including a name, attributes and operations 4) can be also used to represent actors, signals and utilities

Element 2: Interface
1) collection of operations that specifies a service of a class 2) describes the externally visible behaviour, partial or complete, of a class 3) defines a set of operation signatures but not their implementations 4) rendered as a circle with a name

Element 3: Collaboration
1) defines an interaction between elements 2) several elements cooperating to deliver a behavior, rather than individual behavior 3) includes structural and behavioral dimensions 4) represents implementations of patterns of cooperation that make up a system 5) represented as a named ellipse drawn with a dashed line

10

Element 4: Component
1) physical, replaceable part of a system that conforms to and provides the realization of a set of interfaces 2) represents deployment components such as COM+ or Java Beans components 3) represents a physical packaging of logical elements such as classes, interfaces and collaborations 4) it can also be used to represent applications, files, libraries, pages and tables

11

Element 5: Node
1) a physical element, exists at run time 2) represents a computational resource with memory and processing capacity 3) a set of components may reside in a node 4) components may also migrate from one node to another 5) graphically modeled as a cube

12

Behavioral Elements
a) represent behavior over time and space b) verbs of the model We illustrate: 6) use case 7) activity 8) actor 9) package
13

Element 6: Use Case

1) description of a sequence of actions that a system performs to deliver an observable result to a particular actor 2) used to structure the behavioral elements in a model 3) realized by collaboration 4) graphically rendered as an ellipse drawn with a solid line

14

Element 7: Activity
1) is the specification of a parameterized sequence of behavior 2) specifies the coordination of executions of subordinate behaviors, using a control and data flow model 3) may contain actions of various kinds:
occurrences of primitive functions, such as arithmetic functions. invocations of behavior, such as activities communication actions, such as sending of signals. manipulations of objects, such as reading or writing attributes or associations.

15

Element 8: Actor
1) is a user of the system, including:
a) a human user b) a machine c) another system

2) is anything that interacts with the system from the outside or system boundary 3) does not necessarily represent a specific physical entity:
a single physical entity may play the role of several different actors, a given actor may be played by multiple physical entities

16

Element 9: Package
Grouping element of UML: 1) organizes diagrams 2) primary kind of grouping and decomposition 3) conceptual, only available at development time 4) graphically represented as a tabbed folder

17

Relationships
Four basic types of relationships: 1) dependency 2) associations 3) generalization 4) realization Meanings are consistent with the basic Object Oriented relationship types described earlier.
18

Relationship 1: Dependency
A semantic relationship between two elements in which a change to one element (independent element) may affect the meaning of another (dependent element). Given as a directed dashed line possibly with a label:

19

Relationship 2: Association
1) a structural relationship describing a set of links 2) links are connections between objects 3) aggregation is a special type of association depicting the whole-part relationship 4) association is presented as a solid line, possibly directed, labeled and with adornments (multiplicity and role names)

20

Relationship 3: Generalization
1) a relationship in which objects of a specialized element (child) are substitutable for objects of a generalized element (parent) 2) child elements share the structure/behavior of the parent 3) rendered graphically as a solid line with hollow arrowhead pointing to the parent

21

Relationship 4: Realization
1) a semantic relationship between elements, wherein one element specifies a contract and another guarantees to carry out this contract 2) relevant in two basic scenarios:
a) interfaces versus realizing classes/components b) uses cases versus realizing collaborations

3) graphically depicted as a dashed arrow with hollow head, a cross between dependency and generalization

22

Diagrams
A diagram is a graph presentation of a set of elements and relationships where: a) nodes are elements b) edges are relationships Can visualize a system from various perspective, thus is a projection of a system.
23

Diagram Types

24

Diagram 1: Class
Class Diagrams: 1) show a set of classes, interfaces and collaborations, and their relationships 2) address static design view of a system

25

Class Diagram Example

26

Diagram 2: Object
Object Diagrams: 1) show a set of objects and their relationships 2) static snapshots of element instances found in class diagrams

27

Object Diagram Example

28

Diagram 3: Component
Component Diagrams: 1) show the organization and dependencies amongst a set of components 2) address static implementation view of a system 3) show how components map to one or more classes, interfaces and collaborations
29

Component Diagram Example

30

Diagram 4: Composite Structure

Composite Structure Diagrams: reflect the internal collaboration of classes, interfaces or components to describe a functionality. are used to express run-time architectures, usage patterns, and the participating elements' relationships.

31

Composite Structure Example

32

Diagram 5: Package
Package Diagrams: show the organization of packages and their elements provide a visualization of the namespaces.

33

Package Diagram Example

34

Diagram 6: Deployment
Deployment Diagrams: show configuration of run-time processing nodes and the components hosted on them address the static deployment view of an architecture are related to component diagram with nodes hosting one or more components
35

Deployment Diagram Example

36

Diagram 7: Use Case

Use Case Diagrams: show a set of actors and use cases, and their relationships address static use case view of the system are important for organizing and modeling the external behavior of the system

37

Use Case Diagram Example

38

Diagram 8: Activity
Activity Diagrams: show control/data flows from one activity to another address the dynamic view of a system, useful for modeling its functions emphasize the flow of control among objects
39

Activity Diagram Example

40

Diagram 9: State
State Diagrams: show a state machine consisting of states, transitions, events, and activities address the dynamic view of a system are important in modeling the behavior of an interface, class or collaboration emphasize the event-driven ordering
41

State Diagram Example

42

Diagram 10: Sequence

Sequence Diagrams: 1) show interactions consisting of a set of objects and the messages sent and received by those objects 2) address the dynamic behavior of a system with special emphasis on the chronological ordering of messages

43

Sequence Diagram Example

44

Diagram 11: Communication

Communication Diagrams: 1) show the interactions between elements at runtime 2) are used to visualize inter-object relationships. They are much like sequence diagrams: communication diagrams better for visualizing inter-object relationships sequence diagrams better for visualizing processing over time
45

Communication Diagram Example

46

Diagram 12: Timing

Timing Diagrams: 1) define the behavior of different objects within a time-scale 2) provide a visual representation of objects changing state and interacting over time 3) show the interaction between timed events and the time and duration constraints that govern them. Timing diagrams can be used for defining hardware-driven or embedded software components. They can also be used for specifying time-driven business processes.

47

Timing diagram example

48

Diagram 13: Interaction Overview

Interaction Overview Diagrams: 1) visualize the cooperation between other interaction diagrams to illustrate a control flow serving an encompassing purpose 2) are a variant of activity diagrams 3) can include sequence, communication, interaction overview and timing diagrams.
49

Interaction Overview Example

50

UML Summary 1
A model provides a blueprint of a system. UML is a language for visualizing, specifying, constructing and documenting artifacts of software-intensive systems. UML is process-independent but recommended for use with processes that are: 1) use case driven, 2) architecture-centric, 3) iterative, and 4) incremental.
51

UML Summary 2
There are three building blocks which characterize UML: 1) elements, 2) relationships, and 3) diagrams. Elements can be classified based on the diagrams they are used: 1) structural diagrams 2) behavioral diagrams There are four basic types of relationships in UML: dependency association generalization realization
52

UML Summary 3
UML provides 13 diagrams for modelling: 1) class diagrams 2) object diagrams 3) component diagrams 4) composite structure diagrams 5) package diagrams 6) deployment diagrams 7) use case diagrams 8) activity diagrams 9) state machine diagrams 10) sequence diagrams 11) communication diagrams 12) timing diagrams 13) interaction overview diagrams
53