1/17/2013

1
ANALYSIS & DESIGN
DEVELOPMENT OF CYCLE
Two types of approach will be there.
Waterfall development
Iterative development
WATERFALL APPOARCH
The waterfall approach dictates that
developers perform the software development
stages in a rigid linear sequence with no
backtracking.
First capture requirement construct analysis
model perform a system design prepare
a class diagram implementation testing
deployment.
CONTD
This approach is suitable for well understand
application, but such applications seldom
occur
Too many organization attempt to follow a
waterfall when requirements are fluid. This
lead the familiar situation where developers
complains about changing requirement,
business complains about inflexible software
development.
1/17/2013
2
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 kind of objects.
Each iteration includes a full complement of
stages : analysis, design, implementation and
testing.
CONTD
Unlike the strict process of waterfall approach,
iterative development can interleave different
stages and need not construct the entire
system in lock step. If there is problem you can
move backward to an earlier stages for rework.
It is best choice for most application because it
gracefully responds to change and minimize
risk of faliure.
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 problem before
attempting solution.
System Design: device a high level strategy for
solving the application problem. Establish
policies to guide subsequent class design.
CONTD
Class design: augment and adjust the real
world models from analysis so that they are
amenable to computer implementation.
Determine algorithm to for realizing the
operations.
Implementation: translate the design into
programming code and database structures.
Testing: help users master the new
application.
1/17/2013
3
CONTD
Deployment: place the application in the field
and gracefully cut over from legacy
applications.
Maintenance: preserve the long term viability
of the application.
SYSTEM CONCEPTION
It deal with the genesis of an application.
initially somebody thinks of an application,
prepare a business case, and sells the idea to
the organization.
The innovator must understand both business
needs and technological capabilities.
ANALYSIS
It focuses on models. Analysts capture
requirement by constructing models.
Developer must fully understand the problem
before addressing the additional complexities
of design.
During analysis developers consider the
available sources of information and resolves
ambiguities.
CONTD
There are two sub stages of analysis: domain
analysis and application analysis.
The domain analysis focuses on real world
things whose semantics the application
capture. For example airline flight is a real
object that a flight reservation system must
represent.
Domain objects exist independently of any
application and are meaningful to business
experts..
1/17/2013
4
CONTD
The job of constructing a domain model is
mainly to decide which information to capture
and how represent it.
Domain analysis is then followed by application
analysis that address the computer aspects of
the application that visible to users. For
example, a flight reservation screen is a part of
a fight reservation system.
CONTD
The application model does not prescribe the
implementation of the application. It
describes how the application appears from
the outside the black-box view of it.
SYSTEM DESIGN
During system design , the developer make
strategic decision with broad consequence
you must formulate the architecture and
choose global strategies and policies to guide
the subsequent more detailed portion
The architecture is high level plan or strategy
for solving the application problem. the choice
of architecture is based on the requirement as
well as past experience.
CLASS DESIGN
During class design, the developer expand and
optimizes analysis models. There is a shift in
emphasis from application concept towards
computer concepts.
Developer choose algorithms to implement
major system function but they should
continue to defer the idiosyncrasies of
particular programming languages.
1/17/2013
5
IMPLEMENTATION
Implementation is a stage for writing the actual
code.
Developer map design elements to
programming language and database code.
Often tools can generate some of code from
design model.
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 use of models.
CONTD
Tester once again revisit the original business
requirement and verify that a system delivers
the proper functionality. Testing can also
uncover accidental errors that have been
introduced.
Developer check the program at several level.
Unit tests
System tests
TRAINNING
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 the check the software
against the user documentation to ensure that
software meets its original goals.
1/17/2013
6
DEPLOYMENT
The eventual system must work in the field on
various platforms and in various configurations
unexpected interaction can occur when a
system is deployed in a customer environment
Developer must tune the system under various
load and write scripts to install procedures.
Customization
Different spoken language .
MAINTENENCE
Once development is complete system has
been deployed it must maintained for
continued success.
Bugs occur in original system appear gradually
during use and must be fixed.
Successfully application will also leads to
enhancement request and long lived
application will occasionally have to be
restricted.
DOMAIN ANALYSIS
Domain analysis is concerned with devising a
precise, concise, understanding and correct
model of the real world.
Before building anything complex, the builder
must understand the requirements.
During analysis we build the models and begin
to understand the requirements deeply.
To build a domain model, we must interview
business experts, examine requirements
statements, and scrutinize related object.
CONTD
It is important to abstract important features
first and defer small details until later.
The successful analysis model states what
must be done, without restricting how it is
done, and avoids implementation details.
The model serves several purposes:
it clarifies the requirements,
it provides a basis for agreement between the
stakeholders and the developers,
And it becomes the starting point for design and
implementation.
1/17/2013
7
DOMAIN CLASS MODEL
The main purpose of a domain model is to
capture information content of a domain.
Find classes
Prepare a data dictionary.
Find associations.
Add attributes of objects and links.
Organize and simplify classes using
inheritance.
Verify the access path exists likely queries.
CONTD
Iterate and refine the model
Reconsider the level of abstraction.
Group classes into packages.
FINDING CLASSES
The first step in constructing a class model is
to find relevant classes for objects from the
application domain.
Objects include physical entities, such as houses,
persons, and machines as well as concepts, such
as trajectories, seating arrangements, and
payment schedules.
Avoid computer implementation constructs such
as link lists and subroutines.
Classes often corresponds to nouns.
CONTD
For example: a reservation system to sell
tickets to performances at various theatres
Tentative classes would be reservation, system,
tickets, performance and theatre.
Extract nouns
Requirements
Source
Tentative
classes
Classes
Eliminate
spurious classes
1/17/2013
8
KEEPING THE RIGHT CLASSES
Redundant classes
If two classes express the same concept, you should keep
the most descriptive name.
For example, Passenger is good name for the person taking
an airline flight and Customer is appropriate word for the
problem concern with a charter plane.
ATM example:
customer and user are redundant we will 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 the judgment because in another context the class
could be important.
ATM example:
appropriate cost is outside the scope of the ATM example.
CONTD
Vague classes
A class should be specific. Some tentative classes may have ill-
defined boundaries or be too broad in scope.
ATM example:
recordkeeping provision is a vague class and is handled by
transaction.
Attributes
Names that primarily describe individual objects should be
restated an attribute
For example, name, birthdates etc..
ATM example:
accountdata is underspecified but in any case probably
describe an account. An ATM dispenses cash and receiptbut there
is peripheral problem so cash and receipt treated as attributes
1/17/2013
9
CONTD
Operations
If a name describe an operation that is applied to
objects and not manipulated in its own rights, then it is
not a class.
For example, telephoneCall is sequence of actions. So it
can not be class. But in call billing system, telephoneCall
is important which has features like, time of call, date,
duration etc.
CONTD
Roles
The name of the class should reflect its intrinsic nature
and not a role that it plays in an association.
For example, owner would be poor name for a car
manufacturer database.
The proper class is person, which assumes various
different roles, such as owner, driver etc.
What if a list of driver
is added later????
CONTD
Implementation constructs
Eliminate constructs from the analysis model that are
extraneous (unrelated) to the real world.
For example: CPU, subroutine, process algorithm, interrupts.
ATM example:
Transactionlog is simply the set of transaction communication links
can be shown as association.
Derived classes
As a good rule, omit the classes that are derived from other
classes.
If derived class is especially important then you can include it.
Mark all derived classes with a preceding slash (/) in the class
name.
PREPARING A DATA DICTIONARY
Data dictionary is the definition of all modeling
elements and explanations of rational for key
modeling decisions.
Isolated words have too many interpretation, so
prepare a data dictionary for all modeling
elements.
Describe the scope of the class within the current
application, including any assumptions, or
restrictions on its use.
The data dictionary also describes associations,
attributes, operations, and enumeration values.
1/17/2013
10
FINDING ASSOCIATIONS
A structural relationship between two or more
classes is an association.
A reference from one class to another class is
an association.
Association often correspond to verb or verb
phrases.
These includes physical locations (Next To,
Part Of, Contained In), directed actions
(Drives), communication (Talks To), ownership
(Has), or satisfaction of some condition
(Works For).
CONTD
ATM example : the major are taken directly
from the verb phrase in the problem
statement . For some association associations
the verb phrase is implicit in the statement .
Finally , some associations depends on real-
world knowledge or assumption.
1/17/2013
11
KEEPING RIGHT ASSOCIATIONS
Association between eliminated classes.
If you have eliminated one of the classes in the association, you
must eliminate the association or restate it in terms of other
classes.
ATM example: we can eliminate banking network includes cashier
stations and ATMs, ATMs dispenses cash ATM prints receipts, Bank
provide s/w.
Irrelevant or implementation associations.
Eliminate any associations that are outside the problem domain or
deal with implementation constructs.
ATM example: fro example 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.
CONTD
Actions.
An association should describe a structural property of the
application domain, not a transient event.
For example, ATM accepts cash card describes part of
interaction cycle between an ATM and a customer.
ATM example :
ATM accept 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
interact with user .
CONTD
Ternary association.
You can decompose most associations among
three or more classes into binary associations.
ATM example: bank computer processes against
account can be broken into bank computer
process transactions and transaction concern
account. Cashier enters transaction for account
can be broken similarly. ATMS communicate with
central computer and transaction entered on
ATM.
CONTD
Derived associations: omit associations that
can be defined in term of other associations,
because they are redundant for example,
grandparentof can be defined in terms of
parentof associations. Omit associations
defined by condition on attributes.
1/17/2013
12
CONTD
Misnamed associations: dont 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 example: bank computer maintains
accounts is a statement of action ;repharase
as bank hold account.
CONTD
Association end names:
add association end names where
appropriate. For example in the works for
association a company is an employer with
respect to a person and a person is an
employee with respect to a company if there
is only one association between a pair of
classes and the meaning of the association is
clear.
CONTD
ATM can communicate with central computer
is clear from the class name.
Qualified associations:
usually a name identifies the object within some
context ; most names are not globally unique. The
context combine with the name to uniquely
identify the object.
ATM example: the qualifier bankcode
distinguishes the different banks in a
consortium
CONTD
Multiplicity : specify multiplicity but dont put
too much effort into getting it right as
multiplicity often changes during analysis
Missing association: add any missing
associations that are discovered.
ATM example: we overlooked transaction entered
on cashier station customers have accounts and
transaction authorized by cash card . If cashier are
restricted to specific stations, then the association
cashier authorized on cashier station would be
needed.
1/17/2013
13
CONTD
Aggregation : aggregation is important for
certain kind of application, especially for
those involving mechanical parts and bills
materials. For other application aggregation is
relatively minor and it can be unclear whether
to use aggregation or ordinary association.
ATM example: we decide that a bank is a part
of a consortium and indicate the relationship
with aggregation.
FIND ATTRIBUTES
Next to find attributes. Attributes are data
properties of individual objects. Such a weight
, velocity , or color. Attributes values should
not be objects; use an association to show any
relationship between two objects.
Attributes usually correspond to nouns
followed by possessive phrases, such as the
color of car or the position of the cursor.
CONTD
Adjectives often represent specific
enumerated attribute values such as red , on
or expired. attributes are less likely to be fully
described in the problem statement.
Dont discovery of attributes excess . Only
consider attributes directly relevant to the
application. During analysis avoid attributes
that are solely for implementation.
Omit derived attributes.
Looks for attributes on association.
1/17/2013
14
KEEPING THE RIGHT ATTRIBUTE
Eliminate unnecessary and incorrect attributes
with the following criteria.
Object :independent existences of an element
is important rather than just its value then it is
an object.
Qualifier : attribute value depends on
particular context, then consider restating the
attributes as a qualifier.
CONTD
Names : names are better modeled as
qualifier rather than attributes. A name is an
attributes when its uses does not depends on
context especially when it need not be unique
within set.
Identifiers : OO languages in corporate the
notation of an object identifier for
unambiguously referencing an object do not
include an attribute whose only purpose is to
identify an object as object identifier are
implicit in class object.
CONTD
For example, account code is a genuine
attribute banks assign accountcode and
customers to see them. In contrast you should
not list an internal transactionID as an
attributes, although it may be convenient yo
generate one during implementation.
Attribute on associations: if a value requires
the presences of a link then the properties is
an attributes of the association and not of a
relation class.
CONTD
For example person and club the attribute
membershipdate is belong to association
because a person can belong to more than
one clubs and clubs have many member.
Internal values : if an attribute describes the
internal state of an object that is invisible
outside the object, the eliminate it from the
analysis.
Fine detail : omit minor attribute that unlikely
affect most operation.
1/17/2013
15
CONTD
Discordant attributes : an attributes that
seems completely different from and
unrelated to all other attributes may indicate a
class that should be split into two distinct
classes. Mixing two distinct classes is one of
the major causes of troublesome models.
Boolean attributes : reconsider all boolean
attribute.
CONTD
ATM example : we apply these criteria to
obtain attributes for each class
some tentative attribute are actually qualifier
on association .
Bankcode and card code is present in card.
Their format is an implementation detail but
add a new association bank issues a cashcard,.
Cardcode is an qualifier on this association;
bankcode is a qualifier of bank with respect to
consortium.
REFINNIENG WITH INHERITANCE.
Organize a classes by using inheritance to
share common structure inheritance can be
added in two direction generalization(bottom-
up) and specialization(top-down).
Bottom up generalization :
In ATM example remote transaction and cashier
transaction are similar except their initiation and
can be generalized by transaction
1/17/2013
16
CONTD
Top-down specialization: top-down
specializations are often apparent from the
application domain. If for noun phrases
composed of various adjective on the class
name
Generalization vs. enumeration : enumerated
subclasses in the application domain are the
most frequent source of specializations. In
atm example account could be refined into
currentaccount and saving account. But this
distinction does not affect in ATM example.
CONTD
When one association appear more than one
in diagram then try to generalize the
associated classes. Transaction is entered on
both cashier station and ATM entry station
generalized cashier station and ATM.
TESTING ACCESS PATH
Trace the access path through class model
diagram to see if they yield sensible result.
Where a unique value is expected, is there a
path that produce unique result?
For multiplicity many is there a way to pick
out unique values when needed?
Are there useful question that cannot be
answered? They indicate missing information.
1/17/2013
17
CONTD
ATM example: a cash card itself does not
uniquely identify an account , so there user
must choose an account somehow . If the user
supplies an account type , each card can
access at most one saving and one checking
account. The alternative is require customer
to remembers account numbers if cash card
accesses a single account the transfer
between account impossible.
ITERACTION OF CLASS MODELING
Class model is rarely correct in single pass. The
entire software process is one of continual
iteration.
If deficiency found , go back to an earlier stage
if necessary to correct it.
Some refinement come after state model and
interaction model is completed.
CONTD
Sign missing object include:
Asymmetries in association and generalization
: add new classes by analogy
Disparate attribute & operation on a class may
be it should be a separate class. This often
means converting an association into a class.
Duplicate association with same name &
purpose.
CONTD
A role that substantially shapes the semantics
of a class. Maybe it should be a separate class.
This often means converting an association
into a class. For example, a person can be
employed by several companies with different
condition of employment at each ; Employee
is then a class denoting a person working for
a particular company in addition to class
person and class.
1/17/2013
18
CONTD
Missing access paths for operations. Add new
association so that you can answer queries.
Lack of attributes, operations and association
on a class. Why class is needed?
Redundant information. Remove association
that do not add new information or mark
them derived.
Association end names that are too broad or
too narrow for their for their classes.
CONTD
Need to access an object by one of its
attributes values. Considered a qualified
association.
Model building is not as rigidly ordered as we
have shown. You can combine several steps,
once you experienced.
ATM EXAMPLE
Cash card really has a split personality. It is
both an authorization unit within bank
allowing access to the customers accounts
and also piece of plastic data that ATM card
reads to obtain coded IDs.
Transaction is not general enough to permit
transfers between accounts because it
concern only a single account.
CONTD
The distinction between Bank and
Bankcomputer and between Consortium and
Central computer doesnt seems to affect the
analysis.
Customers doesnt seems to enter into
analysis so far however when we consider
operations to open new accounts..
1/17/2013
19
SHIFTING LEVEL OF ABSTRACTION
In our analysis we have regarded nouns and
verbs in the problem of description as direct
analogs of classes and association.
This is a good way to design but not always
sufficient. You must raise level of abstraction
to solve problem.
Shifting level of abstraction . Abstraction
makes a model more complex but can
increase flexibility and reduce the number of
classes.
EXAMPLE
* boss
1
worker
*
1
individualContributer
supervisor
manager
Person
employeeType
reporting level
0..1
*
ATM EXAMPLE
Here we already distinguished between a
cashcard and cardauthorization
We included notation of transaction rather
then trying to list each possible kind of
interaction.
1/17/2013
20
GROUPING CLASSES INTO PACKAGE
The last step is of class modeling is to group
classes into package .
A package is a group of elements (class,
generalization, association etc.) with a
common theme.
Package organize a model for convenience in
drawing, printing, and viewing.
Normally you should restrict each association
to a single package.
Reusability of package.
ATM EXAMPLE
This model is small and not require to
breakout into different package, but it could
serve s a core for more detailed model. The
package might be:
Tellers-cashier, entry station, cashier station,
ATM.
Accounts- account, cash card , card
authorization, customer, transaction, update,
cashier, transaction, remote transaction.
Bank- consortium, bank.
DOMAIN STATE MODEL
Some domain pass through qualitatively
distinct state during their lifetime. There may
be different constraints on attributes values,
different behavior of operation, different
association, multiplicities in the various state.
Most of class domain does not require state
diagram and can be adequately describe by
list of operation.
First identify class with significant state and
not that states of each classes.
CONTD
Then determine event for each state of object
and prepare state diagram for affected object.
Last evaluate the state diagram.
Following step perform to construct domain
state model.
1. Identify domain classes with states.
2. Find state.
3. Find events.
4. Build state diagram.
5. Prepare state diagram.
1/17/2013
21
IDENTIFY CLASSES WITH STATES
List of the domain classes which have distinct
cycle.
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 and rejected.
There can be some cycles for example, if the
reviewer ask for revisions, but basically the life
of this object is progressive.
CONTD
On the other hand , airplane is owned by an
airline cycle through the state of maintenance,
loading, flying, and unloading.
Not every state occurs in every cycles an their
probably other states but in life of this object
is cyclic.
CONTD
In ATM example account is an important
business concept, and the appropriate
behavior for an ATM depends on the state of
an account.
Life of a cycle is a mix of progressive and cyclic
to and from problem states.
FINDING STATES
List the states for each class.
Characterizes each object in class, Attribute
value that object may have, the association
that it may participate in and their
multiplicities, attributes and associations that
are meaningful only in certain states, and so
on.
Give meaningful name, but that dont indicate
how the state came about.
1/17/2013
22
CONTD
Try to directly describe the state.
Dont focus on fine distinction among states
before examining events. Particularly
quantitative differences
State should be based on qualitative differences
in behavior, attributes or associations.
Unnecessary to determine all the states
considering events and all transition among
states , missing states will became clear.
CONTD
In ATM example some state for an account :
normal ( ready for normal access), closed
(closed by the customer but still on file in the
bank records), overdrawn(customer
withdrawal exceed the balance in the
account), and suspended(access to the
account is blocked for some reason).
FINDING EVENTS
Once you have a preliminary set of staes, find
the events that cause transitions among
states.
Find the event that cause the transition
among states.
In many case you regard an event as
completing a do-activity.
You can fid other events by thinking about
taking the object into a specific states.
CONTD
There are additional events that occur within
a state and do not cause transition.
In ATM example important event include:
close account, withdraw excess funds
repeated incorrect PIN, suspected fraud, and
administrative action.
1/17/2013
23
The states to which each applies. Add
transitions to show the change in state caused
by occurrence of an event when an object is in
particular state . If event terminate a state, it
will usually have a single transition from that
state to another state.
Usually not important to consider effects
when building a state diagram from a domain
class.
BUILDING STATE DIAGRAM
EVALUATING STATE DIAGRAM
Examine each state model. Are all state
connected ?
If progressive class is there path from initial
state to the final state?
If cyclic class is the main loop present ? Are
there any dead state that terminate the cycle?
Use knowledge to find missing paths.
Sometimes missing path indicate missing
state.
DOMAIN INTERACTION MODEL
Interaction models, however , is an important
aspect of application modeling.
Most analysis model require more than one
pass to complete. Most application cannot
approached in a completely linear way
because different part of problem interact.
To understand problem with all its implication
you must attack the analysis iteratively,
preparing first approximation model and then
iterating the analysis as your understanding
increases.
1/17/2013
24
REFINING THE ANALYSIS MODEL
Overall analysis model may show
inconsistencies and imbalance within and
across models. Iterate the different portions to
produce a cleaner , more model.
Try to refine classes to increases sharing and
improve structure.
Some constructs will feet awkward and wont
seem fit in right. Reexamine them carefully;
sometimes major restructuring in the model is
needed as your understanding increases.
CONTD
A common difficulty is a physical object that
has two logically distinct aspects. Each aspect
should be modeled with a distinct object.
An indication of this problem is a class that
doesnt fit in cleanly and seems to have two
set of unrelated attributes, associations,
operations.
Other indications to watch for include
exceptions, many special cases, and lack of
expected symmetry.
CONTD
Restructuring your model to capture constraints
better within its structure.
s/w should facilitate operations of business.
Remove classes or associations that seemed
useful at first but now appear extraneous. Often
two classes in the analysis can be combined ,
because the distinction between them doesnt
affect the rest of the model in meaningful way.
A good model feels right and doesnt appear to
have extraneous detail.
RESTATING THE REQUIREMENTS
When the analysis complete, the model serves
as the basis for requirements and defines the
scope of future discourse.
Most of requirements, performance
constraints that should be stated clearly
together with optimization criteria
You should verify final model with the
requestor. During analysis some requirement
may appear to be incorrect or impractical;
confirm correction to the requirements.
1/17/2013
25
CONTD
We found analysis models to be an effective
means of communications with business
expert who are not computer expert.
The final verified model serve as basis for
system architecture, design, implementation.
ANALYSIS & DESIGNING
The goal of analysis model is to specify the
problem fully without introducing a bias to
any particular implementation, but it is
impossible in practice to avoid all taints of
implementation.
There is no absolute line b/w the various
development stages, nor is there any such
thing as a perfect analysis.
CONTD
the purpose of rule is to preserve flexibility
and permit changes later, but remember that
the goal of modeling is to accomplish the total
job and flexibility is just means to an end.
ATM EXAMPLE : we have no further changes
to ATM model at this time. A true application
is more likely to incur revision than a textbook
example, because you have are viewer who
are passionate about application and have
vested interest in it.
APPLICATION INTERACTION MODEL
Most of domain model are static and
operations are unimportant, because domain
as a whole usually doesnt do anything .
Focus of domain model is on building a model
of intrinsic concept after completing model
shift your attention to details of an application
and consider interaction.
1/17/2013
26
CONTD
Begin interaction model by determining the
overall boundary of the system. Then identify
use cases and flesh them out with scenarios
and sequence diagram.
Prepare a activity diagram for use cases that
are complex or have subtleties.
Once you understand the use cases organize
them into relationship. And finally check
against domain model to find any
inconsistencies.
CONTD
Application interaction model can be constructed
with following step.
Determine system boundary.
Find actors.
Find use cases.
Find initial and final events.
Prepare normal scenarios.
Add variation and exception scenarios.
Find external events.
CONTD
Prepare activity diagram for complex use
cases.
Organize actor and use cases.
Check against the domain class model.
DETERMINE SYSTEM BOUNDARY
Must know the precise scope of an
application- the boundary of the system in-
order to specify functionality.
Decide what system include and more
importantly and what it omits.
If system boundary drawn correctly , you can
treat the system as a black box in its
interaction with outside world-you can regard
the system as an single object whose internal
details are hidden and changeable.
1/17/2013
27
CONTD
During analysis determine purpose of system
and view that it represent to its actor.
During design, you can change the internal
implementation of the system as long as you
maintain the external behavior.
Usually not consider humans as part of
systems. They are actors that must interact
with system, but their action are not under
the control of the system.
CONTD
In ATM example.
design the s/w to support a computerized
banking network including both human
cashier & automatic teller machine.
In commercial practices an ATM application
would be separated from cahier application
would share same underlying domain model.
But each would have its own distinct
application model. So ignore cashier details.
FINDING ACTORS
Identify external objects that interact directly
with the system. These are its actors.
Actors include human, external device and
other s/w system.
Actor are not under control of an application
and must considered somewhat unpredictable.
In finding actors , we are not searching for
individuals but for archetypical behavior.
CONTD
Each actor represents am idealized user that
exercises some subset of the system
functionality.
Each external object to see if it has a several
distinct faces. Actor is coherent face presented
to the system , and an external object may
have more than one actor.
ATM example the actors are customer,
consortium, bank.
1/17/2013
28
FINDING USE CASES
For each actors list the fundamentally
different ways in which the actor uses the
system. Each of these ways is a use case. 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 a
service that the system provide-something
that provides value to the actor. Try to keep all
of the use case at similar level of detail.
CONTD
Draw preliminary use case diagram. Show the
actors and the use cases, and connect actors
to use cases. Usually you can associate a use
case with the actors that initiates it, but other
actors may involved as well.
SUMMARY
Use case partition functionality of a system
into a small number of discrete units, that
cover its behavior.
Initiate session . The ATM establishes the
identity of the user and make available a lsit of
account and actions.
Query account. The system provides general
data for an account such as a the current
balance, date of last transaction, and date of
mailing for last statement.
1/17/2013
29
CONTD
Process transaction. The ATM system perform
an action that affect an accounts balance,
such as deposit, withdraw, and transfer .
Transmit data. ATM uses the consortiums
facilities to communicate with the appropriate
bank computer.
FINDING INITIAL & FINAL EVENTS
Use cases do not show the behavior clearly.
To understand behavior you must understand
the execution sequences that cover each use
case.
Start finding event that initiate each use case.
Determine which actor initiates the use case
and define the event that it sends to the
system
Many case initiate event is a request for a
service that use case provides.
CONTD
In other cases the initial event is an
occurrence that triggers a chain of activity.
Give this event a meaningful name.
Also determine final event or events and how
much to include in each use case. For example
use case applying for loan is continued until
application is submitted, until loan is granted
or rejected.
The modeler must define scope of use case by
defining when it terminates.
CONTD
ATM example final & initial event for use case.
Use case Initial Final
Initiate session Customers insertion card System keeps or returns
the cash card
Query account Request for account data Delivery of account data
to customer
Process transaction Initiate transaction Committing or aborting
transaction
Transmit data Triggered by request for
account data or recovery
from n/w or power failure
Successful transmit of
data
1/17/2013
30
PREPARING NORMAL SCENARIOS
For each use case prepare one or more typical
dialogs to get a feel for expected system
behavior.
Scenarios is a sequence of event among a set
of interacting objects.
Think I terms of sample interaction rather
than trying to write down the general case
directly. So that important step is not
overlooked & interaction flow is smooth and
correct.
CONTD
Logical correctness depends on the sequence
of interaction and not their exact times.
Problem statement describes full interaction
sequence, but most of the time you will have
to invent interaction sequence.
Prepare scenarios for a normal cases
interaction without any unusual i/p or error
conditions. For each event identifying the
actor that caused the event and the
parameter of an event.
ADDING VARIATION & EXCEPTION SCENARIOS
After prepared scenarios , considers the
special cases , such as omitted i/p, maximum
& minimum values, and repeated values.
Then considered error cases, invalid values
and failure to responds.
Finally considered various other kind of
interactions that can be overlaid on basic
interactions. Such as help request & status
queries.
CONTD
In ATM some exception & variation are
followed .
The ATM, cant 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.
Transaction is suspended because of
suspicious patterns of card usage.
1/17/2013
31
FINDING EXTERNAL EVENT
Examine the scenarios to find all external
event-include all i/p decision, interrupts and
interactions to or from users or external
devices.
Internal computation steps are not events
except for computation that interact with the
external world.
prepare one or more scenario for each use
case.
1/17/2013
32
CONTD
Prepare a sequence diagram for each
scenarios. A sequence for each scenarios.
A sequences diagram shows the participants
in an interaction and the sequence of
messages among them . The sequence
diagram clearly shows the sender and receiver
of each event.
PREPARING ACTIVITY DIAGRAM FOR COMPLEX
USE CASES
Sequence diagram capture dialog and
interplay between actors, but they do not
clearly show alternative and decision.
Activity diagrams let us consolidate all this
behavior by documenting forks and merges in
the control flow.
It is appropriate to use activity diagram to
document business logic during analysis, but
do not them as an excuse to begin
implementation
1/17/2013
33
ORGANIZING ACTORS & USE CASES
Next step is to organize use cases with
relationship (include, extend and
generalization) this is especially helpful for a
large and complex system as with classes a&
state model.
Similarly , you can also organize actors with
generalization.
You do not use activity diagram as an excuses
to begin premature implementation.
CHECKING AGAINST THE DOMAIN
CLASSES MODEL
At this pt application & domain model should
be consistent.
Use cases , and scenarios are all based on
classes and concept from domain model.
Examine the scenarios and make sure that
domain model has all the necessary date &
also cover all event parameters.
APPLICATION CLASS MODEL
Application class define the application itself ,
rather than the real-world objects that the
application act on.
Application class model are computer-
oriented and define the way that users
perceive the application.
1/17/2013
34
CONTD
Once basic use cases are identified , you can
organize them with relationship.
Construct application class model with
following step.
1. Specify user interfaces.
2. Define boundary classes.
3. Determine controllers.
4. Check against the interaction model.
SPECIFYING USER INTERFACES
Interaction can be separated in two parts
Application logic
User interface
User interface is an objects that provides the
user of a system with coherent way to access
its domain objects, commands, and
application options.
Same program logic can accept i/p from
command lines, files, mouse buttons, touch
panels, physical push button, or remote link if
the surface details are carefully isolated.
CONTD
During analysis treat the user interface at a
coarse (ordinary) level of detail.
Try to determine the cmd. That the user can
perform a cmd. Is a large scale request for a
service. For example making a flight
reservation would be a command.
The format of inputting the information for
the command and invoking them is relatively
easy to change. So work on commands first.
1/17/2013
35
CONTD
It is acceptable to sketch out a sample
interface to help you to visualize the operation
of an application and see if anything
important has been forgotten.
Decoupling application logic from the user
interface lets you evaluate the look & feel
of the user interface while the application is
under development.
EXAMPLE
DEFINNING 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.
It is often helpful to determine boundary
classes to isolate the inside of a system from
the external world.
A boundary class is a class that provide a
staging area for communication between a
system and an external source.
CONTD
Boundary class understand various format of
external source & convert information for
transmission to & from internal system.
ATM example. Cashcardboundary,
accountboundary are the example of
boundary classes which encapsulate the
communication between the ATM and the
consortium.
1/17/2013
36
DETERMINE CONTROLLER
Controller is an active object that manages
control within an application.
It receives signal from the outside world or
from object within the system, react to them,
invokes operations on the object in the
system, and send signals to the outside world.
It capture behavior in the form of an object-
behavior that can be manipulated &
transformed more easily than plain code.
CONTD
Most of work in designing a controller is in
modeling its state diagram. In the application
class model you should capture the existence
of controller in a system, control information,
& the association from the controller to other
objects in the system.
In ATM example there is two major control
loop.
Outer loop verifies customer & account.
Inner loop services transaction.
CHECKING AGAINST INTERACTION
MODEL
Go over the use case & think about hoe they
would have work.
For example if user send a command to the
application , the parameter of command must
come from userinterface object.
In ATM example the preliminary application
diagram are shown.
1/17/2013
37
CONTD
Boundary classes flatten and data structure
and combine information from multiple
domain classes.
Desirable to minimize the number of
boundary classes & their relationship.
APPLICATION STATE MODEL
The application state model focuses on
application classes & augments the domain
state model.
First identify application classes with multiple
states events for these classes.
Then organize permissible event sequences
for each class with state diagram.
Next check various state diagrams to make
sure that common event match.
Finally check state diagram against class &
interaction model to ensure consistency.
CONTD
Construct application state model with the
following steps:
1. Determine application classes with states.
2. Find events
3. Build events
4. Check against other state diagrams.
5. Check against the class models.
6. Check against the interaction models.
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 class & determine which ones
have multiple states. User interface classes &
controller classes are good candidate for state
model rather than boundary classes tends to
be static and for used import-export data.
1/17/2013
38
CONTD
In ATM example user interface classes don not
seems to have any substance .
boundary classes also lack state behavior.
However the controller do have important
states that we will elaborate.
FIND EVENTS
For application interaction model, you
prepared a number of scenarios.
From those scenarios, extract events.
Scenarios mostly highlight major events.
Note the difference between domain &
application state model.
In domain state model focus on data-
significant groupings of data form states that
are subject to events.
CONTD
While in application state model first we find
the event and then we determine states.
In ATMexample, revisit the scenarios from the
application interaction model. Some events
are insert card, enter password , end session,
and take card.
BUILDING STATE DIAGRAMS
Build state diagram for each application class
with temporal behavior.
Choose one of these classes consider a
sequence diagram.
Arrange the events involving the class into a
path whose arcs are labeled by the events.
The interval between two events is state.
Now merge other sequence diagrams into
state diagram.
1/17/2013
39
CONTD
Now find loops within a diagram if a sequence
of events can be repeated indefinitely, then
they form a loop.
Once you find the loop merge other sequence
diagram into state diagram. Find the point in
each sequence diagram where it diverges
from previous ones. That point corresponds to
an existing state diagram.
Beware of two paths that appear identical but
can be distinguished under some
circumstances.
CONTD
After a normal events have been considered,
add variation and exception cases. Consider
events that occur at awkward times.
Handling user error cleanly often requires
more thought and code then normal case.
Error handling is often complicates but must
be done.
You finished state diagram when all scenarios
are cover & diagram handle all events that
affect state.
CONTD
If there are complex interaction with
independent inputs, you can use a nested
state diagram . Other wise a flat state diagram
suffices. Repeat above process of building
state diagram for each class that has time-
dependent behavior.
CHECKING AGAINST OTHER STATE
DIAGRAM
Check the state diagram of each class for
completeness and consistency . Every event
should have sender & receiver,. State without
predecessors or successor are suspicious.
Follow the effect of an input event from object
to object through the system to make sure
they match to the scenarios. Beware of
synchronization error.
1/17/2013
40
CONTD
Build state diagram for each application class
model with temporal behavior.
Obtain information from the scenarios of the
interaction model.
CHECKING AGAINST CLASS MODEL
Make sure that the state diagrams are
consistent with domain & application class
models.
Multiple ATMs can potentially concurrently
access an account
CHECKING AGAINST INTERACTION
MODEL
When state model is ready, go back & check it
against the scenarios of the interaction model.
Simulate each behavior sequence by hand and
verify that the state diagrams gives correct
behavior.
If error is discovered change either state
diagram or the scenarios.
1/17/2013
41
ADDING OPERATIONS
Operation arise from the following sources,
and you should add major operations now.
1. Operations from class model.
2. Operations from use case.
3. Shopping-list operations.
4. Simplifying operations.
OPERATIONS FROM CLASS MODEL
Reading & writing of attributes values &
association link are implied by class model.
During analysis all attributes & associations
are assumed to be accessible.
1/17/2013
42
OPERATIONS FROM USE CASE
Most of complex functionality of a system
come from use cases.
During construction of interaction model , use
cases lead to an activities. Many of these
correspond to operation on model.
In ATMexample consortium has the activity
verifying bankcode bank has the activity to
verifying password
SHOPPING-LIST OPERATIONS
Sometimes real world behavior of classes
suggest operations.
This called the shopping-list, because
operations are not dependent on a particular
application but are meaningful in their own
right.
IN ATMexample shopping-list operations
include.
Account. Close
CONTD
bank. Create
SavingsAccount(customer):account
bank. Create
CurrentAccount(customer):account
bank. Create cashcardAuth(customer):cashcard
Authorization
Cashcard Authorization.addAccount(account)
Cashcard Authorization.removeAccount
(account)
Cashcard Authorization.close.
SIMPLIFYING OPERATIONS
Examine a class model for similar operations &
variations in form on a single operation.
Use inheritance where possible to reduce the
number of distinct operations.
Introduce a super classes as needed to
simplifying operations.
Location each operations at correct level
within a class hierarchy.
1/17/2013
43
SYSTEM DEVELOPMENT LIFE CYCLE
It is conceptual model used in project mgmt
that describes the stages involved in an
information system development project from
initial feasibility study through maintenance of
the completed application.
Various SDLC methodologies have been
developed to guide processes involved
including waterfall model(the original sdlc
method), rapid application
development(RAD), joint application
development(JAD)m the fountain model &
spiral model
CONTD
CONTD
The above image is the classic waterfall model
methodology, which is the first SDLC method
and it describes the various phases involved in
develpoment.
FEASIBILITY
The feasibility study is used to determine if
the project should get the go-ahead.
If the project is to proceed ,the feasibility
study will produce a project plan and budget
estimates for the future stages of
development.
1/17/2013
44
REQUIREMENT ANALYSIS & DESIGN
Analysis gather the requirement for the
system. This stage includes a detailed study of
the business needs of the organization.
Option for changing the business process may
be considered.
Design focuses on high level design like, what
programs are needed and how are they going
to interact, interface design and data design.
These phase is very crucial in the whole
development cycle.
IMPLEMENTATION
In this phase the designs are translated into
code.
Computer programs are written using a
conventional programming language or an
application generator.
Programming tools like compilers, interpreter,
debugger are used to generate the code.
TESTING
In this phase the system is tested. Normally
programs are written as a series of individual
modules, these subject to separate modules,
these subject to separate and detailed test.
The separate modules are brought together
and tested as a complete system.
The system ensure that interfaces between
modules work the system works on the
platform and with the expected volume of
data and that system does what the user
rewquires .
MAINTENANCE
Inevitably the system needs maintenance.
s/w will definitely undergo change once it id
delivered to the customer.
Changes could happen because of some
unexpected i/p values into the system.
In addition , the changes in the system could
directly affect the s/w operations. The s/w
should be developed to accommodate
changes that could happen during the post
implementation period.
1/17/2013
45
INFORMATION SECURITY
There are many different SDLC models &
methodologies, but each generally consists of
a series of defined steps.
For any SDLC model that is used, information
security must be integrated into SDLC to
ensure appropriate protection for the
information that the system transmit, process,
and store.
CONTD
Applying the risk management process to
system development enables organization to
balance requirement for the protection of
agency information and assets with the cost of
security controls and mitigation strategies
throughout the SDLC.
Risk management process identify critical
assets and operations, as well as systematic
vulnerabilities across organozation
CONTD
Some benefit of integrating security into the
SDLC include.
Early identification and mitigation of securities
vulnerabilities and problem with the
configuration of systems, resulting n lower
costs to implement securities control and
mitigation of vulnerabilities.
Awareness of potential engineering challenges
caused by mandatory securities controls.
CONTD
Identification of shared securities services and
reuse of security strategies & tools that will
reduce development costs & improve the
systems security.
Documentation of important security decision
made during the development process to
inform management about security
consideration during all phases of
development
1/17/2013
46
CONTD
Improved organization and customer
confidence to facilitate adoption and use of
systems, and improved confidence in the
continued investment in government system;
and improved systems interoperability and
integration that would be difficult to achieve if
security is considered separately at various
system level.
SDLC
INITIATION PHASE
During this phase , the organization
establishes the need for a system and
documents its purpose.
Security planning should begin in this phase
with the identification of key security roles to
be carried out in the development of the
system.
CONTD
Information to be proceed , transmitted, or
stored is evaluated for security requirements
and all stakeholder should have a common
understanding of the security consideration.
The ISSO(information system security officer)
is identified as well.
Requirements for the confidentiality, integrity
and availability of information should be
accessed at this stage.
1/17/2013
47
CONTD
In this phase the organization clearly defines
its project goals and high level information
security requirements as well as the
enterprise security system architecture.
DEVELOPMENT/ACQUISTION
PHASE
In this phase the system is designed,
purchased, programmed, developed, or
otherwise constructed.
A key security activity in this phase conducting
a risk assessment and using the results to
supplement the baseline security control.
CONTD
The risk assessment enables the organization
to determine the risk to operations, assets and
individuals resulting from the operation of
information systems and the processing
storage , or a transmission of information.
CONTD
Another essential element is the development
of security plans, which establishes the
security requirements for the information
system describes security controls that have
been selected and presented the rational for
security categorization, how controls are
implemented, and how use of systems can be
restricted in high risk situations.
1/17/2013
48
CONTD
The developmental testing of the technical
and security features & functions of the
system ensure that they perform as intended,
prior to launching the implementation and
integration phase.
IMPLEMENTATION PHASE
In this phase, the organization configures and
enables system security features, tests the
functionality of these features, installs or
implementation the system, and obtain a
formal authorization to operate system.
Design reviews and system tests should be
performed before placing the system into
operation to ensure that it meets all required
security specifications.
CONTD
If new controls are added to the application or
the support system, additional acceptance
tests to those new control must be performed.
This approach ensure that new controls meet
security specification and do not conflict with
or invalidating existing controls.
OPERATION/MAINTENANCE PHASE
In this phase, systems and products are in
place & operating , enhancement and/or
modifications to the system are developed &
tested & h/w and s/w components are added
or replaced.
The organization should continuously monitor
performance of the system to ensure that it is
consistent with pre-established user and
security requirement s and that need system
modification are incorporate.
1/17/2013
49
CONTD
Configuration mgmt (CM) and control
activities should be conducted to document
any proposal or actual change in the security
plan of the system.
Information system are in constant state of
evaluation with upgrades in h/w, s/w and
firmware and possible modification in the
surrounded environment.
DISPOSAL PHASE
In this phase plans are developed for
discarding system information, h/w and s/w
and making the transition to a new system.
The information h/w and s/w ,ay be moved to
another system archived discarded or
destroyed.
If performed improperly this phase can result
in unauthorized disclosure of sensitive data.
Contd
System normally evolve to the next generation
because of changing requirements or
improvement s in the technology. Security
plans continuously evolve with the system.
The disposal activities ensure the orderly
termination of the system and preserve the
vital information about the system so that
some or all of the information may be
reactivated in the future if necessary.
CONTD
Particular emphasis is given to proper
preservation of the data proceed by the
system so that the data is effectively migrated
to another system or achieved in accordance
with applicable records mgmt regulations and
policies for potential future access.
1/17/2013
50
ADDITIONAL SECURITIES
CONSIDERATION
Some IT development projects are service-
based and may involved other organization,
such as public-private sectors supply chain
endeavors.
Other project are facility-oriented , such as the
establishment of a data center or a site.
CONTD
Organization developing projects such as
these should follow the principle for
integrating security in SDLC as they examine
and address the additional security
consideration involved in these project.