Object-Oriented Software

Engineering

Chapter II- Modeling using

UML
Understanding modeling tools in
system/software development

1
 Chapter II- Topics
Overview- The UML
Functional Model
Use Case Diagram (essential and system)
Structural Model
Class/object, Component and Deployment
Diagram
Behavioral Models
Activity, State chart, sequence /collaboration

2
 Overview- The UML

3
 OO METHODOLOGIES
 During the early 90s, there were around 50 O-O
methodologies among them:
 Rumbaugh’s Object Modeling Technique (OMT):
Class and Associations – OOA and OOD
 Shlaer-Mellor (Object-Oriented Analysis/Design
(OOA/D),
 Booch Method : Categories and Subsystems - Diagrams
 Wirfs-Brock (Responsibility-Driven Design /Class
/Responsibility /Collaboration) RDD/CRC,
 Coad/Yourdon Methodology : Class, Object, Class-&-
Object
 Jacobson Object-Oriented Software Engineering
(OOSE) Use case driven

4
 PROBLEMS
The existence of different OO methodologies
resulted in the following problems:
Resulted in multitude interpretation of
same concepts
Encouraged confusion
Limited the progress of methods
Methods influenced one another

5
 THE NEED FOR
STANDARDIZATION
 There are many methods and notations
competing with each other that users are
distracted by the decisions they need to
make.
 Existingmethods are already converging
since these methods pick up ideas from other
sources.
 A single, common language is desirable
because it can be used for all development
methods, used throughout the project lifecycle,
and used for different application technologies.
6
 THE UNIFICATION
Based on the fact that differences between
the various methods were becoming
smaller.
The method wars did not move OOT any
longer.
Jim Rumbaugh and Grady Booch decided at
the end of 1994 to unify their work within
a single method: the Unified Method.
 Definition of a universal language for O-O
modeling
 Unified Method 0.8 Oct. 1995

7
 THE UNIFICATION…
 A year later they were joined by Ivar
Jacobson
 Objective: Standardization of the o-o
development process
 The Unified Method was transformed into
UML- the Unified Modeling Language
 6/96 UML 0.9
 9/96 UML 0.91
 A consortium of partners created

8
9
 THE UNIFIED MODELLING LANGUAGE
(UML)
 A language whose vocabulary and rules
focus on the conceptual and physical
representation of a system.
 UML defines structural and behavioral
things and diagrams.
 UML is the language of blueprints for
software.

10
 UML…
It is a graphical language for
Visualizing
Specifying – building models that are precise,
unambiguous, and complete
Constructing – possible to map from a model
in the UML to a programming language
Documenting
Intended for software-intensive systems

11
 WHAT UML IS NOT
UML is not a method or methodology
(Method = Notation (e.g.,UML) +
Process)
UML does not dictate a particular
process
UML can be used to record the
resulting domain and design models,
independent of the process
Choose an appropriate process for a
particular project, independent of the
modeling language

12
 WHY USE UML
Standardized notation without sacrificing
specialized model data
Common language that can be used from
product conception to delivery, from
system to detailed design levels
Reduced learning curve across projects
Increased domain and design model reuse
Increased customer involvement
/understanding of problem translation to
product solution

13
 UML STRUCTURE
UML

Building Common Architecture

mechanisms
blocks
 Building blocks  Architecture
 things  use-case view
 relationships  logical view
 Diagrams  process view
 Common mechanisms  implementation
 specifications view
 Adornments (decoration)  deployment view
 common divisions
 extensibility mechanisms

14
 The Unified Modeling Language
(UML)
UML has three building blocks:
Things, the objects.
Relationships, the glue that holds things
together.
Diagrams, categorized as either structure or
behavioral.

15
 UNDERSTANDING UML
 BUILDING BLOCKS OF UML
1. Things – the abstractions
1. Structural things – nouns, static,
represent conceptual or physical elements:
Class, interface, collaboration, use case, active
class, component, and a node
2. Behavioural things – verbs, dynamic,
represent behaviour over time and space:
Interaction and state machine
3. Grouping things – organizational parts of
UML: Packages
4. Annotational things – explanatory parts
16 of UML: Note
 BUILDING BLOCKS OF UML…
2. Relationships – tie things together
A. Dependency (uses) – a semantic
relationship between two things in which
a change to one thing (the independent
thing) may affect the semantics of the
other thing (the dependent thing)
A car uses a fuel

B. Association – a structural relationship

that describes a set of links, a link being
association
a connection among objects.
0..1 *
employe employee
r role name
17
 BUILDING BLOCKS OF UML…
C. Generalization (is-a) –
a specialization/generalization relationship in which
objects of the specialized element (the child) are
substitutable for objects of the generalized element
(the parent)

18
 BUILDING BLOCKS OF UML…
3. Diagram
The graphical representation of a set of
elements
Help to visualize a system from different
perspectives
May contain any combination of things and
relationships.

19
 UML DIAGRAMS
Diagrams used to describe structure
 Class diagram
 Object diagram
 Component diagram
 Deployment diagram
Diagrams used to describe behavior and
Function
 Use Case diagram (functional)
 Sequence diagram
 Activity diagram
 Collaboration diagrams
 Statechart diagram
20
 Commonly Used UML
Diagrams
The most commonly used UML diagrams are:
Use case diagram, describing how the
system is used.
 The starting point for UML modeling.
 Capture the high level of a system from the user
point of view
Activity diagram.
 Each use case may create one activity diagram.
 Represent the workflow of the system usecase

21
 Commonly Used UML
Diagrams
Sequence Diagram:
Showing the sequence of activities
and class relationships.
Represent the communication
among objects that identified
Each use case may create one or
more sequence diagrams.
A collaboration diagram is an
alternative to a sequence diagram.

22
 Commonly Used UML
Diagrams
Class diagram:
Shows the structure of a system in terms
of classes and relationships.
Sequence diagrams and CRC cards are
used to determine classes.
Statechart diagram:
Each class may create a Statechart
diagram, useful for determining class
methods.
Used to determine the behavior of a
class
23
 Overview of UML Diagrams

24
 RULES OF UML
 UML’s building blocks should be put together to
develop a well-formed model.
 well-formed model is a model that is semantically
self-consistent and in harmony with all its related
models.
The UML has semantic rules for
 Names: What you can call things, relationships, and diagrams
 Scope: The context that gives specific meaning to a name.
 Visibility: How those names can be seen and used by others
 Integrity: How things properly and consistently relate to one

another.
 Execution: What it means to run or simulate a dynamic model.

25
 COMMON MECHANISMS IN
UML
Systems development using UML can be made
simpler by the presence of common mechanisms:
1. Specifications – Behind every part of UML’s graphical
notation there is a specification that provides a textual
statement of the syntax and semantics of that building
block.
• Specification are used to state the system’s details.
• Provides a semantic backplane that contain all the
parts of all the models of the system.
• Example – a class diagram
2. Adornments – Most elements in the UML have a unique
and direct graphical notation that provides a visual
representation of the most important aspects of the
element.
• Every element in the UML’s notation starts with a basic
Transaction
symbol, to which can be added a variety of
adornments to that symbol.
+execute()
+rollback()
#priority()
26 -timestamp()
 COMMON MECHANISMS IN UML…
3. Common divisions
Class and Object
Costomer : Costomer
-name name Alemayehu : Costomer
-address
address name
-phone
phone address
phone
4. Extensibility mechanisms
UML can be extended using the following mechanisms
• Stereotypes: Extends the vocabulary of UML, allowing you
to create new kinds of building blocks that are derived from
existing ones but that are specific to your problem.
• Constraints: Extends the semantics of a UML building block,
allowing you to add new rules or modify existing ones.

27
 ARCHITECTURE
Architecture is the set of significant decisions
about
 The organization of a software system
 The selection of the structural elements and their
interfaces by which the system is composed
 Their behavior, as specified in the collaborations
among those elements
 The composition of these structural and
behavioral elements into progressively larger
subsystems
 The architectural style that guide this
organization: the static and dynamic elements
and their interfaces, their collaborations, and their
composition.
28
 ARCHITECTURE
Software architecture is not only concerned
with architecture and behavior, but also with
usage, functionality, performance, resilience,
reuse, comprehensibility, economic and
technology constraints and trade-offs, and
aesthetic/visual concerns.
Architecture of a system can be described by a
view.
A view is simply a subset of UML modeling
constructs that represent one aspect of the
system
Each of the views involve structural and
29 behavioural models
 Views of a system
Systems can be viewed from a number of
perspectives
different stakeholders: system owners, end
users, analyst, developers, project managers
etc
Each looks at the system in different angle at
different times over the project’s life span
System architecture can be used to manage
these different viewpoints, therefore controlling
the development of a system throughout its life
cycle

30
 UML captures these different angles/viewpoints as a
set of five interlocking views: -
vocabulary system assembly
functionality configuration mangmt

Design view Implementation view

behavior
Use case view

Process view Deployment view

performance system topology

scalability throughput distribution delivery
installation
• Each view focused on a particular aspect of the
system, are stand alone and interact with each other
31
 Use case view
Focuses on scenarios executed
by human users and external
systems
Expresses what the new system
will do without specifying how it
will do it
End-product: use case
diagrams
32
 Design views
Supports the functional requirements of the
system
Focuses on the things (classes, interfaces and
collaborations) that form the vocabulary of the
problem that the system is trying to solve and
the elements of the solution to that problem.
The view encompasses the static and dynamic
aspects of the system
End-product: class and object diagram (static),
sequence/collaboration, activity and statechart
diagram (dynamic)

33
 Process view
Focuses on the aspects of the
system that involves timing and the
flow of control.
Addresses the performance,
scalability and throughput of the
system
End product: activity diagrams

34
 Implementation view
Encompasses the components and files that are
used to assemble and release the physical
system
End-product: component diagrams

Deployment view
Focuses on the geographic distribution of the
various software elements on hardware and
other physical elements that constitute a system
Encompasses the nodes that form the system’s
hardware topology on which the system executes
End-product: deployment diagram
35
 Functional Model

Use Case Diagram

1) Essential
2) System

