System Conception: Chapter - 1

Module – 3 System Conception and Analysis
Chapter – 1
System Conception
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 that proposed system meet, can it be developed at a reasonable
cost, and will the demand for the result justify the cost of building it?
1.1. Devising a System Concept:

Most ideas for new systems are extensions of existing ideas. Here are some ways to find 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 processes
§ Integration: Combine functionality from different systems.
§ Analogies: Look for analogies in other problem domains and see if they have useful ideas
§ Globalization: Travel to other countries and observe their cultural and business practices.
1.2. Elaborating a Concept:

A Good system concept must answer the following questions:
v Who is the application for?
You should clearly understand which person & organization are stakeholder for new system. The most
important two kinds of stakeholders are Financial sponsors and User.
ü Financial sponsors are important because they are paying for system & expect the project to be
success & within budget.
ü User will determine success of system by increase or decrease in their productivity or
effectiveness.
v What problems will it solve?
You must clearly bound the size of the effort and establish its scope. You should determine which
features will be in the new system and which will not.
You must reach various kinds of users in different organizations with their own viewpoints and political
motivations. determine which feature will be in new system & which will not.
v Where will it be used?
You should have a rough idea about how the new system will complement the existing systems. It is
important to know if the software will be used locally or will be distributed via a network.
By: Rajatha S, Dept. of MCA RNSIT 1|26

v When is it needed?
Two aspects of time are important. They are:
Feasible time: The time in which the system can be developed within the constraints of cost and
available resources.
Required time: When the system is needed to meet business goals.
v Why is it needed?
You may need to prepare a business case for the new system if someone has not already done so.
business case will give you insight what stakeholders expect.
The business case contains the financial justification for the new system, including the cost, tangible
benefits, intangible benefits, risk, and alternatives. You must be sure that you clearly understand the
motivation for the new system.
v How will it work?
You should brainstorm about the feasibility of the problem. For large systems you should consider the
merits of different architectures.
The purpose of this is not to choose a solution, but to increase confidence that the problem can be solved
reasonably.
è The ATM Case Study:

Lists our original system concept for an Automated Teller Machine (ATM). We ask high-level questions
to elaborate the initial concept.
Develop software so that customers can access a bank’s computers and carry out their own
financial transactions without the mediation of a bank employee.
Figure: System concept for an automated teller machine
Ø Who is the application for?

A number of companies provide ATM products. Consequently, only a vendor or a large financial
company could possibly justify the cost and effort of building ATM software.
For the ATM case study, we will assume that we are a vendor building the software. We will assume
that we are developing an ordinary product, since deep complexities of the ATM problem domain are
beyond the scope.
Ø 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.
It must be reliable and secure since it will be handling money.

Ø Where will it 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.
Ø When is it needed?
Any software development effort is a financial proposition. The investment in development ultimately
leads to a revenue stream.
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 an economic incentive to participate.
Ø 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.
1.3. Preparing a Problem Statement:

Once you have fleshed out the raw idea by answering the high-level questions, you are ready to write a
requirements statement that outlines the goals and general approach of the desired system.
Throughout development, you should distinguish among requirements, design and implementation.
Þ Requirements describe how a system behaves from the user’s point of view.
Þ Design decisions are engineering choices that provide the behavior specified by the requirements.
Þ Implementation deals with the ultimate realization in programming code.
As Figure 1.1 shows, the problem statement should state what is to be done and not how it is to be
implemented. It should be a statement of needs, not a proposal for system architecture.
Design
Requirements Statement § General approach Implementation
§ Problem scope § Algorithms § Platforms
§ What is needed § Data Structure § Hardware specs
§ Application context § Architecture § Software Libraries
§ Assumptions § Optimizations § Interface standards
§ Performance needs § Capacity Planning
Figure 1.1: Kinds of requirements
A problem statement:
§ may have more or less detail.
§ are ambiguous, incomplete, or even inconsistent.
§ is just a starting point for understanding the problem not an immutable document.
The purpose of the subsequent analysis is to fully understand the problem and its implications. There is no
reason to expect that a problem statement prepared without full analysis will be correct.

