ASETL

Object-Oriented Systems Design

B.Tech Computer Science & Engineering

VII Semester (2021-25)

CSE431
Dr. Bramah Hazela

1
 Course Objectives ASETL

The purpose of this module is to acquaint students with key

aspects of object-oriented principles and systems modeling.
It also aims to give students skills in the use of appropriate
tools and familiarity with techniques applied at different
stages of the software development lifecycle. Object
oriented concepts have been the backbone of software
solution design across platform such as embedded, internet
and business solution. Over the years the market is growing
stronger and bigger size. Meanwhile, the need for reliable
and scalable software solution design is ever-increasing.
Hence, the skilled professionals with good foundation of
object oriented concepts are needed to fulfill the ever
increasing requirements.

2
 Pre-requisites

• Object oriented programming

• Software Engineering

• Software Project Management

3
 Course Learning Outcomes

• Understanding the concept of OOSA & OOSD with UML.

• Create structure diagrams addressing a clearly defined problem
• Apply OOSD techniques to implement behavioral diagrams.
• Able to design real world problems using OOSD components
• Design software system with responsibility and design pattern
concepts

4
 Good Books
• Object-Oriented Software Engineering -- a use case
driven approach (revised edition) by Ivar Jacobson
• Craig Larman,"Applying UML and Patterns: An
Introduction to object-oriented Analysis and Design and
iterative development”, Third Edition, Pearson Education,
2005
• UML Distilled (2nd Edition) by Martin Fowler
• MichealBlaha, James Rambaugh, “Object-Oriented
Modeling and Design with UML”, Second Edition, Prentice
Hall of India Private Limited, 2007
• Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides,“Design patterns: Elements of Reusable object-
oriented software”, Addison-Wesley, 1995, Inc., 1981, Los
Altos, CA.
5
 Module I : Object Oriented Design

Descriptors/Topics

• Introduction to OOSD – What is OOSD?

• What is UML? What are the United Process(UP) phases
• Case study – the NextGen POS system, Inception
• Use case Modeling
• Relating Use cases
• include, extend and generalization.

6
 Objectives
• Understand what object-oriented systems analysis
and design is and appreciate its usefulness.
• Comprehend the concepts of unified modeling
language (UML), the standard approach for modeling
a system in the object-oriented world.
• Apply the steps used in UML to break down the
system into a use case model and then a class
model.
• Diagram systems with the UML toolset so they can be
described and properly designed.
• Document and communicate the newly modeled
object-oriented system to users and other analysts.
 Procedural Approach

Procedures

Software System

Module

8
Object-oriented Approach

9
OOA and OOD

9/17/2024
OOA and OOD Models

11
9/17/2024
 Object Oriented Analysis Vs
Object Oriented Design
OOA OOD

• Identifying objects • The implementation details

• Organizing the objects by generally include −
creating object model • Restructuring the class
diagram data (if necessary),
• Defining the internals of • Implementation of
the objects, or object methods, i.e., internal data
attributes structures and algorithms,
• Defining the behavior of • Implementation of control,
the objects, i.e., object and
actions • Implementation of
• Describing how the objects associations.
interact

12
 Object-Oriented Programming

• Bottom–up approach in program design

• Programs organized around objects, grouped in classes
• Focus on data with methods to operate upon object’s data
• Interaction between objects through functions
• Reusability of design through creation of new classes by adding
features to existing classes

13
 Object-Oriented System Design

• Works well in situations where

complicated systems are undergoing
continuous maintenance, adaptation,
and design
• Objects, classes are reusable
• The Unified Modeling Language (UML)
is an industry standard for modeling
object-oriented systems.
 Object-Oriented System Design (Continued)

• Reusability
Recycling of program parts should reduce
the costs of development in computer-
based systems.
• Maintaining systems
Making a change in one object has a
minimal impact on other objects.
 Object Oriented Design

The stages for object–oriented design can be identified as

• Definition of the context of the system
• Designing system architecture
• Identification of the objects in the system
• Construction of design models
• Specification of object interfaces

16
 Designing Object Oriented Systems

Object Design
• Object design includes the following phases −
• Object identification
• Object representation, i.e., construction of design models
• Classification of operations
• Algorithm design
• Design of relationships
• Implementation of control for external interactions
• Package classes and associations into modules

Contd… 17
 Designing Object Oriented Systems

• System Design
Context
System Architecture
• Object-Oriented Decomposition
• Identifying Concurrency
• Identifying Patterns
• Controlling Events
• Handling Boundary Conditions