36
 USE CASE MODEL
Use Case analysis is one of the first and
primary means of gathering
requirements in the behavioral
methodology.
Used to capture the intended behaviour
of the system under development
(requirements of a system)
The Use case diagram is used to identify
the primary elements and processes that
form the system.

37
 Cont…
Represents the functional
requirements of a system under
development
Captures the business processes
carried out in the system
A use case model may consists of
Single use case diagram
Further (nested) packages of use case
diagrams
The supreme package of the nested
packages is the use case model

38
 Cont..
Use case Modeling could be
Essential
 Used at requirement elicitation stage
 Technology free
 Just to understand what users need to see on the
system from functions point of view
System
 Is a continuation of essential use case
 Adding implementation related details

39
 
System Use case Modeling
The system use case talks more about more or
less same concept like the essential use case
with some details of the implementation.
The modeling will be influenced by the
technology to be used for the systems
development.
System use case model is composed of the
system use case diagram and its
corresponding documentation.
The use case diagram and the documentation
will have same components as the essential
use case model with little technology influence.
40
 Components
Shows the relationship between actors
and use cases in a system
Diagram with the following
components
Actors
Use cases
Boundary
Relationship (Associations, include or use,
Extend)
Documentation
For each use case using the standard
template
41
 On-line Bookstore