è The ATM Case Study:
Figure 1.2 shows a problem statement for an automated teller machine (ATM) network.
Figure 1.2: ATM network, the ATM case study threads throughout the remainder of this book
Design the software to support a computerized banking network including both human cashiers and
automatic teller machines (ATMs) to be shared by a consortium of banks.
Each bank provides its own comt5puter to maintain its own accounts and process transactions against
them. Cashier stations are owned by individual banks and communicate directly with their own bank’s
computers. Human cashiers enter account and transaction data.
Automatic teller machines communicate with a central computer that clears transactions with the
appropriate banks. An automatic teller machine accepts a cash card, interacts with the user, communicates
with the central system to carry out the transaction, dispenses cash, and prints receipts. The system
requires appropriate record keeping and security provisions. The system must handle concurrent accesses
to the same account correctly.

Chapter - 2
Domain Analysis
Domain analysis the next stage of development, is concerned with devising a precise, concise, understandable
and correct model of the real world. To build a domain model, you must interview business experts, examine
requirements statements and scrutinize related artifacts.
This 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.
2.1 Overview of Analysis:

Figure 2.1 shows, 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.
Figure 2.1: Overview of Analysis
Analysis is divided into two sub stages.
i. Domain analysis: Focuses on understanding the real-world essence of a problem.
ii. Application analysis: Incorporating major application artifacts that are seen by users and must be
approved by them.
The analysis model addresses the three aspects of objects: static structure of objects (class model),
interactions among objects (interaction model), and life cycle of objects (state model).
2.2 Domain Class Model:

The first step in analysing the requirements is to construct a domain model. It shows 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.
Information for the domain model comes from the problem statement, artifacts from related systems, expert
knowledge of the application domain and general knowledge of the real-world.

The steps to be performed to construct a domain class model
i. Find Classes. v. Organize and simplify classes using inheritance.
ii. Prepare a data dictionary. vi. Verify that access paths exist for likely queries.
iii. Find associations. vii. Iterate and refine the model.
iv. Find attributes of objects and links. viii. Reconsider the level of abstraction.
ix. Group classes into packages
i. Find Classes:
Constructing a class model is to find relevant classes for objects from the application domain. Classes
often correspond to nouns. Idea is to capture concepts. Not all nouns are concepts, and concepts are also
expressed in other parts of speech.
Figure 2.2 shows, begin by

listing candidate classes found in
the written description of the
problem. Don’t be too selective;
Figure 2.2: Finding Classes by considering the nouns
write down every class that
comes to mind.
Consider the ATM example, the classes can be extracted from problem statement nouns and knowledge
of problem domain that shown in the figure 2.3 and figure 2.4.
è Keeping the Right Classes:

Discard unnecessary and incorrect classes according to the following criteria.
§ Redundant classes: If two classes express the same concept, we will keep the most descriptive
name.
ATM example - Customer and user are redundant; we retain customer because it is more
descriptive.

§ Irrelevant classes: Eliminate the classes that are nothing to do with the problem.
ATM Example: cost is outside the scope of the ATM software.
§ Vague classes: class should be specific.
ATM Example: System, Security provision, Banking network etc are not specific thing.
§ Attribute: Names that primarily describe individual objects should be restated as attributes.
ATM Example: Account Data, Cash, Transaction data are purely indicating attributes not a class.
Figure 2.5: Eliminating unnecessary classes from ATM problem
§ 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.
Example: if we are simply building telephones, then call is part of the state model and not a class.
But Billings system for telephone calls a Call would be important class with attributes date, time,
origin and destination.
§ Roles: The name of a class should reflect its intrinsic nature and not a role that it plays in an
association.
Example: Owner of a car in a car manufacturing database, not correct as a class. It can be a person
(owner, driver, lessee)
§ Implementation Constructs: Eliminate constructs from the analysis model that are irrelevant to
the real world. We may need them during design and not now.
Example: Transaction Log class.
§ Derived classes: As a general rule, omit classes that can be derived from other classes. Mark all
derived classes with a preceding slash (‘/’) in the class name.

