Unit - 3

CSE307 – Object Oriented Analysis & Design

 Chapter - 10
Process Overview
• What is software development process?
– A software development process provides a basis for the organized
production of software, using a collection of predefined techniques
and notations.

– Process steps:
1. Formulation
2. Analysis
3. Design
4. Implementation.

2
 Development Stages
• Software development process has a sequence of
well-defined stages, each with a distinct purpose,
input, and output.
1. System conception
2. Analysis
3. System design
4. Class design
5. Implementation
6. Testing
7. Training
8. Deployment
9. maintenance
 System conception
• Deals with the genesis of an application
• Initially somebody thinks of an idea for an
application and sells the idea to the
organization
• The innovator must understand both business
needs and technological capabilities
 Analysis
• Focuses on creation of models
• They specify what must be done, not how it should
be done
• It is difficult because developers must fully
understand the problem
• Developers consider the available sources of
information and resolve ambiguities
• Two stages
1. Domain analysis
• Focuses on real-world thing how it is captured in application
2. Application analysis
• Addresses the computer application that are visible to users
 System design
• During this stage, the developer makes strategic
decisions with broad consequences
• Must formulate
• Architecture
1. Global strategy
2. Policies
• The system designer must understand how a new
system interacts with other systems
• The architecture must also support future
modification of the application
 Class design
• During class design, the developer expands
and optimizes analysis models
• There is a shift in emphasis from application
concepts toward computer concepts
• Developers choose algorithms to implement
major system functions
 Implementation
• It is the stage for writing the actual code
• Mapping of design elements – programming
language and database code
 Testing
• After implementation the system is complete,
but it must be carefully tested before being
commissioned for actual use
• Testers checks original business requirements
and verify that the system delivers the proper
functionality
 Training
• Organization must train users so that hey can
fully benefit from an application
• It actually accelerates users on the software
learning curve
 Deployment
• Developers must tune the system under
various loads and write scripts and install
procedures
• Actual result here is to produce usable
product release
 Maintenance
• Once development is complete and a system
has been deployed, it must be maintained for
continued success
• Kinds of maintenance
– Bugs that remains in the original system must be
fixed
– Enhancement needs to be satisfied
 Development Life Cycle
• An OO approach to software development
supports multiple life-cycle styles.
• waterfall approach performing the phases of
analysis, design, and implementation in strict
sequence for the entire system
• an iterative development strategy
14
 Difference between waterfall
development and iterative development

1. Linear sequence 1. Cyclic

2. No backtracking 2. Backtracking
3. Applicable to projects 3. Applicable to any
with clear projects
requirements 4. Partial knowledge
4. It is applicable where about tools
tools are completely
known to the
developers
 Chapter – 11
System Conception
• Deals with the genesis of an application.
• Understands both business needs and
technology, thinks of an idea for an
application
• Purpose of system conception is to defer
details and understand the proposed system
meet, developed at a reasonable cost.
Devising a System Concept
Case Study : ATM software
 Problem statement
• The first step to develop anything is to state the
requirements.
• The problem statement should state what is to
be done and not how it is to be done.
• It should be a statement of needs, not a
proposal for a solution.
• The requester should indicate which features are
mandatory and which are optional; to avoid
overly constraining design decisions.
• The requester should avoid describing system
internals.
 Problem statement contd.
• A problem statement may have more or
less detail.
• The problem statement is just a starting
point for understanding problem.
• Subsequent analysis helps in fully
understanding the problem and its
implication.
 Kinds of requirements

8/28/12
Example : ATM Network
ATM System: Problem Statement
• Design the software to support a computerized banking network including both
human cashiers and automatic teller machines (ATMs) to be shared by a
consortium of banks. Each bank provides its own computer to maintain its own
accounts and process transactions against them. Cashier stations are owned by
individual banks and communicate directly with their own bank’s computers.
Human cashiers enter account and transaction data.

• Automatic teller machines communicate with a central computer that clears

transactions with the appropriate banks. The system requires appropriate
recordkeeping and security provisions. ThAn automatic teller machine accepts
a cash card, interacts with the user, communicates with the central system to
carry out the transaction, dispenses cash, and prints receipts.e system must
handle concurrent accesses to the same account correctly.

