CHAP 11SYSTEM CONCEPTION

some ways to find new system concepts

NEW FUNCTIONALITY ;- add functionality to existing system

STREAMLINING :- remove restriction the way system work

SIMPLIFICATION:- let ordinary person perform task

AUTOMATION:- automate manual process INTEGRATION:- combine functionality from

different system GLOBALIZATION:-travel to other country &

observe their cultural & business practice

ELABORATING A CONCEPT Who is the application for?

understand which person & organization are stakeholder (financial sponsors & end user) for new system

financial sponsors are imp. bcs they are paying for system & expect the project to be success & within budget

user will determine success of system

WHAT PROBLEM WILL IT SOLVE determine which feature will be in new system &

which will not

WHERE IT WILL BE USED determine new system is complement of

existing system, it will be used locally or distributed via a network or it jus a new capability that you deploy without disrupting workflow

WHEN IS IT NEEDED? Feasible time;- the time in which system can be

developed within cost & resources required time:-when system needed to meet

business goals WHY IT IS NEEDED?

understand motivation for new system business case will give you insight what

stakeholders expect How it will work?

CHAP 12DOMAIN ANALYSIS

perform following steps to construct domain class model

find classes prepare data dictionary find association find attribute of objects & links Combine classes using inheritance verify that access paths exits iterate & refine model reconsider the level of abstraction group classes into packages

DOMAIN CLASS MODEL

find classes find classes for objects from application domain All classes must make sense in application

sense; avoid computer aspects only consider physical entities.

begin by listing classes found in problem statement, write down every classes that comes to mind.

ATM ex-software

Banking Network cashier ATM Bank

Bank computer Account Transaction

Cashier Station Account Data

Transaction DataCentral

ComputerCash Card Use

rRecei

ptSystem Security Provision Access Customer

Cost

Design a software to support a computerized banking network including both human cashiers & automatic teller machine(ATM) shared by consortium of banks. Each bank provides its own computer to maintain its own account & process transaction against them. Cashier stations are owned by individual banks & communicate directly with their own bank’s computer .Human cashier enter account & transaction data

ATM communicates with central computer. It accepts cash card, interacts with user, communicate with central system to carry out transaction, dispense cash & prints reciept.The system requires appropriate recordkeeping & security provisions. The system must handle concurrent access to same account correctly.

Bank provide their own s/w & you have to design s/w for ATM.the cost of shared system will apportioned to banks according to no. of customers with cash card

REDUNDANT CLASSES :- if two classes express same concept keep the most descriptive name

Ex:- customer describe person taking an airline flight, passenger is more descriptive

here Customer & user are redundant We retain Customer

IRRELEVANT CLASSES:- If class has little or nothing to do with problem eliminate it

Here Cost is outside the scope of ATM s/w VAGUE CLASSES :- A class should be specific. Some tentative class may have ill defined

boundaries Record keeping provision is vague & handled by

transaction

KEEPING THE RIGHT CLASSES

ATTRIBUTES :-Names that describes individual objects are attributes

Account data describes account. ATM dispenses cash & receipts that are peripheral to problem so treat it as attribute

OPERATION:- If a name describes operation applied to object then its not a class

Ex-telephone call is a sequence of action involving a caller & telephone network so call is a part of state model not a class

ROLES :- One physical entity corresponds to several classes.

Ex:- Person & employee for company database of employee are identical but for govt. tax database two are distinct. A person may hold more than one job

KEEPING THE RIGHT CLASSES

IMPLEMENTATION CONSTRUCTS:- eliminate extra constructs that needed later

during design but not now subroutine, algorithm, process ,data structure

are implementation constructs Ex:-Transaction log is set of transaction its exact

representation is design issue DERIVED CLASS:- class that can be derived fro

other class is a derived class

Banking Network

System

Security

Provision

vague

Customer

User

Redundant

Cost

Irrelevant

Account

Data

Transaction

Data

Cash Receipt

Attributes

software

Transaction Log

Access

Implementation

BAD

CLASSES

cashierATM

Bank

Bank computer

Account

Transaction

Cashier StationCentral Computer

Cash Card

GOOD

CLASSES

PREPARING DATA DICTIONARY Prepare data dictionary for al modeling elements &

describe scope of class, restriction on its use, associations, attributes, operations.

FINDING ASSOCIATION Reference from one class to another Ex-class person & company relate them with

Works for Means verbs or phrases – physical phrase (next

to, part of, contained), directed action , communication (talksto ), ownerships (has, part of ),some condition (worksfor, manages)

CRITERIA FOR KEEPING RIGHT ASSOCIATION

ASSOCIATION BETWEEN ELIMINATED CLASSES:- If you eliminate one class in association you must eliminate association

Ex:-eliminate Banking network includes cashier station & ATMs

IRRELEVANT / IMPLEMENTATION ASSOCIATION:-outside the problem domain or deals with implementation constructs

Ex :- System handles concurrent access is implementation concept

ACTIONS:-association describe structural property not an event for object

Ex:-ATM accepts card describes part of interaction between ATM & customer not a permanent relationship between them

TERNARY ASSOCIATION:- decompose most assoc. among 3 or more classes into binary association

