Unit-4- Process oveunit5and6forview.pptx

Process Overview
•A software development process provides a basis for the organized production
of software, using a collection of predefined techniques and notations.
•The process starts with formulation of the problem, then continues through
analysis, design, and implementation.
•The presentation of the stages is linear, but the actual process is seldom linear.
2

Development Stages
■ System conception. Conceive an application and formulate tentative requirements.
■ Analysis. Deeply understand the requirements by constructing models. The goal of
analysis is to specify what needs to be done, not how it is done. You must understand a
problem before attempting a solution.
■ System design. Devise a high-level strategy—the architecture—for solving the
application problem. Establish policies to guide the subsequent class design.
■ Class design. Augment and adjust the real-world models from analysis so that they
are amenable to computer implementation. Determine algorithms for realizing the
operations.
3

■ Implementation. Translate the design into programming code and database
structures.
■ Testing. Ensure that the application is suitable for actual use and that it truly
satisfies the requirements.
■ Training. Help users master the new application.
■ Deployment. Place the application in the field and gracefully cut over from
legacy applications.
■ Maintenance. Preserve the long-term viability of the application.
4

System Conception
System conception deals with the genesis of an application.
Initially somebody thinks of an idea for an application, prepares a
business case, and sells the idea to the organization.
The innovator must understand both business needs and
technological capabilities.
5

Analysis
Analysis focuses on creation of models. Analysts capture and scrutinize
requirements by constructing models. They specify what must be done, not how
it should be done.
•There are two substages of analysis: domain analysis and application analysis.
•Domain analysis focuses on real-world things whose semantics the application
captures. For example, an airplane flight is a real-world object that a flight
reservation system must represent.
• Domain analysis is then followed by application analysis that addresses the
computer aspects of the application that are visible to users. For example, a
flight reservation screen is part of a flight reservation system.
6

System Design
•During system design, the developer makes strategic decisions with
broad consequences. You must formulate an architecture and
choose global strategies and policies to guide the subsequent, more
detailed portion of design.
•The architecture is the high-level plan or strategy for solving the
application problem. The choice of architecture is based on the
requirements as well as past experience.
7

Class Design and Implementation
•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, but they
should continue to defer the idiosyncrasies of particular programming
languages.
Implementation is the stage for writing the actual code. Developers map design
elements to programming language and database code. Often, tools can
generate some of the code from the design model.
8

Testing
•After implementation, the system is complete, but it must be carefully tested before
being commissioned for actual use. The ideas that inspired the original project should
have been nurtured through the previous stages by the use of models.
•Testers once again revisit the original business requirements and verify that the system
delivers the proper functionality.
•Developers should check a program at several levels. Unit tests exercise small portions
of code, such as methods or possibly entire classes.
•Unit tests discover local problems and often require that extra instrumentation be built
into the code. System tests exercise a major subsystem or the entire application. In
contrast to unit tests, system tests can discover broad failures to meet specifications.
Both unit and system tests are necessary.
9

Training
•An organization must train users so that they can fully benefit from an
application. Training accelerates users on the software learning curve.
•A separate team should prepare user documentation in parallel to the
development effort.
• Quality control can then check the software against the user documentation to
ensure that the software meets its original goals.
10

Deployment
•The eventual system must work in the field, on various platforms
and in various configurations.
Unexpected interactions can occur when a system is deployed in a
customer environment.
•Developers must tune the system under various loads and write
scripts and install procedures. Some customers will require software
customizations. Staff must also localize the product to different
spoken languages and locales. The result is a usable product release.
11

Maintenance
•Once development is complete and a system has been
deployed, it must be maintained for continued success.
There are several kinds of 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 a long-lived application will occasionally have
to be restructured.
12

Development Life Cycle
1. Waterfall Development: The waterfall approach dictates that developers
perform the software development stages in a rigid linear sequence with no
backtracking.
• Developers first capture requirements, then construct an analysis model, then
perform a system design, then prepare a class design, followed by
implementation, testing, and deployment. Each stage is completed in its entirety
before the next stage is begun.
•The waterfall approach is suitable for well-understood applications with
predictable outputs from analysis and design, but such applications seldom
occur.
13

Development Life cycle
Iterative Development
•Iterative development is more flexible.
• First you develop the nucleus of a system—analyzing, designing, implementing, and
delivering working code.
•Then you grow the scope of the system, adding properties and behavior to existing
objects, as well as adding new kinds of objects. There are multiple iterations as the
system evolves to the final deliverable.
•Each iteration includes a full complement of stages: analysis, design, implementation,
and testing. Unlike the strict sequence of the waterfall method, iterative development
can interleave the different stages and need not construct the entire system in lock
step.
•Iterative development is the best choice for most applications because it gracefully
responds to change and minimizes risk of failure. Management and business users get
early feedback about progress.
14

System Conception deals with the genesis of an application.
The purpose of System conception is to defer details and
understand the big picture.
What need does the proposed system meet, can it be developed
at a reasonable cost, and will the demand for the result justify
the cost of building it?
11.1 Devising a System Concept
Most ideas for new systems are extensions of existing ideas.
For Ex: a human relations department may have a database 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.
16

Occasionally, a new system is a radical departure from the
past. An online auction automates the ancient idea of buyers
bidding against each other for products.
Here are some ways to find a new system concepts
New functionality: Add functionality to an existing system.
 Streamlining: Remove restrictions or generalize the way a
system works.
 Simplification: Let ordinary persons perform tasks
previously assigned to specialists.
Automation: automate manual process.
Integration: Combine functionality from different systems.
17

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.
18

11.2 Elaborating a Concept
Good system concept must answer the following questions
Who is the application for?
We should clearly understand which persons and organizations are
stakeholders of the new system.
Two of the most important kinds of stake holders are the financial
sponsors and end users.
The financial sponsor are very important because they are paying for
the new system.
19

The users are stakeholders, but in another sense.
What problems will it solve?
We must clearly bound the size of the effort and establish its
scope. We should determine which features will be in the new
system and which will not.
Where will it be used?
At the early stage, it is helpful to get a general idea of where
the new system will be used.
We must determine if the new system is mission-critical
software for the organization, experimental software, or a new
capability that we can deploy.
We should have a rough idea about how the new system will
complement the existing systems.
20

When is it needed?
Two aspects of time are important. The first is the feasible
time, the time in which the system can be developed within
the constraints of cost and available resources.
The other is the required time, when the system is needed to
meet business goals.
Why is it needed?
We may need to prepare a business case for the new system if
someone has not done already. The business case contains
financial justification for the new system including the cost,
tangible benefits etc,.
We must be sure that we clearly understand the motivation for
the new system.
The business case will give insight into what stakeholders
expect, roughly indicating the scope.
21

How will it work?
We should brainstorm about the feasibility of the problem. For
large systems we should consider the merits of different
architectures.
The purpose of this speculation is not to choose a solution, but
to increase confidence that the problem can be solved
reasonably.
The ATM case study
The figure lists the original system concept for an Automated
Teller Machine(ATM).
22

