System Conception

• Deals with origin of an application

• Devising a system concept
– New functionality
– Streamlining
– Simplification
– Automation
– Integration
– Analogies
– Globalization
• Elaborating a concept
– Who is the application for?
– What problems will it solve?
– Where will it be used?
– When is it used?
– Why is it used?
– How will it work?
• Preparing a problem statement
– Requirements statement that outlines goals and general approach of the desired system
• Requirements Statement
– Problem scope
– What is needed
– Application context
– Assumptions
– Performance needs
• Design
– General approach
– Algorithms
– Data structures
– Architecture
– Optmizations
– Capacity planning
• Implementation
– Platforms
– Hardware specifications
– Software libraries
– Interface standards
 Domain Analysis
• Concerned with devising a precise, concise, understandable, and correct
model of the real world
• Domain class model
– Describes real-world classes and their relationships to each other
• Steps to construct 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
Finding Classes
Keeping the right classes
• Preparing data dictionary
– Describes the scope of the classes including assumption
or restrictions
– ATM- a station that allows customers to enter their
own transactions using cash cards as identification. The
ATM interacts with the customer to gather transaction
information, sends the transaction information to the
central computer for validation and processing, and
dispenses cash to the user. We assume that an ATM
need not work independently of the network.
• Finding associations
– Structural relationship between two or more classes
– Example: ATM accepts cash card
 Keeping the right associations

• Discard the unnecessary associations using the following criteria

• Associations between eliminated classes
– Ex: ATM dispenses cash
• Irrelevant or implementation associations
– Ex: System handles concurrent access
• Actions
– Ex: ATM interacts with the user
• Ternary associations
– Bank computer processes transaction against account can be broken into Bank computer processes transaction
and Transaction concerns account
• Derived associations
– Associations that can be defined in terms of other associations
– Multiple paths between classes sometimes indicate derived associations that are composition of primitive
associations
– Ex: Consortium shares ATM is the composition of the associations Consortium owns central computer and
Central computer communicates with ATM
• Misnamed associations
• Association end names
• Multiplicity
• Qualified associations
• Aggregation
• Add Missing associations
• Finding Attributes
– Data properties such as color, weight
– Correspond to nouns
– Omit derived attributes
– Look for attributes on associations
• Keeping the right attributes
– Eliminate unnecessary attributes with the following criteria
• Objects
• Qualifiers
• Names
• Identifiers
• Attributes on associations
• Internal values
• Fine detail
• Discordant attributes
• Boolean attributes
• Refining with inheritance
– Bottom-up generalization
• RemoteTransaction and CashierTransaction can be
generalized by Transaction
– Top-up specialization
– Generalization vs enumeration
• ATM account could be refined into SavingsAccount and
CurrentAccount
– Multiple inheritance
– Similar associations
• Transaction is entered on both CashierStation and ATM;
EntryStation generalizes CashierStation and ATM
– Adjusting the inheritance level
• Testing Access Paths
– Ask questions such as
• 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
• Iterating a class model
– If there is a deficiency, go back to an earlier stage
if necessary to correct it.
• Shifting the level of abstraction
• Grouping classes into packages
 Domain State Model
• Steps performed in constructing a domain
state model
– Identify domain classes with states
– Find states
– Find events
– Build state diagrams
– Evaluate state diagrams
• Identifying classes with states
– Examine the list of domain classes for those that
have a distinct life cycles. Life cycles could be
– Progressive
• Ex: Scientific paper for a journal goes from Being
written to Under consideration to Accepted or Rejected
– Cyclic
• Ex: Airplane goes through the states of Maintenance,
Loading, Flying and Unloading.
– ATM example
• Account – Combination of progressive and cyclic
• Finding States
– Characterize the objects in each class – attribute
values, associations, multiplicities and so on
– States should be based on qualitative differenece
in the behaviour not on quantitative differences
– ATM example: 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
• Suspended – access to the account is blocked for some
reasons
• Finding Events
– Find events that cause transitions among states
– Completion of a do-activity can be regarded as an
event
• Ex: if a technical paper is in the state Under
Consideration then the state terminates when a
decision on the paper is reached
– ATM example: Important events include: close
account, withdraw excess funds, repeated
incorrect PIN, suspected fraud, and administrative
action
• Building state diagrams
• Domain Interaction Model
– Seldom important for domain analysis
– In domain analysis the emphasis is on key
concepts and structural relationships and not the
user’s view
• Iterating the analysis
– Iterative analysis is required to understand the
problem more clearly
– Refining the Analysis model
– Restating the Requirements