18
 Object Oriented Modeling

• Object-oriented concepts
• Unified Modeling Language
• Use case and other UML diagrams
• Packages
• Using UML
 Object-Oriented Concepts
• Objects
• Classes
• Encapsulation and Data Hiding
• Message Passing
• Inheritance
• Polymorphism
• Generalization and Specialization
• Links and Association
• Aggregation or Composition
 Objects

• Persons, places, or things that are

relevant to the system being analyzed
• May be customers, items, orders, and
so on
• May be GUI displays or text areas on a
display
 Classes

• Defines the set of shared attributes and

behaviors found in each object in the class
• Should have a name that differentiates it
from all other classes
• Instantiate is when an object is created from
a class.
• An attribute describes some property that is
possessed by all objects of the class.
• A method is an action that can be requested
from any object of the class.
An Example of a UML Class: A Class Is Depicted as a
Rectangle Consisting of the Class Name, Attributes, and
Methods
 Encapsulation and Data Hiding

Encapsulation
Encapsulation is the process of binding both attributes and methods
together within a class. Through encapsulation, the internal details of a
class can be hidden from outside. It permits the elements of the class to
be accessed from outside only through the interface provided by the
class.

Data Hiding
Typically, a class is designed such that its data (attributes) can be
accessed only by its class methods and insulated from direct outside
access. This process of insulating an object’s data is called data hiding
or information hiding.

24
 Message Passing

The features of message passing are −

•Message passing between two objects is generally

unidirectional.
•Message passing enables all interactions between
objects.
•Message passing essentially involves invoking class
methods.
•Objects in different processes can be involved in
message passing.

25
 Inheritance

• When a derived class inherits all the

attributes and behaviors of the base
class
• Reduces programming labor by using
common objects easily
• A feature only found in object-oriented
systems
A Class Diagram Showing Inheritance

Car and truck are specific

examples of vehicles and
inherit the characteristics of
the more general class
vehicle.
Types of Inheritance

28
Polymorphism

29
Generalization and Specialization

30
 Links and Association

Link
• A link represents a connection through which an object
collaborates with other objects.
Association
• Association is a group of links having common structure and
common behavior. Association depicts the relationship between
objects of one or more classes. A link can be defined as an
instance of an association.
Degree of an Association
• Degree of an association denotes the number of classes involved
in a connection. Degree may be unary, binary, or ternary.
• A unary relationship connects objects of the same class.
• A binary relationship connects objects of two classes.
• A ternary relationship connects objects of three or more classes.

31
Example of Link and Associations

32
 Aggregation ,Composition and Association

Aggregation or composition is a relationship among classes by

which a class can be made up of any combination of objects of
other classes. It allows objects to be placed directly within the
body of other classes. Aggregation is referred as a “part–of” or
“has–a” relationship, with the ability to navigate from the whole to
its parts. An aggregate object is an object that is composed of
one or more other objects.
• Example
• In the relationship, “a car has–a motor”, car is the whole object
or the aggregate, and the motor is a “part–of” the car.
Aggregation may denote −
• Physical containment − Example, a computer is composed of
monitor, CPU, mouse, keyboard, and so on.
• Conceptual containment − Example, shareholder has–a
share.

33
Relationship among Aggregation ,Composition and Association

34
 Aggregation Vs Composition

Aggregation Composition

35
 Object Oriented Analysis

• Object Modelling
Object modelling develops the static structure of the software
system in terms of objects. It identifies the objects, the classes
into which the objects can be grouped into and the relationships
between the objects. It also identifies the main attributes and
operations that characterize each class.

• Dynamic Modelling
Dynamic Modelling can be defined as “a way of describing how
an individual object responds to events, either internal events
triggered by other objects, or external events triggered by the
outside world”.

Contd.. 36
 Object Oriented Analysis

• Functional Modelling
Functional Modelling is the final component of object-oriented
analysis. The functional model shows the processes that are
performed within an object and how the data changes as it
moves between methods. It specifies the meaning of the
operations of object modelling and the actions of dynamic
modelling. The functional model corresponds to the data flow
diagram of traditional structured analysis.

37
 Introduction to Object Oriented Methodology

Object Oriented Modeling:

Modeling is a central part of all the activities
that lead up to the deployment of good
software.

There are two ways to approach a Model:

• Algorithmic Approach
• Object Oriented Approach

38
 Approaches of Modelling

• Rumbaugh(1999): OMT(Object Modeling Technique)

