Pawan Modi

Senior R&D Engineer

May 19, 2008 Senior R&D Engineer Page 1

Agenda

• OOAD Overview
• UML Introduction
• Elements of UML
• Usecase Diagram
• Class Diagram
• Sequence Diagram
• Collaboration Diagram
• Summary

May 19, 2008 Senior R&D Engineer Page 2

OOAD Overview
 OOAD emphasis on finding & describing objects, their attributes & relation
among objects.

 Example: Flight Information System

 Object “Flight” may have tailNumber attribute & getFlightHistory
method.

 Object-oriented techniques enhance key external and internal software

quality factors
 External (visible to end-users)
○ Correctness
○ Robustness and reliability
○ Performance

 Internal (visible to developers)

○ Modularity
○ Flexibility / Extensibility
○ Reusability
○ Compatibility

May 19, 2008 Senior R&D Engineer Page 3

Iterative & Agile Modelling
 Iterative Development:
 Contrasted with a sequential or waterfall lifecycle.
 Early programming & testing of partial system.
 Development start before all requirement are identified.
 Feedback to improve quality to meet project goal.
 Short development steps.

Agile Modelling:
 Idea is to understand but not to document. Documentation is
secondary but not the primary task.
 Purpose of models & modeling is primarily to support
understanding & communication not documentation.

May 19, 2008 Senior R&D Engineer Page 4

UML Introduction
 UML stands for “Unified Modelling Language”.
 UML is a standard visual modeling language.
 It is a industry-standard graphical language for
specifying, visualizing, constructing, and
documenting the artifacts of software systems.
 The UML uses mostly graphical notations to express
the OO analysis and design of software projects.
 Simplifies the complex process of software design.
 Unified process is an Iterative development process
with 2-6 week iteration.
 UML is a unified process.

May 19, 2008 Senior R&D Engineer Page 5

UML Phases & Disciplines


May 19, 2008 Senior R&D Engineer Page 6

Elements of UML
UML defines 13 basic diagram types divided into two general sets.

 Structural Modelling Diagrams

○ Package diagram
○ Class or structure diagram
○ Object diagram
○ Composite diagram
○ Component diagram
○ Deployment diagram
 Behavioural Modelling Diagrams
○ Use Case diagram
○ Activity diagram
○ State Machine diagram
○ Collaboration diagram
○ Sequence diagram
○ Timing diagram
○ Interaction Overview diagram

May 19, 2008 Senior R&D Engineer Page 7

Usecase Diagram
 A set of scenarios that describing an interaction
between a user and a system.
 Mainly used for capturing user requirements.
 Demonstrate how people will use the
application.
 Shows interaction between the system and
entities external to the system where external
entities are referred as actors.
 System boundary represents the boundary
between the actors and the system.
 Usecase is represented using oval symbol.

May 19, 2008 Senior R&D Engineer Page 8

Usecase Diagram Notations
Actor is anything with behavior, including system under discussion (SUD)
which calls upon the services of other system.

 Primary Actor
○ Primary actor has user goals to fulfill through services of the SUD.
 Eg. Cashier use POS machine, User using LR-Portal.

 Supporting Actor:
○ Supporting actor provides a service to the SUD.
 Eg. CAS & LDAP provides support to LR-Portal.

 Offstage Actor:
○ Offstage actor has an interest in the behavior of the usecase but is
not the primary or supporting
 Eg. Tax agency, Billing Module etc.

May 19, 2008 Senior R&D Engineer Page 9

Usecase Diagram Components
Conti..
Relationship
 Association: communication between an actor
and a use case is represented by a solid line.

 Generalization: relationship between one

general use case and a special use case.
Represented by a line with a triangular arrow
head toward the parent use case.

May 19, 2008 Senior R&D Engineer Page 10

Usecase Diagram Components
Conti..
Include: A use cases may contain the
functionality of another use case. In
general it is assumed that any included use
case will be called every time the basic path
is run.

Dotted line labelled <<include>> beginning

at base use case and ending with an arrows
pointing to the include use case.

May 19, 2008 Senior R&D Engineer Page 11

Usecase Diagram Components
Conti..
Extend: One use case may be used to extend the
behaviour of another usecase. This is typically
used in exceptional circumstances.
Dotted line labelled <<extend>> with an arrow
toward the base case. The extending use case
may add behaviour to the base use case.
For example, if before modifying a particular
type of customer order, a user must get approval
from some higher authority, then the <Get
Approval> use case may optionally extend the
regular <Modify Order> use case.

May 19, 2008 Senior R&D Engineer Page 12

Usecase Diagram Components
Conti..

May 19, 2008 Senior R&D Engineer Page 13

Class Diagram
 Class diagram represent the building
blocks of any object-orientated
system.
 Depict a static view of the model.
 Shows relationships between classes and interfaces
 Used for describing structure and behaviour in the use
cases.
 Provide a conceptual model of the system in terms of entities
and their relationships.
 Used for requirement capture, end-user interaction.
 Detailed class diagrams are used for developers.

May 19, 2008 Senior R&D Engineer Page 14

Class Diagram Notations
 Class: each class is represented by a rectangle subdivided
into three compartments
 Name
 Attributes
 Operations
 Modifiers are used to indicate visibility
of attributes and operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (friends and derived)
 ‘-’ is used to denote Private visibility (no one)
 By default, attributes are hidden and operations are visible
 Note: Abstract class can be shown by the italicized name.

May 19, 2008 Senior R&D Engineer Page 15

Class Diagram Notations Conti..
 Interface: An interface is a specification
of behaviour that implementers agree to
meet.

May 19, 2008 Senior R&D Engineer Page 16

Class Diagram Notations Conti..
 There are two kinds of Relationships

 Generalization
○ Example “parent-child relationship”.

 Association
