Module 3 : Process Overview,

System Conception and Domain

Analysis
PROCESS OVERVIEW
 Development Stages

 System conception.Conceive an application and formulate tentative requirements.

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

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

 Waterfall Model
 Lean model
 Iterative Model
 Iterative Incremental Model
 Spiral Model
 V-Model
 Prototype Model
 Big Bang Model
 DevOps methodology
 Agile Model
SYSTEM CONCEPTION
System Conception

System conception deals with the genesis of an application. Initially some person, who understands both
business needs and technology, thinks of an idea for an application. Developers must then explore the idea to
understand the needs and devise possible solutions. The purpose of system conception is to defer details and
understand the big picture—what need does the proposed system meet, can it be developed at a reasonable cost,
and will the demand
for the result justify the cost of building it?
 Devising a System Concept
 Elaborating a concept
 Preparing a Problem Statement
Devising a System Concept

 Most ideas for new systems are extensions of existing ideas

 A new system can also be a radical departure from the past.
Devising a System Concept

How 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.
Elaborating a Concept

Most systems start as vague ideas that need more substance. A good system concept must answer the following
questions.
 Who is the application for?
 What problems will it solve?
 Where will it be used?
 When is it needed?
 Why is it needed?
 How will it work?
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
 The system is considered as a black box
 Design decisions are engineering choices that provide the behavior specified by the requirement
Preparing a Problem Statement

 Frequently customers mix true requirements with design decisions. Usually this is a bad idea. If you separate
requirements from design decisions, you preserve the freedom to change a design. Typically there are many
possible ways to design a system, and you should defer a solution until you fully understand a problem.
 A system concept document may include an example implementation. The purpose of the example is to
show how the system could be implemented using current technology at a reasonable cost. It is a “proof of
existence” statement. However, make it clear that the sample implementation could be done differently in the
final system. The sample implementation is merely proposed as a possibility
Preparing a Problem Statement
Preparing a Problem Statement

 Frequently customers mix true requirements with design decisions. Usually this is a bad idea. If you separate
requirements from design decisions, you preserve the freedom to change a design. Typically there are many
possible ways to design a system, and you should defer a solution until you fully understand a problem.
 A system concept document may include an example implementation. The purpose of the example is to
show how the system could be implemented using current technology at a reasonable cost.
 It is a “proof of existence” statement. However, make it clear that the sample implementation could be done
differently in the final system. The sample implementation is merely proposed as a possibility
Preparing a Problem Statement

 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 a system architecture.
 Avoid describing system internals, as this restricts development flexibility.
 Performance specifications & protocols for interaction with external systems are legitimate requirements.
 Software engineering standards, such as modular construction, design for testability, and provision for future
extensions, are also proper.
 A system concept document may include an example implementation. The purpose of the example is to
show how the system could be implemented using current technology at a reasonable cost. It is a “proof of
existence” statement. However, make it clear that the sample implementation could be done differently in the
final system. The sample implementation is merely proposed as a possibility
The ATM Case Study

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
The ATM Case Study

Who is the application for?

What problems will it solve?
Where will it be used?
When is it needed?
Why is it needed?
How will it work?
The ATM Case Study
The ATM Case Study

 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
computer 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 recordkeeping and security provisions. The system must handle concurrent accesses to the same
account correctly.
 The banks will provide their own software for their own computers; you are to design the software for the
ATMs and the network. The cost of the shared system will be apportioned to the banks according to the
number of customers with cash cards.
Domain Analysis
Domain Analysis

 Domain analysis : devising a precise, concise, understandable, and correct model of the real world.
 Before building anything complex - understand the requirements.
 Requirements can be stated in words, but these are often imprecise and ambiguous. During analysis, we
build models and begin to understand the requirements deeply
 How: Interview business experts, examine requirements statements, and scrutinize related artifacts.
Overview of Analysis
Domain Class Model

 The domain model shows the static structure of the real-world system and organizes it into workable pieces.
 The domain model describes real-world classes and their relationships to each other.
 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.
 Consider all information that is available and do not rely on a single source.