• Booch (1986) : OOD(Object Oriented Design)
• Jacobson(1994) : OOSE(Use cases)
• Coad and Yourdan (1991) : OOA/OOD
• Shber and Mellor(1987) :OOA
• Coleman(1994): FUSION
• Delatte(1993): HOOD(Heirarchical Object
Oriented Design)

39
 UML Background

▪ Object Oriented Software Modeling Language

▪ UML 1.1-1.5, 2.0, 2.1.2, 2.2, 2.3, 2.4.1, 2.5.1(2017) are OMG standard

▪ An industry-standard graphical modeling language

▪ Provides vocabulary and rules for using the language

▪ Vocabulary and the rules focus on representing the logical and physical elements of a
system.

▪ UML is a language used to Visualize, Specify, Construct model of the software system
and Document models of the software system by expressing requirements of the system
during its development and deployment stages.

▪UML is a standard modelling language used for modeling software systems of varying
complexities.

40
 UML

UML: Unified Modeling Language

▪ An industry-standard graphical modeling language and provides a vocabulary

and rules for using the language.

▪ Vocabulary and the rules focus on representing the logical and physical elements
of a system.

▪ UML is a language used to:

• Visualize the software system with well defined symbols

• Specify the software system and help in building precise and complete
models
• Construct model of the software system
• Document models of the software system by expressing requirements of the
system during its development and deployment stages.

• The Companies forming a part of the UML consortium are incorporating UML as
a standard in their development process

41
 Why UML for Modeling?

• UML - An Object Oriented Modeling Technique

• UML is a nonproprietary user friendly language and is simple in constructs

• UML is comprehensive, independent, Scalable & General purpose Modeling

language

• It is not tide to any development process- waterfall, agile, whatever..

• Can be used across the whole life cycle of a software-Promotes iterative refinement
of models

• Uses graphical notation to communicate more clearly than natural language

(imprecise)

• Makes it easier for programmers and software architects to communicate with variety
of programming languages

42
 UML (4+1) View Architecture

Structural view
Implementation View
(Design View)

Use Case
View
(User View)

Behavioral View Environmental View

(Process view) (Deployment view)

43
 Views in UML

•The User View

•The Structural View
•The behavioral View
•The implementation view
•The environment view

44
Phases in UP
UML Diagram Types

46
 The Unified Modeling Language (UML) Concepts
and Diagrams

• Things
• Relationships
• Diagrams
Building Blocks of UML

48
 Things
• Structural things are
• Classes, interfaces, use cases, and other elements that
provide a way to create models
• They allow the user to describe relationships
• Behavioral things
• Describe how things work
• Interactions and state machines
• Group things
• Used to define boundaries
• Annotational things
• Can add notes to the diagrams
 Relationships

• Structural relationships
• Tie things together in structural diagrams
• Behavioral relationships
• Used in behavioral diagrams
 Structural Relationships

• Dependencies
[Graphical notation(---------→)]
• Association
[Graphical notation (Employees Manager )]
• Generalization
• [Graphical notation ( )]
• Realization
• [Graphical notation ( )]
 Behavioral Relationships

• Communicates
• Includes
• Extends
• Generalizes
 UML Diagrams

• Structural diagrams
• Used to describe the relation between
classes
• Behavior diagrams
• Used to describe the interaction between
people (actors) and a use case (how the
actors use the system)
 Structural Diagrams

• Class diagrams- Centered around Classes,

interfaces and collaborations
• Object diagrams-Centered around Objects
• Component diagrams –Centered around
Components
• Deployment diagrams – Centered around
Nodes
 Behavioral Diagrams
• Use case diagrams- Organizes the system
behavior
• Sequence diagrams- Focus on timing of
events
• Collaboration diagrams – Focus on structural
organization of objects
• Statechart diagrams – Focuses on the
changing state of a system driven by events.
• Activity diagrams- Focuses on flow of control
 Commonly Used UML Diagrams

• Use case diagram

• Describing how the system is used
• The starting point for UML modeling
• Use case scenario
• A verbal articulation of exceptions to the main
behavior described by the primary use case
• Activity diagram
• Illustrates the overall flow of activities
 Commonly Used UML Diagrams (Contd.)

• Sequence diagrams
• Show the sequence of activities and class
relationships.
• Class diagrams
• Show classes and relationships.
• Statechart diagrams
• Show the state transitions.
An Overview of UML Diagrams Showing How Each Diagram
Leads to the Development of Other UML Diagrams
 Structural Things

Class Notation Object Notation

59
 Structural Things

Interface Notation Collaboration Notation

Use Case Notation

Node Notation Component Notation