• The banks will provide their own software for their own computers; you are to
design the software for the ATMs and the network. The cost of the shared
system will be apportioned to the banks according to the number of customers
with cash cards.
• LIBRARY MANAGEMENT SYSTEM
• Library management System (LMS) provides a simple GUI (graphicaluser
interface) for the Library Staff to manage the functions of the
libraryeffectively. Usually when a book is returned or issued, it is noted
down in aregister after which data entry is done to update the status of
the books in amoderate scale. This process takes some time and proper
updation cannot beguaranteed. Such anomalies in the updation process
can cause loss of books.So a more user friendly interface which could
update the database instantly,has a great demand in libraries.The goal of
this project is to provide simplicity as well as security andefficiency to the
management. Its main objective is to provide all thefunctions of the library
along with support of barcode reader. Thecontemporary system stores the
database information on a local computer,which can‟t be updated and
accessed on a remote computer or a computer in the library network
Problem 1

“Online Movie Box” is a web portal , all viewers can watch

old and new movies on request. Viewers can search for any
movie and watch. Different pricing is applicable depends
on rating of movies. - List the various sequence of stages
incorporated for developing software for the above
problem along with outcome of each stage.
System conception: End users can be identified; overview of features; client details;
People can be a end-user;
Analysis:
Application analysis: features according to end user ; facilities of this portal can be Explored
Domain Analysis : with respect to developer point of view: basic conception of class
(movie, viewer, etc) , state (download, watching etc)
System design: architecture design; communication with other systems; policies; global
Strategies: eg: portal with paid registration; web-interface with features , etc
Class design: planning for formulating idea ; algorithm; internal view of system (class;
methods like)
Implementation: choose relevant software/language for implementing the formulated idea ;
identification of scripting, validation
Testing: manual or automated should be ; to check whether the code is executed as
expected; eg: viewers should be allowed to watch movie without pay;
Training: end users should be given training for accessing and handling or acquiring facilities of
this portal : eg: training video for how to watch, save, play fastforward
etc
Deployment: actual product release ; before that whether the movies are downloadable or
only play option should be tested; any trial version can be released for this
movie portal
Maintenance: during maintenance period; any bug, corrections reported by viewer should be
addressed by the developer team
 Overview of Analysis
• Begins with a problem statement generated by clients
• Statement in natural language are often ambiguous,
incomplete, and inconsistent
• The analysis model is a precise, concise representation of
the problem that permits answering questions and building
a solution
• Subsequent design steps refer to the analysis model, rather
than the original problem statement
• The analysis model addresses the three aspects of objects:
• Static structure (Class model)
• Sequencing of interactions (State model)
• Data transformations (Interaction model)
Overview of analysis process
Domain Class Model
 Domain Class Model
• The following steps are performed in constructing a
domain class model :
• Identify objects and classes
• Prepare a data dictionary
• Identify associations between objects
• Identify attributes of objects and links
• Organize and simplify object classes using inheritance
• Iterate and refine the model
• Group classes into modules
 1. Identifying Object Classes
• From the problem statement (application
domain), identify relevant object classes.
• All classes must make sense in the application
domain; avoid computer implementation
constructs.
• Not all classes are explicit in the problem
statement; some are implicit in the application
domain.
Keeping the Right classes
• Now discard the unnecessary and incorrect classes according
to the following criteria:
• Redundant classes

• Irrelevant classes

• Vague classes

• Attributes

• Operations

• Roles

• Implementation constructs
 Keeping the Right classes
1) Redundant Classes - If two classes express the same information, the most
descriptive name should be kept.
2) Irrelevant Classes - If a class has little or nothing to do with the problem, it
should be eliminated . This involves judgment, because in another context
the class could be important.
3) Vague Classes - A class should be specific. Some classes may have not
specific should be eliminated.
4) Attributes - Names that primarily describe individual objects should be
restated as attributes.
5) Operations - If a name describes an operation that is applied to objects
and not manipulated in its own right, then it is not a class.
6) Roles - The name of a class not a role that it plays in an association.
7) Implementation Constructs - Constructs extraneous to real world should
be eliminated from the analysis model. They may be needed later during
design, but not now
Eliminating Unnecessary classes
2. Preparing a data dictionary