Who is the application for?
A number of companies provide ATM products. Only a
vendor or a large financial company could possibly justify the
cost and effort of building ATM software.
A vendor would be competing for customers in an established
market. A large vendor could certainly enter such a market,
but might it advantageous to partner with or acquire an
existing supplier.
A small vendor would need some special feature to
differentiate itself from the crowd and attract attention.
If a financial company wanted special features, after
developing ATM software, it could partner with a vendor.
Or it might decide to create a separate organizations that
would build the software, sell it to the sponsoring company,
and then market it to others.
23

What problems will it solve?
The ATM software is intended to serve both the bank and the
customer. For the bank, ATM software increases automation
and reduces manual handling of routine paperwork.
For the customer, the ATM is always available, handling
routine transactions whenever the customer desires.
ATM software must be easy to use and convenient so that
customers will use it in preference to bank tellers. It must be
reliable and secure since it will be handling money.
Where it will be used?
ATM software has become essential to financial institutions.
Customers take it for granted that a bank will have an ATM
machine.
ATM machines are available at many stores, sporting events,
and other locations throughout the world
24

When is it needed?
Any software development effort is a financial proposition.
The investment in development ultimately leads to a revenue
system.
From an economic perspective, it is desirable to minimize the
investment, maximize the revenue, and realize revenue as
soon as possible.
Why is it needed?
There are many reasons why a vendor might decide to build a
software product.
If other companies are making money with similar products,
there is a economic incentive to participate.
25

If other companies are making money with similar products,
there is an economic incentive to participate.
A novel product could outflank competitors and lead to
premium pricing. Business commission internal efforts for
technology that is difficult to buy and critical to them.
How will it work?
We will adopt a three-tier architecture to separate the user
interface from programming logic, and programming logic
from the database.
In reality, the architecture is n-tier, because there can be any
number of intermediate programming levels communicating
with each other.
26

Domain Analysis, the next stage of development, is concerned
with devising a precise, concise, understandable, and correct
model of the real world.
Before building anything complex, the builder must understand
the requirements. Requirements can be stated in words, but these
are often imprecise and ambiguous.
During analysis, we build models and begin to understand the
requirements deeply.
To build a domain model, we must interview business experts,
examine requirements statements, and scrutinize related artifacts.
We must analyze the implications of the requirements and restate
them rigorously. It is important to abstract important features first
and defer small details later.
28

The successful analysis model states what must be
done, without restricting how it is done, and avoids
implementation decisions.
The model serves several purposes:
It clarifies the requirements.
It provides a basis for agreement between the
stakeholders and the developers.
It becomes the starting point for design and
implementation.
29

Overview of analysis
Analysis begins with a problem statement generated during
system conception.
The statement may be incomplete or informal; analysis makes it
more precise and exposes ambiguities and inconsistencies.
The problem statement should not be taken as immutable but
should serve as a basis for refining the real requirements.
Next, we must understand the real-world system described by the
problem statement, and abstract its essential features into a
model.
Statements in natural language are often ambiguous, incomplete
and inconsistent. The analysis model is a precise, concise
representation of the problem that permits answering and
building a solution.
30

Subsequent design steps refer to the analysis model, rather than
the original vague problem statement.
The process of constructing a rigorous model of the problem
domain forces the developer to confront misunderstanding early in
the development process while they are still easy to correct.
The analysis model addresses the three aspects of objects:
static structure of objects(class model),
interactions among objects (interaction model) ,
and life cycle histories of objects (state model)
Almost all problems have useful class models derived from real-
world entities. Problems concerning reactive control and timing,
such as user interfaces and process control, have important state
models.
32

Problems containing significant computation as well as systems
that interact with other systems and different kinds of users have
important interaction models.
Analysis is not a mechanical process. The exact representations
involve judgment and in many regards are a matter of art.
Most problem statements lack essential information, which must
be obtained from the requestor or from the analyst’s knowledge
of the real-world problem domain.
Also there is a choice in the level of abstraction for the model.
The analyst must communicate with the requestor to clarify
ambiguities and misconceptions.
The analysis models enable precise communication.
33

Analysis is divided into two sub stages:
The first domain analysis, focuses on understanding the
real-world essence of a problem
The second, application analysis, builds on the domain
model-incorporating major application artifacts that are
seen by users and must be approved by them.
34

12. 2 Domain Class Model
The first step in analyzing the requirements is to construct a
domain model. The domain model shows the static structure of
the real-world system and organizes it into workable pieces.
The domain model describes real-world classes and their
relationships to each other.
During analysis, the class model precedes the state and
interaction models.
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.
Make sure you consider all information that is available and do
not rely on single source.
35

Find classes and associations first, as they provide the overall
structure and approach to the problem. Next add attributes to
describe the basic network of classes and associations.
Then combine and organize classes using inheritance. Attempts to
specify inheritance directly without first understanding classes and
their attributes can distort the class structure to match preconceived
notions.
Operations are usually unimportant in a domain model. The main
purpose of a domain model is to capture the information content of
a domain.
It is best to get ideas down on paper before trying to organize them
too much, even though they may be redundant and inconsistent, so
as not to lose important details.
36

An initial analysis model is likely to contain flaws that must be corrected by
later iterations. The entire model need not be constructed uniformly.
Some aspects of the problem can be analyzed in depth through several
iterations while other aspects are still sketchy.
We must perform the following steps 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.
37

12.2.1 Finding Classes
The first step in constructing a class model is to find
relevant classes for objects from application domain.
Objects include physical entities, such as houses,
persons, and machines, as well as concepts, such as
trajectories, seating arrangements, and payment
schedules.
All classes must make sense in the application domain,
avoid computer implementation constructs, such as
linked lists and subroutines.
38

Not all classes are explicit in the problem statement; some are
implicit in the application domain or general knowledge.
As shown in the figure, begin by listing candidate classes found in
the written Don’t be too selective; write down every class that
comes to mind. Classes often corresponds to nouns.
For Ex: in the statement “a reservation system to sell tickets to
performance at various theatres” tentative classes would be
Reservation System, Ticket, Performance, and Theatre.
39

Don’t operate blindly, however. The idea to is capture
concepts; not all nouns are concepts, and concepts are
also expressed in other parts of speech.
Don’t worry much about inheritance or high-level
classes; first get specified classes right so that you don’t
subconsciously suppress detail in an attempt to fit a
preconceived structure.
For Ex: if you are building a cataloging and checkout
system for a library, identify different kinds of materials,
such as books, magazines, newspapers, records, videos,
and so on.
We can organize them into broad categories later, by
looking for similarities and differences.
40

ATM example: Examination of the concepts in the ATM problem statement.
Fig shows additional classes that do not appear directly in the statement but can
be identified from our knowledge of the problem domain.
41

12.2.2 Keeping the right classes
Discard unnecessary and incorrect classes according to the following criteria.
42