60
 Behavioral Things

Interaction Notation State Machine Notation

61
 Behavioral Things

Package Notation Note Notation

62
 USE Case Diagram

Syntax:
• Actor --

• Use case --

• Relationship --

• System border --

63
 Use Case Description
Each use case may include all or part of the following

• Title or Reference Name - meaningful name of the UC

• Author/Date - the author and creation date
• Modification/Date - last modification and its date
• Purpose - specifies the goal to be achieved
• Overview - short description of the processes
• Cross References - requirements references
• Actors - agents participating
• Pre Conditions - must be true to allow execution
• Post Conditions - will be set when completes normally
• Normal flow of events - regular flow of activities
• Alternative flow of events - other flow of activities
• Exceptional flow of - unusual situations
events
• Implementation issues - foreseen implementation problems
 Example of Use case diagrams

<<include>>
goes to Lecture
Paul

Reading books

65
 Requirement Elicitation Activities

• Identifying Actors
• Identifying Scenarios
• Identifying USE CASES
• Refining USE CASES
• Identifying Relationship among Actors and USE
CASES
• Identifying Initial analysis objects
• Identifying non functional requirements

66
 USE Case Diagram

Semantics:
• An actor represents anything that is outside of the
system and that needs to exchange information
with the system.
-- An individual person (end-user)
-- A group of people
-- An individual can play different roles
-- A machine
-- …..

67
 USE Case Diagram (Cont’d)

• A use case represents a special sequence of

events triggered by an actor.
• Example: making an initialisation process user-
friendly.
• being willing to initialise
• choosing a variable
• assigning a “wrong” value
• assigning a “correct” value

A use case
• sending a list of variables
• giving the range of the variable
• giving a warning signal
• giving acknowledgement
68
 USE Case Diagram (Cont’d)

• Relationship represents information exchange

between an actor and a use case and between
two use cases.
• We have different types of relationship existing
between an actor and a use case and between
two use cases.
• Ordinary relationship: showing that there is a
relationship between an actor and a use case or
between two use cases.
• We use symbol to represent this type of
relationship.

69
 USE Case Diagram(Cont’d)

• Extend relationship exists between two similar

use cases where the second one has some extra
activities, that is the activities of the first use case
are extended in the second one.
• The first use case sends information to the second
use case to invoke the extra activities.
• Terms:
-- the first use case: base use case,
-- the second use case: extending use case
-- the information: extension point.

70
 USE Case Diagram(Cont’d)

• Example -- think about an Internet search engine.

You type in key words and press “submit”. This will
trigger a sequence of activities happening in a
search engine.
-- If there is no spelling mistake in the key words, the search
engine will go ahead to search for items.
--If there is a spelling mistake, the search engine will ask you
to confirm the key word.

<<extend>> confirm
search
(spelling info) Extension point:
spelling info

71
 USE Case Diagram(Cont’d)

• Generalisation relationship exists between two

similar use cases. The base use case includes basic
activities and the second use case contains the
alternative activities. Both use cases handle the
same thing but the base use case deals with the
general situation and the second one deals with
special cases.
• Generalisation relationship says that alternatives
exist.

72
 USE Case Diagram(Cont’d)

• Example
-- Suppose in an Internet search engine, we have designed two
sequences of searching activities: one sequence of activities is
the normal search and the other one is intelligent search which
is for academy.
-- So we have two use cases corresponding to these two
sequences of activities: one contains the normal search
activities (called base use case) and the other contains the
intelligent search activities.
-- Both handle the request of search, but the second one deal
with special request -- academic request.

Normal Intelligent
search search

73
 USE Case Diagram(Cont’d)

• If two or more use cases have a chunk of same

activities, we can create a new use case that
contains this chunk of activities. The relation from
the original use cases to the new one is the
Include relationship, which means that the original
use cases involve the activities of the new use
case. They share the activities of the new use
case.
• By having the new use case and the include
relationship, we can avoid the repeating of the
same activities in different use cases.

74
 USE Case Diagram(Cont’d)

• Example:
-- Both the normal and the intelligent search
engines need to read the key words you typed in.
-- The activity of reading key words can then be
picked up from the two use cases and placed into a
new use case.
normal intelligent

New case

75
 USE Case Diagram(Cont’d)

Pragmatics:
• Identify system border -- Which action should be taken by
actors and which by system? This is vital important.
• Identify actor(s) -- What are “objects” outside of the system
which want to exchange information with the system? Can we
classify them?
• Identify use case(s) -- What are the main tasks of each
actor? An use case should link to a main task and contain a
complete course of events related to the task.
• Add relationship -- We need to pay extra attention on those
between use cases.

