CSE232:ADVANCE SOFTWARE ENGINEERING

CSE221: OBJECT-ORIENTED ANALYSIS AND

DESIGN

UNIFIED MODELING LANGUAGE (UML)

 What is UML?
● UML stands for Unified Modeling Language is a standard
language (notation) for specification, construction, visualization,
and documentation of the artifacts of a software-intensive system
● Notation is a collection of graphical symbols for expressing model
of the system
● Created and maintained by the Object Management Group
(OMG), http://www.omg.org/uml/
● UML is intentionally not a method, mainly because methods need
to consider the specific framework and conditions of the
application domain, the organizational environment ... UML can
serve as a basis for different methods, as it provides a well-defined
set of modeling constructs with uniform notation and semantics
 UML Advantages
● Provide structure for problem solving
● Reduce time-to-market for business problem solutions
● Decrease development costs
● Manage the risk of mistakes
● Graphical notation is much better than words
● Provides a standard communication language
● Provides multiple diagrams for capturing different architectural views (13
diagrams)
● Promotes component reusability
● Capture the logical software architecture independent of the
implementation language
UML-2 Diagrams
USE-CASE Diagram
 USE-CASE Diagram
● A use case diagram establishes the capability of the system
as a whole from the user’s point of view

● Components of use case diagram:

● Actor
● Use case
● System boundary
● Use cases relationships
● Actors’ relationships
 USE CASE Diagrams - Actor
● Actors model entities external to the system. it can be a person,
organization, or external system that plays a role in one or more
interactions with your system
● UML default notation for actor is stickman
● It can optionally be represented by a user defined icon for non-
human actors

<<actor>>
Customer
User
Manager

Default Notation Optional Notation Optional Notation

Most commonly used Commonly used for non-

notation human actors
 USE CASE Diagrams – Use Case
● Each use case is a sequence of related actions
performed by an actor and the system in a dialogue
● A use case typically represents a major piece of
functionality that is complete from beginning to end
● Use case is represented by a horizontal ellipsis in UML,
with its name either inside the oval or underneath it

Open new account

Cash Withdrawal
 USE CASE Diagrams – Use Case
● Determining use cases:
● What functions will the actor want from the system?
● Does the system store information?
● What actors will create, read, update, or delete that information?
● Does the system need to notify an actor about changes in its
internal state?
● Associations between actors and use cases are indicated in
use case diagrams by solid lines. An association exists
whenever an actor is involved with an interaction described by a
use case.
● System boundary boxes (optional), represented by a rectangle
around the use cases to indicates the scope of your system.
Anything within the box represents functionality that is in scope
and anything outside the box is not.
 USE CASE Diagrams – Example
System (subject) name

Use Cases
Use case name

Actor name

Association
Actor Actors
s

System boundary
Association
 USE CASE Diagrams – Use Case Relationships
● Relationships in use case diagrams is divided into two
categories
● Actor relationships: relationships between actors
➢ if you wish to portray that actors interact among each other
➢ Generally they do not represent any direct requirements on the system
to be produced, but they clarify the overall situation and the context of
the use case
➢ Association, generalization/specialization, aggregations or
compositions … etc. can be used
● Use case relationships: Relationships between use cases
➢ <<extend>>
➢ <<include>>
➢ inheritance
 USE CASE Diagrams – Use Case Relationships
<<extend>>
– is a generalization relationship where an extending use case
continues the behavior of a base use case.
– The extending use case accomplishes this by conceptually inserting
additional action sequences into the base use-case sequence. This
allows an extending use case to continue the activity sequence of a
base use case when the appropriate extension point is reached in
the base use case and the extension condition is fulfilled. When the
extending use case activity sequence is completed, the base use
case continues. The important point here is that the extending use
case behavior is not always added to the base use case but there
should be a condition that fulfils for this inclusion.
 USE CASE Diagrams – Use Case Relationships
<<include>>
● It is a generalization relationship denoting the inclusion of all the
behavior described by another use case in the base use case.
● It can also be considered as an invocation of a use case by
another one. You use include dependencies whenever one use
case needs the behavior of another.
● Inheritance
– Use cases can be inherited from other use cases, offering a third
opportunity to indicate potential reuse. The inheriting use case
would completely replace one or more of the courses of action of the
inherited use case whenever needed
USE CASE Diagrams – Use Case Relationships