ii. Prepare a Data Dictionary:
Prepare a data dictionary for all modeling elements. Account, ATM, Bank,
Describe the scope of the class within the current BankComputer, CashCard,
problem, including all assumptions or restrictions on its Cashier, CashierStation,
CentralComputer, Consortium,
use. Data Dictionary also describes associations,
Customer, Transaction
attributes, operations and enumeration values.
iii. Find associations: Figure 2.6: Data Dictionary for ATM Classes
A structural relationship between two or more classes is called an association. It is also a reference from
one class to another. Associations often correspond to stative verbs or verb phrases. Idea here is to capture
relationships.
Example: Physical Location(partOf, NextTo), Directed Actions(Drives), Communication(TalksTo),
Ownership(Has, PartOf), Satisfaction of some condition(WorksFor, Manages, MarriedTo).
Verb Phrases
Bank computer maintains accounts.
Bank computer processes transaction against account.
Bank owns cashier station.
Cashier station communicates with bank computer.
Cashier enters transaction for accounts.
ATMs communicate with central computer about transaction.
ATM accepts cash card.
ATM interacts with user.
ATM dispenses cash.
ATM prints receipt.
Central computer clears transaction with bank.
System handles concurrent access. Implicit Verb Phrases
Banks provide software. Consortium consists of banks.
Cost apportioned to banks. Consortium owns central computer.
Bank holds account.
Knowledge of problem domain
Customers have cash cards.
Cash card accesses accounts.
System provides record keeping.
Bank employs cashiers.
System provides security
Figure 2.7: Association from ATM problem statement
è Keeping the Right Associations:

Discard unnecessary and incorrect associations, using the following criteria:
§ Associations between eliminated classes: If you have eliminated one of the classes then either
you eliminate association or restate it.
Example: Banking Network includes cashier stations and ATMs. ATM dispenses cash
§ Irrelevant or implementation associations: Eliminate any association that deals with

implementation or outer problem statement.
Example: System handles concurrent access is an Implementation

§ Actions: An association should describe a structural property of the application domain not a
transient event.
Example: ATM accepts Cash card (Interaction cycle)
§ Ternary associations: You can decompose most association among three or more classes into
binary associations. Always decomposed without losing information.
Example: Bank computer processes transaction against account can be convert into Bankcomputer
processes transaction and transaction concern accounts.
§ Derived associations: Omit association and attributes, they may be redundant.
Example: GrandParentOf can be defined in terms of pair of ParentOf and also omit the association
defined by conditions on attributes.
Example: youngerThan expresses condition on the birthdate of two person, not additional
information.
iv. Find attributes of objects and links:

Attributes are data properties of individual objects. Attributes should not be objects. Attributes usually
correspond to nouns followed by possessive phrases, such as “the colour of the car”. Adjectives represent
specific enumerated attribute values, such as, red, on, expired.
è Keeping the Right Attributes:

Eliminate unnecessary and incorrect attributed with the following criteria:
§ Objects: if element is important rather than just its value, then it is an object.
Example: Boss refers to a class and Salary is an attribute.
§ Name: Name often refer as Qualifier rather than attributes.
Example: Names of person are not unique therefore its attributes.
§ Identifiers: It means referencing objects used for some work.
Example: ATM transaction always generate Transaction ID for each operation. So you can count
Transaction ID as attributes.
§ Attributes on Association: If value require the presence of link then attributes of the association
should derived.
Example: Worksfor association attribute can be salary, title etc
§ Internal Values: If an attribute describes internal state of an object then eliminate it.
§ Fine Detail: Omit minor attributes that are unlikely to affect most operation.
§ Discordant attributes: An attribute that seems completely different from and unrelated to all other
attributes then remove it.
§ Boolean Attributes: Convert Boolean attributes into enumeration.
We apply these criteria to obtain attribute for each class that shown in the figure 2.8.

Figure 2.8: ATM class model with attributes
v. Organize and simplify classes using inheritance:

Organize classes by using inheritance to share common features. Inheritance can be added in two
directions:
i. Bottom-up generalization: By generalizing common aspects of existing classes into a superclass.
Example: RemoteTransaction and CashierTransaction are similar and can be generalized by
Transaction
ii. Top-down specification: By specializing existing classes into multiple sub-classes.
Example: Fixed menu, pop-menu, sliding menu and text menu
§ Multiple Inheritance: If require then apply to increase sharing because it increases both conceptual
and implementation complexity.
§ Generalization vs. Enumeration: Generalization is all about common structure. Enumeration is all
about list of values.
Example: CurrentAccount and SavingAccount share common structure but it does not affect behavior
within the ATM application; Type can be made a attributes of Account and enumerate it.
§ Similar association: When the same association name appears more than once with the same
meaning, try to generalize the associated class.
Example: EntryStation generalizes CashierStation and ATM.
§ Adjusting inheritance Level: Assign attributes and association to specific classes in the class
hierarchy. You may need some adjustment to get everything right.

