Object-Oriented Software

Engineering

Chapter Three- 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.
 Existing methods 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
blocks mechanisms Architecture

 Building blocks  Architecture

 things
 use-case view
 relationships  logical view
 Diagrams  process view
 Common mechanisms  implementation view
 deployment view
 specifications
 Adornments (decoration)
 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 of UML: Note

16
 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 a connection among objects.
association

0..1 *
employer employee
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 symbol, to
Transaction 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
-phone name
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 behavioural models

29
 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

Customer Order books

Sell used books

Use Case Functional Review books

Requirements
42
Diagram
 What is the difference with the previous use case?
Sell Item

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 element as it
evolves during development.

66
 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
 Exercise:

 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 component of your model
 Document one of the use cases you have identified “sell used book”

69
 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

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

71
 To be continued

72