System
Register

Custome Order
r books

Sell used
books

Use Case Review

Functional books
42 Requirements
Diagram
 What is the difference with the previous
use case?
Sell Item <<
Inc
lud
es
>>

Reorder
<<Includes>>
Sales Clerk

Login

Add to Stock
<<Includes>>

<<Includes>>

Generate
Report

Manager

43
 Cont…
The Use Case documentation needs
information like:
List of Actors
List of Business Rules (BR)
List of User Interfaces (UI)
 The template will be the same as the
essential use case documentation except
that the “Include” and “Extend” part will be
exercised (included) at this level.
The following example describes one of the
use cases from the previous use case
diagram.
44
 Use case documentation
Name Sell Item
Identifier UC-008
Description Sell available items in a store to a customer
Actor Sales Clerk
Pre Condition none
Post Condition The sales clerk will sell the item if available in store

Extends none
Includes UC-001
Basic Course of Action
1.The Sales Clerk want to sell an item
2.The Sales Clerk logs into the system using “UC-001: Login”
3.The system displays the main Window “UI-002: Main Menu”
4.The Sales Clerk selects “Sell” from the Main Menu
5.The system displays the Sell interface “UI-006: Sell Item”
6.The Sales Clerk selects the items and quantity he want to sell
7.The system check the availability of the items according to the business rule “BR-012: check availability of item”
8.The system displays the total amount of money to be paid with the item list via “UI-013: Payment Voucher”
9.The Sales Clerk indicates he want to print the payment voucher.
10.The system prints the payment voucher
11.The use case ends when the Sales clerk receive the money and give the payment voucher to customer.
Alternative Course of Action A: The item is not available in store
8.The system determines that the item is not available.
9.The system informs the Sales Clerk that the transaction can not be completed via “UI-014: Item Quantity not Available”
10.The use cases resumes at step 6 of the basic course of action