Figure 2.9 shows the ATM class model after adding inheritance.
Figure 2.9: ATM class model with attributes and inheritance
vi. 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?
• Are there useful questions that cannot be answered?
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. However, check
disconnected classes to make sure you have not overlooked any associations.
Example: A cash card itself does not uniquely identify an account, so the user must choose an account
somehow.
vii. Iterating a Class Model:

A class model is rarely correct after a single pass. If you find any deficiency, go back to an earlier stage if
necessary, to correct it. So iterate and refine the model.
There are several sings of missing classes.

a) Asymmetries in associations and generalizations: Add new classes by analogy.

b) Disparate attributes and operations on a class: Split a class so that each part is coherent.
c) Difficulty in generalizing cleanly: One class may be playing two roles. Split it up and one part
may then fit it cleanly.
d) Duplicate associations with the same name & purpose: Generalize to create the missing
superclass that unites them.
e) Missing access paths for operations: Add new associations so that you can answer queries.
Figure 2.10 shows a revised class diagram that is simpler and cleaner.
Figure 2.10: ATM class model after further version
viii. Shifting the Level of Abstraction:

So far in analysis, we have taken problem description as directly compared between classes, attributes and
associations. This is a good way to begin analysis, but it does not always suffice. Sometimes you must
raise the level of abstraction to solve a problem.
Abstraction makes a model more

complex but can increase flexibility and
reduce the number of classes. In case of
abstraction, we need to think in terms of
pattern. A pattern distills the knowledge
of experts and provide a proven solution
to a general problem.
Figure 2.11: Shifting the level of abstraction

ix. 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 & viewing.
• To assign classes to packages, look for cut points. A cut point is a class that is a sole connection
between two otherwise disconnected parts of a model.
• A cut point acts as a bridge between two packages.
Example: ATM model, package might be:
Ø Tellers – Cashier, Entry Station, Cashier Station, ATM
Ø Accounts – Account, cash card, card authorization, customer, transactions, update, cashier
transaction, remote transaction.
Ø Bank – consortium, bank
2.3 Domain State Model:

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.
The Following steps are performed in constructing a domain state model.
§ Identifying classes with states § Building state diagrams
§ Finding States § Evaluating state diagrams
§ Finding Events
i. 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.
ATM Example: Account is appropriate behavior for ATM. Life cycle of Account is progressive and
cycling to and from problem states.
ii. Finding States:

List the state for each class. Characterized the object by their
ü Attributes Values
ü Associations that may participants
ü Attributes and association that are meaningful in certain states only.
§ Avoid names that indicate how the state came about; try to directly describe the state.
§ States should be based on qualitative differences in behavior, attributes, or associations.
§ By looking at events and considering transitions among states, missing states will become clear.
Example: Some states for Account: Normal (Normal access); Closed (Closed by customer);
Overdrawn (withdrawal exceeds the balance); Suspended (blocked for some reason)

iii. Finding Events:
Now, find events that cause transitions among states. Think about stimuli (input) that cause a state to
change. Find other events that takes object into a specific state.
Example: Pickup receiver on telephone, it enters into Dialing State. But many telephones have
pushbuttons that invoke specific functions.
So, there are some additional event that occur within a state and don’t cause a transition. For Domain
State model, make focus on events that cause transition among states.
ATM example: events include: close account, withdraw excess funds, repeated incorrect PIN, suspected
fraud, and administrative action.
iv. Building State Diagrams:

Determine for which state, each event
applies. Add transitions to show the
change in state caused by the
occurrence of an event when an object
is in particular state.
Once you have specified the
transitions, check does it represent an
error or not? If yes, then add
transitions to error state.
Figure 2.12 shows the domain model
Figure 2.12: Domain State model
for the Account class.
v. Evaluating State Diagrams:

§ Examine each state model. Are all states connected?
§ Path from initial state to the final state?
§ Are the expected variations represent it?
§ Are there any dead states that terminate the cycle?
§ Find missing path and states from it.
When a state model is complete, it should indicate life cycle of the class.
ATM Example: Our state model for Account is simplistic but we are satisfied with it.
2.4 Domain Interaction Model:

The interaction model is seldom important for domain analysis. During domain analysis the emphasis is on
key concepts and deep structural relationships and not the user’s view of them.
2.5 Iterating the Analysis:

Most analysis models require more than one pass to complete. Problem statements often contain
circularities, and most applications cannot be approached in a completely linear way, because different
parts of the problem interact.

