Chapter 13

Application Analysis
Application Interaction Model
 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-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.
 One 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
 We 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 operation son 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, mor e
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.