Redundant classes: If two classes express the same concept, we should keep the
most descriptive name. For Ex: although Customer might describes a person
taking an airline flight, Passenger is more descriptive.
On the other hand, if the problem concerns contracts for a charter airline,
Customer is also an appropriate word, since a contract might involve several
passengers.
ATM Example: Customer and User are redundant; we retain Customer because
it is more descriptive.
Irrelevant classes: If a class has little or nothing to do with the problem,
eliminate it. This involves judgment, because in another context the class could be
important.
For Ex: in a theatre ticket reservation system, the occupations of the ticket holders
are irrelevant, but the occupations of the theatre personal may be important.
43

ATM Ex: Apportioning Cost is outside the scope of the ATM software.
Vague Classes: A class should be specific. Some tentative classes may have ill-
defined boundaries or be too broad in scope.
ATM Ex: RecordkeepingProvision is vague and is handled by Transaction. In
other applications, this might be included in other classes, such as
StockSales,TelephoneCalls, or MachineFailures.
Attributes: Names that primarily describe individual objects should be restated
as attributes. For Ex: name, birthdate, and weight are usually attributes.
If the independent existence of a property is important, then make it a class and
not an attribute.
44

For Ex: an employee’s office would be a class in an application to reassign
offices after a reorganization.
ATM Ex: AccountData is underspecified but in any case probably describes
an account. An ATM dispenses cash and receipts, but beyond that cash and
receipts are peripheral to the problem, so they should be treated 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.
For Ex: a telephone call is a sequence of actions involving a caller and the
telephone network. If we are simply building telephones, then call is part of
the state model and not a class.
An operation that has features of its own should be modeled as a class,
however, For Ex: in a billing system for telephone calls a Call would be an
important class with attributes such as date, time, origin, and destination.
45

Roles: The name of a class should reflect its intrinsic nature and not a role that
it plays in an association. For Ex: Owner would be a poor name for a class in a
car manufacturer’s database.
What if a list of drivers is added later? What about persons who lease cars? The
proper class is Person, which assumes various different roles, such as owner,
driver, and lessee.
One physical entity sometimes corresponds to several classes. For Ex: Person
and Employee may be distinct classes in some circumstances and redundant in
others,
In company database of employees, the two may be identical. In a government
tax database, a person may hold more than one job, so it is important to
distinguish Person from Employee; each person can correspond to zero or more
instances of employee information.
46

Implementation constructs: Eliminate constructs from the analysis model
that are extraneous to the real world. We may need them later during design.
For Ex: CPU, subroutine, process, algorithm, and interrupt are
implementations constructs for most applications, although they are
legitimate classes for an operating system.
Data structures, such as linked lists, trees, arrays, and tables, are almost
always implementation constructs.
ATM Ex: Some tentative classes are really implementation constructs.
TransactionLog is simply the set of transcations; its exact representation is a
design issue.
Communication links can be shown as associations; CommunicationLine is
simply the physical implementation of such a link.
47

Derived Classes : As a general rule, omit classes that
can be derived from other classes. If a derived class is
especially important, we can include it, but do so only
sparingly. Mark all derived classes with a preceding
slash(‘/’) in the class name.
48

Preparing a Data
Dictionary
49

12.2.3 Preparing a data Dictionary
Isolated words have too many interpretations, so prepare a
data dictionary for all modeling elements. Write a paragraph
precisely describing each class.
Describe the scope of the class within the current problem,
including any assumptions or restrictions on its use. The data
dictionary also describes associations, attributes, operations,
and enumeration values.
Fig below shows a data dictionary for the classes in the
ATM problem
50

12.2.4 Finding Associations
Next step is to find association between classes. A
structural relationship between two or more classes is an
association. A reference from one class to another is an
association.
Attributes should not refer to classes; use an
association instead. For Ex: class Person should not have
an attribute employer; relate class Person and class
Company with association WorksFor.
Associations can be implemented in various ways, but
such implementation decisions should be kept out of the
analysis model to preserve design freedom.
52

Associations often correspond to stative
(thought and opinion) verbs or verb phrases.
These include physical location (NextTo, part
of, ContainedIn), directed actions(Drives),
communication (TalksTo), ownership(Has, part
of), or satisfaction of some condition (WorksFor,
MarriedTo, Manages).
Extract all the candidates from the problem
statement and get them down on paper first;
don’t try to refine things too early.
Again, don’t treat grammatical forms blindly;
the idea is to capture relationships, however
they are expressed in natural language.
53

12.2.5 Keeping the Right Associations
Associations between eliminated classes: If we have eliminated
one of the classes in the association, we must eliminate the
association or restate it in terms of other classes.
ATM Ex: We can eliminate Banking network which includes
cashier stations and ATM’s, ATM dispenses cash, ATM prints
receipts, Banks provide software, Cost apportioned to banks, System
provides recordkeeping, and System provides security.
Irrelevant or implementation associations: Eliminate any
associations that are outside the problem domain or deal with
implementation constructs.
ATM Ex: For Ex: System handles concurrent access is an
implementation concept. Real-world objects are inherently
concurrent; it is the implementation of the access algorithm that
must be concurrent.
55

Actions: An association should describe structural
property of the application domain, not a transient event.
Sometimes, a requirement expressed as an action implies
an underlying structural relationship and we should
rephrase it accordingly.
ATM Ex: ATM accepts cash card describes part of the
interaction cycle between an ATM and a customer, not a
permanent relationship between ATMs and cash cards.
We can also eliminate ATM interacts with user. Central
computer clears transaction with bank describes an action
that implies structural relationship Central computer
communicates with bank.
Ternary associations: We can decompose most
associations among three or more classes into binary
associations or phrase them as qualified associations.
56

If a term in a ternary association is purely descriptive
and has no identity of its own, then the term is an
attribute on a binary association.
Association Company pays salary to person can be
rephrased as binary association Company employs
person with a salary value for each Company-Person
link.
ATM Ex: Bank computer processes transaction
against account can be broken into Bank computer
processes transaction and Transaction concerns account.
57

Derived Associations: Omit associations can be
defined in terms of other associations, because
they are redundant. For Ex: GrandparentOf can
be defined in terms of a pair of ParentOf
associations.
Also omit associations defined by conditions on
attributes. For Ex, youngerThan expresses a
condition on the birth dates of two persons, not
additional information.
58

Sometimes the existence of an association can be derived from two or more
primitive associations and the multiplicity can not. Keep the extra association if
the additional multiplicity constraint is important.
For Ex: in figure below a company employs many persons and owns many
computers. Each employee is assigned zero or more computers for the
employee’s personal use; some computers are for public use and are not
assigned to anyone.
The multiplicity of the AssignedTo association can not be deduced from the
Employs and Owns associations.
59

Misnamed Associations: Don’t say how or why a
situation came about, say what it is. Names are important
to understanding and should be chosen with great care.
ATM Ex: Bank computer maintains accounts is a
statement of actions, rephrase as Bank holds account.
Association end names: Add association end names
where appropriate. For Ex: in the WorksFor association a
company is an employer with respect to a Person and a
Person is an employee with respect to Company.
If there is only one association between a pair of classes
and the meaning of the association is clear, we may omit
association end names.
For Ex: the meaning of ATMs communicate with central
computer is clear from the class names.
60