<<extend>> relationship

Inheritance relationship

<<include>> relationship
USE CASE Diagrams – Example
 USE CASE Description
● Use case diagrams doesn’t provides the details of the
sequence of activities associated with each use case.
● Hence, a narrative description of the sequence of steps
is needed
● It is written in natural language, there is no standard to
write but content-related structuring is recommended
● Each step should clearly show who is carrying out the
step
● Steps should show the intent of the actor not the
mechanics of what the actor does
USE CASE Description
USE CASE Description: include
USE CASE Description: include
USE CASE Description: Inheritance
USE CASE Description: Inheritance
USE CASE Description: Inheritance
USE CASE Description: extend
USE CASE Description: extend
USE CASE Description: extend
 UML Diagrams
● Use case diagrams represent the functions of a system
from the user’s point of view
● Class diagrams represent the static structure in terms of
classes and relationships
● Object diagrams represent objects and their
relationships, and correspond to simplified collaboration
diagrams that do not represent message broadcasts
● Sequence diagrams are temporal representation of
objects and their interactions
● Collaboration diagrams are spatial representation of
objects, links, and interactions
 UML Diagrams
● State chart diagrams represent the behavior of a
class in terms of states
● Activity diagrams are to represent the parallel
behavior of an operation as a set of actions
● Component diagrams represent the logical
components of an application
● Deployment diagrams represent the deployment of
components on particular pieces of hardware
 Class Diagram
● Class diagram shows the static structure of an object-oriented
model: classes, internal structure, relationships … etc.
● The topmost compartment contains the name of the class. The
middle compartment contains a list of attributes (member
variables), and the bottom compartment contains a list of
operations (member functions).
● Sometimes, the bottom two compartments are omitted. Even when
they are present, they typically do not show every attribute and
operations. This occurs if the goal is to show only those attributes
and operations that are useful for the particular diagram.
 Class Compartments
Class Name
Bold
Singular
Class Name Employee
Starts with a capital letter
name:
address:
String
dateOfBi th:
String
employeeNo:
r Integer
Date
Attributes socialSecurityNo: String
depa tment:
manager:
r DeptEmployee
sala y:
taxCode:
r Integer
Integer
setName(name: String): Boolean
leave ()
Operations retire
changeAddress
() (address: String): Boolean
 Attributes
● An attribute is a (data) element which is contained in the
same way in each object of a class and is represented by
each object with an individual value.

• Synta
x attributeName:Package::Class Multiplicity = InitialValue {TaggedValues}
Visibility

Public
Attribute type(+) visible and usable for all

