Module-3

Analysis and Design

Chapter 1
Process overview
• A software Development process provides a
basis for the organized production of
software, using a collection of predefined
techniques and notations.
 1. Development Stages:
The development stages can be summarized as follows:
• System Conception
• Analysis
• System design
• Class design
• Implementation
• Testing
• Training
• Deployment
• Maintenance
System Conception:
Conceive an application and formulate tentative
requirements.

Analysis:
• Understand the requirements by constructing
models…focus on what…rather then how?
• Two sub stages of analysis: Domain analysis and
application analysis.
• Domain analysis focuses on real-world things
whose semantics the application captures.
Eg: Airplane flight is a real world object that a flight
reservation system must represent.
• Domain analysis is then followed by
application analysis.
• Application analysis addresses the computer
aspects of the application that are visible to
users. Eg : flight reservation screen is a part of
Flight Reservation System.
• Application Objects are meaningful only in the
context of an application.
• Not the implementation aspect (black box
view)
System Design:
• Depends on the present requirement and past
experiences.
• The architecture must also support future
modifications to the application.
• For simple systems. architecture follows
analysis.
• For large and complex systems: there is
interplay between the construction of a model
and the model’s architecture and they must
be built together.
Class design:
• Augment and adjust the real-world models
from analysis so that they are amenable to
implementation.
• Developers choose algorithms to implement
major system functions.
Implementation:
• Translate the design into code and database
structure.
• Often tools can generate some of the code
from the design model.
Testing:
• Ensure that the application is suitable for actual use and
that it truly satisfies the requirements.
Unit tests discover local problems and often require
that extra instrumentation be built into the code.
• System test exercise a major subsystem or the entire
application.
This can discover broad failures to meet specifications.
• Both unit and system tests are necessary.
• Testing should be planned from the beginning and
many tests can be performed during implementation.
Training:
• Help users master the new application.
• Organization must train users so that they can fully
benefit from an application.
Deployment:
• Place the application in the field.
• The eventual system must work on various platforms
and in various configurations.
• Localize the product to different languages.
Maintenance:

• Bugs that remain in the original system will gradually

appear during use and must be fixed.
• A successful application will also lead to
enhancement requests and long lived application
will occasionally have to be restructured.
 Development Life Cycle
Waterfall Development
• developer performs a software development
stages in a Rigid linear sequence with no
backtracking.
• Suitable for well understood applications with
predictable outputs from analysis and design, such
systems seldom occur.
• A waterfall approach also does not deliver a useful
system until completion.
• This makes it difficult to assess progress and
correct a project that has gone awry.
 Iterative Development
• More flexible.
• There are multiple iterations as the system
evolves to final deliverable.
• Each iteration includes a full complement of
stages: analysis, design, Implementation and
testing.
• This is the best choice for most applications
because it gracefully responds to changes and
minimizes risk of failure.
• Management and business users get early
feedback about progress.
Chapter 2
System Conception
• System Conception deals with the
genesis(origin or source) of an application.
• Some people, who understand both business
needs and technology, think of an idea for an
application.
• Developers then explore the idea to
understand the needs and devise possible
solutions.
 1. Devising a System Concept.
• Most ideas for a new system are extension of existing
ideas.
• Eg: HR dept may have a DB of employee benefit
choices and require that a clerk enter changes.
• An obvious extension is to allow employees to view
and enter their own changes.
• Many issues :( Security, reliability, privacy ...)
• But.. New idea is a straightforward extension of an
existing concept.
• Eg2: online auction system. which is the automation
of the existing system which is running presently
manually .
 Some ways to find new system
concepts:
• New Functionality- Add functionality to an existing system.
• Streamlining- remove restriction or generalize the way a system
works.
• Simplification- Let ordinary persons perform tasks previously
assigned to specialists.
• Automation- automate manual processes
• Integration- Combine functionality from different systems.
• Analogies- Look for analogies in other problem domains and
see if they have useful ideas.
• Globalization-Travel to other countries and observe their
cultural and business practices.
 2. Elaborate a concept
A good system concept must answer the following
questions.
• Who is the application for ? Stack holders
Financial sponsor, end users.
• What problems will it Solve?
• Where will it be used ?
• When is it needed?
• Why is it needed ?
• How will it works?
 CASE STUDY
ATM Case Study (Automated Teller machine)
System Concept for an automated teller machine.
“Develop software so that customers can access a
bank’s computer and carry out
their own financial transactions without the
mediation of a bank employee”
• Who is the application for?
The Vendor building the software (assume its we)
• What problems will it Solve?
ATM is built to serve both the bank (automation)
and the customer (ubiquitous)
Where will it be used ?
ATM are available at many stores, sporting events and
other locations throughout
the world
• When is it needed?
From an economic perspective, it is desirable to minimize
the investment,
maximize the revenue, and realize revenue as soon as
possible. (OOMD Helps)
• Why is it needed ?
A novel product could outflank competitors and lead to
premium pricing.Here
the case study is taken for explanation.
• How will it work?
We adopt a three-tier architecture
Chapter 3
Domain Analysis
 1. Overview of Analysis
