DESIGN VIEW is the summary of the complete DESIGN SOLUTION contributed article, which begins on Page 2.
There's much hoopla surrounding the upcoming UML 2.0 specification. Soon enough you will be able to take advantage of elaborated interfaces and ports, interaction fragments and operators, plus beter modeling of behavior over time. However, UML 2.0 is many months from being released in its final form—let alone being voted on and adopted. A number of questions are being raised about the spec due to conflicting reports. This article offers some answers.
Four related requests for proposals (RFPs) exist for the UML 2.0: Infrastructure, Object Constraint Language (OCL), XML Metadata Interchange (XMI), and Superstructure. The superstructure RFP is the one that most users (those who construct real models and build systems that work in the real world) will care about, since the proposal contains the most "user-visible" parts of UML 2.0.
Two main forces drive the RFP's requirements: scalability and architecture. Changes made for architecture in UML 2.0 primarily involve the structural (class) model, while changes for scalability are best seen in the improved sequence diagrams.
According to the RFP, UML 1.x notions of interface and architecture must be enhanced to support and simplify support for standard component frameworks and architectures. Moreover, data-flow modeling must be added, relationship semantics have to be clarified, and sequence diagrams need enhancing.
Discussion within the article focuses on structured classes, statechart inheritance, and sequence and timing diagrams. A series of figures help to illustrate these segments.
Though UML 2.0's final release is months away, some major features and characteristics are already known, giving users a preview to improved architectural modeling.
| HIGHLIGHTS: | |
| UML Superstructure | The superstructure RFP is driven by scalability and architecture. These concepts are important to define metaclasses that work well as they scale from small to large. |
| Statechart Inheritance | "Substitutability" is the crux of inheritance. That is, an instance of a subclass may be freely substituted for an instance of the superclass, and the system still makes sense and works. |
| Sequence Diagrams | UML 2.0's changes to sequence diagrams improve the diagrams' "spec-ness" (the ability to specify things) and their scalability. |
| Timing Diagrams | Sequence diagrams effectively show the sequence of service invocations, but they come up short as a view of actions over time. The author came up with more effective timing diagrams that were incorporated into UML 2.0. |
Full article begins on Page 2
There’s much hoopla about the upcoming UML 2.0 specification, even though it’s many months away from being released in its final form. Conflicting reports from a number of sources have confused users, and many of them are raising valid concerns: What is new in UML 2.0? Will my old models be compatible with the new UML? Is this feature or that feature in it? Vendor A says it’s UML 2.0-compliant. Can that be true with a standard that isn’t yet released? These are all good and valid questions.
Four related requests for proposals (RFPs) exist for the UML 2.0: Infrastructure, Object Constraint Language (OCL), XML Metadata Interchange (XMI), and Superstructure. The infrastructure RFP deals with the basis on which the UML is defined and the alignment with the MetaObject Facility (MOF), another OMG technology. The OCL RFP calls for improvements in the OCL. However, few users outside of those defining the UML actually use OCL. The XMI RFP specifies a format for exchanging semantic model information, yet at the moment, it doesn’t specify how to exchange diagrams. The XMI RFP requests an improvement to XMI that specifies ways to exchange diagrams.
Though those three RFPs are important and useful, they’re primarily for metamodelers, such as those defining the UML itself and for UML tool vendors. The fourth and last RFP—superstructure—is the one that most users (those who construct real models and build systems that work in the real world) will care about.
UML SUPERSTRUCTURE CONTENT At the highest level, the superstructure RFP requires the following:- Enabled modeling of structural patterns, such as component-based development and the specification of run-time architectures.
- Clarified semantics of the generalization, dependency, and association relationships.
- Support encapsulation and scalability in behavioral modeling. particularly for state machines and interactions.
- Restrictions removed from activity graph modeling due to mapping to state machines.
The RFP goes on to say that the UML 1.x notions of interface and architecture must be enhanced to support and simplify support for standard component frameworks and architectures. It also says that data-flow modeling must be added, and that many of the relationship semantics must be clarified. Moreover, the RFP notes that sequence diagrams are too limited in their expressiveness and semantics, so they ought to be enhanced. Also, activity diagrams should be semantically separated from state machines. Finally, the RFP requires proposals to clean up inconsistencies and errors in the UML 1.x specifications. In short, the superstructure requirements were to improve the ability and utility of the UML with respect to architecture and scalability. The RFP was issued in Sept. 2000, and called for a submission date of April 2001.
Oops. Okay, we missed that. The date was missed largely because of the strong desire to clean up the internal metamodel of the UML, its so-called "hairy underbelly." This created a high degree of "churn" in the internal structure of the submission. Concepts have been proposed, incorporated, and later discarded for another, presumably better, idea. We’re all after a better, simpler, more expressive, and more powerful UML. The submission has been adopted but is not yet released, pending a finalization process that will take many months. This means that it’s provisionally accepted and will now be subjected to a finalization effort that will require up to a year or more before releasing the UML 2.0 standard.
The superstructure proposal contains the most "user-visible" parts of the UML 2.0 proposal. Two forces drive the RFP requirements—scalability and architecture. These are related but distinct concepts. In particular, it’s important to define modeling concepts (metaclasses) that work well "in the small" and scale up to working well "in the large." We don’t want to have to suddenly switch to an entirely different set of concepts because we’re dealing with architecture and not something smaller. That would require a priori assumptions before work begins, which would be problematic in practice.
It’s far better to define a set of concepts that scale up to architecture than to define a separate set of concepts to deal exclusively with architecture. Still, the concepts are distinct. The changes in UML 2.0 for architecture are primarily in the structural (class) model, while the changes for scalability are best seen in the improved sequence diagrams.
STRUCTURED CLASSES The notions of Component and Subsystem are clearly architectural in scope. But how are they related to classes, and how do they relate to each other? The UML 1.x specifications are vague on these issues. In UML 2.0, we’ve introduced the concept of a Structured Class—a class that consists of parts with an explicit "nested" notation. The purpose is to model containment hierarchies, which are classes composed of "parts."Figure 1 shows a simple Rhapsody (a UML tool from I-Logix) class diagram that illustrates the UML 2.0 structured class concept. An "ElevatorCar" is made up of a number of parts. In this case, buttons, a list of destinations (and the destinations themselves), and a door. Similarly, a Floor class has a button to request elevators to go up or down and a position indicator for every elevator that goes to the floor. These are structured classes because they’re broken down into more primitive part objects. In all likelihood, the Door, ElevatorGnome, and Shaft classes are also structured classes, but their decomposition is shown elsewhere in the model.
Another addition for architectural modeling is the addition of ports, or instantiable connection points. Ports may optionally be used along with structured classes to allow "part" instances (those inside structured classes) to export out specific services or operations across the enclosing structured class boundary. The use of ports is a design pattern (see "ROOM Design Pattern" in Real-Time Design Patterns: Robust Architecture for Real-Time Systems, Addison-Wesley, 2002). As such, it presents pros and cons with respect to its usage. Nevertheless, UML 2.0 has elevated ports to first-order concepts even though their use is optional.
Figure 2a is a metaphor for using ports. A client wants to get a service performed by a server, who is a part of a service organization. He calls using his phone (a required port) to the secretary who is his only visible entity within the service organization. He points out that he has a contract that says he can request a service to be performed. The secretary acts as a relay to pass the request onto the server via the end port (terminating at the server).
Figure 2b is a corresponding UML model. The little boxes on the edge of the classes are the (optional) ports. The client’s "required" port is associated with the "required" side of the interface, while the service organization’s "offered" port is associated with the "offered" side of the interface. That is, clients may require interfaces on the part of servers; servers offer services via interfaces. The outer port is a relay port delegating the service request off to the server via its offered end port. So, the port is just a way to offer a specific series of services from an internal "part" object across the encapsulating structured class boundary.
Figure 3 shows a more-elaborate example that uses ports—a Smart Robot Arm. Note that "instance multiplicity," (the number of occurrences of the instance within the structured class) may be indicated either with the multiplicity in the corner, or inside of square brackets, such as the seven dc motors in the robot arm: DCMotor\[7\]. Note that while the diagram shows associations—internal class features such as attributes and operations, as well as generalization—these things needn’t be shown unless desired. The figure merely shows some of possibilities.
UML 2.0 expands the interface concept in two important ways. First, UML 1.x interfaces only allow for specifying the offered side, and that notation is kept. UML 2.0 also enables you to (optionally) specify the required (client) side as well—shown as the "socket." The complete ball-and-socket shows the same interface used both as a requirement and as something supplied.
Interfaces are enhanced in other ways as well. In UML 1.x, interfaces weren’t allowed to contain attributes or state machines. In the current proposal, UML 2.0 interfaces can have "virtual" attributes. Interfaces in UML 2.0 still aren’t instantiable, and when the standard specifies a set of attributes, it means that the realizing class must have those attributes. Further, one of the weaknesses of interfaces in UML 1.x was that there was no way to specify allowable sets of sequences of service invocations. We all know that many systems require certain sequences of services. Certainly, I’d much rather land a plane with the landing gear lowered prior to touchdown!
In UML 2.0, these operation-invocation sequences may be specified with protocol state machines. A protocol state machine is just like a normal state machine, except that it has limitations. It can’t have entry or exit actions, activities, internal transitions, history states, and so on. Its purpose is to specify allowable sets of operation services in interfaces. Components are a kind of structured class. Therefore, they can also optionally have ports and interfaces.
The notation for a component has changed slightly from UML 1.x. Now there’s a component icon in the corner, or a stereotype <>. The relationship between components and subsystems also is clarified in UML 2.0. A subsystem is a kind of component. Subsystems are usually "larger than" components and may contain components. You can specify the artifacts of a component or subsystem, such as the files that hold the executable code, in the "artifacts" segment of the component box, if desired. STATECHART INHERITANCE If you have a "reactive" or "stateful" class (that is, one with a statechart), you would naturally expect that any subclass of that class would also be reactive. Thus, you should somehow see the lineage from its parent. UML 1.x was vague on the issue. In UML 2.0, the approach taken by I-Logix was to specify what "inheritance of statecharts" means.What makes inheritance useful is the notion of "substitutability." That is, an instance of a subclass may be freely substituted for an instance of the superclass, and the system still makes sense and works. The rules for what you can do to an inherited statechart within a subclass takes this into account. You can extend by adding add new states, substates, and-states, transitions, and actions, and specialize by using polymorphic methods, reroute transitions, and modify actions lists. But you can’t delete transitions or states, or "re-parent" a state—that is, add a new composite state that owns the state.
SEQUENCE DIAGRAMS The changes to sequence diagrams were to accomplish two primary goals—improve their "spec-ness" (their ability to specify things) and improve their scalability. The most obvious changes reflect the latter goal. Sequence diagrams can be broken up into "interaction fragments," which may themselves be represented in the same or a separate diagram.While sequence diagrams look much the same as in UML 1.x, with lifelines, messages, and so on, there are some readily apparent differences. One is the five-sided box at the upper left-hand corner of the diagram (Fig. 4). This is the "operator" for the interaction fragment. In the diagram, we see "sd example." The operator sd names the fragment. We also see another sequence diagram nested within the larger one, with the operator "alt." Short for "alternative" (if/then/else), it applies to the nested fragment. If the guard evaluates to TRUE, then the upper part of that fragment is executed. Otherwise the "else" guard evaluates to TRUE and the lower part will be executed. This notation is much more useful than the branching notation in UML 1.x. But also note the recursive nature. An interaction fragment may contain other nested interaction fragments, each of which may have operators that apply to the entire (nested) fragment. The operators include:
sd — named sequence diagra
ref — reference to "interaction fragment"
loop — repeat interaction fragment
alt — selection
par — concurrent (parallel) regions
seq — partial ordering (default) (aka "weak")
strict — strict ordering
assert — required (that is, causal)
opt — optional "exemplar"
neg — "can’t happen" or a negative specification
The ref operator allows you to reference interaction fragments defined in their own separate diagrams.
Lifelines may also be decomposed as shown in Figure 5. In this case, the instance line "ServiceBase" can be decomposed in another diagram (shown slightly offset in the figure). The message entry and exit points, called "gates," allow tools to ensure that the diagrams are compatible and consistent with each other.
TIMING DIAGRAMS Sequence diagrams are very effective views for the sequence of service invocations. However, they are a suboptimal view of actions over time. To show time more effectively, I developed with timing diagrams (see Real-Time UML: Developing Efficient Objects for Embedded Systems, Addison-Wesley, 1998). These are now incorporated into the UML 2.0 proposal, with only minor changes. Figure 6 shows a simple timing diagram with state along the vertical axis and time along the horizontal. The values along the vertical axis are normally discrete, such as "state" or the values of some enumerated type. The timing diagram discrete value axis is quite general and any discrete valuable condition may be used, even a logic or arithmetic expression. The timing diagram also contains other elements from sequence diagrams, such as gates, messages, and constraints.
Figure 7 shows the coordination of multiple instances over time. The instances are separated via dashed lines and the states of all three instances can be shown over time.
For continuous values, two forms can be used. The default form is shown in the lower part of Figure 8. The value is "held" until the instant at which it changes. This is the default because for most discrete systems, this is exactly how they work. For physical processes and for systems engineering environments in which values can change continuously, the alternative form might be preferred. This alternative form is being recommended in the upcoming UML For Systems Engineering specification.
OTHER STUFF There’s much more to UML 2.0 than we’ve talked about here, but probably the most important thing to remember is that your UML 1.x models will remain completely valid in most cases. There’s been very significant redesign and re-redesign of the internal metamodel structure. This continues as technical details are hashed out, rethought, and hashed out again. Many small, and yet important (to some people), changes are being made to associations, association subsetting, merging actions and activities, and so on. The fundamental nature and expressiveness of the UML remains. However, three large-scale things must be briefly mentioned:
First, interaction overview diagrams have merged activity diagrams with sequence diagrams, allowing an activity diagram to serve as a "master chart" for a set of sequence diagrams. This allows you to construct a "map" of sequence diagrams and navigate easily among them.
Second, activity diagrams in UML 1.x have the same semantic basis as statecharts. In other words, they can say exactly the same things although they use a different notation. In UML 2.0, activity diagrams are now based on Petri net token-based semantics, rather then finite state automata, and are more expressive. While this is less important for computational algorithms, it aids in process modeling.
Finally, UML 2.0 now includes Flow Diagrams that can show data flow among structural elements (object roles). Note that this is similar to, but not the same as message flow on collaboration diagrams. But for those modelers who wish to do data-flow-diagram (DFD)-style models, you will be able to do this with the UML as illustrated in Figure 9.
The UML 2.0 has its basis firmly set upon UML 1.x. Most UML 1.x models are valid in UML 2.0 However, UML 2.0 has a number of significant, if incremental, improvements for architectural modeling. These include structured classes, elaborated interfaces and ports, scalability, interaction fragments and operators, and enhanced modeling of behavior over time. And let’s not forget timing diagrams. However, you don’t have to worry about these new features if you don’t want to. You can still build significantly complex systems using only three diagrams—class, sequence, and state diagrams.
While the final release of the UML 2.0 is still at least some months away, we know some of its major features and characteristics. And we—as developers of complex, next-generation real-time and embedded systems—have a lot to look forward to.
Bruce Powel Douglass is the chief evangelist at I-Logix Inc. (www.ilogix.com), Andover, Mass. He holds a PhD from the University of South Dakota in Vermillion. Douglass can be reached at [email protected].