PSARE, H/H/P, and Object-Orientation
In the PSARE book, we introduced some features to make the architecture model directly compatible with object-oriented techniques. These features are Architecture Message Diagrams and Module Inheritance Diagrams, both introduced in Section 4.2 of the book, and Class Diagrams, introduced in Section 4.3.2. In addition, we identified Statecharts as a specific option for inclusion in Control Specifications, as described in Section 4.3.4 of the book. Since Statecharts represent sequential Finite State Machines, they were always a viable option for CSPECs, but making them specific to the H/H/P Methods aligns the methods more closely with the UML.
These added features are sufficient to interface the architecture model in the system layers with OO representations in the software layers, but since the UML has become the representation of choice for OO software development, we need to define specific mappings from H/H/P constructs to UML constructs. We'll present these mappings in this region of the web site. As we do so, we'll illustrate the use of these mappings in the online case study, and we'll discuss them in the forum.
As a prelude to defining the mappings, it is worth noting some of the similarities and differences between H/H/P and the UML.
The newly added features of H/H/P, described above, provide the most obvious similarities between the two techniques. Since architecture modules, flows, and interconnects were always user-definable, these similarities always existed, but the new features make them more specific. What remain to be defined are the mappings between H/H/P and the various diagram types of the UML
Event-driven H/H/P requirements models and the UML's Use-Case Diagrams represent another similarity between the techniques, which we'll build upon. The two concepts are almost identical, differing only in some notational details.
The most obvious difference between the techniques is that H/H/P was developed specifically for multi-disciplinary physical systems, whereas UML is a combination of software-specific methods. Consequently, H/H/P, notably the Architecture Model, is very physical in nature, with representations of physical interconnects and the information, material, and energy that traverses them, whereas the UML is much more abstract in nature, consistent with the abstract nature of software.
There is also a significant difference in the manner in which the two techniques were conceived. One of the founding principles of H/H/P was simplicity, realized in part by using as few symbols and diagram types as possible, with clear and simple interrelationships. The UML, on the other hand, took the three source techniques and simply bundled them together into a large set of symbols and diagrams, with complex interrelationships. Another founding principle of H/H/P is the separate representations of requirements, architecture, and the links between them; the UML does not have such a clear separation.