Lecture Notes On UML UNIT-IV - ssmengg.edu.in sem/OOAD... · Subject: OOAD Semester: 8TH Course No: CSE-802 KHALID AMIN AKHOON 2 UML Diagrams: In UML 2.0 there are 13 types of diagrams.

Subject: OOAD Semester: 8TH Course No: CSE-802

KHALID AMIN AKHOON 1

Lecture Notes

On

UML

UNIT-IV UML DIAGRAMS: TERMS AND CONCEPTS, RELATIONSHIP, DIAGRAMS.

ADVANCED CLASS DIAGRAM: ADVANCED RELATIONSHIP, INTERFACE TYPES

AND RULES, PACKAGES COMMON MODELLING TECHNIQUES, MODELLING

GROUPS ELEMENTS, MODELLING ARCHITECTURAL VIEWS. - INSTANCES AND

OBJECT DIAGRAMS: MODELLING CONCRETE/PROTOTYPICAL INSTANCES.

LINKS, OBJECTS INTERATION. -COLLABORATIONS, USE CASES,

INTERACTION DIAGRAMS, STATE TRANSITION DIAGRAMS. –

ARCHITECTURAL MODELLING: COMPONENT DIAGRAM, DEPLOYMENT

DIAGRAM, PATTERN AND FRAME WORK.



UML Diagrams:

In UML 2.0 there are 13 types of diagrams. To understand them, it is

sometimes useful to categorize them hierarchically:

Structure Diagrams emphasize what things must be in the system being

modeled:

Class diagram

Component diagram

Composite structure diagram

Deployment diagram

Object diagram

Package diagram

Behavior Diagrams emphasize what must happen in the system being

modeled:

Activity diagram

State Machine diagram

Use case diagram

Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of

control and data among the things in the system being modeled:

Interaction overview diagram (UML 2.0)

*Communication diagram (Collaboration Diagram)

Sequence diagram

UML Timing Diagram (UML 2.0)





Class Diagrams:

A Class defines the attributes and the methods of a set of objects. All objects

of this class (instances of this class) share the same behavior, and have the

same set of attributes (each object has its own set).

The term “Type” is sometimes used instead of Class, but it is important to

mention that these two are not the same, and Type is a more general term. In

UML, Classes are represented by rectangles, with the name of the class, and

can also show the attributes and operations of the class in two other

“compartments” inside the rectangle.

Graphical Notation, example:



POS System



Advanced Classes:

Classes are indeed the most important building block of any object-oriented

system. However, classes are just one kind of an even more general building

block in the UML• classifiers. A classifier is a mechanism that describes

structural and behavioral features. Classifiers include classes, interfaces,

datatypes, signals, components, nodes, use cases, and subsystems.

Classifiers (and especially classes) have a number of advanced features

beyond the simpler properties of attributes and operations described in the

previous section: You can model multiplicity, visibility, signatures,

polymorphism, and other characteristics. In the UML, you can model the

semantics of a class so that you can state its meaning to whatever degree of

formality you like.

In the UML, there are several kinds of classifiers and classes; it's important

that you choose the one that best models your abstraction of the real world.

Advance Classes

The UML provides a representation for a number of advanced properties, as

Figure shows. This notation permits you to visualize, specify, construct, and

document a class to any level of detail you wish, even sufficient to support

forward and reverse engineering of models and code.



A classifier is a mechanism that describes structural and behavioral features.

Classifiers include classes, interfaces, datatypes, signals, components, nodes,

use cases, and subsystems.

The most important kind of classifier in the UML is the class. A class is a

description of a set of objects that share the same attributes, operations,

relationships, and semantics. Classes are not the only kind of classifier,

however. The UML provides a number of other kinds of classifiers to help you

model.

Graphically, the UML distinguishes among these different classifiers, as shown

in the below figure.



Classifiers:

Visibility:

A classifier can see another classifier if it is in scope and if there is an explicit

