Event partitioning

The goal of event partitioning is to be an easy-to-apply systems analysis technique for turning large systems into a collection of smaller, simpler, minimally-connected, easier-to-understand ‘mini systems’ / use cases. The approach is explained by Stephen M. McMenamin and John F. Palmer in "Essential Systems Analysis" (New York: Yourdon Press, 1984). A brief version of the approach is described in the article on Data Flow Diagrams. A more complete discussion is in Edward Yourdon's " [http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_18#CONSTRUCTING_THE_ENVIRONMENTAL_MODEL Just Enough Structured Analysis] ". The description focuses on using the technique to create data flow diagrams, but it can be used to identify use cases as well.

The premise of event partitioning is that systems exist to respond to external events: identify what happens in the business environment that requires planned responses, then define and build systems to respond according to the rules of the business. In particular, a business system exists to service the requests of customers. A customer, in the jargon of the UML, is an ‘actor’.The method has the following steps.
* 1. Identify the external systems by brainstorming a list of the ‘actors’ (external systems), which are the sources of external events. If you find a graphic to be helpful, create a context diagram showing the actors outside of the system under study and the flows / signals between them.
* 2. Putting oneself in the shoes of an ‘actor’, list the ‘external events’ / ‘triggers’ that they want the system to have a planned response to. The system has no control over the occurrence of the external events.
* 3. Identify what will enable the system to detect the external events:
** the arrival of one or more pieces of data (possibly in the form of a message)
** the arrival of one or more points in time
* 4. Identify the planned response(s) that the system may carry out when the events occur. It’s the response(s)/use cases that will enable the system to achieve its goals.

The technique was extended with ‘non-event’ events by Paul T. Ward and Stephen J. Mellor in "Structured Development for Real-Time Systems: Essential Modeling Techniques" (New York: Yourdon Press, 1985),

“Since the terminators [actors] are by definition outside the bounds of the system-building effort represented by the model, the implementors cannot modify the terminator [actor] technology at will to improve its reliability. Instead, they must build responses to terminator [actor] problems into the essential model of the system. A useful approach to modeling responses to terminator [actor] problems is to build a list of ‘normal’ events and then to ask, for each event, ‘Does the system need to respond if this event "fails to" occur as expected?’ ” [emphasis added]

The event information may be captured in a table.

This approach helps the analyst to decompose the system into 'mentally bite-sized' mini-systems using events that require a planned response. The level of detail of each response is at the level of ‘primary use cases’. Each planned response may be modelled using DFD notation or as a single use case using use case diagram notation.

The "basic flow" within a process or use case can usually be described in a relatively small number of steps, often fewer than twenty or thirty, possibly using something like ‘structured English’. Ideally, all of the steps would be visible on one page or less. Alternatively, using the notations of structured techniques, an analyst could create a ‘Nassi-Shneiderman diagram’. In the UML, the use case could be modelled using a sequence diagram, a communication diagram, or even an activity diagram. This could be problematic if there are many complex scenarios of the use case; the analyst may wish to model all or most of the scenarios.

If the response is more lengthy or complex (i.e., more than a page of text), an analyst may decompose (‘factor out’) into smaller ‘secondary use cases’ to keep the ‘parent’ primary use case smaller and simpler. While describing a use case, an analyst may also uncover ‘business rules’ that may be captured in a separate document using OCL or some other formal notation, then referenced in all use cases where they must be obeyed.

ee also

* Business case
* Use case
* User story
* Use case diagram

External links

Edward N. Yourdon. [http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_18#CONSTRUCTING_THE_ENVIRONMENTAL_MODEL "Just Enough Structured Analysis", Chapters 18, 19]

References

*cite book
first = Stephen M.
last = McMenamin
coauthors = John F. Palmer
year = 1984
title = Essential Systems Analysis
publisher = Prentice-Hall (Yourdon Press)
id = ISBN 0132879050 (ISBN-13 978-0132879057)
*cite book
first = Paul T.
last = Ward
coauthors = Stephen J. Mellor
year = 1985
title = Structured Development for Real-Time Systems: Volume1, Essential Modeling Techniques
publisher = Prentice-Hall (Yourdon Press)
id = ISBN 0138547874 (ISBN-13 978-0138547875)