BITS Pilani OOAD Document Analysis & Design

BITS Pilani
Pilani Campus
Object Oriented
Analysis & Design
K Hari Babu
Department of Computer Science & Information Systems
Dept. of Computer Science & Information Systems BITS Pilani, Pilani Campus
Traditional Software Development
Model
Algorithms + Data Structures = Programs
Emphasis was more on functionality.
In object oriented systems, emphasis is on objects
which combine functionality and data together.
Tell system: Compute payroll of this employee.
Tell employee object: Compute your payroll
Responsibilities are assigned to objects.
Software development
Analysis, design, implementation, testing &
refinement to transform users need into
software solution that satisfies those needs
Object-oriented approach
more rigorous process to do things right
more time spent on gathering requirements,
developing requirements model & analysis model,
then turn into design model
need not see code until after 25% development
time
Software process transforming needs
to software product

Object-oriented approach: A use-case
driven approach
Object-oriented software development life cycle consists
of
Object-oriented analysis
Object-oriented design
Object-oriented implementation
Use-case model can be employed throughout most
activities of software development
designs traceable across requirements, analysis, design,
implementation & testing can be produced
all design decisions can be traced back directly to user
requirements
usage scenarios can be test scenarios
Object-Oriented Systems
Development Approach
Object-Oriented software development
Activities
Object-oriented analysis - use case driven
Object-oriented design
Prototyping
Component-based development
Incremental testing
Encourages
viewing of system as a system of cooperative objects
incremental development
Object-oriented analysis -
use-case driven
Use Case, is a name for a scenario to describe
the usercomputer system interaction.
Determine system requirements, identify classes
& their relationship to other classes in domain
To understand system requirements
need to identify the users or actors
who are the actors ? How do they use system ?
Use case
Typical interaction between user & system
that captures users goal & needs
use cased modeling
expressing high level processes & interactions
with customers in a scenario & analyzing it
gives system uses, system responsibilities
developing use case is iterative
when use case model better understood &
developed, start identifying classes & create their
relationship
Identifying objects
What are physical objects in system ?
Individuals, organizations, machines, units of
information, pictures, whatever makes up application/
make sense in context of real world
objects help establish workable system
Intangible objects ?
Data entry screens, data structures
Documentation
modeling & documentation inseparatable
good modeling implies good documentation
Object-oriented Design
Goal : to design classes identified during
analysis phase and the user interface
Identify additional objects & classes that
support implementation of requirements
Eg. add objects for user interface to system (data
entry windows, browse windows)
Activities & focus of oo analysis & oo
design are intertwined

Object-oriented Design
First, build object model based on
objects & relationship
Then iterate & refine model
Design & refine classes
Design & refine attributes
Design & refine methods
Design & refine structures
Design & refine associations

Guidelines in Object-oriented Design
Reuse rather than build new classes
Know existing classes
Design large number of simple classes
rather than small number of complex
classes
Design methods
Critique what has been proposed
Go back & refine classes

Model
Model is an iterative process.
It can represent static or dynamic
situations.
Model
Static
Dynamic
Represents a systems behaviors
that, taken together, reflect its
behavior over time.
(e.g.) interaction & activity diagrams
Provides a systems
parameters at rest or at a
specific point in time.
(e.g.) class diagram
Why modeling
Blue print
Clarity
Familiarity
Maintenance
Simplification
Advantages of modeling
Easy to express complex ideas
Reduce complexity
Enhance & reinforce learning and training
Low cost
Easy to change the model
What is Unified Modeling Language (UML)?
The UML is a graphical / standard
language for visualizing, specifying,
constructing & documenting the artifacts of
a software system.
History of UML
1980 1990 Many different methodologies
1. Booch method by Grady Booch
2. Object Modeling Technique (OMT) by Jim
Rumbaugh
3. Object Oriented Software Engineering (OOSE) by
Ivar Jacobson

Each method had its strengths & weaknesses.
1. Booch was great in design
2. OMT & OOSE were great in analysis

History of UML

UML 1.0 (January 1997)
UML 1.1 (November 1997)
UML 1.3 (Minor revision 1999)
UML 1.4 (Minor revision 2000)
UML 2.0 (Major revision 2004)
UML Concepts
UML can be used to support entire
software life cycle.
1. The interaction of application with the outside world (use case
diagram)
2. Visualize object interaction (sequence & collaboration
diagrams)
3. The structure of system (class diagram)
4. View the system architecture by looking at the defined
package.
5. The components in your system (component diagram)

UML Diagrams
1. Class diagram (Object Modeling)
2. Use case diagram
3. Activity diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Component diagram
8. Deployment diagram
1. Class diagram
Shows tatis structure of the system
Object modelling is the process by which the logical
objects in the real world are mapped to objects in
the program.
Problem space logical space