or implicit relationship to the target.

Scope:

Another important detail you can specify for a classifier's attributes and

operations is its owner scope. The owner scope of a feature specifies whether

the feature appears in each instance of the classifier or whether there is just a

single instance of the feature for all instances of the classifier. In the UML, you

can specify two kinds of owner scope.



Abstract and Concrete Classes and Operations



Component Diagram:

Component diagrams show the organization and dependencies among a

group of components. Component diagrams comprise of:

Components

Interfaces

Relationships

Packages and Subsystems (optional)

Component diagrams are used for:

Constructing systems through forward and reverse engineering.

Modeling configuration management of source code files while

developing a system using an object-oriented programming language.

Representing schemas in modeling databases.

Modeling behaviors of dynamic systems.

Example

The following figure shows a component diagram to model a system’s source

code that is developed using C++. It shows four source code files, namely,

myheader.h, otherheader.h, priority.cpp, and other.cpp. Two versions of

myheader.h are shown, tracing from the recent version to its ancestor. The

file priority.cpp has compilation dependency on other.cpp. The file other.cpp

has compilation dependency on otherheader.h.



Composite structure Diagrams:

A composite structure diagram is a diagram that shows the internal structure

of a classifier, including its interaction points to other parts of the system. It

shows the configuration and relationship of parts, which together, perform the

behavior of the containing classifier. Class elements have been described in

great detail in the section on class diagrams. This section describes the way

classes can be displayed as composite elements exposing interfaces and

containing ports and parts.



Part:

A part is an element that represents a set of one or more instances which are

owned by a containing classifier instance. So for example, if a diagram

instance owned a set of graphical elements, then the graphical elements could

be represented as parts; if it were useful to do so, to model some kind of

relationship between them. Note that a part can be removed from its parent

before the parent is deleted, so that the part isn't deleted at the same time.

A part is shown as an unadorned rectangle contained within the body of a

class or component element.

Port:

A port is a typed element that represents an externally visible part of a

containing classifier instance. Ports define the interaction between a classifier

and its environment. A port can appear on the boundary of a contained part, a

class or a composite structure. A port may specify the services a classifier

provides as well as the services that it requires of its environment.

A port is shown as a named rectangle on the boundary edge of its owning

classifier.



Interfaces:

An interface is similar to a class but with a number of restrictions. All interface

operations are public and abstract, and do not provide any default

implementation. All interface attributes must be constants. However, while a

class may only inherit from a single super-class, it may implement multiple

interfaces.

An interface, when standing alone in a diagram, is either shown as a class

element rectangle with the «interface» keyword and with its name italicized to

denote it is abstract, or it is shown as a circle.

Note that the circle notation does not show the interface operations. When

interfaces are shown as being owned by classes, they are referred to as

exposed interfaces. An exposed interface can be defined as either provided or

required. A provided interface is an affirmation that the containing classifier

supplies the operations defined by the named interface element and is defined

by drawing a realization link between the class and the interface. A required

interface is a statement that the classifier is able to communicate with some

other classifier which provides operations defined by the named interface

element and is defined by drawing a dependency link between the class and

the interface.

A provided interface is shown as a "ball on a stick" attached to the edge of a

classifier element. A required interface is shown as a "cup on a stick" attached

to the edge of a classifier element.



Delegate:

A delegate connector is used for defining the internal workings of a

component's external ports and interfaces. A delegate connector is shown as

an arrow with a «delegate» keyword. It connects an external contract of a

component as shown by its ports to the internal realization of the behavior of

the component's part.

Collaboration:

Collaboration defines a set of co-operating roles used collectively to illustrate

a specific functionality. Collaboration should only show the roles and attributes

required to accomplish its defined task or function. Isolating the primary roles

is an exercise in simplifying the structure and clarifying the behavior, and also



provides for re-use. Collaboration often implements a pattern. A collaboration

element is shown as an ellipse.

Role Binding:

