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