3.3.3 Object Oriented Analysis, Design, and Implementation
CHART II is a complex system, integrating text, graphics, pictures, sound, and video. It will operate in a distributed multimedia environment where multiple CHART workstations and traffic devices are connected to the MDOT enterprise network along with several database servers that provide transparent access to multiple sources of data. Such a complex environment necessitates the use of a software analysis, design, and implementation approach that can handle complex data and data relationships, accommodate the movement from a centralized to decentralized architecture, and provide for the simultaneous connection to multiple heterogeneous databases. The obvious answer is the use of Object Oriented Analysis, Design, and Implementation (OOAD&I).
OOAD&I is a relatively new approach to system analysis, design, and implementation. Until recently, no single standard had emerged for documenting OOAD&I. However, in the last several years a unifying standard called the Unified Modeling Language (UML) has emerged. UML consists of a standard set of diagram types that lead the systems analysts, designers, and implementers from requirements through user-system interactions and to completed designs and systems.
A very tight connection exists between a completed UML design and actual software code development. Moreover, since a single process will be responsible for generating the initial version of all programs, this connection ensures that programs are built in a consistent style. It enables the programmers to move from one area to another without the extra burden of needing to learn different programming styles from programmers who had previously worked on the code. It will also save time and money, both in development and debugging and maintenance phases.
New Computer Aided Software Engineering (CASE) tools are available that assist with UML diagram generation, code generation from diagram models, and "round-trip" engineering. Round-trip engineering is a process wherein change in the model can be reflected in the code, and code changes can be reflected in the model. Automated code generation from CASE tools has a number of benefits. It can speed the initial development time by automatically generating the code framework. It can also ensure that all approved objects and components of the design are skeletally included in the system code. For the initial design phase of CHART II, a CASE tool called ObjectTeam® was used.
The use of OOAD&I is very much in concert with MDSHA needs on the CHART II project. The CSC/PBFI Team guarantees that MDSHA will be involved in every step of the CHART II design, and the team is committed to an iterative requirements generation and implementation process. "Round trip" engineering can help in this process by ensuring that the design and the developed product are in sync. As CHART II is being developed and prototyped, new ideas will emerge that change some of the original concepts. These new ideas will typically be reflected in either the programs or the design. Historically, the system changes are not captured in both the programs and the design, or if they are, they are not consistent. A "round-trip" engineering function will enable both types of generation. If the code is changed, the model can be regenerated without losing notes or customizations that typically would not be included in the programs. If the model is changed, the programs can be regenerated without overwriting program comments and customizations.
Each major element in the system will be developed as one or more individual components. Each component will be replaceable without shutting down the system, which will allow easy upgrades and corrections to specific elements of the system without affecting any other element of the system. This approach eliminates system downtime for upgrades and maintenance of software elements.
Another advantage to the use of OOAD&I techniques is that objects that code designers and developers work with are documented in a way that is familiar to ITS operators, managers, and CHART systems staff. Unfamiliar and arcane computer science terminology in the design material is replaced with terminology familiar to the user. This further ensures successful systems through more meaningful communications between user and developer, communications that stay consistent throughout the systems life cycle.
Clearly, the use of OOAD&I and components in the implementation of the CHART II system has distinct advantages over other approaches. It meets MDSHA’s needs for a process that provides the flexibility to accommodate the inevitable changes generated from the iterative design process, system prototyping, and direct MDSHA involvement in the design process. Since it is the same methodology that the CSC/PBFI Team is using for AVCM development on the CHART network task, our team members and staff know how to use this methodology and have already hit the ground running with it for the CHART II system.