Domain Class Model

 Find classes.
 Prepare a data dictionary.
 Find associations.
 Find attributes of objects and links.
 Organize and simplify classes using inheritance.
 Verify that access paths exist for likely queries.
 Iterate and refine the model.
 Reconsider the level of abstraction.
 Group classes into packages.
Domain Class Model

 Finding Classes
 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 assignments, and payment schedules.
 All classes must make sense in the application domain; avoid computer implementation constructs, such as
linked lists and subroutines.
 Not all classes are explicit in the problem statement; some are implicit in the application domain or general
knowledge
Domain Class Model

 Finding Classes
Domain Class Model

 Keeping the right Classes

 Redundant classes.
 Irrelevant classes.
 Vague classes.
 Attributes.
 Operations.
 Roles.
 Implementation constructs
 Derived classes
Domain Class Model

 Keeping the right Classes

Domain Class Model

 Preparing a Data Dictionary

 Write a paragraph precisely describing each class.
 Describe the scope of the class within the current problem, including any assumptions or restrictions on its
use.
 The data dictionary also describes associations, attributes, operations, and enumeration values
Domain Class Model

 Preparing a Data Dictionary

Domain Class Model

 Finding Associations
 A structural relationship between two or more classes is an association.
 A reference from one class to another is an association.
 Keeping the Right Associations
Domain Class Model

 Finding Associations
 A structural relationship between two or more classes is an association.
 A reference from one class to another is an association.
 often correspond to stative verbs or verb phrases.
 These include physical location (NextTo, PartOf, ContainedIn), directed actions (Drives), communication
(TalksTo), ownership (Has, PartOf), or satisfaction of some condition (WorksFor, MarriedTo, Manages).
 Extract all the candidates from the problem statement and get them down on paper first;
 Don’t try to refine things too early.
 Again, don’t treat grammatical forms blindly; the idea is to capture relationships,
Domain Class Model

 Finding Associations


Domain Class Model

 Keeping the Right Associations

 discard unnecessary and incorrect associations
 Associations between eliminated classes.
 Irrelevant or implementation associations
 Actions
 Ternary associations, Derived associations, Misnamed associations
 Association end names, Qualified associations
 Multiplicity
 Missing associations
 Aggregation
Domain Class Model

 Keeping the Right Associations

Domain Class Model
Domain Class Model

 Finding Attributes
 Data properties of individual objects, such as weight, velocity, or color.
 Attribute values should not be objects; use an association to show any relationship between two objects.
 Usually correspond to nouns followed by possessive phrases, such as “the color of the car” or “the position
of the cursor.”
 Adjectives often represent specific enumerated attribute values, such as red, on, or expired.
 Will not be fully described in the problem statement
 draw on your knowledge of the application domain and the real world to find them
 find attributes in the artifacts of related systems
 Do not carry discovery of attributes to excess.
 Only consider attributes directly relevant to the application. Get most important attributes first & refine later.
Domain Class Model

 Keeping the Right Attributes

 Eliminate unnecessary and incorrect attributes with the following criteria
 Objects
 Qualifiers
 Names
 Identifiers
 Attributes on Associations
 Internal Values
 Fine detail
 Discordant attributes
 Boolean attributes
Domain Class Model

 Keeping the Right Attributes

Domain Class Model

 Refine with Inheritance

 Bottom-up Generalization
 Top-Down Specialization
 Generalization vs enumeration
 Multiple inheritance
 Similar association
 Adjusting the inheritance level
Domain Class Model

 Refine with Inheritance

Domain Class Model

 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?
 Think of questions you might like to ask.
 Are there useful questions that cannot be answered?
 check disconnected classes to make sure you have not overlooked any associations.
Domain Class Model

 Iterating a Class Model

 entire software development process is one of continual iteration
 If you find a deficiency, go back to an earlier stage if necessary to correct it
 Asymmetries in associations and generalizations
 Disparate attributes and operations on a class.
 Difficulty in generalizing cleanly.
 Duplicate associations with the same name and purpose
 A role that substantially shapes the semantics of a class.