• Prepare a data dictionary for all

modeling entities such as class,
attribute, operation and
association.
• Write a paragraph precisely
describing each entity which
describes the scope of their need
within the current problem.
 Example – Data Dictionary
• Account – a single account in a bank against
which transactions can be applied.
• ATM – a station that allows customers to
enter their own transactions using cash cards
as identification.
• Bank – a financial institution that holds
accounts for customers and that issues cash
cards authorizing access to accounts over the
ATM network.
 3. Identifying Associations
■ Next Identify associations between classes.
■ A reference from one class to another is an association.
■ Associations often correspond to stative verbs or verb
phrases. These include
physical location (next to, part of),
directed actions (drives),
communication (talks to),
ownership (has, part of) or
satisfaction of some kind (works for).
■ Majority of the associations are taken from verb
phrases in the problem statement.
■ Note:
■ Don’t try to refine things too early.
ATM System: Identifying Associations

Explicit Verb phrases

● Banking Network includes cashier stations and ATMs
● Consortium Shares ATMs
● Bank computer maintains accounts
● ATM interacts with user
● ATM dispense cash
● ATM prints receipts
● Bank provide software
● Cost apportioned to banks
ATM System: Identifying Associations

Implicit verb phases

● Consortium consists of banks
● Bank holds account
● Consortium owns central computer
● System provides record keeping
● System provides security
● Customers have cash cards
Knowledge of problem domain
● Cash card accesses accounts
● Bank employs cashiers
Keeping the right Associations
Discard unnecessary and incorrect associations using the following
criteria:
1.Associations between eliminated classes
If one of the classes in the association has been eliminated, then the
association must be eliminated or restated in terms of other classes.
2.Irrelevant or implementation Associations
Eliminate any association that are outside the problem domain or deal with
implementation constructs.
3.Actions
An association should describe a structural property of the application
domain, not a transient event. (ex. ATM accepts cash card )
4.Ternary Association
Most associations between three or more classes can be decomposed into
binary associations or phrased as qualified associations.
5.Derived Association
Omit associations that can be defined in terms of other associations because
they are redundant.
Keeping the right Associations
Further specify the semantics of associations as follows:

1) Misnamed Associations
Names are important to understanding and should be chosen with great
care.
2) Role names
Add role names where appropriate. The role name describes the role that a
class in the association plays from the point of view of other class.
3) Qualified Associations
A qualifier distinguishes objects on the “many” side of an association. So
wherever necessary in association add qualifiers.
4) Multiplicity
Specify multiplicity, but don’t put too much effort into getting it right, as
multiplicity often changes during analysis.
5) Missing Associations
Add any missing associations that are discovered.
ATM Network
 4. Identifying Attributes
• Attributes are properties of individual objects, such
as name, weight, velocity, or color. Attributes
shouldn’t be objects.
• Attributes usually correspond to nouns followed by
possessive phrases, such as the “color of the car”.
• Adjectives often represent specific enumerated
attribute values, such as red.
• We can find the attributes with our knowledge of the
application domain and the real world.
• Derived attributes are clearly labeled or should be
omitted.
 Keeping the Right Attributes
Eliminate unnecessary and incorrect attributes with the following
criteria:

● Objects: If the independent existence of an entity is important,

rather than just its value, then it is an object. For e.g.:- Boss is an
object and salary is an attribute. The distinction often depends on
the application.
● Qualifiers: If the value of an attribute depends on a particular
context, then consider restating the attribute as a qualifier. e.g.:-
Employee number is not a unique property of a person with two
jobs, it qualifies the association company employs person.
● Names: Names are often better modeled as qualifiers rather than
attributes.
● Identifiers: Object Oriented Languages incorporate the notion of
an object id for unambiguously referencing an object. Do not list
object identifiers in object models (implicit in object models). Only
list attributes which exist in application domain.
 Keeping the Right Attributes
● Internal values: If an attribute describes the internal
state that is invisible outside the object, then eliminate
it from the analysis.
● Fine detail: Omit minor attributes which are unlikely to
affect most operations.
● Discordant attributes: An attribute that seems
completely different from and unrelated to all other
attributes may indicate a class that should be split into
two distinct classes.
● Link Attributes: If a property depends on the presence
of a link, then the property is an attribute of the link and
not of related objects.
 5. Refining with Inheritance