An association between two instances of the same class requires
association end names to distinguish the instances. For Ex: the
association Person manages person would have the end names
boss and worker.
Qualified Association: Usually a name identifies an object within
some context; most names are not globally unique. The context
combines with the name to uniquely identify the object.
For Ex: the name of a company must be unique within the
chartering state but may be duplicated in other states. The name of
a company qualifies the association State charters company;
State and Company name uniquely identify Company. A qualifier
distinguishes objects on the “many” side of an association.
61

ATM Ex: The qualifier bankCode distinguishes the different banks in a
consortium. Each cash card needs a bank code so that transactions can be
directed to the appropriate bank.
Multiplicity: Specify multiplicity, but don’t put too much effort into getting it
right, as multiplicity often changes during analysis.
Challenge multiplicity values of “one”. For example, the association one
Manager manages many employees precludes matrix management or an
employee with divided responsibilities.
For multiplicity values of “many” consider whether a qualifier is needed, also
ask if the objects need to be ordered in some way.
62

Missing Associations: Add any missing associations that are discovered.
ATM Ex: We overlooked Transaction entered on cashier station, Customers have
accounts, and Transaction authorized by cash card. If cashiers are restricted to
specific stations, then the association Cashier authorized on cashier station would
be needed .
Aggregation: Aggregation is important for certain kinds of applications,
especially involving mechanical parts and bills of material.
For other applications aggregation is relatively minor and it can be unclear
whether to use aggregation or ordinary association. Aggregation is just an
association with extra connotations.
Use whichever seems more natural at the time and move on.
ATM Ex: We decide that a Bank is part of a Consortium and indicate the
relationship with aggregation.
63

ATM Ex: Fig below shows a class diagram with the remaining associations. We
have split Transaction into RemoteTransaction and CashierTransaction to
accommodate different associations.
64

12.2.6 Finding Attributes
Attributes are data properties of individual objects, such as weight, velocity, or
color.
Attribute values should not be objects; use an association to show any
relationship between two objects.
Attribute usually correspond to nouns followed by possessive phrases, such as
“the color of the car” or “the position of the cursor”. Adjectives often represent
specific enumerated attribute values, such as red, on, or expired.
Unlike classes and associations, attributes are less likely to be fully described in
the problem statement. We must draw on your knowledge of the application
domain and the real world to find them.
We can also find attributes in the artifacts of related systems. Fortunately,
attributes affect the basic structure of the problem.
65

Do not carry discovery of attributes to excess. Only consider attributes directly
relevant to the application. Get the most important attributes first; we can add
fine details later.
During analysis, avoid attributes that are solely for implementation. Be sure to
give each attribute a meaningful name.
Normally, we should omit derived attributes. For example, age is derived from
birthdate and currentTime. Do not express derived attributes as operations,
such as getAge, although we may eventually implement them that way.
Look for the attributes on associations. Such an attribute is a property of the
link between two objects, rather than being a property of an individual object.
For Ex: the many-to-many association between Stockholder and Company has
an attribute of numberOfShares.
66

12.2.7 Keeping the right attributes
Eliminate unnecessary and incorrect attributes with the following criteria
Objects: If the independent existence of an element is important, rather than just
its value, then it is an object.
For Ex: boss, refers to a class and salary is an attribute. The distinction often
depends on the application.
For Ex: in a mailing list city might be considered as an attribute, while in a
census City would be a class with many attributes and relationships of its own.
An element that has features of its own within the given application is a class.
Qualifiers: If the value of an attribute depends on a particular context, then
consider restating the attribute as a qualifier. For Ex: employeeNumber is
not a unique property of a person with two jobs; it qualifies the association
Company employs person.
67

Names: Names are often better modeled as qualifiers rather than attributes. Test:
Does the name select unique objects from a set? Can an object in the set have
more than one name?
If so, the name qualifies a qualified association. If a name appears to be unique
in the world, we may have missed the class that is being qualified.
For Ex: department-Name may be unique within a company, but eventually the
program may need to deal with more than one company. It is better to use a
qualified association immediately.
A name is an attribute when its use does not depend on context, especially when
it need not be unique within some set.
Name of persons, unlike names of companies, may be duplicated and are
therefore attributes.
68

Identifiers: OO languages incorporate the notion of an object identifier for
unambiguously referencing an object. Do not include an attribute whose only
purpose is to identify an object, as object identifiers are implicit in class models.
Only list attributes that exist in the application domain. For Ex: accountCodes
and customers see them.
In contrast, we should not list an internal transactionID as an attribute, although
it may be convenient to generate one during implementation.
Attributes on associations: If a value requires the presence of a link, then the
property is an attribute of the association and not of a related class.
Attributes are usually obvious on many-to-many associations; they cannot be
attached to either class because of their multiplicity.
69

For Ex, in an association between Person and Club the attributes
membershipDate belongs to the association, because a person can belong to
many clubs and a club can have many members.
Attributes are more subtle on one-to-many association because they could be
attached to the “many” class without losing information.
Resist the urge to attach them to classes, as they would be invalid if multiplicity
changed. Attributes are also subtle on one-to-one associations.
Internal values: If an attribute describes the internal state of an object that is
invisible outside the object, then eliminate it from the analysis.
Fine detail: Omit minor attributes that are unlikely to affect most operations.
70

Discordant attributes: An attribute that seems completely different from and
unrelated to all class should be simple and coherent.
Mixing together distinct classes is one of the major causes of troublesome
models. Unfocused classes frequently result from premature consideration of
implementation decisions during analysis.
Boolean attributes: Reconsider all Boolean attributes. Once we can broaden a
boolean attribute and restate it as an enumeration.
ATM Ex: We apply these criteria to obtain attributes for each class. Some
tentative attributes are actually qualifiers on associations. We consider several
aspects of the model:
71

BankCode and CardCode are present on the card. Their format is an
implementation detail, but we must add a new association Bank issues
CashCard. CardCode is a qualifier on this association; bankCode is the qualifier
of Bank with respect to Consortium.
The computers do not have state relevant to this problem. Whether the machine
is up or down is a transient attribute that is part of implementation.
Avoid the temptation to omit Consortium, even though it is currently unique. It
provides the context for the bankCode qualifier and may be useful for future
expansion.
72

12.2.8 Refining with Inheritance
The next step is to organize classes by using inheritance
to share common structure.
 Inheritance can be added in two directions: by
generalizing common aspects of existing classes into a
superclass (bottom up)or by specializing existing classes
into multiple subclasses(top down).
Bottom-up generalization: We can discover
inheritance from the bottom up by searching for classes
with similar attributes, associations, and operations. For
each generalization, define a superclass to share common
features.
We may have to slightly redefine some attributes or
classes to fit in.
75

ATM Ex: RemoteTransaction and CashierTransaction
are similar, except in their initiation, and can be
generalized by Transaction. CentralComputer and
BankComputer have little in common for purposes of the
ATM example.
Top-down specialization: Top-down specializations are
often apparent from the application domain. Look for
noun phrases composed of various adjectives on the class
name: fluorescent lamp, incandescent lamp; fixed menu,
pop-up menu, sliding menu.
Avoid excessive refinement. If proposed specializations
are incompatible with an existing class, the existing class
may be improperly formulated.
Generalization vs. enumeration : Enumerated
subcases in the application domain are the most frequent
source of specializations. 76