76
 CASE STUDY

A recycling machine
• System description: The
system controls a recycling
machine for returnable
bottles, cans and crates. The
machine can be used by
several customers at the
same time and each
customer can return all three
types of item on the same
occasion.

77
 CASE STUDY (Cont’d)

The system has to check, for each item, what type has
been returned. The system will register how many
items each customer returns and when the customer
asks for a receipt, the system will print out what was
deposited , the value of the returned items and the total
return sum that will be paid to the customer. An
operator also uses the system. He asks for a printout
of the total number of items that have been deposited
at the end of each day. He has right to change the
deposit values of the items through a console. When
anything wrong with the machine, the operator will be
called by a special alarm signal.

78
 CASE STUDY (Cont’d)

• Identify actors:

operator

customer

79
 CASE STUDY (Cont’d)

• Identify use cases:

Generating daily report

Returning items
Changing item values

80
 CASE STUDY (Cont’d)

“Entire” use case model:

81
 Documentation

• Events/activities of each use case must beThese are

documented. activities
that need to
• Insert an item
be
• Register documented
• Classify
• Calculate value
Returning item
customer • Request Receipt

• Accumulate
• Print out item,s value and sum

82
 Assessment Questions (Contd.)
True OR False
1. Programs written in object oriented language define individual
objects.
2. The individual attributes(properties) of each class of objects define
the objects appearance.
3. Instance variables are also called as object variables.
4. A class that inherits from another class is called a superclass and
the inherited from class is called the subclass.
5. A constructor method can be used to define the initial state of the
object.

83
 Assessment Questions
Fill in blanks
1. A mechanism that enables a number of different
procedures to have the same name is called……………………..
2. Objects are identified by assigning them
unique………………………..
3. In OOSD, models are orgainzed around
………………………….concepts
4. ………………….is a feature by virtue of which a class can be
derived into new one.
5.The real life concept of deriving something more specific
from a generalized existing thing is called………………………….
6.A class is made up of two components a set of attributes
called………………. And their behavior called……………………..
84
 User View

Use-cases are descriptions of the functionality of a system

from a user perspective.
1.Depict the behaviour of the system, as it appears to an
outside user.
2. Describe the functionality and users (actors) of the system.
3. Show the relationships between the actors that
system, the use cases (functionality) they use, and the
relationship between different use cases.
4. Document the scope of the system.
5. Illustrate the developer’s understanding of the user’s
requirements.
 Use Case Diagram, purpose
Class Activity
diagrams diagrams

Requirements Sequence
document diagrams
(text in natural language)

Statechart
diagrams

• Use case models are developed at different levels of abstraction

–system, system component, or a class.
• Use case modelling is an iterative and incremental process.
–If user requirements change, the changes should be made in all the affected
documents.
Use case diagram for Online Shopping website

87
View Items use case extended by several use cases

88
Checkout use case

89
 Important tips for drawing a Use Case diagram

Following are some important tips that are to be kept in mind while
drawing a use case diagram:
1.A simple and complete use case diagram should be articulated.
2.A use case diagram should represent the most significant interaction
among the multiple interactions.
3.At least one module of a system should be represented by the use
case diagram.
4.If the use case diagram is large and more complex, then it should be
drawn more generalized.

90
 CASE STUDIES
• Consider a cellular phone network. This network
must place the phone call correctly. Also it should
schedule the receiving and conference calls. Draw
its Use Case Diagram.
• Consider a Hospital Management System. Draw its
Use Case Diagram.
• Consider the student course registration system of
Amity University. Draw its Use Case Diagram.
• Draw the Use Case Diagram for the training and
placement division of Amity University.

91
 Case Study- NextGen POS

◼ NextGen POS
◼ The Next Generation Point-Of-Sale System
 Case Study: NextGen POS

◼ Tasks
◼ Record sales
◼ Handle payments
◼ Control inventory
◼ Print receipts
◼ Easy-to-use
◼ Touch-screen interface
◼ Multi-node vending system
◼ Distributed system
NextGen Pos: System Boundary

◼ External
◼ Cashier
◼ Inventory System
◼ Payment Authorization System
◼ Internal
◼ Point-of-sale system
◼ Complete payment handling
 Case Study Focus

• Applications generally can be divided into 3 layers –

- User interface
- Application logic
- Other components/layers
• Focus on application logic layer

95
Sample Layers and Objects in Object Oriented system