● The next step to organize classes by using inheritance to
share common structure.
● Inheritance can be added in two directions:-
1) By generalizing common aspects of existing classes into a
super class (bottom up),
2) Refining existing classes into specialized subclasses (top
down).
● We can discover inheritance from the bottom up by
searching for classes with similar attributes, associations, or
operations.
● Top down specializations are often obvious from the
application domain.
● Multiple inheritance may be used to increase sharing, but
only if necessary, because it increase implementation
complexity.
 6.Testing Access Paths
• Trace access paths through object model
diagram to see if they yield sensible results.
• Where a unique value is expected, is there a path
yielding a unique result?
• For multiplicity “many” is there a way to pick out
unique values when needed?
• Are there useful questions which can’t be
answered?
• Thus we will be able to identify if there is some
missing information.
 7. Iterating domain class Model
• Class model is rarely correct after a single pass.
• Different parts of a model are iterated often at
different stages of completion.
• If there is any deficiency, go back to an earlier stage
if necessary to correct it.
✔ Signs of missing objects
✔ Signs of unnecessary classes
✔ Signs of missing associations
✔ Signs of unnecessary associations
✔ Signs of incorrect placement of associations
✔ Signs of incorrect placement of attributes
Example: ATM Network
 8. Grouping Classes into Modules
• The last step of domain class modeling is to group
classes into sheets and modules.
• Diagrams may be divided into sheets of uniform size
for convenience in drawing, printing, and viewing.
• A module is a set of classes that captures some
logical subset of the entire model.
• The ATM object model consists of three modules
tellers, accounts, and banks
✔ Tellers-cashier, entry station, cashier station, ATM
✔ Accounts-account, cash card, card authorization, customer
✔ Banks-consortium, bank
Domain State Model
for ATM
 Steps to construct
domain state model
• Identify domain classes with states.
• Find states.
• Find events.
• Build state diagrams.
• Evaluate state diagrams.
Identify domain classes with states.
• Identify the significant states in the life cycle of an object.
• For example, a scientific paper for a journal goes from Being
written to Under consideration to Accepted or Rejected.
• There can be some cycles, for example, if the reviewers ask
for revisions, but basically the life of this object is
progressive.
• An airplane owned by an airline cycles through the states of
Maintenance, Loading, Flying, and Unloading
• ATM example. Account is an important business concept, and
the appropriate behavior for an ATM depends on the state of
an Account. The life cycle for Account is a mix of progressive
and cycling to and from problem states. No other ATM classes
have a significant domain state model.
 Finding States
• List the states for each class.
• Characterize the objects in each class—the
attribute values that an object may have,
• the associations that it may participate in and
their multiplicities, attributes and associations
that are meaningful only in certain states, and
so on.
• Give each state a meaningful name.
 ATM example
• Here are some states for an Account:
• Normal (ready for normal access),
• Closed (closed by the customer but still on file
in the bank records),
• Overdrawn (customer withdrawals exceed the
balance in the account), and
• Suspended (access to the account is
blocked for some reason).
ATM – Account Class
 Finding Events
• Once you have a preliminary set of states, find the events
that cause transitions among states.
• Think about the stimuli that cause a state to change.
• In many cases, you can regard an event as completing a
do-activity.
• For example, if a technical paper is in the state Under
consideration, then the state terminates when a decision
on the paper is reached.
• In this case, the decision can be positive (Accept paper) or
negative (Reject paper).
• In cases of completing a do activity, other possibilities are
often possible and may be added in the future—for
example, Conditionally accept with revisions.
 ATM example
• Important events include:
• close account,
• withdraw excess funds,
• repeated incorrect PIN,
• suspected fraud, and
• administrative action.
 Building State Diagrams
