Event partitioning

Event partitioning is an easy-to-apply systems analysis technique that helps the analyst organize requirements for large systems into a collection of smaller, simpler, minimally-connected, easier-to-understand "mini systems" / use cases.

System context diagram for a fictitious hotel. (By convention, bidirectional flows, with arrows at both ends, are often used when a dialogue is initiated externally. For example, "booking dialogue" contains the flow "booking request", which is the initial trigger; "booking confirmation", the result, is sent back.)

Overview

The event-partitioning approach is explained by Stephen M. McMenamin and John F. Palmer in Essential Systems Analysis.[1] A brief version of the approach is described in the article on Data Flow Diagrams (DFDs). A more complete discussion is in Edward Yourdon's Just Enough Structured Analysis.[2] 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 Unified Modeling Language (UML), is an "actor".

Event partitioning topics

Actor → Event → Detect → Respond

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" (or working with actor representatives), brainstorm a list of the "external events" / "triggers" that they want the system to have a planned response to. (Note that the system cannot originate external events; only an actor can.)
  • 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 (called "temporal" events by M&P, and distinguished by them from external events)
  • 4. Identify the planned response(s) that the system may carry out when the events occur. It's the response(s)/use case(s) 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.[3]

"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?' " [4] [emphasis added]

Data dictionary notation

Yourdon/DeMarco style of data dictionary notation may be used to describe the composition and structure of data.

Symbol Meaning
= "contains", "is", or "is composed of"
+ "and", "as well as", or "together with" (not arithmetic "plus")
[x ; y ; z] ) may be used to separate items in the list.
m{x}n or
m:n{x} or
 "from m to n iterations of x". If m or n is not specified, then the lower or upper limit is simply "unknown" or "unspecified". Multi-dimensional arrays may be specified by nesting, e.g., 10 { 10 { x } 10 } 10 defines a two-dimensional matrix of 10 rows with 10 columns.
(x) "optionally x". This is equivalent to 0{x}1 or 0:1{x} or .
@ prefix for an identifier within an iteration. For example, in {@i+@j+x} i and j are identifiers.
* ... * Anything between single asterisks is regarded as a comment. At the data element level, a comment may contain such type tags as "range :", "limits :", "precision :", "unit :" or "values :".

The data structure elements can map to structured programming′s control structures:

NB. The items defined may be "material" (e.g., room key) as well as "data" (e.g., arrival date-time).

Identifying Requirements and Their Reasons

The event-response information may be captured in a table. The event is the raison d’être for the response, which gives "traceability" from the response back to the environment.

1. Actor 2. External Event / Trigger 3. Detected by 4. Response(s) / Use Case(s)
Guest Guest requests a room of a certain type, for a particular arrival date, departure date, at a certain rate, etc. booking request +
(payment validation) +
(*external reservation system* booking confirmation) [5]		 Book Room (may include guaranteed booking, alternate hotel booking, waitlisted booking)
Guest Guest asks to cancel room booking. cancellation request [6] Cancel Booking
Guest Guest arrives at hotel. arrival message = * *
     = [guest name ; booking reference] [7]		 Check in Guest
Time / Scheduler Guest fails to arrive at hotel. [This is a "non-event" event.] 11 pm (local time) [A "non-event" event is detected by the arrival of a point in time, a deadline.] Create Guest Bill,
Update Booking
Guest Guest asks to check out of hotel. check-out request = * *
     = [guest name ; room number] [8]		 Create Guest Bill,
Update Room Occupancy
Time / Scheduler Guest fails to check out of hotel. [This is a "non-event" event.] 11 am (local time) [A "non-event" event is detected by the arrival of a point in time, a deadline.] Create Guest Bill
Guest Guest offers payment of bill. payment vehicle = * *
     = [cash ; cheque ; credit card ; debit card] + (guest id) [9]		 Accept Guest Payment
Time / Scheduler Time to prepare Room Occupancy Report for previous night. 8 am (local time) Report on Room Occupancy
Hotel Manager Hotel Manager requests Room Occupancy Report. occupancy report request Report on Room Occupancy
Smoke / CO Alarm Alarm detects smoke. smoke alarm message Report Smoke Alarm
Smoke / CO Alarm Alarm detects CO (carbon monoxide). CO alarm message Report CO Alarm

Defining requirements
Single process in a fictitious hotel using data flow diagram notation.
Single use case in a fictitious hotel using use case diagram notation.

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 all at once (often a page or less). The intention is to reduce one of the risks associated with short-term memory, namely, forgetting what is not immediately visible ("out of sight, out of mind").

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 an activity diagram, a sequence diagram, or a communication 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.

Complexity versus fragmentation

If the response is lengthy or complex (i.e., more than a page of text), an analyst may decompose ("factor out" or deduplicate) into smaller "secondary use cases" to keep the "parent" primary use case smaller and simpler. These secondary use cases may prove to be reusable as well. (In a UML use case diagram, they would be drawn as extended or included use cases, which are related to one or more primary use cases.)

While describing a use case, an analyst may also uncover "business rules". Some analysts suggest capturing business rules in a separate document using the Object Constraint Language or some other formal notation. Then when a business rule must be obeyed in a use case, the analyst makes reference to it. This minimises repetition [10] within a specification, but risks fragmentation of a specification. One technique that may reduce this tension is to use hyperlinks in the specification document.

This reductionist approach lies somewhat in contrast to a systems thinking approach as represented by Peter Checkland's soft systems methodology.

In addition to functional requirements captured in a use case description, an analyst may include such non-functional requirements as response time, learnability, etc.

See also

References
  1. MCME-84: McMenamin, Stephen M.; John F. Palmer (1984). Essential Systems Analysis. Prentice-Hall (Yourdon Press). ISBN 0-13-287905-0. (ISBN 978-0-13-287905-7)
  2. YOUR-89: "yourdon.com - Just Enough Structured Analysis, Chapters 18, 19". 1989. Archived from the original on 2007-02-14. Retrieved 2008-04-24.
  3. WARD-85: Ward, Paul T.; Stephen J. Mellor (1985). Structured Development for Real-Time Systems: Volume 2, Essential Modeling Techniques. Prentice-Hall (Yourdon Press). ISBN 0-13-854787-4. (ISBN 978-0-13-854787-5)
  4. WARD-85, pp. 38-39.
  5. booking dialogue = * *
         = *input* booking request + *output* booking confirmation
    booking request = * *
         = guest name + room type + (room facilities) +
           arrival date-time + departure date-time
    room type = * type of bedroom *
         = * values : [ single ; double ; family ] *
    room facilities = * booleans that indicate presence or absence of a facility *
         = television + radio + alarm clock + climate control + Internet access +
           telephone + refrigerator + mini-bar + toilet + sink + bath + shower + bidet
    arrival date-time = * *
         = date-time
    departure date-time = * *
         = date-time
    date-time = * ISO 8601 format *
         = year + month + day of month + 'T' + hour + minute >
  6. cancellation dialogue = * *
         = *input* cancellation request + *output* cancellation confirmation
  7. arrival dialogue = * *
         = *input* arrival message + *output* arrival packet
    arrival packet = * *
         = room key + room card + complimentary drink coupon
  8. check-out dialogue = * *
         = *input* check-out request + *output* guest bill
  9. payment dialogue = * *
         = *input* payment vehicle + *output* guest receipt
    guest receipt = * *
         = guest name + guest address + {charge detail} + charge total + (taxes) + amount due + amount paid
  10. see also Don't repeat yourself, also known as "DRY"
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.