DOMAIN STATE MODEL
Raghukumar D.S
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
• 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
Domain State Model Steps First
-Identify the Domain class with states Second
-Find the statesThird
-Find events Fourth
-Build State diagrams Fifth
-Evaluate state diagrams
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
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
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
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
• 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)
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 loop3. Is any dead state terminate cycle
ATM :model for Account
DOMAIN INTERACTION MODEL
• 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
ITERATING THE ANALYSIS
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
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
• 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
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
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
THANK YOU FOR YOUR TIME