• Add transitions to show the change in state caused by the
occurrence of an event when an object is in a particular state.
• If an event terminates a state, it will usually have a single
transition from that state to another state.
• If an event initiates a target state, then consider where it can
occur, and add transitions from those
states to the target state.
• Consider the possibility of using a transition on an enclosing state
rather than adding a transition from each sub-state to the target
state.
• If an event has different effects in different states, add a transition
for each state.
• Once you have specified the transitions, consider the meaning of
an event in states for which there is no transition on the event.
• ATM example. Figure on next slide shows the domain state model
for the Account class
Domain state model.
Domain Interaction Model
• The interaction model is seldom important for
domain analysis.
• During domain analysis the emphasis is on key
concepts and deep structural relationships
and not the users’ view of
them.
• The interaction model, however, is an
important aspect of application modeling.
 Chapter: 13
Application Analysis
❑ interaction modeling by determining the overall boundary of the system.
❑ Then identify use cases and flesh them out with scenarios and sequence diagrams.
❑ prepare activity diagrams for use cases that are complex or have subtleties.
❑ Once you fully understand the use cases, you can organize them with relationships.
❑ And finally check against the domain class model to ensure that there are no
inconsistencies.
❑ You can construct an application interaction model with the following steps.
■ Determine the system boundary.
■ Find actors.
■ Find use cases.
■ Find initial and final events.
■ Prepare normal scenarios.
■ Add variation and exception scenarios.
■ Find external events.
■ Prepare activity diagrams for complex use cases.
■ Organize actors and use cases.
■ Check against the domain class model.
Determining the System Boundary
• The precise scope of an application—the
boundary of the system—in order to specify
functionality.
• Humans are actors
that must interact with the system, but their
actions are not under the control of the
system.
• Fix boundary by taking exact problem
statement with unambiguous statements.
 Finding Actors
• identify the external objects that interact directly with the system.
• These are its actors. Actors include humans, external devices, and
other software systems.
• The important thing about actors is that they are not under
control of the application,
• it does not crash if an actor fails to behave as expected.
• Each actor represents an idealized user that exercises some subset
of the system functionality.
• Examine each external object to see if it has several distinct faces.
• An actor is a coherent face presented to the system, and an
external object may have more than one actor.
• For the ATM application, the actors are Customer,
Bank, and Consortium.
 Finding Use Cases
• For each actor, list the fundamentally different ways in which the actor
uses the system.
• Each of these ways is a use case. The use cases partition the functionality
of a system into a small number of discrete units.
• All system behavior must fall under some use case.
• You may have trouble deciding where to place some piece of marginal
behavior. Keep in mind that
there are always borderline cases when making partitions;
• Each use case should represent a kind of service that the system provides
• Something that provides value to the actor. Try to keep all of the use cases
at a similar level of detail.
• Show the actors and the use cases, and connect actors to use cases.
• Usually you can associate a use case with the actor that initiates it, but
other actors may be involved as well. Don’t worry if you overlook some
participating actors.
• You should also write a one or two sentence summary for each use case.
ATM use case
ATM use case summarize
Preparing Normal Scenarios
• Prepare scenarios for “normal” cases—interactions without any
unusual inputs or error conditions.
• An event occurs whenever information is exchanged between an
object in the system and an outside agent, such as a user, a
sensor, or another task.
• The information values exchanged are event parameters.
• For example, the event password entered has the password
value as a parameter.
• Events with no parameters are meaningful and even common.
• The information in such an event is the fact that it has occurred.
• For each event, identify the actor (system, user, or other external
agent) that caused the event and the parameters of the event.
ATM-Normal Scenario
ATM - Normal Scenario
Adding Variation and Exception
Scenarios
ATM – Sequence Diagram
Activity Diagram
Organizing Actors and Use Cases
 Specifying User Interfaces

• Defining Boundary Classes

• Determining Controllers
• Checking Against the Interaction Model
Application Class Model
 Application state model
• You can construct an application state model
with the following steps.
■ Determine application classes with states.
■ Find events.
■ Build state diagrams.
■ Check against other state diagrams.
■ Check against the class model.
■ Check against the interaction model.
 Adding Operations
■ account.close()
■ bank.createSavingsAccount(customer): account
■ bank.createCheckingAccount(customer): account
■ bank.createCashCardAuth(customer):
cashCardAuthorization
■ cashCardAuthorization.addAccount (account)
■ cashCardAuthorization.removeAccount (account)
■ cashCardAuthorization.close()
Initial Class Diagram of ATM