2.Use case diagram
It shows a set of use cases and actors and
their relationships.
Address the static view of a system.
Actor user (or) someone / something
outside the system that interacts with the
system (it must be a noun) & it is
represented by a stickman.
contd
2.Use case diagram
Use case a sequences of actions (it must be
a verb) & it is represented by an oval.
Relationship illustrates a connection among
model elements.
Unidirectional Bi-directional
It is created to visualize the interaction of your
system with the outside world.
2.Use case diagram

3.Activity Diagram
It shows the flow of events with our system
& what is going on inside a use case.
We draw the activity diagram for each &
every use case.
It is showing flow of control from activity to
activity.
3.Activity Diagram
Activity it represents the performance of a
task within the workflow.
Activity is represented by a lozenge (horizontal
top and bottom with convex sides)
Start state shows the beginning of a workflow on
an activity diagram.
There is only one start state.
3.Activity Diagram
A start state is represented by a solid
circle.

An end state represents a final or terminal
state on an activity diagram.
A end state is represented by a bulls eye.
3.Activity Diagram
A state transition shows what activity
follows after another.
It is represented by a solid line with an
arrow.

3.Activity Diagram
A decision is a point in an activity diagram where
guard conditions are used to indicate different
possible transitions.
It is represented by a diamond.
Guard conditions control the transition of a set of
alternate transitions that follows after the activity
has been completed.

3.Activity Diagram

AND
Joint
Synchronization bar
3.Activity Diagram
A synchronization bar allows you to show
concurrent threads in a work flow of a use
case.
It represented by a thick horizontal or
vertical line.
3.Activity Diagram ProcessLoan Use case
4.Sequence Diagram
It shows step by step what must happen
to accomplish a piece of functionality
provided by the system.
It has 2Ds.
1. Vertical dimensions represents time
2. Horizontal dimensions represents
different objects.
Vertical line is called the objects life line.
4.Sequence Diagram
Life line the existence object at a
particular time.

Objects are shown at the top.

The object role is shown as a vertical
dashed line, the life line.

4.Sequence Diagram
A message is the communication between 2
objects that triggers an event.

It is represented by a labeled arrow.

Each message is represented by an arrow
between the life lines of 2 objects.
4.Sequence Diagram
A focus of control shows the period of
time during which an object is performing
an action, either directly or through a
subordinate procedure.

It represented by a tall, thin rectangle.
4.Sequence Diagram
5.Collaboration Diagram

It displays objects and their links to one
other.

It is made up of the following basic
elements :
1. Actors
2. Objects
3. Links
4. Messages

1. Actors user
2. Objects data + logic / the representation
of some real world entity.
3. Links a pathway for communication
between objects.
represented by a solid line
between 2 objects
4. Messages the communication between
objects that triggers an event.
represented by a labeled arrow above
the link.

6. State Chart Diagram
It shows the sequence of states.
A state is represented as a rounded box,
which may contain one or more
compartments.
Name compartment holds the name of
the state.
Internal transition compartment list of
actions / activities
Start & end states

6. State Chart Diagram

7.Component Diagram
It shows relationship between the
components in the system.

A component may be a software
component [for (e.g.) a.h file in C++ (or) a
.java file in Java], a run time component
[for (e.g.) a.DLL file]
7.Component Diagram

8. Deployment Diagram
It shows the configuration of run time
processing elements & the software
components, processes & objects that live
in them.
It shows the nodes in the system & the
connections between them.
8. Deployment Diagram

Object Oriented Analysis
Identifying Use Cases
Object Analysis: Classification
Identifying object relationships, Attributes
and Methods.
Identifying the use cases: Goals
The use-case approach to object-oriented
analysis and the object-oriented analysis
process.
Identifying actors.
Identifying use cases.
Documentation.
Sources
1. Examination of existing system
documentation.
2. Interviews.
3. Questionnaire.
4. Observation.
The Object-Oriented Analysis (OOA)
Process
The process consists of the following
steps:
1. Identify the actors:
Who is using the system?
Or, in the case of a new system, who will be
using system?
The OOA Process
2. Develop a simple business process
model using UML activity diagram.
The OOA Process
3. Develop the use case:
What the users are doing with the system?
Or, in the case of a new system, what
users will be doing with the system?
The OOA Process (Cont)
4. Prepare interaction diagrams:
Determine the sequence.
Develop collaboration diagrams.
5. Classificationdevelop a static UML
class diagram:
Identify classes.
Identify relationships.
Identify attributes.
Identify methods.
6. Iterate and refine: If needed, repeat
the preceding steps.
Use Case Model
Use cases are scenarios for understanding
system requirements.
The use-case model describes the uses of
the system and shows the courses of events
that can be performed.
Some Definitions
User Human Users + Other Systems
Use Case A piece of functionality
Use-Case Model All the use cases
Use-Case Driven Development
process follows a flow
Use Case Model (Cont)
Use case defines what happens in the
system when a use case is performed.
The use-case model tries to
systematically identify uses of the
system and therefore the system's
responsibilities.
Use Cases
"A Use Case is a sequence of
transactions in a system whose task is
to yield results of measurable value to
an individual actor of the system."
<<uses>> Associations
The <<uses>> association occurs when
you are describing your use cases and
notice that some of them have common
subflows.
The <<uses>> association allows you to
extract the common subflow and make
it a use case of its own.
Extends Associations
The <<extends>> association is used
when you have one use case that is
similar to another use case but does a
bit more or
Is more specialized; in essence, it is like
a subclass.
Use Case Diagram Notation
Actor
Association
Use Case
Use case with Extension points
<<Uses>>
<<Extends>>
Capture the system's functional requirements from the
users' perspective
Actively involve users in the requirements-gathering
process
Provide the basis for identifying major classes and their
relationships
Serve as the foundation for developing system test
cases