A role binding connector is drawn from collaboration to the classifier that

fulfils the role. It is shown as a dashed line with the name of the role at the

classifier end.

Represents:

A represents connector may be drawn from collaboration to a classifier to

show that collaboration is used in the classifier. It is shown as a dashed line

with arrowhead and the keyword «represents».



Occurrence:

An occurrence connector may be drawn from collaboration to a classifier to

show that collaboration represents the classifier. It is shown as a dashed line

with arrowhead and the keyword «occurrence».

Deployment diagram:

A deployment diagram puts emphasis on the configuration of runtime

processing nodes and their components that live on them. They are

commonly comprised of nodes and dependencies, or associations between

the nodes. Deployment diagrams are used to:

Model devices in embedded systems that typically comprise of software-

intensive collection of hardware.

Represent the topologies of client/server systems.

Model fully distributed systems.

Example

The following figure shows the topology of a computer system that follows

client/server architecture. The figure illustrates a node stereotyped as server

that comprises of processors. The figure indicates that four or more servers

are deployed at the system. Connected to the server are the client nodes,

where each node represents a terminal device such as workstation, laptop,

scanner, or printer. The nodes are represented using icons that clearly depict

the real-world equivalent.



Object Diagram:

An object diagram models a group of objects and their links at a point of

time. It shows the instances of the things in a class diagram. Object diagram

is the static part of an interaction diagram.

Example: The following figure shows an object diagram of a portion of the

class diagram of the Banking System.



Package Diagram:

Package diagrams are used to reflect the organization of packages and their

elements. When used to represent class elements, package diagrams provide

a visualization of the namespaces. The most common use for package

diagrams is to organize use case diagrams and class diagrams, although the

use of package diagrams is not limited to these UML elements.

The following is an example of a package diagram.

Elements contained in a package share the same namespace. Therefore, the

elements contained in a specific namespace must have unique names.

Packages can be built to represent either physical or logical relationships.

When choosing to include classes in specific packages, it is useful to assign

the classes with the same inheritance hierarchy to the same package. There is

also a strong argument for including classes that are related via composition,

and classes that collaborate with them, in the same package.

Packages are represented in UML 2.1 as folders and contain the elements that

share a namespace; all elements within a package must be identifiable, and



so has a unique name or type. The package must show the package name and

can optionally show the elements within the package in extra compartments.

Package Merge:

A «merge» connector between two packages defines an implicit generalization

between elements in the source package, and elements with the same name

in the target package. The source element definitions are expanded to include

the element definitions contained in the target. The target element definitions

are unaffected, as are the definitions of source package elements that don't

match names with any element in the target package.

Package Import:

The «import» connector indicates that the elements within the target

package, which in this example is a single class, use unqualified names when

being referred to from the source package. The source package's namespace

gains access to the target classes; the target's namespace is not affected.

Nesting Connectors:

The nesting connector between the target package and source packages

shows that the source package is fully contained in the target package.



Behavior Diagrams:

Activity diagram:

Overview:

Activity diagram is another important diagram in UML to describe dynamic

aspects of the system. Activity diagram is basically a flow chart to represent

the flow form one activity to another activity. The activity can be described

as an operation of the system. So the control flow is drawn from one

operation to another. This flow can be sequential, branched or concurrent.

Activity diagrams deals with all type of flow control by using different

elements like fork, join etc.

Purpose:

The basic purposes of activity diagrams are similar to other four diagrams. It

captures the dynamic behavior of the system. Other four diagrams are used

to show the message flow from one object to another but activity diagram is

used to show message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not only

used for visualizing dynamic nature of a system but they are also used to

construct the executable system by using forward and reverse engineering

techniques. The only missing thing in activity diagram is the message part.

It does not show any message flow from one activity to another. Activity

diagram is some time considered as the flow chart. Although the diagrams

looks like a flow chart but it is not. It shows different flow like parallel,

