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 object’s 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

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