Description of Building Management System The design and implementation of the Building Management System was produced to illustrate

how a rigorous object analysis can specify domain requirements in detail and remain independent of implementation, while at the same time bounding functionality and establishing a partitioning framework upon which design and implementation can proceed and be successful. The final result is a working, interactive program that provides you the direct experience of owning and managing your own office building! We are making available now the design and implementation documents we produced in this process, including the following: BMS Design ( BMSDesign.zip ) - A Rational/Rose model file which contains updates to the analysis model necessary to get Rose to generate code frameworks from the model. - A description of major design decisions that affect the software object infrastructures - The initial C++ source code generated by Rose from our design model (*) - This description file (*) Our example does not illustrate the full extent of capabilities for code generation from Rose. Our intention was simply to illustrate a mapping of UML model constructs into major C++ features and structures, and to perform the minimum amount of design modeling necessary to produce code from the model and at the same time set a framework for the rest of the design. BMS Implementation (BMSEXEC.zip ) - The running executable BMS program and required .dll files - Program User instructions - Final source code that program is linked with divided into 2 categories 1. Code for classes from Building Management Domain OOA 2. Code for all other domains that were ultimately included in this example, like GUI, Access Privileges, etc - This description file

Major Design Decisions Domain Partitioning Our goal was to parallel the analysis partitioning for classes and domains as much as possible in the design so the illustration of the process would be clear. As a result, all the classes from the original OOA of the Building Management domain have a corresponding class in the implementation. However because the implementation of our example is really only pretending to turn lights on and off, or to command real HVAC hardware, all of the other hardware related domains such as the Sensor, Device Interface, Phone Line Communications, and Magnetic Media Management domains have been substituted with a GUI equivalent for the purposes of demonstration and portability of this example to a home or office PC. So commands to Copyright Esprit Systems Consulting, Inc PO Box 1486 West Chester, PA 19390 610-436-8290 fax 610-436-9848 www.EspritInc.com esprit@EspritInc.com

Copyright Esprit Systems Consulting, Inc PO Box 1486 West Chester, PA 19390 610-436-8290 fax 610-436-9848 www.EspritInc.com esprit@EspritInc.com

HVAC or Lighting System hardware, for example, show up as outputs to the user program window to indicate function completion as specified in the OOA output to those actor classes. Another example is that sensor-based derivation of the Room.Thermostat Setting value, which would normally be calculated through an Analog Sensor object conversion algorithm, is being updated through a GUI transaction. Functionality partitioned into the Access Privileges domain, which controls user permission to perform various transactions, has been implemented by a special menu command called Identity, which allows the user to actively change roles in the domain, thereby enabling or disabling command options under the selection menu for that role. Identity Verification has been implemented as an extra step when the user requests to change their role to Employee. The user must select a particular Employee instance which they intend to be. Once selected, their identity is considered as verified as if they had passed a retina scan or knew their own badge pin number, and remains so until the user decides to change their role to another Employee instance. Threads of Control In the design of the program, two threads of control were created to run concurrently from the perspective of the user. The first thread interacts with the user to input data for externally detected events and carries out their responses with calls to Building Management class operations. The second thread handles detecting and responding to temporal based events such as Set Point execution and Lease Expiration. Of course, the Lease class, for example, encapsulates data and operations used in both threads, yet all are found within the Lease class definition. That is the essence of object development. The organization of the code is around the object, while the objects operations can be used in multiple functional threads. Attribute Data and Data Structures All attributes from the OOA model became private data members for the corresponding class, with the exception of the Timer Id. In analysis, the Timer Id attribute was a placeholder for the potential concurrent timing each Set Point and Lease instance was performing for its own lifecycle execution. In our design, the timing thread is simply looping over the class instances in search of time-out situations by comparing date/time attributes against the system clock. The notion of a real data item to store a pointer value to an instance of a Timer class has been optimized away. The data structure, or container class, which stores the actual set of instance data values for each class was implemented as an instantiation of the Carray template, which was then designated a private static data item for each class accordingly from the OOA model. This was chosen for ease of mapping from the analysis, and does not necessarily represent the most performance-efficient design possible. In generalization (inheritance) class hierarchies, the container structure was allocated to the superclass when functions queried all subclass intances without regard for subclass membership (Set Point, in this case), and was allocated to the subclasses when the instance sets were queried differently based on subclass membership (Zone and Section, in this case). Association link data was implemented by preserving the Id qualifier attributes modeled in the analysis, and using them as private data members in the instance structure. Conversion to pointers after initialization would have made the execution of operations more efficient, but would have made the capability to save and restore instance data sets from previous program runs much more difficult, because pointer values, Copyright Esprit Systems Consulting, Inc PO Box 1486 West Chester, PA 19390 610-436-8290 fax 610-436-9848 www.EspritInc.com esprit@EspritInc.com

which are virtual memory locations, have no meaning outside the context of the local program memory. A combination of both strategies could have solved both problems, but was not an achievable goal given our development schedule. Persistence To make experimenting with the executable program easier and more interesting over time, we wanted users to be able to start with a default set of Rooms, Zones, and Room Entrances (essentially a brand new, just built, building), and be able to save their new instance data for other classes and continue running on those instance sets on future executions of the program. As a result, three class data persistence strategies were developed and then used on the appropriate classes. Strategy 1) The class initializes with a hardcoded set of initial instances by invoking the constructor operation in a loop at program start. This default set of instances never changes because the instance set is constant. The Room and Room Entrance classes use this strategy. Short of physically constructing an addition to the office building, this information will not change. Of course, the current state of any Room instance may be updated over time, but no new Rooms will be created at run time, nor will any be deleted. Strategy 2) The class initializes with a default set of instances as described in strategy 1. However, if a previous run is loaded into the program, this initial set is deleted completely, and the set from the previous run is used as a replacement. The Zone class uses this strategy. Zone instances can be created and deleted at run time, and it is the result of these changes that are being preserved and stored externally from the program whenever a save is requested. Strategy 3) The instance set remains empty at program start. Only by loading in instance data preserved from a previous run of the program does the class instance set get initially populated. Again, instances can be created and deleted at run time, and then preserved for future use by requesting a save. All other classes used this strategy. Functional Mapping to Operations The general strategy for mapping the behavioral (state diagrams) and functional (state actions) requirements to the implementation is as follows: 1. Unique class event names from state models became public instance operations 2. States from state diagrams became private instance operations. 3. Transitions from state models became logic in event operations to decide whether an event should be ignored or actually result in invoking the state operation to effect a state change. 4. State actions became logic executed in state operations. In some cases, this general strategy was modified: - transition logic optimized away when event was self-directed by an instance to effect an automatic transition to the next state. - common functional pieces of different action blocks in the same class, or functional subsets of larger algorithms may have been factored out into their own private functions within the class. Copyright Esprit Systems Consulting, Inc PO Box 1486 West Chester, PA 19390 610-436-8290 fax 610-436-9848 www.EspritInc.com esprit@EspritInc.com

Copyright Esprit Systems Consulting, Inc PO Box 1486 West Chester, PA 19390 610-436-8290 fax 610-436-9848 www.EspritInc.com esprit@EspritInc.com