Re: [AM] modelling the state of a service

(responding to Ian)

> I thought about a state diagram. Here are some of the issues
> I came up with:
>
> A state diagram represents the state of one object - what is
> the object? The service? What about the component pieces?
> A service is made up of lots of components each with its
> own state - do I use composite states?
> How do I model the situation where if a process on one node
> fails the service is still available but if it fails on two nodes the
> service is unavailable? i.e. one event of a type is ok, two is
> not, unless we've recovered in the meantime.

I've done this sort of thing a couple of times before.  Each
service to a client depends on zero or more other services,
and each service has one or more clients.  The clients
want information that means something to them.

This means that each service in the network has its own
state machine, and the state it's in depends on its own
state and the states of services it depends upon.  Yet
the state the client is interested in will probably need
less detail.  The client may only be interested in
'Working' or 'Not Working', or he may be interested
in other potential states.  One system I worked on
reported several states; { Working, Reduced Throughput;
Reduced Functionality; Reduced Both; Emergency
Shutdown; Not Available } and if things got worse, it
failed to report at all.  These were states that caused
different client behaviour, so were of interest to the
client.

Sometimes, different clients want different information;
in this system, one monitoring client wanted to know
when there was no fault-tolerance capacity left in
the supplier services to this service - e.g. unless
both suppliers of a service (or at least two) were
reporting 'Working', the service reported 'Not Fault
Tolerant' to the monitoring client.

Guidelines - keep a state machine on each node of the 
service network; let the client needs drive what states 
get reported; let the need for reporting these states 
drive what states are recorded internally.  Report 
changes of state only when it would result in changed
behaviour on the part of the client.  If he can't respond
differently he doesn't need to know.

The problem is complex, but don't make it harder than 
it needs to be by trying to cut corners.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------