branched, concurrent and single.



So the purposes can be described as:

Draw the activity flow of a system.

Describe the sequence from one activity to another.

Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities

performed by the system. But activity diagram are not exactly a flow chart as

they have some additional capabilities. These additional capabilities include

branching, parallel flow, swim lane etc.

Before drawing an activity diagram we must have a clear understanding

about the elements used in activity diagram. The main element of an activity

diagram is the activity itself. An activity is a function performed by the

system. After identifying the activities we need to understand how they are

associated with constraints and conditions.

So before drawing an activity diagram we should identify the following

elements:

Activities

Association

Conditions

Constraints

Once the above mentioned parameters are identified we need to make a

mental layout of the entire flow. This mental layout is then transformed into

an activity diagram.

The following is an example of an activity diagram for order management

system. In the diagram four activities are identified which are associated with

conditions. One important point should be clearly understood that an activity



diagram cannot be exactly matched with the code. The activity diagram is

made to understand the flow of activities and mainly used by the business

users.

The following diagram is drawn with the four main activities:

Send order by the customer

Receipt of the order

Confirm order

Dispatch order

After receiving the order request condition checks are performed to check if it

is normal or special order. After the type of order is identified dispatch

activity is performed and that is marked as the termination of the process.



• Activity diagram commonly contains

o Activity states & action states

o Transitions

o Objects

Action states & Activity states:

Action states represent the non interruptible actions of objects which can’t be

further decomposed & takes insignificant execution time.

Activity states can be further decomposed, their activity being represented by

other activity diagram. Also activity states are not atomic, so they may be

interrupted & takes some time to complete.

There is no notational distinction between action & activity states, except that an

activity state may have additional parts, such as entry & exit action.

Action Flow:

Action flow arrows illustrate the relationships among action states.



Object Flow:

Object flow refers to the creation and modification of objects by activities.

An object flow arrow from an action to an object means t hat the action creates or

influences the object.

An object flow arrow from an object to an action indicates that the action state

uses the object.

Branching:

A diamond represents a decision with alternate paths. The outgoing alternates

should be labeled with a condition or guard expression. You can also label one of

the paths "else."



Symbols used in Activity Diagram



Where to use Activity Diagram?

The basic usage of activity diagram is similar to other four UML diagrams.

The specific usage is to model the control flow from one activity to another.

This control flow does not include messages.

The activity diagram is suitable for modeling the activity flow of the system.

An application can have multiple systems. Activity diagram also captures

these systems and describes flow from one system to another. This specific

usage is not available in other diagrams. These systems can be database,

external queues or any other system.

Now we will look into the practical applications of the activity diagram. From

the above discussion it is clear that an activity diagram is drawn from a very

high level. So it gives high level view of a system. This high level view is

mainly for business users or any other person who is not a technical person.

This diagram is used to model the activities which are nothing but business

requirements. So the diagram has more impact on business understanding

rather implementation details.

Following are the main usages of activity diagram:

Modeling work flow by using activities.

Modeling business requirements.

High level understanding of the system's functionalities.

Investigate business requirements at a later stage.



State Machine diagram:

A state–chart diagram shows a state machine that depicts the control flow of

an object from one state to another. A state machine portrays the sequences

of states which an object undergoes due to events and their responses to

events. State–Chart Diagrams comprise of:

States: Simple or Composite

Transitions between states

Events causing transitions

Actions due to the events

State-chart diagrams are used for modeling objects which are reactive in

nature.

Example

In the Automated Trading House System, let us model Order as an object

and trace its sequence. The following figure shows the corresponding state–

chart diagram.



Example of vending Machine

Waiting

do/ Display Menu to Insert Coin

Selection

do/ Display Message Select Drink...

Dispensing

do/ Dispence drinkSelect Drink[ ckeck available ] / Display Message

Select Drink[ not available ]

Receive Drink

Insert Coin[ valid ] / Make Selection

