UML

• What is UML ?
• UML is a language for Documenting
• Building Blocks of the UML
 What Is UML

“The Unified Modeling Language(UML) is a graphical language

for visualizing, specifying, constructing, and documenting the
artifacts of a Software-intensive system.The UML offers a
standard way to write a system blueprints, including conceptual
things like business process and system function as well as
concrete things such as programming language statements,
database schemas, and reusable software components”
 UML is a language for Documenting

A healthy S/W organization produces all sorts of

artifacts in addition to raw executable code. These
artifacts include
• Requirements
• Architecture
• Design
• Source code
• Project plans
• Tests
• Prototypes
• Releases
 Building Blocks of the UML

The vocabulary of the UML encompass three kinds of building blocks

• Things
• Relationships
• Diagrams
 Things in the UML
Things in the real world are represented as objects, in the same way that things in
the constructed world are.

There are four kinds of things in UML:

• Structural things
• Behavioral things
• Grouping things
• Annotation things
 Structural things

Structural things are the nouns of UML models. These are mostly static
parts of a model, representing elements that are either conceptual or
physical. In all , there are 7 kinds of structural things.

• Classes
• Interfaces
• Collaborations
• Use Cases
• Active Classes
• Components
• Nodes
 Behavioral Things
Behavioral things are the dynamic parts of UML models.
These are the verbs of an model, representing behavior
over time and space. In all there are two primary kinds of
behavioral things.

• Interaction
• State machine
 Grouping Things
Grouping things are the organizational parts of UML
models. These are the boxes into which a model can be
decomposed. In all there is one primary kind of grouping
thing, namely, Packages

Annotational Things
Annotational things are the explanatory parts of UML
models. These are the comments you may apply to
describe.
Inheritance

1. Class B extends Class A

2. “is - a” , “type-of” relationship
3. Relation is shown by hollow arrow head
4.Class A is Generalized form of Class B
5.Class B is Specialized form of Class A
Realization
1. Class A implements interface B
2. Class realizes interface B
3. Relationship is shown by dotted line and
hollow arrow head pointing a interface
Association
1. Class A is associated with Class B
2. It is classified into Aggregation
Unidirectional
and Composition

Relationship is shown by continuous line

Bidirectional
Associations

1. Association can have name and you can use that name to describe the nature of
relationship
2. When a class participates in an association, it has a specific role which it can play
in the relationship.
3. You can show roles in diagram.
 Multiplicity

The above relationship can be read as following :

For each instance of course offering , there can be either 0 or 1 Professors or

instructors

For each instance of Professor , many course offerings may be taught.

Multiplicity should always be read from 1 to many .

Dependency

1. Class A depends on Class B.

2. Relationship is shown by dotted line and a arrow head.
3. Any change to independent thing will affect the dependent thing.
4. Any change is specification of class B may affect class A which uses it
but not viceversa.
5. This relationship can be shown between packages.

(source) (target)
Aggregation

1. Type of Association
2. Represents a whole part relationship. It’s a “has-a ” relationship.
3. Relationship is represented by a hollow diamond and continous line
4. Diamond is towards whole part
5. A has B as a part of it.
6. A exists even if B is deleted
7. Loose bonding
8. For example : Assembly – Parts : Aircraft - Engine
Composition

1. Type of association
2. Represents a whole part relationship.It’s a “has-a” relationship.
3. Relationship is represented by shaded diamond and a continuous line
4. Diamond is towards whole part
5. A consists of B.
6. A gets deleted when B is deleted. It’s a on-delete cascade
7. Tight bonding.
8. For example : Library : Books -- Whole : Parts
Overriding

1. If we show a method in Parent class as well as Derived class.

2. It implies that Overriding is depicted in the class diagram.

If the method is not shown in derived class then it

implies that derived class has that method from parent class
Rose diagram of a Class
1. The diagram shows a class Operation.
2. Variable name is of String datatype with access specifier as Private.
3. Method3() has a return type as Long with access specifier as Private.
4. Private is shown in Rational Rose as a lock symbol.
5. Variable age is of Long datatype with access specifier as Protected.
6. Method2() has a return type as Double with access specifier as Protected.
7. Variable status is of Boolean datatype with access specifier as Public.
8. Method1() has a return type as Boolean with access specifier as Public.

In UML

+ Public
- Private
# Protected
Rose Facility

On suppressing the attributes class looks like the following

On suppressing operations and attributes class looks like the following

 UML Notations

Package Component Note

Name

Textual
content

Analysis Analysis Analysis UseCase Actor

Entity Class Boundary Class Control
Class

Action
OOA
Object Oriented Analysis

1. This is problem phase

2. Ask question WHAT ?????
3. WHAT is it that the system should do ?
4. WHAT will be the classes ?
5. WHAT will the classes do ? ( functionality aspect )
6. WHAT will be relationships between classes ?

OOD

Object Oriented Design

1. This is solution phase

2. Ask question HOW ?????
3. HOW will classes handle responsibility ?
4. HOW will the classes communicate with each other ?
5. HOW will I define attributes and methods ?
6. HOW will be the implementation ?
Structural View

1. This has Object and class diagrams .

2. Static in nature

Implementation View
1. This has Component diagram.

Environment View

1. This has Deployment diagram.

Behavioral View

1. Sequence Diagram
2. Collaboration Diagram
3. State Chart Diagram.
4. Activity Diagram.
5. All of the above represent Dynamic behavior.
Use Case Analysis

1. Emphasize on finding external behavior of system.

