User:MaxHund/Event partitioning
From Wikipedia, the free encyclopedia
Event partitioning is a method for systems analysis that was created by Stephen M. McMenamin and John F. Palmer. The approach is explained 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 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. In particular, a business system exists to service the requests of customers. A customer, in the jargon, is an ‘actor’. The method has the following steps.
- Identify the external systems by brainstorming a list of the ‘actors’. Create a context diagram of the system under study.
- Putting oneself in the shoes of an ‘actor', list the goals (‘external events’ / ‘triggers’) that they want the system to help them achieve. The system has no control over the occurrence of the external events.
- Identify what will enable the system to detect the goals:
- the arrival of a piece of data (often in the form of a message)
- the arrival of a point in time
- Identify the planned response(s) that the system may carry out when the events occur.
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]
This information may be captured in a table.
| Actor | External Event / Trigger | Detected by | Response(s) / Use Case(s) |
|---|---|---|---|
| Hotel Guest | Guest requests a room of a certain type, for a particular arrival date, departure date, at a certain rate, etc. | booking request (data) | Book Room (may include guarantee), Waitlist Room |
| Sister Hotel's Reservation System | Sister Hotel reports availability of room. | booking request (data) | Book External Room |
| Hotel Guest | Guest requests cancellation of room booking. | cancellation request (data) | Cancel Booking |
| Hotel Guest | Guest arrives at hotel. | arrival message [guest name ; booking reference] (data) | Check in Guest |
| Time / Scheduler | Guest fails to arrive at hotel. [This is a 'non-event' event.] | 11 pm (local time) (time) | Create Guest Bill, Update Booking |
| Time / Scheduler | Time to prepare Room Occupancy Report for previous night. | 8 am (local time) (time) | Report on Room Occupancy |
| Hotel Manager | Hotel Manager requests Room Occupancy Report. | room occupancy report request (data) | Report on Room Occupancy |
| Hotel Guest | Guest asks to check out of hotel. | check-out request (data) | Create Guest Bill, Update Room Occupancy |
| Hotel Guest | Guest offers payment of bill | payment vehicle [cash ; cheque ; credit/debit card] (data) | Accept Guest Payment |
| Smoke Alarm | Alarm detects smoke in hotel. | smoke alarm message (data) | Report Smoke Alarm |
| Carbon Monoxide Alarm | Alarm detects CO [at x parts per million] in hotel. | CO alarm message (data) | Report Carbon Monoxide Alarm |
The level of detail of the responses is at the level of ‘primary use cases’. The basic flow of use cases can usually be described in a relatively small number of steps, often fewer than twenty or thirty. Ideally, all of the steps would be visible on one page or less.
If the response is more lengthy or complex, 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, then referenced in all use cases where they must be obeyed.
[edit] See also
[edit] External links
Edward N. Yourdon. Just Enough Structured Analysis, Chapters 18, 19
[edit] References
- McMenamin, Stephen M.; John F. Palmer (1984). Essential Systems Analysis. Prentice-Hall (Yourdon Press). ISBN 0132879050. (ISBN-13 978-0132879057)
- Ward, Paul T.; Stephen J. Mellor (1985). Structured Development for Real-Time Systems: Volume1, Essential Modeling Techniques. Prentice-Hall (Yourdon Press). ISBN 0138547874. (ISBN-13 978-0138547875)