Insert Coin[ invalid ]

Purchase Drink



Use case diagram:

Use case diagrams present an outside view of the manner the elements in a

system behave and how they can be used in the context.

Use case diagrams comprise of:

Use cases

Actors

Relationships like dependency, generalization, and association

Use case diagrams are used:

To model the context of a system by enclosing all the activities of a

system within a rectangle and focusing on the actors outside the

system by interacting with it.

To model the requirements of a system from the outside point of view.

Requirements Capture

Building Blocks of a Use Case Diagram

o Actors

o Use Cases

o Relationships between Use Cases

Actors:

A role that interacts with the system.

Represents a role, not individuals; can be a person or a device or

another system.

Communicate with the system by sending and/or receiving messages.

An actor may participate in many use cases; a use case may have

several actors participating in it.



Use-Case:

Is an abstraction of a set of sequences that yield some functionality?

Represents some user-visible function.

Is always initiated by an “actor”.

Describes the interaction between the actors and the system for a

system function.

Achieves a discrete goal for the actor.

Relationships between Use Cases:

Uses/Includes

Extends

“Extend” relationship: «extend»

Use Case B extends Use Case A when Use Case B describes the

behavior of Use Case A under a particular condition.

An extending Use Cases is used to describe variations in the

normal flow of events described by a general use case



“Include” relationship: «include»

Use Case A uses (or “uses”) Use Case B when Use Case B is a

behavior/functionality that is required by Use Case A. That

behavior has been factored out into a separate Use Case because

it is required across several use cases.

Common behavior in several use cases can be factored out into a

single use case that is used by the other use cases



Example:

Let us consider an Automated Trading House System. We assume the

following features of the system:

The trading house has transactions with two types of customers,

individual customers and corporate customers.

Once the customer places an order, it is processed by the sales

department and the customer is given the bill.

The system allows the manager to manage customer accounts and

answer any queries posted by the customer.



Interaction overview diagram (UML 2.0):

An interaction overview diagram is a form of activity diagram in which the

nodes represent interaction diagrams. Interaction diagrams can include

sequence, communication, interaction overview and timing diagrams. Most of

the notation for interaction overview diagrams is the same for activity

diagrams. For example, initial, final, decision, merge, fork and join nodes are

all the same. However, interaction overview diagrams introduce two new

elements: interaction occurrences and interaction elements.

Interaction Occurrence:

Interaction occurrences are references to existing interaction diagrams. An

interaction occurrence is shown as a reference frame; that is, a frame with

"ref" in the top-left corner. The name of the diagram being referenced is

shown in the center of the frame.

Interaction Element:

Interaction elements are similar to interaction occurrences, in that they

display a representation of existing interaction diagrams within a rectangular

frame. They differ in that they display the contents of the references diagram

inline.



Putting it all Together:

All the same controls from activity diagrams (fork, join, merge, etc.) can be

used on interaction overview diagrams to put the control logic around the

lower level diagrams. The following example depicts a sample sale process,

with sub-processes abstracted within interaction occurrences.



Interaction Diagrams:

Interaction diagrams depict interactions of objects and their relationships.

They also include the messages passed between them.

There are two types of interaction diagrams:

Communication diagram (Collaboration Diagram)

Sequence Diagram

Interaction diagrams are used for modeling:

The control flow by time ordering using sequence diagrams.

The control flow of organization using collaboration diagrams.

Communication Diagram:

A communication diagram, formerly called a collaboration diagram, is an

interaction diagram that shows similar information to sequence diagrams but

its primary focus is on object relationships.

In communication diagrams, objects are shown with association connectors

between them. Messages are added to the associations and show as short

arrows pointing in the direction of the message flow. The sequence of

messages is shown through a numbering scheme.

The following diagrams are the examples of communication diagram.



Customer Coin Reader

System interface

Dispencer

2: Check coin

7: Checking

1: Insert coin

3: Request for menu

4: Display menu

