Submit a requirements analysis and system design for the Acme Computerized Alarm Processing System (ACAPS) that is described below. Details for what to submit are given in the section “What to submit”
Here is a description of the ACAPS system that you are to design. Scenarios for ACAPS are given in the section “Scenarios”.
Acme Alarm Company is a central station monitoring company. They provide around the clock monitoring for both residential and commercial properties. Each property that is monitored has sensors like smoke and fire detectors, motion detectors, and intrusion detectors. Each property also has a control panel where the owner (or employees) can arm or disarm any of the sensors, as well as enable and disable all of the sensors EXCEPT the fire and smoke detectors.
Every property is divided into zones. Zones are used to identify different locations on the property. A sensor is assigned to one and only one zone.
The Plain Old Telephone System is used to send alarms from the property to the central station. When a sensor “fires”, it sends a signal to the control panel. The control panel then dials the central station and connects to a device we will call an alarm decoder (ADEC). The ADEC is capable of handling many calls simultaneously. We can assume that it never fails – that a call is never lost.
The information that is sent from the control panel to the ADEC is:
Acme has developed a hardware interface and I/O driver to connect the ADEC to a computer that supports the PC architecture. The I/O driver is designed to call a user supplied “event handler”. When the I/O driver gets an alarm from the ADEC, it calls the user supplied event handler and passes the 5 parameters listed above.
Operators will sit at PC displays that are connected to the system. When an alarm is received from the ADEC, it must be processed and sent to one of the active operator displays. When an operator sees the alarm on the PC, all of the information about the client is displayed to assist the operator.
To handle the alarm, the operator calls the people indicated for this alarm (police, fire dept, client contact, etc). The operator enters the names of the contacts they speak to and the PC system records the data and time. This information is then entered into an alarm history database when the operator selects the resolve alarm function.
Requirements (defined by ACME)
1. ACME has established the following rules for routing an alarm to a given display:
1.1.An operator must be logged in at the display.
1.2.If there is an operator with NO alarm on display at the moment, choose that one.
1.3.If all operators are handling an alarm, choose the operator with the fewest alarms queued.
1.4.Once the specific display has been selected, determine if the new alarm takes precedence over the alarms queued or on display. Precedence rules are as follows:
1.4.1. Fire
1.4.2. Door (or window) Open
1.4.3. Motion
1.4.4. Door (or window) Close
1.4.5. Within an alarm type, alarms are ordered as they arrive (FIFO)
2. To insure that an alarm does not go unprocessed for a long time, the system will monitor the time an alarm is on an operator’s alarm queue. If it is on the queue for more than a settable time, the alarm must be removed from the queue and routed to an administrator’s PC. The Administrator’s PC is always on.
3. When an alarm is taken from an operator’s alarm queue and displayed, the operator display PC must look up the necessary client information from the client database and display this information on the screen.
4. For legal reasons, ACME is required to retain a history of all received alarms. The system must record which operator handled the alarm, and any disposition information that the operator will record when handling the alarm.
5. An operator cannot determine the order of alarms that they handle. The PC system will decide the order. After an operator has completed handling of an alarm, the PC will present the next alarm on that operator’s alarm queue.
6. If an alarm having a higher priority than the alarm on display is received at an operator’s PC, then the current alarm state must be saved, and the new alarm must be displayed. When the new alarm has been handled (completed by the operator), the previous alarm must be restored to the operator’s display.
7. The alarm history must be maintained in persistent storage (database).
8. The system should allow for clients to be added and removed
9. The system should allow for operators to be added and removed.
10. The system should produce a number of reports. The reports should be run against the system database and should by pas the alarm processing system. ACME has requested that the database be implemented using one of the popular commercial-off-the-shelf database systems (Oracle, Sybase, etc).
11. The system should allow for the client base to increase in size by at least ten times the current number of clients.
12. An alarm should be handled (on display on an operator console) within two minutes of its receipt at the ADEC.
13. An operator may not log off if there are alarms on the operator’s queue.
14. The system must provide 99.95% up time.
15. Failures at an operator PC shall have no impact on the rest of the system
16. If the central alarm processor (the computer that is interfaced to the ADEC), it must be back up within 5 minutes.
17. The central alarm processor cannot lose state. If it fails or is otherwise restarted, it must “remember” the state of the operators alarm queues.
18. The system must not cost more that $1,000,000.00
19. The system must be in production with 6 months.
We are only interested in the application logic, not in the details of external systems such as database systems or display systems. In particular, you do not need to worry about how to display any operator information. Although you need not specify detailed content of messages sent to a display, you must specify the nature of the information (alarm, logon on screen, error message, etc).
You may submit your project material electronically (by email). The diagrams must be in a format that I can read. I recommend that you use the DIA product that I described on the class mailing list and make diagrams in PNG format (Portable Network Graphics). If you submit electronically please create a ZIP file (WinZIP) that contains your diagrams and written material and send the ZIP file as an attachment to me.
All text must be written using MS Word or be submitted in plain ASCII or RTF format (Rich Text Format).
Please include an email address for me to return you project grade.
You may also submit hard copy by bringing it to class on December 5th.
Please do not send me your projects by US Post!
Include one use case for every scenario, and any use cases not specifically described by a scenario but needed to support a requirement. Identify either the scenario or requirement but its number in this document.
Include one for each use case. Reference the use case by name. Identify Entity, Boundary, and Control objects using a stereotype (for example, <<entity>>).
Identify the objects and their associations, including direction and multiplicity. These objects should correspond to the objects named in the sequence diagrams. Provide the major operations and major attributes. Type is not required.
Answer these questions.
The client has requested that the Alarm system have a notion of “state”, that is, if it crashes at any particular moment, ACME requires that it be in the same “state” when it recovers. This means that the system must remember what the state of every PC is, and which alarms are on the alarm queues at each PC.
(1) How will you make this information persistent? Local disk files or as a set of tables in the system database (see requirement number 10)? Why? Argue strongly why you favor one over the other,
(2) Is there another approach to recovery of state? For example, could the system ask each PC to tell it what state it is in? Is this a good approach or bad approach? Why?
(1) An operator logs on.
John an operator sits down at a PC station where a system log in window is displayed. John enters an operator ID and a password. The system verifies that the John’s ID and password are valid by checking the system database. If the information is valid, John is presented with an alarm handling display, including the first alarm, if any exist.
(2) An operator logs off.
Mary, an operator, selects the log off function from the command menu. Since there are no alarms in Mary’s alarm queue, the system records the fact that the Mary is not logged on and places the PC in the log on state. The system removes this PC from the pool of operating alarm displays.
(3) Alarm from ADEC and at least one operator is available
The system alarm handling callback function is called by the ADEC interface. The alarm data is parsed and the system checks the state of logged on PCs. The system determines that John’s PC has no alarm on display and no alarms in its alarm queue. The system updates its information to show that an alarm is on John’s PC alarm queue, and sends a message to John’s PC containing the parsed alarm data.
(4) A PC with no alarm on display receives an alarm message from the system.
John’s PC currently shows no alarm on display and no alarm in the alarm queue. John’s PC receives a message from the system for a new alarm. The PC changes the display to present the alarm information to John. All information about the client and the type of alarm, including its location on the client premises is looked up in the database.
(5) An operator handles an alarm
John, having made the necessary calls to the proper authorities, records the information – name and title – about the person who responded to the call. John’s PC updates the system database to record the disposition of the alarm. The responding authority, date, and time are recorded in the history file, and a pointer to the history record is added to the client history record.
John’s PC, having another alarm on its alarm queue, gets the alarm from the alarm queue and sets up the display for the new alarm.
6) Alarm from ADEC and all operators are handling alarms.
The system alarm handling callback function is called by the ADEC interface. The alarm data is parsed and the system checks the state of logged on PCs. All PCs currently are handling alarms. The system searches the list of PCs to determine which PC has the fewest alarms on queue. The system determines that Betty’s PC currently has the smallest alarm queue. The system updates its information to show that another alarm is on Betty’s PC alarm queue, and sends a message to Betty’s PC containing the parsed alarm data.