Domain state model Domain interaction model analysis and design

1. DOMAIN STATE MODEL
Raghukumar D.S

2. Introduction
• Some Domain objects pass through
connected distinct states and each state has
different constraints and Association or
multiplicities
• The state diagram describes the various
states that object can assume and their
properties and Constraints in all and the
events take in each state

3. • Most Domain classes do not require State
diagrams
• Described by list of operations
• Minority of classes that do exhibit distinct
states
• However , a state model can help
understanding their behaviour

4. Domain State Model Steps
First
-Identify the Domain class with states
Second
-Find the states
Third
-Find events
Fourth
-Build State diagrams
Fifth
-Evaluate state diagrams

5. Identify the Domain class with states
• Examine the list of domain classes for those that
have a distinct life cycle
• Look for the classes that can be characterized by the
progressive history or that exhibit cycle behavior
• Identify the significant state in the cycle of an object
• Not every state occur in every circle ,but the life
object is cycle
• ATM: state of an account

6. Finding States
• Each states characterize the objects in each
class on basis of attribute value that object
may have
• Associations may participates in and their
multiplicities ,attributes and associations are
meaningful in certain states only
• Try to describe the state
• Don’t focus on destination , particularly based
on small ,medium ,big . Because states based
on qualitative difference in behavior
• ATM: Accounts types

7. Finding Events
• Finding events that cause transition among the
states and think about stimuli that change the
state
• In many cases, you can regard an event as
completing a DO-activity
• We can find other events by thinking about
taking object in to a specific state
• There are additional events that occur within a
state and do not cause a transition but in D S M
we should focus on events that should cause
transition among the states
• ATM:: incorrect pin ,closing account

8. Building State Diagrams
• Note the states which each events applies
and add transitions to show the change in
state that caused by occurrence of event
• If an event terminates a state : it will usually
have a single transition from that state to
another
• If an event initiate a target state : then Add
transition from those states to target state
• Consider the possibility of using a transition
on enclosing state rather than adding a
transition from each substate to the target
state

9. • If an event has different effect in different states
then add a transition for each state
• There is no transition consider the meaning of
an event in states
• If ignored or everything fine or error ? Then add
transition to error state
• If something effect then you add new state
(discovering new State)

10. Evaluating State Diagrams
• Examine each state model . Are all states
connected ?
• Pay attentions to paths and check it for
1. represents cyclic class ?
2. Presence of main loop
3. Is any dead state terminate cycle
ATM :model for Account

11. DOMAIN INTERACTION
MODEL

12. • The interaction model is seldom important
for domain analysis
• During domain analysis the emphasis is on
key concept and deep structural
relationships and not the users view of
them
• However ,is a important aspect of
application modelling

13. ITERATING THE ANALYSIS

14. Learning Objectives
• The problem statements often contain
circularities and most applications cannot be
approached In linear model
• 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
understand increase

15. REFINING ANALYSIS MODEL
• The overall analysis model may shows
inconsistence and imbalance within and
across models. Iterate the different portion
to produce a cleaner
• Try to refine classes to increase sharing and
improve structure
• Reexamine the fully when wont seem to fit in
right
• Common difficulty is a physically object that
has two logical aspects

16. • Remove the states first look fine but now
appear extraneous
• If doesn’t affect the rest of model in any way
then two classes can combined
• A good model feels right and does nt appear
to have extraneous detail

17. Restating the requirements
• 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. you may have some performance
constraints and these should be stated be
stated clearly
• Should verify the final model with requestor

18. Analysis and Design
• The goal of analysis is to specify the
problem fully without introducing a bias
to any particular implementation
• If it is impossible in practice to avoid all
taints of implementations
• Don’t treat the rules we have given too
rigidly
• ATM: no further changes to ATM model at
this time

19. THANK YOU FOR YOUR TIME