5: select item

6: Check for availability

8: Acknowledgement of availablility10: Recieved item 9: Request of item



Sequence Diagrams:

Sequence diagrams are interaction diagrams that illustrate the ordering of

messages according to time. Notations:

These diagrams are in the form of two-dimensional charts. The objects that

initiate the interaction are placed on the x–axis. The messages that these

objects send and receive are placed along the y–axis, in the order of

increasing time from top to bottom.

Sequence Diagrams: the basic elements:

Class roles:

Class roles describe the way an object will behave in context. Use the UML

object symbol to illustrate class roles, but don't list object attributes.

Activation:

Activation boxes represent the time an object needs to complete a task.



Messages

Messages are arrows that represent communication between objects. Use

half-arrowed lines to represent asynchronous messages. Asynchronous

messages are sent from an object that will not wait for a response from the

receiver before continuing its tasks.

Lifelines:

Lifelines are vertical dashed lines that indicate the object's presence over

time.



Destroying Objects:

Objects can be terminated early using an arrow labeled "< < destroy > >"

that points to an X.

Loops:

A repetition or loop within a sequence diagram is depicted as a rectangle.

Place the condition for exiting the loop at the bottom left corner in square

brackets [ ].



Vending Machine Sequence Diagram

Customer Coin Reader System interface

Dispencer

Insert coin Check coin

Request for menu

Display menu

select item Check for availabilityChecking

Acknowledgement of availablility

Request of item

Recieved item





UML Timing Diagram (UML 2.0):

Timing Diagrams:

UML timing diagrams are used to display the change in state or value of one

or more elements over time. It can also show the interaction between timed

events and the time and duration constraints that govern them.

State Lifeline:

A state lifeline shows the change of state of an item over time. The X-axis

displays elapsed time in whatever units are chosen, while the Y-axis is labeled

with a given list of states. A state lifeline is shown below.

Value Lifeline:

A value lifeline shows the change of value of an item over time. The X-axis

displays elapsed time in whatever units are chosen, the same as for the state

lifeline. The value is shown between the pair of horizontal lines which crosses

over at each change in value. A value lifeline is shown below.



Putting it all Together:

State and value Lifelines can be stacked one on top of another in any

combination. They must have the same X-axis. Messages can be passed from

one lifeline to another. Each state or value transition can have a defined

event, a time constraint which indicates when an event must occur, and a

duration constraint which indicates how long a state or value must be in effect

for. Once these have all been applied, a timing diagram may look like the

following.

Pattern:

Patterns help you to visualize, specify, construct, and document the artifacts

of a software intensive system. You can forward engineer a system by

selecting an appropriate set of patterns and applying them to the abstractions

specific to your domain. You can also reverse engineer a system by

discovering the patterns it embodies, although that's hardly a perfect process.

Even better, when you deliver a system, you can specify the patterns it

embodies so that when someone later tries to reuse or adapt that system, its

patterns will be clearly manifest.



Framework:

A framework is an architectural pattern that provides an extensible template

for applications within a domain. For example, one common architectural

pattern you'll encounter in real time systems is a cyclic executive, which

divides time into frames and sub frames, during which Processing takes place

under strict deadlines. Choosing this pattern versus its alternatives (an even-

driven architecture) colors your entire system. Because this pattern (and its

alternative) is so common, it makes sense to name it as a framework

Reference Books:

1. Booch/rambaugh, Jachobson-UML User guide, Addison Wesley.

2. Rambaugh: Object Oriented modeling and design PHI

Online References:

1. http://www.sparxsystems.com/resources/uml2_tutorial

2. https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_oriented_ana

lysis.htm

Lecture Notes On UML UNIT-IV - ssmengg.edu.in sem/OOAD... · Subject: OOAD Semester: 8TH Course No: CSE-802 KHALID AMIN AKHOON 2 UML Diagrams: In UML 2.0 there are 13 types of diagrams.

Documents