To understand a problem with all its implications, you must attack the analysis iteratively, preparing a first
approximation to the model and then iterating the analysis as your understanding increases.
i. 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. Add details that you glossed over during
the first pass. 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 doesn’t affect
the rest of the model in any meaningful way.
ii. 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. 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, implementation.
You should revise the original problem statement to incorporate corrections and understanding
discovered during analysis.
iii. Analysis and Design:

The goal of analysis is to specify the problem fully without introducing a bias to any particular
implementation. The purpose of the rules 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 a means to an
end.

Chapter – 3
Application Analysis
We include these application artifacts in analysis, because they are important, visible to users and must be
approved by them.
3.1 Application Interaction Model:
Most domain models are static and operations are unimportant. The focus of domain modeling is on building
a model of intrinsic concepts. After completing the domain model, we then shift our attention to the details
of an application and consider interaction.
Begin interaction modeling by determining the overall boundary of the system. Then identify use cases and
flesh them out with scenarios and sequence diagrams.
You can construct an application interaction model with the following steps:
• Determine the system boundary. • Add variation and exception scenarios.

• Find actors. • Find external events.
• Find use cases. • Prepare activity diagrams for complex use cases.
• Find initial and final events. • Organize actors and use cases.
• Prepare normal scenarios. • Check against the domain class model.
i. Determine the System Boundary:

Must know the precise scope of an application-the boundary of the system-in order to specify functionality.
If the system boundary is drawn correctly, you can treat the system as a black box in its interactions with the
outside world-you can regard the system as a single object, whose internal details are hidden and changeable.
During analysis, you determine the purpose of the system and the view that it presents to its actors. During
design, you can change the internal implementation of the system as long as you maintain the external
behavior.
Usually, you should not consider humans as part of a system, unless you are modeling a human organization,
such as a business or a government department.
Example: ATM System boundary
ii. Find Actors:

Once you determine the system boundary, identify the external objects that interact directly with the system.
These are its actors.

Actors include humans, external devices, and other software systems. 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.
Example: In ATM System Boundary actors are Customer, Bank and Consortium.
iii. Find Use Cases:
For each actor, list the fundamentally different ways in which the actor uses the system 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.
Usually you can associate a use case with the actor

that initiates it, but other actors may be involved as
well.
ATM example: Figure 3.1 shows the use cases, and
the summarize of each as below.
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 Figure 3.1: Use case diagram for the ATM
last transaction and date of mailing for last statement.
Process Transaction: The ATM system performs an action that affects an account’s balance. 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.
iv. Finding initial and final events:

Must understand the execution sequences that cover each use case. Start by finding the events that initiate
each use case.
Determine which actor initiates the use case and define the event that it sends to the system. Determine the
final event or events and how much to include in each use case.
ATM example: Here are initial and final events for each use case.
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.
§ recovery from a network, power, or another kind of failure.
The final event is successful transmission of data.
v. Preparing Normal Scenarios:

For each use case, prepare one or more typical scenarios. These illustrate the major interactions, external
display formats, and information exchanges.
A scenario is a sequence of events among a set of interacting objects. Prepare scenarios for “normal” cases-
interactions without any unusual inputs or error conditions. An event occurs whenever information is
exchanged between an object in the system and an outside agent, such as a user, a sensor, or another task.
ATM Example: Normal scenario for each use case shown in the below figures.
The ATM asks the user to insert a card.

The user inserts a cash card.
The ATM accepts the card and reads its serial number.
The ATM requests the password.
The user enters “1234”
ATM verifies password with consortium
ATM asks user to select the kind of transaction (withdrawal, deposit,
mini statement); user selects withdrawal
ATM asks for the amount of cash; the user enters $100
ATM verifies that amount in account balance
ATM dispenses cash and asks user to take it; the user takes the cash
ATM asks whether the user wants to continue; user indicates no
The ATM prints receipt,ejects the card and asks the user to take them
ATM asks user to insert card
Figure 3.2: Scenarios of Initiate Session
The ATM display a menu of accounts and commands.

The user chooses to query an account.
The ATM contacts the consortium and bank which return the data.
The ATM displays account data for the user.
The ATM displays a menu of accounts and commands.
Figure 3.3: Scenarios of Query Account

The ATM display a menu of accounts and commands.