For Ex: an ATM account could be refined into CheckingAccount and
SavingsAccount. It is useful in some bankking applications; type can
be made a simple attribute of Account.
Multiple Inheritance: We can use multiple inheritance to increase
sharing, but only if necessary, because it increases both conceptual
and implementation complexity.
Similar associations: When the same association name appears
more than once with substantially the same meaning, try to
generalize the associated class.
ATM Ex: Transaction is entered on both CashierStation and ATM;
EntryStation generalizes CashierStation and ATM.
Adjusting the inheritance level: We must assign attributes and
associations to specific classes in the class hierarchy. Assign each
one to the most general class for which it is appropriate
77

12.2.9 Testing Access Paths
Trace access paths through the class model 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?
Think of the questions we might like to ask. Are there useful
questions that cannot be answered? They indicate missing
information.
If something that seems simple in the real world appears complex
in the model, we may have missed something. It can be acceptable
to have classes that are “disconnected” from other classes.
This usually occurs when the relationship between a disconnected
class and the remainder of the model is diffuse. Check
disconnected classes to make sure you have not overlooked any
associations.
79

ATM Ex: A cash card itself does not uniquely identify
an account, so the user must choose an account
somehow. If the user supplies an account type, each card
can access at most one savings and one checking
account.
This is probably reasonable, and many cash cards
actually work this way, but it limits the system. The
alternative is to require customers to remember account
numbers.
80

12.2.10 Iterating a Class Model
A class model is rarely correct after a single pass. The entire
software development process is one continual iteration; different
parts of a model are often at different stages of completion.
If we find a deficiency, go back to an earlier stage if necessary to
correct it. Some refinements can come only after completing the
state and interaction models.
There are some signs of missing classes.
Asymmetries in associations and generalizations: Add new
classes by analogy or by comparison or by similarity.
Disparate attributes and operations on a class: Split a class so
that each part is coherent i.e. clear and logical.
Difficulty in generalizing cleanly: One class may be playing two
roles. Split it up and one part may then fit in cleanly.
81

Duplicate associations with the same name and purpose:
Generalize to create the missing super class that unites them.
A role that substantially shapes the semantics of a class: May
be it should be a separate class. This often means converting an
associations into a class.
For Ex: a person can be employed by several companies with
different conditions of employment at each; Employee is then a
class denoting a person working for a particular company, in
addition to class Person and Company.
Also look out for missing associations.
Missing access paths for operations: Add new associations so
that we can answer queries.
Another concern is superfluous model elements.
82

Lack of attributes, operations, and associations on a class:
Why is the class needed? Avoid inventing subclasses merely to
indicate an enumeration. If proposed subclasses are otherwise
identical, mark the distinction using an attribute.
Redundant information: Remove associations that do not add
new information or mark them as derived.
And finally we may adjust the placement of attributes and
associations.
Associations end names that are too narrow for their classes:
Move the association up or down in the class hierarchy.
Need to access an object by one of its attribute values:
Consider a qualified association. In practice, model building is not
as rigidly ordered as it is shown. We can combine several steps,
once we are experienced.
83

ATM Ex: CashCard really has a split personality- it is both an authorization unit
within the a bank allowing access to the customer’s accounts and also a piece of
plastic data that the ATM reads to obtain coded IDs.
In this case, the codes are actually part of the real world, not just computer
artifacts; the codes, not the cash card, are communicated to the central computer.
We should split cash card into two classes:
CashAuthorization, an access to one or more customer accounts.
CashCard, a piece of plastic that contains a bank code and a cash card number
meaningful to the bank. Each card authorization identifies one or more accounts-
for example, one checking account and one savings account.
Transaction is not general enough to permit transfers between accounts because it
concerns only a single account.
84

In general, a Transaction consists of one or more updates on individual account.
All updates in a single transaction must be processed together as an atomic unit;
if any one fails, then they all are canceled.
The distinction between Bank and BankComputer and between Consortium and
CentralComputer doesn’t seem to affect the analysis. The fact that
communications are processed by computers is actually an implementation
artifact.
Merge BankComputer and CentralComputer into Consortium. Customer doesn’t
seem to enter into the analysis so far. However, when we consider operations to
open new accounts, it may be an important concept.
Figure below shows a revised class diagram that is simpler and cleaner.
85

12.2.11 Shifting the Level of Abstraction
We have taken the problem statement quite literally. We
have regarded nouns and verbs in the problem
description as direct analogs of classes and associations.
This is a good way to begin analysis, but it does not
always suffice. Sometimes we must raise the level of
abstraction to solve a problem.
For Ex: we encountered one application in which the
developers had separate classes for
IndividualContributors, Supervisor, and Managers. This
model certainly is correct, but it suffers from some
problems.
87

There is much commonality between the three classes- the only
difference is the reporting hierarchy. For Ex: they all have phone
numbers and addresses.
We could handle the commonality with a superclass, but that only
makes the model larger. An additional problem arose when we
talked to the developers and they said they wanted to add another
class for the persons to whom managers reported.
Fig below shows the original model and an improved model that
is more abstract. Instead of “hard coding” the management
hierarchy in the model, we can “soft code” it with an association
between boss and worker.
A person who has an employeeType of “individualContributor” is
a worker who reports to another person with an employeeType of
“Supervisor” .
Similarly, a person who is a supervisor reports to a person who is
a manager.
88

In the improved model a worker has an optional boss, because the
reporting hierarchy eventually stops. The improved model is
smaller and more flexible.
An additional reporting level does not change the model’s structure;
it merely alters the data that is stored.
89

One way that we can take advantage of abstraction is thinking in
terms of patterns. Different kinds of patterns apply to the different
development stages, but here we are interested in patterns for
analysis.
A pattern distills the knowledge of experts and provides a proven
solution to a general problem. For Ex: the right side of figure is a
pattern for modeling a management hierarchy.
The use of tried and tested patterns gives us the confidence of a
sound approach and boosts our productivity in building models.
ATM Ex: We have already included some abstractions in the ATM
model. We distinguished between a CashCard and a
CardAuthorization.
We included the notation of transactions rather than trying to list
each possible kind of interaction.
90

12.2.12 Grouping Classes into Packages
The last step of class modeling is to group classes into packages. A
Package is a group of elements ( classes, associations,
generalizations, and lesser packages) with a common theme.
Packages organize a model for convenience in drawing, printing,
and viewing. Furthermore, when we place classes and associations
in a package, we are making a semantic statement.
Generally speaking, classes in the same package are more closely
related than classes in different packages. Normally, we should
restrict each association to a single package, but we can repeat
some classes in different packages.
To assign classes to packages, look for cut points- a cut point is a
class that is the sole connection between two otherwise
disconnected parts of a model. Such a class forms a bridge
between two packages.
91