45
 Cont…
Note
Association between Actors and Use cases
dictate the need for Interfaces (screen or
Report)
Use case description does not include
unexpected interruption of the action either
by the actor or by system failure
The flow of events should be in
action-response style.

46
 General steps in Use case
Modeling
Identify actors from the SRS or problem
definition
Identify use cases
Identify relationships
Use symbols for representing use cases
and actors with in a boundary
Define use case description

47
 Actor
An actor define roles that users can play.
Actors model anything that needs to
exchange information with the system
The different roles the actor represents are
the actual business roles of users in a given
system.
An actor in a use case diagram interacts
with a use case.

48
 Actor …
Actor classes have actors instances or
objects that represent specific actors.
An actor is shown as a stick figure in a
use case diagram depicted "outside" the
system boundary.
To identify an actor, search in the
problem statement for business terms
that describe roles in the system.

Doctor Patient Student

49
 USE CASES
A use case is a specific way of using the
system by performing some part of the
functionality.
A visual representation of a distinct
business functionality in a system.
The business process is discrete in nature.
A use case describes what a system
does; not how.
List the discrete business functions in
your problem statement - potential use
case.
Remember that identifying use cases is a
discovery rather than a creation.
50
 USE CASES …
 A use case is shown as an ellipse in a use case diagram
Perform Medical
Make Appointment
Tests

 Use cases have the following characteristics:

 Use case are interactions or dialogs between a system and
actors, including the messages exchanged and the actions
performed by the system. Use cases may include variants of
these sequences, including alternative and exception
sequences.
 Use cases may be initiated by actors and may involve the
participation of numerous other actors.
 Use cases may have extension points that define specific
points within an interaction at which other use cases may be
inserted
 Use cases classes have use case instances or objects called
scenarios that represent specific interactions.
51
 Use-Cases: describing how the
user will use the system
 A use case is a typical sequence of actions
that a user performs in order to complete a
given task
 The objective of use case analysis is to model
the system from the point of view of
… how users interact with this system
… when trying to achieve their objectives.
It is one of the key activities in requirements
elicitation and analysis

52
 Use cases
A use case should
Cover the full sequence of steps from the
beginning of a task until the end.
Describe the user’s interaction with the
system
 Not the computations the system performs.
Be written so as to be as independent as
possible from any particular user interface
design.
Only include actions in which the actor
interacts with the computer.

53
 Scenarios
A scenario is an instance of a use case
A specific occurrence of the use case
 a specific actor ...
 at a specific time ...
 with specific data.

54
 RELATIONSHIPS
Relationships between actors and use
cases
 represented by directional or nondirectional edges
 May be annotated by stereotypes
May relate two use cases
May relate two actors, or
May relate a use case and an actor

55
 RELATIONSHIPS
 Association
denoted as solid lines or paths.
Arrowheads may be used to indicate who
initiates communication in the interaction.
 Includes
Indicates that the base use case will contain
the inclusion use case.
A base use case defines the location at which
the inclusion use case is included.
Denoted as dashed lines with an open
arrow-head pointing at the inclusion use
case and are labelled with the <<include>>
keyword (stereotype).
56
 RELATIONSHIPS …
 Extends
 Indicates that the base use case may be
augmented by the extension use case; i.e.,
the inclusion use case will augment the base
use case if an extension condition is satisfied.
 A base use case defines the extension point.
 Denoted
 as dashed lines or paths with an open arrow-head
pointing an extension use case
 labelled with the extension condition in square
brackets,
 the <<extend>> keyword (stereotype), and
 the extension point name in parentheses.

57
 RELATIONSHIPS …
 Generalization
 From specialization to generalized use case
 Indicate the specialization use cases are consistent with
the generalized use case and may add additional
information.
 A specialized use case may be used in place of a
generalized use case and may use any portions of the
interaction of the generalized use case.
 Denoted as solid lines or paths with a hollow arrow-
head pointing at the generalized use case.
 From specialization to generalized Actor
 The specialized actor are consistent with the
generalized actor and may add additional information.
 A specialized actor may be used in place of a
generalized actor and receives the characteristics of
the generalized actor.
 Denoted as solid lines or paths with a hollow arrow-
head pointing at the generalized actor.
58
 RELATIONSHIPS …
Place Order «extends»
___________ Place rush oder
set priority