The user selects an account withdrawal.
The ATM asks for the amount of cash.
The user enters $100.
The ATM verifies that the withdrawal satisfies its policy limits.
The ATM contacts the consortium and bank and verifies that the
account has sufficient funds.
The ATM dispenses the cash and asks the user to take it.
The user takes the cash.
The ATM displays a menu of accounts and commands.
Figure 3.4: Scenarios of Process Transaction
The ATM request account data from the consortium.

The consortium accepts the request and forwards it to the appropriate
bank.
The ATM receives the request and retrieves the desired data.
The bank sends the data to the consortium.
The consortium routes the data to the ATM.
Figure 3.5: Scenarios of Transmit data
vi. Adding variation and exception scenarios:

Once scenario is prepared, consider “special” cases, such as omitted input, maximum and minimum values,
and repeated values. Then consider error cases, including invalid values and failures to respond.
Finally, consider various other kinds of interactions that can be overlaid on basic interactions, such as help
requests and status queries.
ATM example: Some variations and exceptions follow
§ The ATM can’t read the card. § The machine is out of cash or paper.
§ The card has expired. § The communication lines are down.
§ The ATM times out waiting for a § The transaction is rejected because of
response. The amount is invalid. suspicious patterns of card usage.
vii. Finding External Events:

To find all external events include all inputs, decisions, interrupts and interactions to or from users or external
devices.
An event can trigger effects for a target object. Internal computation steps are not events, except for
computations that interact with the external world.
Use scenarios to find normal events, but don’t forget unusual events and error conditions.

ATM Example: Figure
3.6 shows a sequence
diagram for the
process transaction
scenario.
Figure 3.7 summarizes

events with the arrows
indicating the sender
and receiver but not
showing event
Figure 3.6: Sequence diagram for the process transaction scenario.
parameters.
Figure 3.7: Events for the ATM case study
viii. Preparing Activity Diagrams for

Complex Use Cases:
Activity diagrams let you consolidate all
this behavior by documenting forks and
merges in the control flow.
It is certainly appropriate to use activity
diagrams to document business logic
during analysis, but do not use them as
an excuse to begin implementation.
Figure 3.8 shows, when the user inserts
a card, there are many possible responses. Figure 3.8: Activity Diagram for Card Verification

ix. Organize actors and Use Cases:
Organize use cases with relationships
(include, extend, and generalization). It is
especially helpful for large and complex
systems.
Figure 3.9 organizes the use cases for ATM
with the include relationship.
Figure 3.9: Organizing use cases

x. Checking against the Domain Cass Model:
The application and domain models should be mostly consistent. The actors, use cases, and scenarios are all
based on classes and concepts from the domain model.
Cross check the application and domain models to ensure that there are no inconsistencies.
3.2 Application Class Model:

Application classes define the application itself, rather than the real-world objects that the application acts
on. Most application classes are computer-oriented and define the way that users perceive the application.
You can construct an application class model with the following steps.
• Specify user interfaces. • Determine controllers.
• Define boundary classes. • Check against the interaction model.
i. Specify User Interfaces:

Most interactions can be separated into two parts: application logic and the user interface.
A user interface is an object or group of objects that provides the user of a system with a coherent way to
access its domain objects, commands, and application
options.
During analysis the emphasis is on the information

flow and control, rather than the presentation format.
The format of inputting the information for the

commands and invoking them is relatively easy to
change, so work on defining the commands first.
Figure 3.10 shows a possible ATM layout.

Figure 3.10: Format of ATM interface

ii. Define Boundary Classes:
It is often helpful to define boundary classes to isolate the inside of a system from the external world. A
boundary class is a class that provides a staging area for communications between a system and an
external source.
A boundary class understands the format of one or more external sources and converts information for
transmission to and from the internal system.
ATM example: It would be helpful to define boundary classes (CashCardBoundary, AccountBoundary)
to encapsulate the communication between the ATM and the consortium.
iii. Determining Controllers:

A controller is an active object that manages control within an application. It receives signal from the
outside world or from objects within the system, reacts to them, invokes operations on the objects in the
system, and sends signals to the outside world.
In the application class model, however, you should capture the existence of the controllers in a system,
the control information that each one maintains, and the associations from the controllers to other objects
in the system.
Consider the example, Normal Scenarios for each use case on ATM that has two major control loops.
The outer loop verifies customers and accounts. The inner loop services transaction.
iv. Check against the Interaction Model:

Once we build the application class
model, go over the use cases and
think about how they would work.
When the domain & application class
models are in place, you should be
able to simulate a use case with the
classes.
ATM example: Shows a preliminary
application class model and the
Figure 3.11: ATM application class model
domain classes with which it interacts.
3.3 Application State Model:

Application state model focuses on application classes and enhances the domain state model. Application
class are more important than domain classes.
Identify application classes with multiple states and use the interaction model to find events for these classes.
Then organized event sequences for each class with a state diagram.

Next check various state diagram to make sure that common events match. Finally check state diagram
against the class and interaction model.
So, to construct application state model with following steps:
• Determine application classes with states. • Check against other state diagram
• Find events • Check against the class model
• Build state diagram • Check against the interaction model.
i. Determining Application Classes with States:

Identify classes that are prominent to users and important to the operation. Consider each application class
and determine which one have multiple states. User interface classes and controller classes are good
candidate.
In contrast, boundary classes are less likely to be involved in state model.
ii. Finding Events:

From prepared scenario, extract events. Don’t overlook common interaction and highlights the major
events.
Difference between domain and application processes for state model.
Ø With Domain model, first we find states and then we find events. Because its focus on data.
Ø With Application model, first we find events and then states.
ATM example: We revisit the scenario from the application interaction model. Some events are: Insert card,
enter password, end session and take card.
iii. Building State Diagram:

Next step is to build state
diagram for each application
class. Choose any one of these
classes and consider a sequence
diagram for it.
Now find the events from that.
The interval between any two
events is a state. Give each state
a name. Then merge other
sequence diagrams into the state
diagram.
Now finds loops within the
diagram. If a sequence of events
can be repeated indefinitely then
they form a loop. Once loops
found, merge other sequence
diagram and look for alternative
path. Figure 3.12: State diagram for SessionController

Another alternative is to partition a state diagram into two concurrent sub-diagrams, using one sub-diagram
for the main line and other for distinguishing information.
ATM Example: Figure 3.12
shows the state diagram for the
SessionController. The middle
of the diagram has the main
behavior of processing the card
and password. A communication
failure can interrupt processing
at any time. The ATM returns the
card upon a communication
failure, but keeps it if there are
any suspicious circumstances.
After finishing transaction,
receipt printing occurs in
Figure 3.13: State diagram for TransactionController
parallel to card ejection, and the
user can take the receipt and
card in any order.
Figure 3.13 and Figure 3.14
show the state diagram for the
TransactionController that is
spawned by the
SessionController. Here, The
SessionController focuses on
verifying users, while the
TransactionController services
account inquires and balance
changes.
Figure 3.14: State diagram for Transfer
iv. Checking against other State Diagrams:

Check state diagram for each class. Every event should have sender and receiver, occasionally the same
object. Follow the effects of input event from object to object to make sure that they match scenarios.
Example: SessionController initiates the TransactionController, and the termination of the
TransactionController causes the SessionController to resume.
v. Checking against the Class Model:

Similarly, make sure that the state diagrams are consistent with the domain and application class models.
ATM example: 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. We will not resolve the details here
vi. 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 by hand and verify that the state diagram gives the correct behavior.

If error discovered, change state diagram or scenarios. Don’t assume that the scenarios are always correct.
If not, then modify the state diagram.
ATM example: As best as we can tell right now, the state diagrams are sound and consistent with the
scenarios.
3.4 Adding Operations:

Till now we did not focus on operations because the list of useful open-ended and it is difficult to know when
to stop adding them.
Following are source through which we can add operations:
§ Operations from Class model § Shopping-List Operations
§ Operations from Use Cases § Simplifying operations.
4 Operations from Class Model:

To add operation, note down attributes values and links implies by Class model because it does not show
explicitly. During analysis all attributes and association are assumed to be accessible.
4 Operations from Use Cases:
To add operation, we are using use cases. Most complex functionality of a system comes from its use
cases. During the construction of the interaction model, use cases lead to activities. Many of these
correspond to operations on the class model.
4 Shopping-List Operations:
Shopping list Operations are not dependent on particular application but are meaningful in their own right.
ATM Example:
Ø bank.createSavingAccount(customer): account
Ø bank.CreateCheckingAccount(customer): account
Ø bank.createCashCardAuth(customer): cashCardAuthorization
Ø cashCardAuthorization.addAccount(account)
Ø cashCardAuthorization.remove Account(account)
Ø account.close()
Ø cashCardAuthorization.close()
4 Simplifying Operations:
Study class model for similar operation and variations in form on a single operation.
Use inheritance where possible to reduce the number of distinct operations. If needed then only introduce
New superclass. Locate each operation at correct level within the class hierarchy.