Domain Class Model

 Iterating a Class Model

 look out for missing associations.
 Missing access paths for operations.

 Lack of attributes, operations, and associations on a class.

 Redundant information.

 Association end names that are too broad or too narrow for their classes.
 Need to access an object by one of its attribute values.
Domain Class Model

 Iterating a Class Model

Domain Class Model

 Shifting the Level of Abstraction


Domain Class Model

 Grouping Classes into Packages

 The last step of class modeling is to group classes into packages.
 A package is a group of elements (classes, associations, generalizations, and lesser packages) with a common
theme.
 Packages organize a model for convenience in drawing, printing, and viewing.

 Normally you should restrict each association to a single package, but you can repeat some classes in
different packages.

 Reuse a package from a previous design if possible, but avoid forcing a fit.
Domain Class Model

 Grouping Classes into Packages

 ATM example. The current model is small and would not require breakdown into packages, but it could
serve as a core for a more detailed model. The packages might be:
 ■ tellers—cashier, entry station, cashier station, ATM
 ■ accounts—account, cash card, card authorization, customer, transaction, update, cashier
 transaction, remote transaction
 ■ banks—consortium, bank
Domain State Model
Domain State Model

 Identify domain classes with states.

 Find states.
 Find events.
 Build state diagrams.
 Evaluate state diagrams.
Identifying Classes with States

 ATM example. Account is an important business concept, and the appropriate behavior for an ATM depends
on the state of an Account. The life cycle for Account is a mix of progressive and cycling to and from
problem states. No other ATM classes have a significant domain state model.
Finding states

 ATM example. Here are some states for an Account: Normal (ready for normal access), Closed (closed by
the customer but still on file in the bank records), Overdrawn (customer withdrawals exceed the balance in
the account), and Suspended (access to the account is blocked for some reason).
Finding Events

 ATM example. Important events include: close account, withdraw excess funds, repeated incorrect PIN,
suspected fraud, and administrative action.
Building State Diagrams

 Note the states to which each event applies.

 Add transitions to show the change in state caused by the occurrence of an event when an object is in a
particular state.
 If an event terminates a state, it will usually have a single transition from that state to another state.
 If an event initiates a target state, then consider where it can occur, and add transitions from those states to
the target state.
 Consider the possibility of using a transition on an enclosing state rather than adding a transition from each
substate to the target state.
 If an event has different effects in different states, add a transition for each state.
Building State Diagrams

 Once you have specified the transitions, consider the meaning of an event in states for which there is no
transition on the event.
 Is it ignored? Then everything is fine.
 Does it represent an error? Then add a transition to an error state.
 Does it have some effect that you forgot? Then add another transition.
 Sometimes you will discover new states.
 If the objects in the class perform activities on transitions, however, add them to the
 state diagram
Building State Diagrams

 ,
Evaluating State Diagrams

 Are all the states connected?

 Pay particular attention to paths through it.
 If it represents a progressive class, is there a path from the initial state to the final state?
 Are the expected variations present?
 If it represents a cyclic class, is the main loop present?
 Are there any dead states that terminate the cycle?
 ATM example. Our state model for Account is simplistic but we are satisfied with it. We would require
substantial banking knowledge to construct a deeper model.
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 users’
view of them.
 The interaction model, however, is an important aspect of application modeling
Iterating the Analysis

 Refining the Analysis Model

 Remove inconsistencies and imbalances within and across models
 Iterate the different portions to produce a cleaner, more coherent model.
 refine classes to increase sharing and improve structure
 Remove classes or associations that seemed useful at first but now appear extraneous
 A good model feels right and does not appear to have extraneous detail

 Restating the Requirements

 verify the final model with the requestor.

 Analysis and Design

Summary

 The domain model captures general knowledge about an application—concepts and relationships known to
experts in the domain

 The domain model has class models and sometimes state models, but seldom has an interaction model.

 The purpose of analysis is to understand the problem and the application so that a correct design can be
constructed.

 A good analysis captures the essential features of the problem without introducing implementation artifacts
that prematurely restrict design decisions