Moreover, the UML coverage have been boosted in addition to significantly greater with this brand-new edition This pedagogy has been much better inside brand-new edition to add in sidebars. Moreover, Pressman provides a case study termed "Safe Home" over the book, gives the application of software engineering to an industry project New enhancements on the book likewise incorporate chapters around the Agile Process Models, Requirements Engineering, and Design Engineering.
This book have been totally kept up to date and possesses hundreds of brand-new references to software tools that address all important topics in the book This additional material to the book includes an expansion of the case study, which illustrates it with UML diagrams.
The Online Learning Center includes resources for both instructors and students such as checklists, categorized web references, Powerpoints, a test bank, and a software engineering library-containing over software engineering papers Post a Comment.
Details of the encryption layers are not discussed here. Figure 4 below Deployment Diagram 1 in the model illustrates these hardware elements.
It also illustrates the main software components that will exist in the system. The web server and web browsers are generic; the main software components then are the Control Software described below , and the device control software on each device not described here. The classes in this diagram are described below. Discussed later. This will contain an activation code and all devices initially added to the system.
Additional configurations can be created Duplicate Configuration use case to allow the homeowner to experiment with the system, set up temporary configurations e. There is an association from SafeHomeSystem that identifies the current configuration; this is changed during the Set Current Configuration use case.
Can be changed at any time. ActivationCode: Contains a simple integer identifying a code that is typed to arm or disarm the system Specify Activation Code use case. Different people can be given different codes, e. A future extension of the system would be to identify the time period during which certain codes are active. DeviceType: Maintains information about each type of device that may be installed in the system. Each Device has a DeviceType — information that is common to all devices of the same type is kept here.
Device: A representation of particular piece of hardware installed in the system. A device is installed by telling the user interface that it exists specifying its serial number and then powering it up the Add Device use case.
The software should then be able to detect its presence wirelessly. Cannot be changed. Unique for each device manufactured by SafeHome. May be left blank although this would make the system less informative and may be changed at any time.
The label might, for example, describe symbolically the location of a sensor or camera. Sensor: Represents a device that should trigger a reaction by the system if some condition becomes true a door is open, CO is detected, water is detected, motion is detected, fire is detected.
There can be several subclasses. SafeHome Architectural Model. AlarmSignaler: Represents a device that will sound an alarm. Camera: Represents a camera that can send images to the system, and can be panned and zoomed. Represents certain parameters set for that device in a particular configuration. These parameters are changed in the Change Device In Configuration use case. This can be used to divide the house into up to five zones e. The default is zero, meaning undefined zone.
An AlarmSignaler in zone 0 will always sound. An AlarmSignaler given a numbered zone will only sound if a sensor in that zone triggers the alarm. This is discussed more later. The default is true. The homeowner may want to set this to false for some devices — e. FloorPlan: Part of an optional feature of the system. The homeowner may set up several floor plans that can be looked at visually in the web interface — there would be one for each floor of the house.
These can be used, for example, to help him or her understand where a camera is pointing, etc. The floor plan has a set of devices each with its own FloorCoordinates and a set of Segments representing doors, walls, etc. Each appears differently visually when drawn in the user interface. FloorCoordinates: Specify the location in meters from the top-left corner of the FloorPlan although the homeowner does not have to draw the unit to scale if he or she does not want to.
Figure 6 is a simple activity diagram showing the top level behavior of the SafeHomeSystem class. When the SafeHome central processor is running, it must be able to do two things at once: Perform its main security monitoring functions and respond to configuration changes. For example, the system could be armed and detecting burglars at the same time as the homeowner is logging in from some external location via the web to change the active configuration e.
Figure 6: Top level activity diagram Figure 7 describes the behavior of the SafeHomeSystem class during the Monitoring activity of Figure 6. There are three possible values for its activationState attribute: CheckingSystem, Disarmed and Armed; the latter two are substates of NormalOperation — in which the system spends most of its time.
The system toggles backwards and forwards between Disarmed and Armed in response to user actions. Note that Figure 7 does not model the user interface — this is kept quite separate, as is good practice in software engineering and is discussed in the context of Figure 9. The successfulActivation and successfulDeactivation events are triggered by the user interface.
This is the deep history symbol; it means that after resetting, the system will go back to doing what it was doing before i. This is necessary to prevent the reset process from circumventing security. In this state the system has to respond to sensors by triggering alarms. Everything is normal while it is in this substate. We invite critique and suggestions for improvement. Quick overview of SafeHome SEPA describes much of the background of the SafeHome product line; we suggest you read the relevant sections of the book before proceeding.
We will, however, quickly set the scene: The SafeHome company has developed an innovative hardware box that implements wireless Internet The idea is to use this technology to develop and market a comprehensive home automation product line. This would ultimately provide not only security functions, but also would enable control over telephone answering machines, lights, heating, air conditioning, and home entertainment devices. The first generation of the system, described here, will only focus on home security since that is a market the public readily understands.
Key actors and use cases When fully developed the system envisioned by the SafeHome marketing team will implement hundreds of use cases. Figure 1 shows that there are there are two main actors roles played by users of the system : HouseholdUser and ConfigurationManager. The latter is a sub-actor of the former since ConfigurationManagers can do everything that HouseholdUsers can. The Arm System and Disarm System use cases both require the actor to specify an activation code.
The latter is shown as an inclusion use case. The use cases performed by the Configuration manager require a more sophisticated Log-In use case to be performed.
Figure 1: Use cases for release 1 of the system Figure 2 shows additional use cases that will need to be implemented in order to provide the functionality of changing configurations of the system.
For simplicity we have not shown the fact that each of these also includes the Log-In use case. There will also be a set of use cases for designing a room layout. These are not included for the time being. Packages for organizing the model The SafeHome model is arranged into a hierarchy of packages to help organize it. Figure 3 shows the packages. Each of the elements in the remaining sections of this document is arranged into one of the packages shown.
There is also a conceptual outer package, simply called SafeHome, that includes all of them. Hardware description. Before understanding the software architecture it is often best to first understand the hardware on which the software will run and with which it will interact. The CP software can run on any computer with an external broadband Internet connection or a modem, as well as an If both broadband and modem are installed, they can act as backups for each other.
The CP also acts as a wireless Internet base station for communication with the devices described below. The CP could run on any home PC; we assume however, that to ensure the integrity of the security system, the software would actually run on a dedicated computer — so crashes of other programs, viruses, etc.
This dedicated computer would have an uninterruptible power supply, but would lack such things as a video card, keyboard and screen, commonly found in a home PC.
Some of these are sensors e. Some are alarm signalers siren, flashing light, etc. Some are cameras that can send digital pictures to the CP, and can be panned or zoomed. It is the intent of the company that the line of devices would be expanded in the future, so the interface with the CP needs to be flexible to allow for innovation.
The devices need a power supply, and may have battery backups — details such as that are out of the scope of this document. The main thing to know at this point is that a significant number of devices can be purchased, installed physically and then configured with the software system so that the software system can communicate with them.
Like the devices described above, they communicate with the CP wirelessly. They allow for such basic functions as arming and disarming the system. Normally there would be one in the home near the front door, but there could be others e. However, in order to access the full functionality of SafeHome, its users must connect to the CP via a web browser. The CP runs a web server, accessible over its wireless connection or through the SafeHome corporate web site ; this provides the full user interface UI capability for the system.
The web UI is a superset of the capability available on the hardware control panels. Users who are traveling can have full access to their home system by connecting to the SafeHome corporate web site. Direct external connection to the CP is not allowed to help prevent denial-of-service attacks and other forms of hacking. Communication among all the above components is heavily encrypted to enhance security. Details of the encryption layers are not discussed here.
Figure 4 below Deployment Diagram 1 in the model illustrates these hardware elements. It also illustrates the main software components that will exist in the system. The web server and web browsers are generic; the main software components then are the Control Software described below , and the device control software on each device not described here.
The classes in this diagram are described below. Discussed later. This will contain an activation code and all devices initially added to the system. Additional configurations can be created Duplicate Configuration use case to allow the homeowner to experiment with the system, set up temporary configurations e. There is an association from SafeHomeSystem that identifies the current configuration; this is changed during the Set Current Configuration use case.
Can be changed at any time. ActivationCode: Contains a simple integer identifying a code that is typed to arm or disarm the system Specify Activation Code use case.
Different people can be given different codes, e.
0コメント