• The problem statement should not be taken as
immutable, but rather as a basis for refining
the requirements.
• Analysis is divided into two sub stages
• Domain analysis
• Application analysis
 2. Domain Class Model
• First step in analyzing the requirements is to
construct a domain model.
• Static structure of the real world system is
captured.
• The domain model describes real-world classes
and their relationships to each other.
• Information for the domain model comes from
the problem statement, artifacts from related
systems, expert knowledge of the application
domain and general knowledge of the real world.
 The steps to be performed to
construct a domain class model:
• Find Classes.
• Prepare a data dictionary.
• Find associations.
• Find attributes of objects and links.
• Organize and simplify classes using inheritance.
• Verify that access paths exist for likely queries.
• Iterate and refine the model.
• Reconsider the level of abstraction.
• Group classes into packages
 Finding classes
• Classes often correspond to nouns. Ref figure 12.2.
• Eg- ” a reservation system sell tickets to performances
at various theater”- Tentative classes would be
Reservation, System, Tickets, Performance and
Theaters.
• Idea is to capture concepts. not all nouns are
concepts, and concepts are also expressed in other
parts of speech.
• Additional classes that do not appear directly in the
statement but can be identified from our knowledge
of the problem domain
Keeping the right classes
Domain Class Model: Keeping the right
classes
Discard unnecessary and incorrect classes according to
the following criteria
• Redundant classes: If two classes express the same
concept, you should keep the most descriptive name.
ATM example. Customer and user are redundant; we
retain customer because it is more descriptive.
• Irrelevant classes
Apportioning cost is outside the scope of the ATM
software.
• Vague classes: class should be specific.
Attributes: Names that primarily describe individual
objects should be restated as attributes.
• 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.
Eg-if we are simply building telephones, then call is part
of the state model and not a class
• Roles: The name of a class should reflect its intrinsic
nature and not a role that it plays in an association.
• Owner of a car..in a car manufacturing database, not
correct as a class. It can be a person( owner, driver,
lessee)
• Implementation Constructs:
Eliminate constructs from the analysis model
that are extraneous to the real world.
We may need them during design and not now.
• Derived classes:
As a general rule, omit classes that can be
derived from other classes.
mark all derived classes with a preceding
slash(‘/’)in the class name.
 Preparing a Data Dictionary
• Prepare a data dictionary for all modeling elements.
• Describe the scope of the class within the current
problem, including all assumptions or restrictions on
its use.
• DD also describes associations, attributes, operations
and enumeration values
Data Dictionary for the ATM classes
Account ATM
Bank BankComputer
CashCard Cashier
cashierStation CentralComputer
Consortium Customer
Transaction
 Finding associations
• A structural relationship between two or more
classes is an association.
• A reference from one class to another is an
association.
• Associations often correspond to verbs or verb
phrases. Idea here is to capture relationships
 Keeping the Right Association
Discard unnecessary associations, using the
following criteria:
• Associations between eliminated classes.
• Irrelevant or implementation associations.
• Actions: An association should describe a
structural property of the application
domain not a transient event.
• Ternary associations.
• Derived associations :they may be redundant
Further specify the semantics of associations as
follows:
• Misnamed associations.
• Association end names.
• Qualified associations.
• Multiplicity
• Missing associations
• Aggregation.
• Fig 12.9 shows class diagram with remaining
associations
 Find attributes of objects and links.
• Attributes are data properties of objects
• Attribute values should not be objects; use an
association to show any relationship between
objects.
• Attributes usually correspond to nouns
followed by possessive phrases, such as “the
color of the car
 Keeping the right attributes:
Eliminate unnecessary and incorrect attributed with the
following criteria:
• Objects . Discordant attributes
• Qualifiers . Boolean attributes.
• Names
• Identifiers
• Attributes on associations
• Internal values
• Fine detail
• Discard attributes
• Boolean attributes
 Refining With Inheritance
Organize classes by using inheritance to share
common features:
• Bottom up generalization.
• Top-down generalization
• Generalization vs. enumeration.
• Multiple inheritance
• Similar associations
• Adjusting the inheritance level.
• Fig 12.11 shows the ATM class model after adding
inheritance
• Verify that access paths exist for likely queries.
• Trace access paths through the class model to
see if they yield sensible results.
• Iterate and refine the model.
• A class model is rarely correct after a single
pass, so iterate and refine the model.
• Fig 12.12 shows a revised class diagram that
is simpler and cleaner.
Group classes into packages.
• The last step of class modeling is to group classes into
packages.
• A package is a group of elements(classes, association,
generalizations and
lesser packages) with common theme.
3. Domain State Model
The Following steps are performed in constructing a
domain state model
• Identifying classes with states
• Finding states
• Finding Events
• Building state diagrams
• Evaluating state diagrams
After running thro the above steps, the domain state
model obtained is a shown in Figure
Domain Interaction Model
• The Interaction model is seldom important for
domain analysis.
• The Interaction model is an important aspect
of application modeling
5. Iterating the Analysis
The iteration to the analysis should ne done as
follows:
• Refining the Analysis Model
• Restating the Requirements
• Analysis and Design.ng