96
Layered Architecture Pattern

97
Closed Layers and Request Access

98
Open Layers and Request Flow

99
Layered Architecture (example)

100
 Case Study : NextGen POS System

NextGen point-of-sale (POS) system –

• Computerized application used (in part) to record sales and handle
payments typically used in a retail store
• Components – Hardware: computer and bar code scanner etc. – Software
• Interfaces to various service applications, such as a third-party tax
calculator and inventory control
• Must be relatively fault-tolerant – Even if remote services are temporarily
unavailable (such as the inventory system), they must still be capable of
capturing sales and handling at least cash payments
• Increasingly must support multiple and varied client-side terminals and
interfaces – Thin-client Web browser terminal – Regular personal
computer with graphical user interface – Touch screen input – Wireless
PDAs, etc.

101
 Case Study : NextGen POS System

• Sold to different clients with disparate needs in terms of business

rule processing
• Each client will desire a unique set of logic to execute at certain
predictable points in scenarios of using the system, such as – When a
new sale is initiated – When a new line item is added
• Need a mechanism to provide flexibility and customization.
• Using an iterative development strategy, we are going to proceed
through requirements, object- oriented analysis, design, and
implementation.

102
 NextGen POS: Actors

◼ Primary Actors

Cashier Manager Administrator

◼ Secondary Actors

Customer Payment Authorization System Inventory System

 NextGen POS: Use Cases

NextGen POS

Process Sale

Cashier Payment Authorization System

Analyze Sale

Manager
Inventory System

Manage System

Administrator
 Use Case: Process Sale

Use Case UC1: Process Sale

Scope: Point of Sale System

Level: User Goal

Goal in Accurate and fast sales process with no payment

Context: errors.
Actors: Primary:
- Cashier: processes the sales items and
returns changes
Secondary:
-Customer: purchases sales items and gets
change
-Payment Authorization Service: processes
customer authorization
 Use Case: Process Sales

Steps 1. Customer arrives at POS checkout with goods

(Basic Flow): to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents
item description, price, and running total.
Price calculated from a set of price rules.
5. Cashier repeats step 3-4 until done with all
items.
6. System presents total with taxes calculated.
7. Cashier tells Customer the total, and asks for
payment.
8. Customer pays and System handles payment.
9. System logs completed sale and sends sale
and payment information to the external
Accounting system (for accounting
and commissions) and Inventory system (to
update inventory).
10. System presents receipt.
11. Customer leaves with receipt and goods.
 Use Case and System Sequence Diagram SSD

:System
Simple: Process Sale scenario
:Cashier
1. Customer arrives at POS
makeNewSale()
checkout with goods to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier enterItem(itemID, quantity)
4. System records sale line itemand
presents item decription, price, description, total
and running total
Cashier repeats 3-4 until indicates [*more items]
done.
endSale()
5. System presents total with taxes
6. Cashier tells customer the total total with tax
and asks for payment
7. Customer pays and system makePayment(amount)
handels payment
change due, receipt
SSD and System Boundary

:System
:Cashier

makeNewSale()

enterItem(itemID, quantity)

endSale()

makePayment(amount)
 Principles of Modeling

•Principle-1
The choice of Model is important
•Principle-2
Levels of precision may differ
•Principle-3
The best model are connected to Reality
•Principle-4
No single model is Sufficient

109
 Domain Modeling

OOA

Dynamic Behavior Modeling

with
Use Cases

Domain Modeling
 Domain Modeling

◼ Goal
◼ The problem domain is captured in a domain model
◼ Activities
◼ Identify the conceptual classes with their attributes and their
associations
◼ Input
◼ Use Cases
◼ Result
◼ Conceptual class diagram
◼ Domain objects
◼ Associations among the objects
◼ Attributes of the objects
 Domain Model Issues

◼ No Software Artifacts …
◼ No attribute types
◼ No methods
◼ … but Conceptual Class
◼ Symbol – the box
◼ Intension – described in an annotation
◼ … and System Decomposition
◼ Division by conceptual classes
 How To Develop The Domain Model

Apply the following steps:

1. Identify candidate conceptual classes
2. Add associations between the classes
3. Add attributes to the classes
 Domain Modeling Guidelines

◼ Class Naming
◼ Use existing names of the problem domain
◼ Exclude irrelevant features
◼ Do not add things, that are not there
(mapmaker strategy)

◼ Modeling of Unreal Elements

◼ Example of a telecom system:
Message, Port, Connection
◼ Example of conceptual classes:
ProductSpecification, ItemDescription
 NextGen POS: Step 1