For Ex: in a file management system, a File is the cut
point between the directory structure and the file contents.
Try to choose packages to reduce the number of
crossovers in the class diagrams.
With a little care, we can draw most class diagrams as
planar graphs, without crossing lines.
Reuse a package from a previous design if possible, but
avoid forcing a fit. Reuse is easiest when part of the
problem domain matches a previous problem.
If the new problem is similar to a previous problem but
different, we may have to extend the original model to
encompass both problems.
Use your judgment about whether this is better than
building a new model.
92

ATM Ex: The current model is small and would not require
breakdown into packages, but it could serve as a core for a more
detailed model. The packages might be:
Tellers- cashier, entry station, cashier station, ATM
Accounts- account, cash card, card authorization, customer,
transaction, update, cashier transaction, remote transaction
Banks- consortium, bank
Each package could add details. The account package could contain
varieties of transactions, information about customers, interest
payments, and fees.
The bank package could contain information about branches,
addresses, and cost allocations.
93

12.3 Domain State Model
Some domain objects pass through qualitatively distinct states
during their lifetime.
It is useful to construct a state diagram of such a domain class. The
state diagram describes the various states the object can assume, the
properties and constraints of the object in various states and the
events that take an object from one state to another.
Most domain classes do not require state diagrams and can be
adequately described by a list of operations. For the minority of
classes that do exhibit distinct states, a state model can help
understanding their behavior.
First identify the domain classes with significant states and note the
states of each class. Then determine the events that take an object
from one state to another.
94

Given the states and the events, we can build state
diagrams for the affected objects. Finally evaluate the
state diagrams to make sure they are complete and
correct.
The following steps are performed in constructing a
domain state model
Identify domain classes with states
Find states
Find events
Build state diagrams
Evaluate state diagrams
95

Identifying classes with States
Examine the list of domain classes for those that have a distinct
life cycle. Look for classes that can be characterized by a
progressive history or that exhibit cyclic behavior.
Identify the significant states in the life cycle of an object. For Ex: 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.
On the other hand, an airplane owned by an airline cycles through
the states of Maintenance, Loading, Flying, and Unloading.
Not every state occurs in every cycle, and there are probably other
states, but the life of this object is cyclic.
96

There are also classes whose life cycle is chaotic, but
most classes with states are either progressive or cyclic.
ATM Ex: 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 state 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.
97

Give each state a meaningful name. Avoid names that
indicate how the state came about; try to directly describe
the state.
Don’t focus on fine distinctions among states,
particularly quantitative differences, such as small,
medium, or large. States should be based on quantitative
differences in behavior, attributes, or associations.
It is unnecessary to determine all the states before
examining events. By looking at events and considering
transitions among states, missing states will become
clear.
ATM Ex: Here are some states for an Account: Normal,
Closed, Overdrawn, Suspended
98

Finding Events
Once you have a preliminary set of states, find the events
that cause transitions among states. Think of the stimuli
that cause a state to change.
In many cases, you can regard an event as completing a
do-activity. For Ex, 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 ex, Conditionally accept with
revisions.
WE can find other events by thinking about taking the
object into a specific state. 99

For Ex, if you lift the receiver on a telephone, it enters the Dialing state. Many
telephones have pushbuttons that invoke specific functions.
If you press the redial button, the phone transmits the number and enters the
Calling state. If you press the program button, it enters the Programming state.
There are additional events that occur within a state and do not cause a
transition. For the domain state model you should focus on events that cause
transitions among states.
When you consider an event, capture any information that it conveys as a list of
parameters.
ATM Ex: Important events include: close account, withdraw excess funds,
repeated incorrect PIN, suspected fraud, and administrative action.
100

Building State Diagrams
Note the states to which each event applies. Add transitions to show the change
in state caused by the occurrences 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.
101

Is it ignored? Then everything is fine. Does it represent an error? Then add a
transition to an error state. Does it have some effect that you forgot? Then add
another transition. Sometimes you will discover new states.
It is usually not important to consider effects when building a state diagram for a
domain class. If the objects in the class perform activities on transitions,
however, add them to the state diagram.
ATM Ex: Fig below shows the domain state model for the Account class.
102

Evaluating State Diagrams
Examine each state model. Are all states connected? Pay particular attention to
paths through it. If it represents a progressive class, is there a path from the
initial state to the final state? Are the expected variations present?
If it represents a cyclic class, is the main loop present? Are there any dead states
that terminate the cycle?
Use the knowledge of the domain to look for missing paths. Sometimes missing
paths indicate missing states. When a state model is complete, it should
accurately represent the life cycle of the class.
ATM Ex: Our state model for Account is simplistic but we are satisfied with it,
We would require substantial banking knowledge to construct a deeper model.
104

Iterating the Analysis
The iteration to the analysis should be done as follows:
Refining the Analysis Model
◦ The overall analysis model may show inconsistencies and
imbalances within and across models. Iterate the different
portions to produce a cleaner, more coherent model.
◦ Try to refine classes to increase sharing and improve structure.
Sometimes more restructuring is needed as your understanding
increases.
◦ Watch out for generalizations factored on the wrong concepts.
Remove classes and associations that seemed useful at first but
now appear extraneous.
◦ A good model feels right and does not appear to have extraneous
detail.
DOMAIN INTERACTION MODEL
105

Restating the Requirements
When the analysis is complete, the model serves as the basis for the requirements
and defines the scope of future discourse. Most of the real requirements will be
part of the model.
You should verify the final model with the requestor. During
analysis some requirements may appear to be incorrect or
impractical; confirm corrections to the requirements.
The final verified analysis model serves as the basis for system architecture,
design, and implementation.
You should revise the original problem statement to incorporate
corrections and understanding during analysis.
106

Analysis and Design
The goal of analysis is to specify the problem fully without introducing a bias to
any particular implementation, but it is possible to avoid all taints of
implementation.
There is no absolute line between the various development stages,
nor is there any such thing as a perfect analysis.
Don’t treat the rules very rigidly. The purpose of rules is to preserve flexibility
and permit changes later, but remember that the goal of modeling is to
accomplish the total job, and flexibility.
107

 Most domain models are static and operations are
unimportant, because a domain as a whole usually
doesn’t do anything.
 The focus of domain modeling is on building a model
of intrinsic concepts. After completing the domain
model then shift our attention to the details of an
application and consider interaction.
 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

Determine the System Boundary
 Must know the precise scope of an application- the
boundary of the system-in order to specify functionality.
Decide what the system includes and, more importantly,
what it omits.
 If the system boundary is drawn correctly, we can treat the
system as a block box in its interactions with the outside
world- system can be regarded as a single object, whose
internal details are hidden and changeable.
 You should not consider humans as part of the system,
unless you are modeling a human organization, such as a
business or a government department.

 Banking network including both human cashiers and
automatic teller machines” . It is important that cashier
transactions and ATM transactions be seamless- from the
customer’s perspective either method of conducting
business should yield the same effect on a bank account.
 However, in commercial practice an ATM application
would be separate from a cashier application- an ATM
application spans banks while a cashier application is
internal to a bank.
 Both applications would share the same underlying
domain model, but each would have its own distinct
application.

 Finding Actors
 Once the system boundary is known, identity the external