2. Determine all possible users and actors.
3. Determine interaction between actors and services.
4. Describe each use case in terms of scenario.
5. Determine relationships if any , between Use Cases.
6. Use Case implies Functionality.
7. Direction of arrow in Use Case diagram shows initiation of data flow.
8. Don’t consider Acknowledgments , Exception in Use Case diagram .
9. Exception is data driven.
10. Generally humans have unidirectional use case.
11. Actors can be shown with inheritance.
12. Actors are roles to be shown.
Use Case Relationships

1. Relationship shown is extend between Buy Merchandise and Browse use case.
2. EXTENDS implies optional relationship.
3. Any of the following situation will occur.
3.a User will login and browse the online shopping site and leave.
3.b User will login , browse and Buy Merchandise.
4. So we can interpret this as Buy only after browsing .
5. Browse but don’t buy.
6. Use this when you think its ADD-ON to existing functionality.
Use Case Relationships

1. Relationship shown here is include.

2. INCLUDE implies compulsory.
3. Customer Order use case sends data to Delivery centre regarding details of order.
4. Customer Order use case must have knowledge of Payment Details use case.
 Relationships shown in Use Case diagram

Some other relationships which can be shown in Use case diagram.

Indicates bidirectional relationship One user extending other user

Sequence Diagrams Interaction Diagrams

1. They show a set of objects and messages sent and received by those
objects.
2. The objects are named or anonymous instances of classes.
3. Distinguishing features of these diagrams are object lifeline and focus of
control.
4. Object lifeline : It shows existence of a object over a period of time. It’s a
vertical dashed line.
5. Focus of Control : It’s a tall , thin , rectangle that shows period of time
during which object is performing an action , either directly or through
subordinate procedure. The top of rectangle is aligned with start of
procedure and bottom with completion.
6. You can show recursion , self operation .
7. This diagram is with respect to time.
8. Models dynamic aspect of systems.
Collaboration Diagrams Interaction Diagrams

1. They show the interaction between objects.

2. You can render the links that connect the objects and adorn these
links with messages that objects send and receive.
3. Special features of these diagrams are path and sequence number.
4. Path : Indicates how one object is linked to another.
5. Sequence number : To indicate the order of message flow. [ 1 is the
first message . 1.1 is the first nested message in message 1 . Similarly
for 1.2 ]
6. Iteration can be shown by interaction expression [ I := 1…n ]
7. To model a condition , prefix sequence number by say [ x > 0 ]
8. Models dynamic aspect of systems.
Activity Diagrams

1. Used for modeling dynamic aspect of system.

2. Shows the flow from activity to activity . Activities result in some action
which can result in a change in state of system.
3. Initial state of activity is shown by solid ball and stop state by solid ball
in a circle.
4. Similar to flowchart you can include a branch which specifies alternate
paths based on some condition.
5. Fork represents the splitting of a single flow of control into 2 or more
concurrent flows of control. Below the fork we show activities in parallel.
6. We can show sequential or concurrent flows.
7. Join represents synchronization of two or more concurrent flows. It can
have two or more incoming transitions and once outgoing transition.
Above the join activities can go on in parallel.
8. Forking and Joining is shown by Synchronization bar and its shown by
a thick horizontal line.
9. Number of flows that leave a fork should match number of flows that
enter a join.
10. You can partition activity diagrams into groups. Each group is called
swim lane as groups can be divided vertically. Each swim lane has a
unique name.
State Chart Diagrams

1. For modeling dynamic aspects of system.

2. Used for modeling lifetime of object.
3. Models flow of control from event to event.
4. It contains Simple and composite states.
5. Stable state of an object is the one in which the object may live for a period of
time.
6. Events that trigger a transition from state to state and actions that occur on
each state change can be depicted.
7. In reaction to event or a state change , object may respond by dispatching an
action.
Component Diagrams

1. It shows the organization dependencies among a set of components.

2. Deployment components : these are necessary and sufficient to form an
executable system such as (DLL’s , Exe’s).
3. Work product components: these are residue of development process , such as
code files , data files from which deployment components are created.
4. Execution components: these are created as a consequence of an executing
system , such as COM+ object , which is instantiated from DLL.
5. Stereo Types for components :
5.1 executable : component that may be executed
5.2 library : static or dynamic object library
5.3 table : database table
5.4 file : document containing source code or data .
6. Main purpose of of using components is to model the deployment
components.
Deployment diagrams

1. They are used to model physical aspects of a system.

2. Models static deployment view of system. Topology of hardware.
3. Useful in communication between project’s hardware engineers and
software engineers.
4. Dependency and Association relationships can be shown.
5. Typically we show servers , local network , console etc. in this diagram.
Run Payroll
Brief Description
The Use case describes how the payroll is run every Friday and the last working day of the
month.
Flow of Events
The use case begin when it’s time to run the payroll. The Payroll is run automatically
every Friday and the last working day of the month.
1.The System retrieves all employees who should be paid on the current date.
2.The system calculates the pay using entered timecards, purchase order, employee
information(e.g. salary, benefits, etc.) and all legal deduction.
3.If the payment delivery method is mail or pick-up, the system prints a paycheck.
4.If the payment delivery method is direct deposit, the system creates a bank transaction
and sends it to the Bank System for Processing.
5.The use case ends when all employees receiving pay for the desired date have been
processed.
Use Case Diagram
Class Diagram
Sequence Diagram
Collaboration Diagram
Deployment Diagram
State Diagram