◼ Conceptional Classes

Register Item Store Sale

Sales Line
Cashier Customer Manager
Item

Product Product
Payment
Catalog Specification
 Analysis vs. Design
Domain Model
A payment Payment Pays-for Sale
in the domain date time
amount 1
model is a
concept.
1

Design Model

A payment Payment Pays-for Sale

in the design amount: Money 1 date time
model is a
software getBalance(): Money 1 getTotal(): Money
class. ... ...
 NextGen POS: Step 2
◼ An Association is ...
◼ ... a relationship between instances of types that indicates some
meaningful connection

association

Register Records-current Sale

1

1
 Finding Associations

◼ Common Associations list

◼ Summarizes some typical situations, which leads to
associations
◼ Is physical part of
◼ Is logical part of
◼ Is physically contained in
◼ Is logically contained in
◼ ...
 Association Guidelines

◼ Focus on those associations for which knowledge of the

relationship needs to be preserved for some duration
◼ „Need-to-know“ associations
◼ Too many associations rather confuse than illuminate
◼ Avoid redundant or derivable associations
 Association Guidelines

◼ Multiplicities
◼ Specify domain constraints

multiplicities

Store 1 Item

*
contains
 NextGen POS: Step 2 Associations

◼ Unforgettable Relationships
◼ Register Records Sale
◼ To know the current sale, generate total, print receipt
◼ Sale Paid-by Payment
◼ To know if the sale has been paid, relate the amount tendered to
the sale total, and print a receipt
◼ ProductCatalog Records ProductSpecification
◼ To retrieve a product specification, given an itemID
 Domain Model

concept or SalesLineItem Records-sale-of Item

domain object
quantity 0..1 1
1..* *
association
Contained-in Stocked-in
1 1
Sale Store
attributes 1
date time address name

1 1
Paid-by Captured-on Houses
1 1
Payment 1 Register
amount
 NextGen POS: Step 3

◼ An attribute is ...
◼ ... a logical data value of an object

attributes
Sale
date
startTime: Time
 Attribute Guidelines

◼ Criteria
◼ Choose those attributes for which requirements suggest or imply
a need to remember information
◼ Keep attributes simple
◼ Simple data types
◼ Boolean, Date, Number, String, ...
◼ Common data types
◼ Address, Color, Phone Number, ZIP code,...
 More Attribute Guidelines
◼ Complex Attributes

Cashier
Not a simple
Bad name attribute
currentRegister

Cashier Register
Uses
Good
name 1 number

1
 More Attribute Guidelines

◼ Make an own conceptual class if a non-primitive data

type
◼ Is composed of separate sections
◼ phone number, name of person
◼ There are operations associated with it (parsing or validation)
◼ Social security number
◼ It has other attributes
◼ Promotional prices usually have start and end date
◼ It has a quantity with a unit
◼ Payment amount with currency unit
 More Attribute Guidelines
◼ Modeling Attribute Quantities and Units

Payment
Amount: Number Not useful

Payment Has-amount Quantity Is-in Unit

* amount: Number *

Payment 1 1

amount: Quantity
Better
Payment
amount: Money
 NextGen POS: Step 3

Records-sale-of 1 Item

0..1
*
SalesLineItem 1 Stocks
quantity Store
1..* 1 address
Contained-in name
Logs-completed
1 1
*
Houses
Sale Captured-on
1..*
date time 1
Register
Paid-by 1 1 1
1 Initiated-by 1
Payment Customer
amount partial domain model
 Summary

◼ Analysis modeling is not design

◼ Handle system as black-box
◼ Model interaction between actors and system with
System Sequence Diagrams
◼ Domain objects are not software classes
◼ Domain model is important input for design
◼ Domain objects may become software classes
 Case study - Inception

Business Case

• Existing POS Products

– Not adaptable to customer's business, in terms of varying business rules.

– They do not scale well as terminals and business increase.

– None can work in either on-line or off-line mode, dynamically adapting depending on
failures.

–
None easily integrate with many third-party systems.
–
None allow for new terminal technologies such as mobile PDAs.
– There is marketplace dissatisfaction with this inflexible state of affairs, and demand for a
POS that rectifies this.
 Case study - Inception

Glossary
Term Definition Format Aliases

item A product or service for sale

Payment Validation by an external

authorization payment authorization service
that they will make or guarantee
the payment to the seller.
UPC Numeric code that identifies a 12-digit Universal
product. Usually symbolized code of Product Code
with a bar code placed on several
products. subparts
 Case study - Inception