objects that interact directly with the system. These are its
actors. Actors include humans, external devices and other
software systems.
 Actors are not under the control of the application. In
finding actors, we are not searching for individuals but for
archetypical behavior.
 Each actor represents an idealized user that exercises
some subset of the system functionality. An actor is a
coherent face presented to the system, and an external
object may have more than one actor.

 ATM Ex: A particular person may be both bank teller and
a customer of the same bank. This is an interesting but
usually unimportant coincidence- a person approaches the
bank in one or the other role at a time.
 For the ATM application, the actors are Customer, Bank,
and Consortium.
 Finding Use Cases
 For each actor, list 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, and all system behavior
must fall under some use case.

 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 them at similar level of detail.
 For Ex: if one use case in a bank is “apply for loan” then
another use case should not be “withdraw cash from
savings account using ATM”. A better match would be
“make withdrawal”.
 Draw preliminary use case diagram. Show the actors and
the use cases, and connect actors to use cases. Write a one
or two sentences for each use case.

 Initiate session: The ATM establishes the identity of the
user and makes available a list of accounts and actions.
 Query account: The system provides general data for an
account, such as the current balance, date of last
transaction, and date of mailing for last statement.
 Process transaction: The ATM system performs an
action that refers an account’s balance, such as deposit,
withdraw, and transfer. The ATM ensures that all
completed transactions are ultimately written to the bank’s
database.
 Transmit data: The ATM uses the consortium’s facilities
to communicate with the appropriate bank computers.

 Finding Initial and Final Events
 Use cases partition system functionality into discrete
pieces and show the actors that are involved with ach
piece, but they do not show the behavior clearly.
 To understand the behavior, we must understand the
execution sequences that cover each use case. Start by
finding the events that initiate each use case.
 Determine which actor initiates a use case and define the
events that it sends to the system. Initial event is a request
for the service that the use case provides or it can be an
occurrence that triggers a chain of activity.
 Also determine the final event or events and how much to
include in each use case.

 For ex, the use case of applying for a loan could continue
until the application is submitted, until the loan is granted
or rejected etc., The modeler must define the scope of
each use case by defining when it terminates.
 ATM Ex: The initial and final events for each use case
are:
 Initiate session: The initial event is the customer’s
insertion of a cash card. There are two final events: the
system keeps the cash card or the system returns the cash
card.
 Query account: The initial event is a customer’s request
for account data. The final event is the system’s delivery
of account data to the customer.

 Process transaction: The initial event is the customer’s
initiation of a transaction. There are two final events:
committing or aborting the transaction.
 Transmit data: The initial event could be triggered by a
customer’s request for account data.
 Another possible initial event could be recovery from a
network, power, or another kind of failure. The final event
is successful transmission of data.
 Prepare Normal Scenarios
 For each use case, prepare one or more typical dialogs to
get a feel for expected system behavior. These scenario
illustrates major interactions, external display formats, and
information and information exchanges.

 A scenario is a sequence of events among a set of
interacting objects. For most problems, logical correctness
depends on the sequences of interactions and not their
exact times.
 Sometimes the problem statement describes the full
interaction sequence, but most of the time will have to
invent the interaction sequence.
 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.
 The information values exchanged are event parameters.
For ex, the event password entered has password value as
a parameter.

 For each event, identify the actor that caused the event
and the parameters of the event.
 Fig below shows a normal scenario for each use case.

 Adding Variation and Exception Scenarios
 After prepared with the typical scenarios, consider special
cases such as “special” cases, such as omitted input,
maximum and minimum values, and repeated values.
 Then consider error cases, including valid and failures to
respond. For many interactive applications, error handling
is the most difficult part of development.
 If possible, allow the user to abort an operation or roll
back to a well-defined starting point at each step.
 Finally consider various other kinds of interactions that
can be overlaid on basic interactions, such as help requests
and status queries

 ATM Ex: Some variations and exceptions follow.
 The ATM can’t read the card.
 The card has expired.
 The ATM times out waiting for a response.
 The amount is invalid.
 The machine is out of cash or paper.
 The communication lines are down.

 Finding external events
 Examine the scenarios to find all external events including all
inputs, decisions, interrupts and interactions to/from external
users.
 Use scenarios to find normal events-also take care of unusual
and error condition
 password entry, dispense cash are external event though every
time the user and password are different and cash amount is
different.
 Event instances whose values affect the flow of control should
be distinguished as different kinds of events.
 Bad account, bad password are different events.
 “Pushing an enter key” creates an event. The distinction of
events depends on the application.

 Prepare a sequence diagram for each scenario.
 A sequence diagram shows the participants in an
interaction and the sequence of messages among them.
 Sequence diagram clearly shows the sender and receiver
of each event.
 From the sequence diagram you can then summarize the
events that each class sends and receives.
 Fig below shows a sequence diagram for the process
transaction scenario.

 Preparing activity diagrams for complex use cases
 Sequence diagram do not show alternatives and decisions.
◦ For Ex-One sequence diagram for main flow of interaction and
additional sequence diagram for each error and decision point.
 Activity diagram-consolidate all this behaviour by
documenting forks and merges in the control flow. These
are only for analysis never use this for implementation.
 ATM example for activity diagram(Card verification)
 When the user inserts a card, there are many possible
responses. Some responses indicate a possible problem
with the card or account; hence the ATM retains the card.

 Organizing actors and use cases
 Organize Use Cases with relationships(include, extend
and generalization)
◦ Helpful in large and complex systems
 Don’t proceed unless you are sure of base use case(defer
the organization)
 You can also organize actors with generalization. For
Ex: an Administrator might be an operator with
additional privileges.
 Figure below organizes the use cases with the include
relationship.

 Checking against the domain class model
 check if the application model done till now is
consistent with domain(but must be).
◦ actors, use cases & scenarios because they all are
based on classes & concepts from domain model
 Testing access path of a domain model is the first
attempt at use cases.
 Check for no inconsistencies. Confirm that domain
model has all necessary data and covers all event
parameters.

 Application class model
 Define the application itself rather than real world objects
that the application acts on.
 Construction involves:
◦ Specifying user interfaces
◦ Defining boundary classes
◦ determining controllers
◦ checking against the interaction model

 Specify user interfaces
 Most interactions involve:
application logic and user interface
user interface-is an object or group of objects that
provides user of a system with a coherent way to
access its domain objects, commands and application
options.
 During Analysis, Emphasis is on information flow &
control rather than presentation format. I/P can be
from any device---coarse level.
 Determine the commands that the user can perform- a
command is a large-scale request for a service.
 Ex. Make a flight reservation –is a cmd.

 Do a mock interface and check for missing things.
 Decoupling application logic from user interface help us
evaluate “look and feel” of the UI while the application
is under development.

 Define boundary classes
 A system must be able to operate with and accept
information from external sources, but it should not have
its internal structure dictated by them.
 A boundary class is a class that provides a staging area
for communication b/w a system and external sources.
Understand both internal and external format and helps
in communication.
 ATM: define the boundary classes CashCardBoundary,