Private (-) only the class itself and the classes declared as friend can
access private
Needed if the attribute Tagged values are user-defined, language- and tool-specific keyword/value pairs
attributes
is not mandatory
which extend the semantics of individual model elements with specific
[0, 1] Means the attribute
Protected is optional
(#) access is allowed to the class
characteristic itself, its subclasses, and the
properties.
classes
[1] This is the defaultdeclared as friend
{readonly}
[*] Zero or more, can be used with array{attr >attributes
0}
Normally all attributes are mandatory
 Derived Attributes
● Derived attributes. Attributes that are calculated
automatically. The calculation prescription is specified in the
form of a constraint
● Specification of an initial value does not apply
● Derived attributes are marked by a prefixed slash (/)
● Example

/age : Integer {age = today – birthDate}

 Attributes Examples
● name : String = 'Unknown'
● birthDate : Date
● radius : Integer = 25 {readonly}
● /age : Integer {age = today – birthDate}
● –versionNo : Integer
● time : DateTime::Time
● dynamArray[*]
● name : String[1]
● firstName : String[0,1]
● firstNames : String[1..5]
 Operations
● Operations are services which may be required from an
object. They are described by their signature; operation
name, parameters, and, if needed, return type.

• Synta
x name (type argument : ArgumentType = DefaultValue, ...): ReturnType {TaggedValues}
Visibility

Public +
Specify the direction
Begins Tagged
withofa the values
lower case are user-defined, language- and tool-specific keyword/value pairs
letter
Private - argument which extend the semantics of individual model elements with specific characteristic
Protected # in properties.

out {abstract}
{obselete}
inout
 Operations Examples
● getPosition(x, y)
● getPosition(out x : Integer, out y : Integer)
● resize(byFactor : Real): GeomFigure
● +addPhoneNumber(phoneNumber : String, type : CallType =
#Fax)
● payIn(in amount : Amount):Amount
 Notes in UML
● Notes are comments to a diagram or an arbitrary element in a
diagram, without any semantic effect
● Notes enable annotations, comments, explanations, and
additional descriptive text to be made to any UML model
elements, e.g. to classes, attributes, operations, relationships,
… etc.

Note
 Relationships
Most common relationship types between classes are:
● Association
● Aggregation
● Composition
● Dependency
● Generalization
 Relationships: Association
● Association represents a semantic connection among
classes

Association Name

Student makes Project

Association

Class
Class
 Relationships: Aggregation
● A special form of association that models a whole-part
relationship between an aggregate (the whole) and its parts
● The parts can survive without the whole and the whole can exist
without the parts
Whole Part

Pond Duck
contains

Aggregation
 Relationships: Composition
● A form of aggregation with strong ownership and coincident
lifetimes
● For example: airplane and wings since airplane cannot exist
without wings. Also, airplane and engine, building and room …
etc.
Whole Part

University Department
has

Composition
 Association: Multiplicity and Navigation
• Multiplicity defines how many objects participate in a
relationships
– The number of instances of one class related to ONE
instance of the other class
– Specified for each end of the association
• Associations, aggregations, and composition are bi-
directional by default, but it is often desirable to restrict
navigation to one direction
– If navigation is restricted, an arrowhead is added to indicate
the direction of the navigation

– Invoice can access the address, but the address does not know
with which invoices it is associated
 Association: Multiplicity

• Unspecified
• Exactly one
• Zero or more (many,
unlimited)

• One or more
• Zero or one
• Specified range
• Multiple, disjoint ranges
Association: Multiplicity and Navigation Example

Multiplicity

Park 0..1 0..* Car

Navigation
 Relationships: Dependency
● A relationship between two model elements where a change in
one (independent) may cause a change in the other
(dependent)
● For example “using” relationship

Dependent Class Independent Class

Client Supplier

Dependency
relationship
 Relationships: Generalization
● A relationship among classes where one class shares
the structure and/or behavior of one or more classes
● Defines a hierarchy of abstractions in which a
subclass inherits from one (single inheritance) or more
superclasses (multiple inheritance)
● Generalization is an “is-a-kind-of” relationship as
seen from the child class with respect to the parent
class(es)
Relationships: Generalization
Ancestor class
(Superclass)
Account
balance
nam
numbe
e
r
Withdraw(
CreateStatement()
) Generalization
Relationship

Checkin Savings
g
Withdraw( GetInterest()
Withdraw(
)
)
Descendent classes
(Subclasses)
 What Gets Inherited?
● A subclass inherits its ancestor's attributes,
operations, and relationships
● A subclass may:
● Add additional attributes, operations, relationships
● Redefine inherited attributes or operations
● Common attributes, operations, and/or
relationships should be shown at the highest
applicable level in the hierarchy
 Example: Multiple Inheritance

FlyingThing Anima
l

Multiple
inheritance

Airplan Helicopter Bird Wol Hors

e f e
 Example: What Gets Inherited
● Car inherits weight and Transportation
licenseNumber attributes from speed
GroundVehicle capacity
● Car inherits speed and capacity setSpeed( )
attributes from Transportation
● Car inherits register() operation from
GroundVehicle
● GroundVehicle inherits speed and GroundVehicle Aircraft
capacity attributes from weight numberOfEngines
Transportation licenseNumber
getSeatLimit( )
● GroundVehicle inherits setSpeed() register( )
operation from Transportation
● AirCraft inherits speed and capacity
attributes from Transportation Truck
Car
size tonnage
● AirCraft inherits setSpeed()
operation from Transportation getTax( )
 Overriding Inheritance
Overriding: The process of replacing a method inherited from a
superclass by a more specific implementation of that method in a
subclass

Restrict job placement

 Abstract and Concrete Classes
Tagged Value Or
Abstract class: {abstract} Class name in
italics
An abstract class is Abstract
never used to generate Shape Class
object instances; it is draw( )
intentionally incomplete
and thus forms the basis
of further subclasses Circle Triangle Rectangle
diameter base length
which can have draw( ) height height
instances. draw( )
rotate( )
draw( )
move(()

Concrete class: Concrete Classes

is a class that can be
instantiated
Class Diagram Example
 State Diagram (State Chart)
● State diagram shows a sequence of states an object
can assume during its lifetime, together with the
stimuli that cause changes of state.
● It consists of:
● A finite, non-empty set of states
● A finite, non-empty set of events
● State transitions
● An initial state
● A set of final states
 State Diagram (State Chart)
● A state belongs to a single class and represents an
abstraction or a combination of a set of possible attribute
values of objects of this class.
● No transition may lead to an initial state, and no event allows
leaving the final state.
● States have either unique names or they are anonymous
states with no names.
● Anonymous states are different from each other, i.e. two
unnamed states in a diagram are two different states.
● In all other cases, states bearing the same name are actually
the same state.
 State Diagram: Representation

Named States
(All of them represent the same state)

Anonymous States
(Two different states)

Initial and Final States

 State Diagram: Representation
• The behavior compartment can mainly take the following actions (all of
them are optional):
Entry/ behavior details
Do/ behavior details
Exit/ behavior details
• Entry and Exit behavior cannot be interrupted, Entry occurs once you
enters the state, while Exit occurs once you exit from the state.
• Do can be interrupted by state transition triggers.
• If there is no state transition triggers the transition occurs once all the
behaviors occur.
• If there is no transition and there is a guard condition the transition
occurs once all the behaviors occur and the guard condition is true
otherwise no transitions occur.
 State Diagram: Events and Transitions
• An event is an occurrence which has a particular significance
in a given context and it triggers a state transition.
• An event may have the following causes:
• A condition (defined for a transition) is satisfied.
• A message sent to the object.
• Events are represented by arrows leading from one state to
the next.
 State Diagram: Events and Transitions
• On the arrows, the transition descriptions are noted in the following
form:
Trigger
[Guard Condition]
/Behavior

• The Guard Condition is a Boolean expression that evaluates to

either True or False, if it evaluates to True, the behavior is
performed and then the transition occurs.
• The behavior can be the name of an operation, or it can be
formulated freely.
• It may contain state variables, attributes of the class, or parameters
of the incoming transitions.
State Diagram: Initial and Final States
 State Diagram: Transitions

Guard blocks transition if it is False

Guard blocks models the choice between transition paths

Transition occurs because of the completion of internal behavior

 State Diagram: States and Transitions

If state diagram is drawn for an object, the states represent different

values of the state variables of the object (its attributes). While the
behaviors represent methods that should be fired when the state
variables change their values.
State Diagram: Pseudo States
State Diagram: Time Events

Time event
Sequence Diagram
 Sequence Diagram: Messages

Message Format: attribute = messageName(arguments): returnType

Arguments Format: [<name>:class, ...]
Sequence Diagram: Nested Messages
Sequence Diagram: Message Arrows
Sequence Diagram: Synchronous Messages
Sequence Diagram: Asynchronous Messages
Sequence Diagram: Creation and Destruction of Participants
Collaboration Diagram
Collaboration Diagram: Messages
Collaboration Diagram: Messages
Collaboration Diagram: Messages
Collaboration Diagram: Example
Component Diagram
Component Diagram: Provided and Required Interfaces
Component Diagram: Interface Representation
Component Diagram: Connecting Components
Activity Diagram
Activity Diagram: Activities and Actions
Activity Diagram: Decisions
Activity Diagram: Merges
Activity Diagram: Parallel Tasks
Activity Diagram: Fork and Join
Activity Diagram: Call Activity
Activity Diagram: Swimlane
Activity Diagram: Time Events