|
|
|
|
|
|
|
All the windows and doors are alarmed, and there is a panic button on each phone and one next to the bed in the master bedroom. The grounds are alarmed as well, although these alarms are carefully calibrated so that they are not set off by small animals or birds. |
|
|
|
|
|
|
|
|
There is a central alarm system in the basement, which sounds a warning chirp when the alarm has been tripped. If the alarm is not disabled within a set amount of time, the police are called. If a panic button is pushed, the police are called immediately. |
|
|
|
|
|
|
|
|
The alarm is also wired into the fire and smoke detectors and the sprinkler system. The alarm system itself is fault tolerant, has its own internal backup power supply, and is encased in a fireproof box. |
|
|
|
|
|
|
|
|
New Term: In the conceptualization phase, you try to understand what the customer hopes to gain from the program: What is this program for? What questions might this simulation answer? For example, you might be able to use the simulation to answer the questions, How long might a sensor be broken before anyone notices? or Is there a way to defeat the window alarms without the police being notified? |
|
|
|
|
|
|
|
|
The conceptualization phase is a good time to think about what is inside the program and what is outside. Are the police represented in the simulation? Is control of the actual house alarm in the system itself? |
|
|
|
|
|
|
|
|
Analysis and Requirements. |
|
|
|
|
|
|
|
|
The conceptualization phase gives way to the analysis phase. During analysis, your job as object-oriented analyst is to help the customer understand what he requires from the program. Exactly what behavior will the program exhibit? What kinds of interactions can the customer expect? |
|
|
|
|
|
|
|
|
New Term: These requirements are typically captured in a series of documents. These documents might include use cases. A use case is a description of how the system will be used. It describes interactions and use patterns, helping the programmer capture the design goals of the system. |
|
|
|
|
|
|
|
|
High-Level and Low-Level Design |
|
|
|
|
|
|
|
|
Once the product is fully understood and the requirements have been captured in the appropriate documentation, it is time to move on to the high-level design. During this phase of the design the programmer doesn't worry about the platform, operating system, or programming language issues. He concentrates, instead, on how the system will work: What are the major components? How do they interact with one another? |
|
|
|
|
|