This document discusses domain state modeling. It explains that some domain objects pass through distinct states, each with different properties and constraints. A domain state model identifies classes with states, finds the states and events that cause transitions, builds state diagrams, and evaluates the diagrams. The document provides steps for domain state modeling and examples using an ATM machine to illustrate states like account types and events like incorrect PIN. It emphasizes iteratively refining the analysis model to improve consistency and structure.

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