Introduction

• NextGen POS, with the flexibility to support

– Varying customer business rules,

– Multiple terminal and user interface mechanisms, and

– Integration with multiple third-party supporting systems

 Case study - Inception

Brief format Use Case

• A story of an actor using a system to meet a goal Process Sale:

1. A customer arrives at a checkout with items to purchase.

2. The cashier uses the POS system to record each purchased item.

3. The system presents a running total and line-item details.

4. The customer enters payment information, which the system validates and records.

5. The system updates inventory.

6. The customer receives a receipt from the system and then leaves with the items.
 Use case Diagrams
Information
Flow Actor
POST
Buy
Items

Cashier Customer
Log In

Use case
Refund System
Purchased boundary
items
Relating Use cases
The include Relationship
 The include Relationship

• Some partial behavior across several use cases. (most common)

– E.g., Paying by credit occurs in several use cases,

including Process Sale, Process Rental, Contribute to Lay-away Plan.

– Rather than duplicate this text, it is desirable

To separate it into its own subfunction use case, and indicate its inclusion.
– This is simply refactoring and linking text to avoid duplication

• Guideline: Use include

– When you are repeating yourself in two or more separate use cases and

– When you want to avoid repetition

 Applying UML: Use Case Diagrams

NextGen POS

Process
Sale
Cashier «actor»
«include» «include»
Accounting
«include» System

Handle Check Handle Cash Handle Credit

Payment Payment Payment
Customer «actor»
«include» Credit
«include» «include» Authorization
Service
UML notation:
the base use
case points to Process Rental
the included use
case

Handle Returns

Manage Users

...
The include Relationship
 Using include with Asynchronous Event Handling

• Asychronous Events
– When a user is able to, at any time, select or branch to a particular
window, function, or Web page, or within a range of steps.

• Basic notation is to use a*, b*, ... style labels in the Extensions section
– To imply an extension or event that can happen at any time.
Using include with Asynchronous Event Handling
 Why to use include relationship?

• There are other relationships: Extend and Generalization

• Cockburn, an expert use-case modeler,

– Advises to prefer the include relationship over extend and generalization.

• As a first rule of thumb

– Always use the include relationship between use cases.

• People who follow “include” have less confusion with their writing than
people who mix include with extend and generalizes [Cockburn01].
 Concrete/Abstract Use Cases

• Concrete use case

– Initiated by an actor and performs the entire behavior desired by the actor.

– Are the elementary business process use cases

– Process Sale is a concrete use case.

• Abstract use case

– Never instantiated by itself; it is a subfunction use case that is part of another use case.

– Handle Credit Payment is abstract; it doesn't stand on its own, but is always part of
another story, such as Process Sale.
 Base/Addition Use Cases

• Base use case

–A use case that includes another use case, or is extended / specialized by another use
case.

–Process Sale is a base use case with respect to the included Handle Credit Payment.

• Addition use case

– The use case that is an inclusion, extension, or specialization.

– Handle Credit Payment is the addition use case in the include relationship to Process
Sale.

• Addition use cases are usually abstract. Base use cases are usually concrete.
The extend Relationship
 The extend Relationship

• Suppose a use case's text should not be modified

– Continually modifying the use case with many new extensions and conditional steps is a
maintenance headache

– It has been base-lined as a stable artifact, and can't be touched. How to append to the use

case?

• Extend relationship allow to create an extending or addition use case,

– And within it, describe where and under what condition it extends the behavior of some

base use case.

 Applying UML: Use Case Diagrams

Process Sale

Extension Points:
Payment VIP Customer UML notation:
1.The extending use case
«extend» points to the base use case.
Payment, if Customer presents a gift
certificate 2.The condition and
extension point can be
Handle Gift Certificate Payment shown on the line.
 The extend Relationship

A signature quality of extend relationship is that the base use case (Process Sale)
has no reference to the extending use case (Handle Gift Certificate Payment)
 Use of Extension Point

• Extending use case is triggered by some condition.

• Extension points are labels in the base use case

–Here, extending use case references as the point of extension

• Step numbering of base use case can change without affecting the
extending use case

–Extension point may simply "At any point in use case X,“

• It is common in systems with many asynchronous events, such as

– A word processor ("do a spell check now," "do a thesaurus lookup now"), or

– Reactive control systems.

 Prefer Extension Section

• Practical motivation of using the extend technique is

– When it is undesirable for some reason to modify the base use case

Updating the Extensions section is usually the preferred solution, rather

than creating complex use case relationships