Ex:- bank computer processes transaction against account can be broken into Bank computer processes transaction Transaction concerns account

DERIVED ASSOCIATION:- omit association that can be defined in terms of other association because they are redundant

Ex:- grandparent of can be defined in terms of pair of Parents of Classes, attributes & associations in class

model represents independent information. Multiple paths between classes indicates derived association

Although derived association do not add information ,they are useful in real world & in design

ATM

Central Computer

Consortium

1

1

1

*

Communicates with

Bank

1 0..1

Bank Computer

1 *

Communicates with

1

1

Account Customer

1 * * 1

Cashier

1

*

Employs

Cashier Station

1

*

Cashier Transaction

1 *

Entered On

1*

Entered By

Remote Transaction

1 *

EnteredOn

*

1

CashCard

* 1

AuthorizedBy

1

*

*

1

FINDING ATTRIBUTES Attributes are data properties of individual

objects. Attribute values should not be an class Only consider attributes directly relevant to

application. Be sure to give each attr. A meaningful name.

Omit derived attribute

0bjects:- if independent existence of element is important than is value consider it as object.

Ex:- Boss refers to a class & salary is an attribute

KEEPING RIGHT ATTRIBUTES

QUALIFIER:- if value of attribute depends on particular context consider it as qualifier

Ex:- employee no is qualifier NAMES:- name is an attribute when it does not

depend on context & it is not unique. Ex:- dept. name, person name IDENTIFIERS:- do not include attribute whose

only purpose is to identify an object Ex:- transactionID is not attribute INTERNAL VALUES:- if attribute describe internal

state of object then eliminate it Omit minor attribute that are unlikely to affect

most operation

REFINING WITH INHERITANCE Organize classes by using inheritance to share common

structure Inheritance can be added in two directions

By generalizing classes into super class By specializing existing classes into multiple

subclasses

BOTTOM-UP GENERALIZATION:-discover inheritance from bottom-up searching for classes with similar attributes, association & operation

Define a super class to share a common feature. Ex :- remote Transaction & CashierTransaction are

similar except initiation so they can be generalized by Transaction

TOP-DOWN SPECIALIZATION:- Look for noun phrases composed of various

adjectives on class name Ex:-fixed menu, pop-up menu, sliding menu MULTIPLE INHERITANCE:- Use it to increase sharing but only if necessary

because it increases both conceptual & implementation complexity

SIMILAR ASSOCIATION:- When same association name appears more than

once with same meaning generalize it

DOMAIN STATE MODEL [04] Objects passes through distinct states during

their lifetime. Describes various states of objects,

Properties & constrains of object in various state

Events that take object from one state to another

Steps for constructing a domain state model

IDENTIFY CLASS WITH STATE FIND STATE FIND EVENT BUILD STATE DIAGRAM VALUATE STATE DIAGRAM

IDENTIFY DOMAIN CLASS WITH STATE

Check list of domain classes for those that have distinct life cycle.

Identify significant states in life cycle of object Ex:- scientific paper for journal goes from

Being written Under consideration Accepted or rejected

ATM EX:-Account class has lifecycle & ATM depends on state of an account

FIND STATE List states for each class Give each state a meaningful name State should be based on qualitative difference

in behavior, attributes & association ATM Ex:- state for Account

Normal (ready for normal access) Closed (closed by customer but still on file in

bank records) Overdrawn (customer withdrawals exceed the

balance in account) Suspended (access to account is blocked for

some reason)

FINDING EVENTS Find event that causes transition among states. Consider those events that occurs within state

but do not cause transition You can regard event as do-activity Ex:- scientific paper for journal

ATM Ex:- close account, repeated incorrect PIN,

Administrative action

Under

consideration

Accepted or

rejected

Decision on paper reached

BUILDING STATE DIAGRAM Note state to which event applies. Add transitions to show change in state caused

by event. If a event has different effect in different state

add a transition for each state

Closed

Normal

Suspended

Overdrawn

Close account

Suspected

fraudRelease

holdRepeated

Incorrect

PIN

Withdraw excess fund

Deposit sufficient fund

ITERATING THE ANALYSIS

requires more than one pass to complete Problem statement often contain

circularities & can not approached in linear way because different parts of problem interacts

Prepare first model & then iterate it as your understanding increases

Verify final analysis with requestor & application domain expert

Refine the analysis model Overall analysis model shows inconsistencies &

imbalance. Try to refine classes to increase sharing &

improve structure. some constructs won’t fit in model; You

probably missed or miscast a general concept; reexamine them & change model

Include exception, special case Remove classes or association that seemed to

be useful at first but now appears extra; you can combine two classes in analysis can be combined

A good model have few small areas & don’t have extra details

RESTATING THE REQUIREMENTS Most of real requirements will be part of model

Other requirements specify method of solution & should be separated if possible.

During analysis some requirements may appear to be incorrect & impractical; confirm correction to requirements

Business expert verify it to make sure that it correctly models the real world

Final model serves as basis for system architecture, design & implementation.

ANALYSIS & DESIGN Goal of analysis is to specify the problem without

implementation details but it is impossible to avoid all taints of implementation

There is no absolute line between various development stage nor there is any such thing as a perfect analysis