Professional Documents
Culture Documents
Class Car
<<instanceOf>>
Attributes
Model
Location
#Wheels = 4
<<instanceOf>>
Operations
Start
Accelerate
<<instanceOf>>
Why Object Orientation? (Benefit of object orientation)
Higher levels of abstraction
Objects encapsulates data (attributes) and functions(methods). So
internal details are hidden from outside.
Support abstraction at object level.
Seamless transition among different phases of software development
Reduce the level of complexity and redundancy makes for clearer
and robust system development.
Encouragement of good programming techniques
Easy to produce more modular and reusable code through classes
and inheritance using OO language (C++,java…)
Promotion of reusability
Classes are designed generically with reuse as a constant
background goal in OO system using inheritance.
Why Object Orientation? (Benefit
of object orientation (Contd.)
Object-Oriented Analysis
An investigation of the problem (rather than
how a solution is defined)
During OO analysis, there is an emphasis on
finding and describing the objects (or concepts)
in the problem domain.
For example, concepts in a Library Information
System include Book, and Library.
Also called domain objects, entities.
Why Object Orientation? (Benefit of object orientation
Object-Oriented Design
Emphasizes a conceptual solution that fulfills the
requirements.
Need to define software objects and how they
collaborate to meet the requirements.
For example, in the Library Information System, a Book
software object may have a title attribute and a
getBookDetails() method.
• What are the methods needed to process the
attributes?
Designs are implemented in a programming language.
In the example, we will have a Book class in Java.
Analysis, Design and Construction
Analysis
Design Construction
investigation
logical solution code
of the problem
Design:
Conceptual solution that meets requirements.
Not an implementation
E.g. Describe a database schema and software objects.
The Solution Domain
The ‘Hows’ of the system
Do the thing right (design)
Analysis, Design and Construction (Contd.)
OOA: we find and describe business objects or
concepts in the problem domain
login
submit details
passport
applicant administrator
check status
get details
regional
administrator
police verify
store verification
issue passport
Class Diagram:
Class Diagram gives the static view of an application.
A class can refer to another class. A class can have its objects or may inherit from
other classes.
UML Class Diagram gives an overview of a software system by displaying classes,
attributes, operations, and their relationships.
This Diagram includes the class name, attributes, and operation in separate designated
compartments.
Example Class Diagram for passport automation system
applicants
name Passport
father name administrator
DOB
username
permanent address
password
temporary address
email id
login()
phone number
verify()
pan no
update()
applicants
user name
password
Database
login() name
submit details()
checkstatus() store()
Regional
administrator
Police username
username password
password
login()
login() verify()
verify() update()
update()
Object Diagram
Object diagrams are derived from class diagrams so object diagrams are
dependent upon class diagrams.
Object diagrams represent an instance of a class diagram.
Object diagrams also represent the static view of a system but this static view is a
snapshot of the system at a particular moment
Activity Diagram:
Activity diagram describe the dynamic aspects of the system. Activity diagram is
basically a flowchart to represent the flow from one activity to another activity.
Example activity diagram for passport automation system
login
submit
details
get details
verification
penalty as
issue
per law
passport
Example activity diagram for passport automation system
Sequence Diagram: (Interaction Diagram)
Sequence Diagrams depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place
It shows timeline which show the order of the interaction visually by using the vertical
axis of the diagram to represent time what messages are sent and when.
Example sequence diagram for passport automation system
applicant passport regional police database
administrator administrator
1: login
2: give details
3: store the details
6: send details
7: verify details
8: send verification
7: verify details
1: login passport
2: give details administrator
6: send details
applican
14: issue passport 8: send verification
regional
t 3: store the details
administrator
5: update the details
9: update the details
13: update the details
12: send verification
10: send details
police
State Chart Diagram
State chart Diagram describes different states of a component in a system. The
states are specific to a component/object of a system. It describes state machine.
It models dynamic behaviour of class.
Example state chart diagram for passport automation system
PASSPORT
AUTOMATION
POLICE
APPLICANT
REGIONAL
PASSPORT
ADMINISTRATOR
ADMINISTRATOR
Deployment Diagram
Deployment diagrams are used to visualize the topology of the physical components of a
system, where the software components are deployed.
Deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships
Example deployment diagram for passport automation system
passport automation
system
police
passport regional
applicant
administrator administrator
Package Diagram
Package diagrams are used to structure high level system elements.
Packages are used for organizing large system which contains
diagrams, documents and other key deliverables.
Package Diagram can be used to simplify complex class diagrams, it
can group classes into packages.
Example package diagram for passport automation system
applicant passport
administrator
web
regional police
administrator
DOMAIN
verification
give and get
details
issue
technical details
login database1
Case study: Hospital management system
A system to manage the activities in a hospital:
Patients request for appointment for any doctor. The details of the
existing patients are retrieved by the system. New patients update
their details in the system before they request for appointment with
the help of assistant. The assistant confirms the appointment based
on the availability of free slots for the respective doctors and the
patient is informed. Assistant may cancel the appointment at any
time.
Construct Actors, Use cases, class diagram, Sequence
Diagram and state chart diagram.
Case Study: The NextGen POS System
• A POS system is a computerized application used
to record sales and handle payments;
• it is typically used in a retail store.
• It includes hardware components such as a
computer and bar code scanner, and software to
run the system.
• It interfaces to various service applications, such as
a third-party tax calculator and inventory control.
Case Study: The NextGen POS System
• (Contd.)
These systems must be relatively fault-tolerant. That is, 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.
Secondary focus
Technical
Services layer Logging Database Access Explore how to
design objects
Use Case Modelling
Use Case Model describes the proposed functionality of the new system. It is a
pictorial representation of interaction between user and system.(Usecase
Diagram)
Use Case represents a discrete unit of interaction between a user (human or
machine) and the system. Example :login to system, register with system and
create order are all Use Cases. It is also called scenarios.
Each Use Case has a description which describes the functionality that will be
built in the proposed system.
A Use Case may 'include' another Use Case's functionality or 'extend' another
Use Case with its own behavior.
Use Cases are typically related to 'actors'. An actor is a human or machine entity
that interacts with the system to perform meaningful work.
Actors An Actor is a user of the system. This includes both human users and
other computer systems. An Actor uses a Use Case to perform some piece of
work which is of value to the business.
Use Case Modelling (Contd.)
Components of Use case Diagrams
Use cases: A use case describes a sequence of actions
that provide something of measurable value to an
actor and is drawn as a horizontal ellipse.
Actors: An actor is a person, organization, or external
system that plays a role in one or more interactions
with your system. Actors are drawn as stick figures.
Associations: Associations between actors and use
cases are indicated by solid lines. An association
exists whenever an actor is involved with an
interaction described by a use case.
Use Case Modelling (Contd.)
Notations
Use Case Modelling (Contd.)
Actors
• An actor models an external entity which communicates
with the system:
– User
– External system Passenger
– Physical environment
• An actor has a unique name and an optional description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS coordinates
Use Case Modelling (Contd.)
Use Case
• A use case represents a class of functionality provided by
the system as an event flow.
A use case consists of:
• Unique name
PurchaseTicket
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements
Example :Use case Modelling – NextGenPOS System
Example :Use case Modelling – NextGenPOS
System
Use case Modelling
Use Case: Process Sales
Customer arrives at POS checkout with goods to purchase.
Cashier starts a new sale.
Cashier enters item identifier.
System records sale line item and presents item description, price, and
running total. Price calculated from a set of price rules.
Cashier repeats step 3-4 until done with all items.
System presents total with taxes calculated.
Cashier tells Customer the total, and asks for payment.
Customer pays and System handles payment.
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).
System presents receipt.
Customer leaves with receipt and goods.
Relating Use Cases
There are three other types of relationship
between usecases.
Extends
Includes
Generalization
<<extends>> Association (Relationship)
• <<extends>> relationship
represent exceptional or
seldom invoked cases.
• The exceptional event
flows are factored out of
the main event flow for
clarity.
• Use cases representing
exceptional flows can
extend more than one use
case.
• The direction of a
<<extends>> relationship is
to the extended use case
<<includes>>Association(Relationship) or
<<uses>> relationship
• <<includes>> relationship
represents behavior that
is factored out of the use
case.
• <<includes>> behavior is
factored out for reuse,
not because it is an
exception.
• The direction of a
<<includes>> relationship
is to the using use case
(unlike <<extends>>
relationships).
Generalization relationship
Use case generalization can be used when one use case that is similar to
another, but does something slightly differently or something more.
Generalization works the same way with use cases as it does with
classes.
The child use case inherits the behavior and meaning of the parent use
case.
Base and the derived use cases are separate use cases and should have
separate text descriptions
Represented by a line and a hollow arrow from child to parent