○ Example “student enrolls in course”.
○ Aggregation.
○ Composition.

May 19, 2008 Senior R&D Engineer Page 17

Class Diagram Notations Conti..
 Generalization:
 A generalization is used to indicate
inheritance.

May 19, 2008 Senior R&D Engineer Page 18

Class Diagram Notations Conti..
 Association:
 Association is the general relationship type between
elements. Association has two ends with role-name,
multiplicity & navigability.

 When code is generated for class diagrams, association

name become instance variables in the target class.
Example: "playsFor" will become
an instance variable in the "Player" class.

May 19, 2008 Senior R&D Engineer Page 19

Class Diagram Notations Conti..
 Associations can be further classified as
• Aggregation
○ Aggregations are used to depict elements which are made up
of smaller components.
○ Aggregation relationships are shown by a white diamond-
shaped arrowhead pointing towards the target or parent class.
○ Specific kind of container-containee relationship.
• Composition
○ Composition is a stronger form of aggregation.
○ Composition are shown by a black diamond-shaped
arrowhead and is used where components can be included in
a maximum of one composition at a time.
○ Specific kind of whole part relationship.

May 19, 2008 Senior R&D Engineer Page 20

Class Diagram Notations Conti..
 The following diagram illustrates the difference between
aggregation & composition.
 An address book is made up of a multiplicity of contacts and
contact groups.
 A contact group is a virtual grouping of contacts
 A contact may be included in more than one contact group.
 If you delete an address book, all the contacts and contact
groups will be deleted too
 If you delete a contact group, no contacts will be
deleted.

May 19, 2008 Senior R&D Engineer Page 21

Sequence Diagram
 A sequence diagram is a form of
interaction diagram.
 Sequence diagrams shows which
objects communicate with which other
objects and what messages trigger
those communications.
 Shows objects with their interactions
over time represented as messages
drawn as arrows from the source lifeline
to the target lifeline

May 19, 2008 Senior R&D Engineer Page 22

Sequence Diagram Notations
 Lifeline:
 A lifeline represents an individual participant
in a sequence diagram.
 A lifeline will usually have a rectangle
containing its object name.

May 19, 2008 Senior R&D Engineer Page 23

Sequence Diagram Notations
Conti..
 Message:
 Messages are displayed as arrows.
 Messages can be complete, lost or found;
synchronous or asynchronous; call or signal.
 First message is a synchronous message
(denoted by the solid arrowhead) complete with
an implicit return message.
 Second message is asynchronous
(denoted by line arrowhead).
 Third message is asynchronous return
message (denoted by the dashed
line).

May 19, 2008 Senior R&D Engineer Page 24

Sequence Diagram Notations
Conti..
 Self Message:
 Represent a recursive call of an operation.
 One method calling another method belonging to
the same object.
 It is shown as creating a nested focus of control.

Lost and Found Messages:

 Lost messages are those that are either sent but
do not arrive at the intended recipient
 Found messages are those that arrive from an
unknown sender

May 19, 2008 Senior R&D Engineer Page 25

Sequence Diagram Notations
Conti..
 Object Creation & Deletion:
 Object may be created or destroyed.
 Symbol at the head of the lifeline is shown at
a lower level down the page than the symbol
of the object that caused the creation.
 Object is terminated by a stop symbol
represented as a cross.

May 19, 2008 Senior R&D Engineer Page 26

Sequence Diagram Notations
Conti..
 Duration and Time Constraints :
 Time is important in real-time system & time-
bound business process.
 It is important to consider the length of time
it takes to perform actions.
 Duration constraint messages will be
shown as a sloping line.

May 19, 2008 Senior R&D Engineer Page 27

Sequence Diagram Notations
Conti..
 Loop:
 Loop fragment encloses a series of
messages which are repeated.

May 19, 2008 Senior R&D Engineer Page 28

Collaboration Diagram
 Collaboration diagram also called as communication
diagram.

 Collaboration diagram is an interaction diagram that

shows similar information to sequence diagrams but its
primary focus is on object relationships.

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

May 19, 2008 Senior R&D Engineer Page 29

Collaboration Diagram Conti..

May 19, 2008 Senior R&D Engineer Page 30

UML TIPS
 Try to write blace box usecases.

 Finding Usecases:
○ Choose system boundary.
○ Identify the primary actor & its goal.
○ Define UCs that satisfy goals of primary actor.

 Finding Actors:
○ Ask yourself the following questions to find actor.
○ Who use system? Who start & stop system? Who does user
& security management? Who does system administration?,
Who evaluate system activity or performance? Who evaluate
logs? Is there is any monitoring process that restart the
system if it fail?

May 19, 2008 Senior R&D Engineer Page 31

Summary
 UML is a standard visual modeling language.
 A set of scenarios that describing an interaction between a
user and a system is called Usecase.
 Usecases are represented using oval symbol.
 Anything with behaviour who fulfil its goals using SUD is
called Actor.
 Static view of model is represented by class diagram.
 Different kinds of relationships among the classes are
association, generalization, aggregation & composition.
 Diagram that represent run time view or communication
between objects is called sequence diagram.
 The messages in sequence diagram can be sync, async
or return message.
 Collaboration diagram is also kind of interaction diagram.

May 19, 2008 Senior R&D Engineer Page 32

References
Online Tutorial

 http://uml.tutorials.trireme.com/
 http://www.sparxsystems.com.au/resources/
uml2_tutorial/index.html
 http://www.borland.com/

Book:
Applying UML & Patterns – Craig Larmen

May 19, 2008 Senior R&D Engineer Page 33

 Question ??

Kindly send all your queries to the following id

modipawan8126@gmail.com

May 19, 2008 Senior R&D Engineer Page 34

  Thank you!

May 19, 2008 Senior R&D Engineer Page 35