Purpose of Use-case Modeling
Case Study
Student welfare division oversees services students need. Students
give their preference for hostel rooms, SWD assigns rooms. SWD
issues certificates upon students request for common proofs such
as bonafide certificate, residence certificate etc. Students need to
register into courses at the beginning of every semester after
consulting registration advisor. Registration in some courses require
that prerequisite courses were cleared by student. Registration in
some courses called Audit Courses require a separate fee payment
with the Institute cashier. Within two weeks from the registration day,
students can substitute existing courses/add a new course. They will
be verified and approved by dean of ARC. After 10 weeks from the
day of registration, students may request withdrawal from courses.
ARC staff supply course lists to faculty who teach courses. Faculty
need to take attendance, conduct tests and assign grades.
Case Study
USE CASE NAME Request Certificate
ACTOR Student
DESCRIPTION Describes the process when a student submits a request for a certificate.
NORMAL COURSE 1. Student enters idno and password in SWD website.
2. If they match, he is displayed a menu.
3. Student navigates to request certificate page.
4. He selects the required certificate and submits.
5. Student logout.
6. Clerk of SWD login.
7. Clerk checks the validity of details.
8. Clerk drafts the certificate
9. Clerk prints the certificate.
10. Clerk gets the certificate signed by Dean, SWD.
11. Clerk keeps the certificate to dispatch window.
ALTERNATE COURSE 2. If the idno and password is wrong, login screen is displayed again.
3. If the student doesn't find the required certificate in the list, he personally approaches SWD
clerk.
7.
a) If the student is invalid, clerk cancels the request with appropriate message.
b) If the certificate doesn't suit the student, clerk cancels the request.
c) if clerk needs more details, he calls for the student.
PRECONDITION
POST CONDITION Certificate is issued.
ASSUMPTIONS

Noun-Phrase Approach
Common Class Patterns Approach
Classes, Responsibilities, and Collaborators (CRC)
approach
Use Case driven approach
Identifying Classes
Generally nouns give clues about classes, verbs give clue about
methods.
1. Change plurals to singular and list all nouns.
2. Make them into 3 categories.
1. Relevant classes
2. Fuzzy classes
3. Irrelevant classes (strike them off)
3. Review redundant classes.
4. Review classes containing adjectives.
If adjective suggests a new behaviour, make a new class.
5. Review the possible attributes.
They are used only as values
6. Review the class purpose.
Each class must have a purpose. If we are not able to write a statement of purpose,
eliminate it.

Noun-Phrase Approach
Events:
Classes that are points in time that must be recorded. Attributes are who, what,
when, where, how, or why.
Organization:
Classes that specify collection of people, resources, facilties whose existence
is independent of individuals.
People:
Those who interact with the system
People about whom information should be kept.
Places:
Classes that represent physical locations, buildings, stores, sites

Common Class Patterns
Approach
Based on the idea that an object either can accomplish a
certain responsibility itself, or it may require the
assistance of other objects.

Classes, Responsibilities,
Collaborators (CRC Cards)
For each discovered class,
1. Identify classes responsibilities
2. Assign responsibilities
3. Identify collaborators.
CRC Cards
Student
Name Room
RequestRoom Course
RegisterCourse
WithdrawCourse
Collaborators
Three relationships are common among classes:
Dependency (uses)
Aggregation (has)
Inheritance (is)
Class Relationships
Three relationships are common among classes:
Association
Physical or conceptual connection between two or more objects
Dependency (uses)
Special case of association
A class depends on another class if it manipulates objects of the other class in any way.
Design goal: minimize dependencies.
Aggregation (has)
Special case of dependency.
A class aggregates another if its objects contain objects of the other class.
has-a relationship.
Multiplicities *, 1..*, 0..1, 1
Composition: The contained object doesnt have independent existence.
Inheritance (is)
Capable of exhibiting the same behavior but possibly with additional responsibilities and
richer state.
is-a relationship.
Class Relationships
Sequence Diagram
Source:ccs.neu.edu
Collaboration Diagram
Source:ccs.neu.edu
A state diagram shows the states of an object and the
transitions between states.
Objects having discrete states that affect their beaviour.

State Diagram
Source: http://www.agilemodeling.com

BITS Pilani OOAD Document Analysis & Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BITS Pilani OOAD Document Analysis & Design

Uploaded by

Copyright:

Available Formats

BITS Pilani

You might also like