AccountBoundary to encapsulate the communication
between the ATM and the consortium.
 This interface will increase flexibility and make it easier
to support additional consortiums.

 Determine controllers
 Is a piece of Reified behaviour captured as active objects that
manages control within an application.
◦ It receives signals from outside or within a system, reacts,
invokes operation & sends signals to the outside world.
◦ Helps in sequencing the behaviour of the system.
 Capturing the existence of controllers in a system is important,
◦ The control information that each one maintains and the
association of controller with other objects.
 ATM: Has two major loops: outer verifies customer and
accounts. Inner services transactions. These can be handled with
a controller.

 Checking against the interaction model
 While building application class model check use cases and
think how they would work.
◦ Example- If a user sends a command to the application, the
parameters of the command must come from user-interface
object.
◦ Requesting of the command must come from some controller
object. Now simulate a use case with the classes.
 ATM Ex: Fig below shows a preliminary application model
and the domain classes with which it interacts. There are two
interfaces-
 One for Users and the other for communicating with the
consortium.

 The TransactionController handles both queries on accounts
and the processing of transactions. The SessionController
manages ATMsessions, each of which services a customer.
 Each ATMsession may or may not have a valid CashCard and
Account. The SessionController has a status of ready, impaired,
or down.
 There is a log of ControllerProblems and the specific problem
type.

 Application State Model
 The application state model focuses on application classes and
augments the domain state model. Application classes are more
likely to have important temporal behavior than domain classes.
 Application state model can be constructed by following the
below 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

 Determine application classes with states
 The application class model adds computer-oriented classes that
are prominent to users and important to the operation of an
application.
 Consider each application class and determine which ones have
multiple states. User interface classes and controller classes are
good candidates for state models.
 In contrast, boundary classes tend to be static and used for
staging data import and export- they are less likely to involve a
state model.
 ATM Ex: The user interface classes do not seem to have any
substance. This is probably because our understanding of the
user interface is incomplete at this point in development.

 Finding Events
 For the application interaction model, number of scenarios are
prepared. Now study those scenarios and extract events. With
the domain model, first we find states and then events.
 The domain model focuses on data- significant groupings of
data form states that are subject to events. With the application
model, first we find events and then we determine states.
 ATM Ex: We revisit the scenarios from the application
interaction model. Some events are: insert card, enter password,
end station, and take card.

 Building State Diagrams
 The next step is to build state diagram for each application class
with temporal behavior. Choose one of this classes and consider
a sequence diagram.
 Arrange the events involving the class into a path whose arcs are
labeled by the events. The interval between any two events is a
state.
 Give each state a name. Merge other sequence diagrams into the
state diagram. The initial state diagram will be a sequence of
events.
 Every scenario or sequence diagram corresponds to a path
through the state diagram. Find loops within a diagram. If a
sequence of events can be repeated indefinitely, then they form a
loop.

 In loop, the first state and the last state are identical. Atleast one
state in a loop must have multiple transactions leaving it or the
loop will never terminate.
 Once the loops are found, merge other sequence diagrams into
the state diagram. Find the point in each sequence diagram
where it diverges from previous ones.
 Attach the new event sequence to the existing state as an
alternative path. The hardest thing in deciding at which state an
alternate path rejoins the existing diagram.
 The judicious use of parameters and conditional transitions can
simplify state diagrams considerably but at the cost of mixing
together state information and data.
 For Ex: a subdiagram to allow for one user failure might have
states No error and One error.

 After normal events have been considered, add variation and
expected case. Consider events that occur at awkward times- for
Ex: a request to cancel a transaction after it has been submitted
for processing.
 Then we are done with the state diagram of a class when the
diagram covers all scenarios and it handles all events that can
affect a state.
 If there are complex interactions with independent inputs, we
can use a nested state diagram.
 ATM Ex: Fig 1 shows the state diagram for the
SessionController. The middle of the diagram has the main
behavior of processing the card and password.
 Fig 2 and Fig 3 show the state diagram for the
TransactionController that is spawned by the SessionController.

 Checking against other State Diagrams
 Check the state diagrams of each class for completeness and
consistency. Every event should have a sender and a receiver,
occasionally the same object.
 States without predecessors or successors are suspicious; make
sure they represent starting or termination points of the
interaction sequence.
 Objects are inherently concurrent; beware of synchronization
errors where an input occurs at an awkward time. Make sure that
corresponding events on different state diagrams are consistent.
 ATM Ex: The SessionController initiates the
TransactionController, and the termination of the
TransactionController causes the SessionController to resume.

 Checking against the Class Model
 Make sure that the state diagrams are consistent with the domain
and application class models.
 ATM Ex: Multiple ATMs can potentially concurrently access an
account. Account access needs to be controlled to ensure that
only one update at a time is applied.
 Checking against the Interaction Model
 When the state model is ready, go back and check it against the
scenarios of the interaction model. Simulate each behavior
sequence and verify that the state diagram gives the correct
points.
 ATM Ex: the state diagrams are sound and consistent
with the scenarios.

 Adding Operations
 OOA places less emphasis on defining operations
 We de-emphasis on operations because the list of
potentially useful operations is open-ended and it is
difficult to know when to stop adding them.
 Operations arise from the following sources
 Operation from the Class Model
 The reading and writing of attribute values and
association links are implied by the class model, and
need not show them explicitly.
 During analysis all attributes and associations are
assumed to be accessible.

 Operations from Use Cases
 Most of the complex functionality of a system comes
from its use cases. During the construction of the
interaction model, use case lead to activities.
 Many of this correspond to operations on class model.
 ATM Ex: Consortium has the activity verifyBankCode,
and Bank has the activity verifyPassword.
 Shopping-List Operations
 Shopping-list operations provide an opportunity to
broaden a class definition beyond the narrow needs of
the immediate problem.

 ATM Ex: Shopping-list operations include:
 Account.close()
 bank.createSavingsAccount(customer):account
 bank.createCheckingAuth(customer):cashCardAuthoriz
ation
 cashCardAuthorization.addAccount(account)
 cashCardAuthorization.removeAccount(account)
 cashCardAuthorization.close()

 Simplifying Operations
 Examine the class model for simpler operations and
variations in form on a single operation.
 Try to broaden the definition of an operation to
encompass such variations and special cases.
 Use inheritance whenever possible to reduce the
number of distinct operations.
 Introduce new superclasses as needed to simplify the
operations, provided that the new superclasses are not
forced and unnatural.
 Locate each operation at the correct level within the
class hierarchy.

 A result of this refinement is often fewer, more
powerful operations that are nevertheless simpler to
specify than the original operations, because they are
more uniform and general.
 ATM Ex: The ATM example does not require
simplifiaction.

Unit-4- Process oveunit5and6forview.pptx

Unit-4- Process oveunit5and6forview.pptx

Recommended

Recommended

More Related Content

Similar to Unit-4- Process oveunit5and6forview.pptx

Similar to Unit-4- Process oveunit5and6forview.pptx (20)

More from ChiragSuresh

More from ChiragSuresh (9)

Recently uploaded

Recently uploaded (20)

Unit-4- Process oveunit5and6forview.pptx