Description And Design Overview

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 besuccessful. 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 modelnecessary 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 toillustrate 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 classesand 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 hardwarerelated 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-9848www.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, isbeing 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. IdentityVerification 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...