Questions
Q. No
1. What do you mean by system conception? What are the ways to find new system conception?
2. Elaborate and explain the questions to be answered for a good system concept.
3. What are the high-level questions to elaborate the initial systems concept? Hence explain with the
help of ATM case study.
4. What are the questions to be asked while preparing a problem statement? Discuss the same take
ATM case study.
5. What are the steps must be performed to construct a domain class model? Hence explain all the
steps, in brief.
6. Explain the steps to construct a domain class model.
Discuss the steps to construct a domain class model, with an example ATM.
What is a domain class model? What are the steps to construct a domain class model?
7. Explain the steps in eliminating unnecessary attributes? Write the class diagram for ATM by
adding attributes.
8. Write in detail, the “Finding associations and keeping the right association in domain class
model”.
9. Explain in detail the “Finding classes and keeping the right classes in domain class model”, with
an ATM example.
***Similarly read all steps which are required to construct domain class model.****
10. Write and Explain the steps performed in constructing a domain state model.
11. Explain the steps to construct an application interaction model.
Discuss the steps to construct an application interaction model with an example.
List and explain the different steps to construct an Application interaction model.
12. Explain the steps to construct an application state model.
Discuss the various steps to construct the Application State Model.
13. What is Application State Model? Explain the steps to construct the Application Class Model.

System Conception: Chapter - 1

Uploaded by

Copyright:

Available Formats

System Conception: Chapter - 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Conception: Chapter - 1

Uploaded by

Copyright:

Available Formats

Module – 3 System Conception and Analysis

1.1. Devising a System Concept:

1.2. Elaborating a Concept:

By: Rajatha S, Dept. of MCA RNSIT 1|26

è The ATM Case Study:

Ø Who is the application for?

Ø What problems will it solve?

By: Rajatha S, Dept. of MCA RNSIT 2|26

1.3. Preparing a Problem Statement:

By: Rajatha S, Dept. of MCA RNSIT 3|26

By: Rajatha S, Dept. of MCA RNSIT 4|26

2.1 Overview of Analysis:

The statement may be

The problem statement should

2.2 Domain Class Model:

By: Rajatha S, Dept. of MCA RNSIT 5|26

Figure 2.2 shows, begin by

è Keeping the Right Classes:

By: Rajatha S, Dept. of MCA RNSIT 6|26

Figure 2.5: Eliminating unnecessary classes from ATM problem

By: Rajatha S, Dept. of MCA RNSIT 7|26

è Keeping the Right Associations:

§ Irrelevant or implementation associations: Eliminate any association that deals with

By: Rajatha S, Dept. of MCA RNSIT 8|26

iv. Find attributes of objects and links:

è Keeping the Right Attributes:

By: Rajatha S, Dept. of MCA RNSIT 9|26

Figure 2.8: ATM class model with attributes

v. Organize and simplify classes using inheritance:

By: Rajatha S, Dept. of MCA RNSIT 10|26

Figure 2.9: ATM class model with attributes and inheritance

vi. Testing Access Paths:

vii. Iterating a Class Model:

There are several sings of missing classes.

By: Rajatha S, Dept. of MCA RNSIT 11|26

Figure 2.10: ATM class model after further version

viii. Shifting the Level of Abstraction:

Abstraction makes a model more

By: Rajatha S, Dept. of MCA RNSIT 12|26

2.3 Domain State Model:

i. Identifying Classes with States:

ii. Finding States:

By: Rajatha S, Dept. of MCA RNSIT 13|26

iv. Building State Diagrams:

v. Evaluating State Diagrams:

2.4 Domain Interaction Model:

2.5 Iterating the Analysis:

By: Rajatha S, Dept. of MCA RNSIT 14|26

i. Refining the Analysis Model:

ii. Restating the Requirements:

iii. Analysis and Design:

By: Rajatha S, Dept. of MCA RNSIT 15|26

3.1 Application Interaction Model:

• Determine the system boundary. • Add variation and exception scenarios.

i. Determine the System Boundary:

ii. Find Actors:

By: Rajatha S, Dept. of MCA RNSIT 16|26

iii. Find Use Cases: