2.1 Object Orientation with UML

The Unified Modeling Language™ (UML) is used to express the constructs and relationships of complex systems. It was created in response to a request for proposal (RFP) issued by the Object Management Group (OMG), the organization that owns the UML standard. Dozens of people from many different companies worked on the UML and several calendar years went into its creation. The OMG accepted it as a standard in November 1997. The success of the UML is unprecedented; it has been widely adopted and used in the creation of all kinds of systems, including real-time and embedded systems. These systems range from the small (e.g., cardiac pacemakers) to the large (e.g., fighter aircraft) and from the mundane (e.g., printers) to the exotic (e.g., spacecraft frameworks). Systems in many vertical markets, including telecom, office automation, factory automation, robotics, avionics, military, medical, and automotive, have been modeled in the UML and implemented. I have consulted with companies building widely different systems all created with the UML and found that with the proper and intelligent application of the UML, they have been able to make significant (30% to 80%) improvements in time-to-market, quality, and reusability of corporate intellectual property (IP). All done with the UML, as it is specified in the standard, without modification or extension.^[1]

^[1] I don't mean to imply that merely the adoption of UML will improve productivity. There have been some notable failures in the adoption of UML. The successful adoption of any new technology requires willingness, thoughtfulness, and perseverance on the part of the adopter.

That having been said, there exist a number of extensions to the UML. Some are proprietary extensions, claiming to offer some improvement in this way or that. Others are standardized extensions, in the form of a UML "profile" a specialized version of the UML that is extended in only small ways to make it more applicable to some particular subject domain. In my role as cochair of the Real-Time Analysis and Design Working Group (RTAD) within the OMG, I have even participated in the creation of some of these extensions. Nevertheless, I stand by my assertion that the UML is completely sufficient for the modeling and creation of real-time and embedded systems. What the profiles have done is simply to codify a particular way in which the UML has been used. For example, the UML Profile for Schedulability, Performance and Time (also called the Real-Time Profile, or RTP) [3], does little more than codify what developers were already doing in UML to capture real-time and performance aspects of the systems they were creating. Profiles like the RTP enable better exchange of models, particularly between modeling creation tools, such as Rhapsody^®, and schedulability analysis tools, such as RapidRMA^™.^[2] The RTP is the subject of Chapter 4.

^[2] RapidRMA is a schedulability analysis tool available from Tri-Pacific Corporation, www.tripac.com.

As of this writing the UML standard is 1.5 [1].^[3] However, work is almost completed for a major revision to the UML, version 2.0 [2]. A submission from the U2P consortium, of which I-Logix was a key contributor, was adopted in the spring of 2003. The submission is now undergoing finalization. At this time, the expectation is that the new version will be released in the spring of 2004. The metamodel and notations for the UML 2.0 submissions are fairly stable at this time, although there may be small deviations from what is ultimately released as the new standard.

^[3] The management of "point" releases of the UML is done by a revision task force (RTF) whose mandate is to fix defects and which is not allowed to introduce fundamentally new concepts to the UML. Thus, UML 1.x versions are all highly similar and have no significant semantic differences.

UML is more complete than other methods in its support for modeling complex systems and is particularly well suited for real-time embedded systems. Its major features include

• Well-defined object model for defining system structure

• Strong dynamic modeling with modeling of both collaborative and individual behavior

• Support for different model organizations

• Straightforward representation of concurrency aspects

• Models of physical topology (deployment)

• Support for object-oriented patterns to facilitate design reuse

Throughout this book, these features will be described in more detail and their use shown by examples. This chapter explores the structural aspects of the UML at the fine- and coarse-grained abstraction level.