<<includes>
>
Check password
<<includes>
Track Order >

Validate User

Retinal Scan

59
 System Boundary
 The use case describes the functionality of a
system from an outside point of view – from
the users point of view.
 Only the interaction between actors and
system are shown, what happens inside the
system is hidden.
 This boundary is clarified by the system
boundary
 Defines the scope of what a system will be.
 A system boundary of a use case diagram
defines the limits of the system.
 The system boundary is shown as a rectangle
spanning all the use cases in the system
60
 SYSTEM BOUNDARY
A use case diagram depicting the system
boundary of a clinic application
Clinic
* Make Appointment
*
Patient

Perform Medical
Tests
* *

Doctor
61
 RELATIONSHIPS …

Library User (Patron)

Faculty Members NonAcademic Staff Students External User

2ndYear 3rdYear 4thYear 5thYear Postgraduate

62
 Good Practice
Develop a use case diagram at different
levels wherever appropriate.
Minimizes complexity
System level
Module level
Class
Interface
etc

63
 FLOW OF EVENTS
Specify the behavior of a use case by
describing the flow of events in text
clearly enough for an outsider to
understand it easily.
Include
How and when the use case starts and
ends
When the use case interacts with the
actors
What objects are exchanged
The basic flow and alternative flows of
the behavior
64
 FLOW OF EVENTS…(major
elements)
 Introduction: Describe a quick background of the use
case.
 Actors: List the actors that interact and participate in
this use case.
 Actor Description/Definition: Define/Describe each
actor.
 Pre-conditions: Pre-conditions that need to be
satisfied for the use case to perform.
 Post-conditions: Define the different states in which
you expect the system to be in, after the use case
executes.
 Basic Flow: List the primary events that will occur
when this use case is executed.
 Alternative flows: Any subsidiary events that can
occur in the use case should be separately listed. List
each such event as an alternative flow. A use case can
have as many alternative flows as required.
65
 COMMON

MODELING TECHNIQUE
The most common thing for which you will
apply use case is to model the Functional
behavior of an element ; A system as a
whole, a subsystem, or a class
Focus on what that element does, not how it
does
 Reasons for applying use cases to
elements
a) By modeling the behavior of an element with
use cases, you provide a way for domain
experts to specify its outside view to a degree
sufficient for developers to construct its inside
view.
b) Use cases provide a way for developers to
approach an element and understand it.
c) Use cases serve as the basis for testing each
66
element as it evolves during development.
 HINTS AND TIPS: For developing use cases
The goal is to develop a well-structured
use case that:
Names a single identifiable, and reasonably
atomic behavior of the system or part of the
system.
Factors common behavior by pulling such
behavior from other use cases that it includes.
Factors variants by pushing such behavior into
other use cases that extend it.
Is described by a minimal set of scenarios that
specify the normal and variant semantics of
the use case.

67
 HINTS AND TIPS
A well-structured use case diagram
Is focused on communicating one aspect of a
system’s static use case view.
Contains only those use cases that are
essential to understanding that aspect.
Provides detail content with its level of
abstraction.
Is not so minimalist as to misinform the
reader about semantics that are important.

68
 Example:
 On-line Bookstore is a web application that can
be accessed by the store’s registered customer,
whereby each customer can order books, review
one or more books sold in the book store, and
sell used books to other customers. Before
performing any one of these transactions, the
customer must first log-in into the system using
their user id and password kept in their account.
The customer can also take a book he/she
ordered.
 Problems:
 Develop a use case model(system use case)-
Provide your reason to pick “one” as a
69
component of your model
 Document one of the use cases you have
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out
Customer Order books
<<include>>

<<include>>
Sell used Log-in
books
<<include>>

Review books

70
 Use case: Sell used books
Main flow of events: -
1. The CUSTOMER clicks the Sell Used Books button on the
Home
Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the
used books
that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the
information that
the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed
are accurate.
If yes, the CUSTOMER clicks the OK button on the web
page.
7. The system updates the USED BOOKS table in the
database.
71
 The benefits of basing software
development on use cases
They can
Help to define the scope of the system
Be used to plan the development process
Be used to both develop and validate the
requirements
Form the basis for the definition of test
cases
Be used to structure user manuals

72
 Use cases must not be seen as a
solution
The use cases themselves must be validated
 Using the requirements validation methods.
Some aspects of software are not covered by
use case analysis.
Innovative solutions may not be considered.

73
 To be continued

74