Rational Rhapsody Tip #72 - Composite structure diagrams in Rational Rhapsody (Intermediate)

Happy New Year!

In this 4th in a series of slightly longer videos with narration, I explain how composite structure diagrams in UML 2.x work with a focus on their implementation in IBM Rational Rhapsody (they're actually called structure diagrams in Rhapsody). The video uses Rhapsody 8.4 but the core of the functionality has been around for a very long time. Related to this are are concepts of ports, parts and connectors and the idea that you can hierarchically decompose systems using structured classifiers, i.e. classes that own and connect parts. This video focuses on standard UML interfaces (I'll cover SysML Internal Block Diagrams in a later one). In this video I highlight the concepts with a model that mimics a pedestrian cross light sequence and I show how ports and interfaces support component-based design where you can plug-and-play different implementations of functionality provided the provided and required interfaces on connected ports are compliant.

Towards the end of the video I also show how it's possible to switch a property in Rhapsody called StructuredClassView so that the frame on the diagram represents the Classifier. This property is used by the SysML profile and is normally something you'd set up front before building the model. I also show how it's possible to switch the class symbol on a diagram to a structured view, in which the compartment of the class symbol acts like a composite structure diagram. This is useful when you want to show deep nesting on the same diagram. Anyway, hope it helps. If anybody has any questions about Rhapsody then feel free to get in contact.

In this 4th in a series of videos about diagram in the UML and Systems Modeling Languages, I'm going to cover composite structure diagrams; a key structure diagram in the 2005 revision of the Unified Modeling Language called UML 2.

Composite structure diagrams express the composite structure of classifiers, or more specifically structured classifiers.

Structured classifiers are typically classes. In Rhapsody they could also be actors or use cases, and they are called structured because they contain and connect the usages of other classifiers to form a static assembly of parts. Key to this are concepts of ports, parts and connectors that were also added in UML2; and that originated from other notations, predominantly a notation called ROOM or Real-Time Object-Oriented Modeling that underlay a tool called Rose RT.

These concepts focused on encapsulation and component-based design, enabling classes to be re-used and plugged-and-played together if the interfaces contracted on ports are compliant.They also enable hierarchically decomposition to any level, and hence have formed an important basis for successful language extensions to the UML such as the Systems Modeling Language.

I created this new traffic light training model last week with Rhapsody 8.4. As we look at it, the first thing to note is that composite structure diagrams are called just structure diagrams in Rhapsody, and the initial ‘composite’ word is left out. Rhapsody released its support for structured classes before the finalization of UML 2.0.

Secondly, ‘composite’ structure diagrams can be created underneath packages, as I’ve done here, or underneath a classifier. Note when I do this, that with default properties set, Rhapsody will put the classifier on to the diagram canvas when we create a structure diagram underneath it. In fact, creating them under the class is the approach I recommend.

Making sure you create the diagram underneath the classifier, rather than under a package, becomes more important when diagram frames come into play, but I’ll cover that later. First, let’s have a look at a composite structure diagram in this model. Here we can see the structured class called Light Assembly. It has two parts in it linked via contracted ports.

The RYG Assembly class here, has a port that is contracted to provide an interface that the controller requires. I can tell this from the lollipop-and-cup symbology emanating off the ports.
The connector here, is a link or connector between Parts, not between Classes and is owned by the class that contains these two parts.

So often I see people new to UML try and link ports together when the elements they are trying to link are classes.

This is not UML. In UML, there is a difference between Classifiers which define the properties, behaviors and ports of an element, and Parts which are usages of a Classifier. We can think of the class as being the defining rubber stamp, and parts as being usages of the stamp in a particular context.

If I return to the structure diagram, you can see these are parts because of the name. The text before the colon is the Part name, and the text after, is the Classifier. The Light Assembly class is used in a higher-level assembly of parts, in which a structured class called Traffic Light Domain connects together a part typed by a Light Assembly class with a part typed by an actor called User.

This supports hierarchical decomposition to any level. The Light Assembly is decomposed into Parts which may be further decomposed.

The symbol inside the structured compartment here tells us that the Port is behavioral and hence the classifier will realize the messages in provided interfaces.

The Tucan Controller is not therefore further decomposed. It has a state machine diagram that mimics a particular sequence of traffic lights in a type of UK pedestrian crossing called a Tucan; an evolution of an earlier version called a Pelican crossing.

Returning to the Light Assembly, the RYG Assembly class here, is further decomposed. Its port is a non-behavior port. It relays messages to an internal part that provides the concrete realisation of the interface which controls the lights.

The connectors to the red, yellow and green, light parts don’t use ports, rather they are instantiations of associations that exist in the class model.

Let’s return through the diagrams, back up the hierarchy. We can see that structured classes provide a very intuitive notation for hierarchical decomposition of systems. The static connections in the model can also be used by the Rhapsody code generator, to generate and build an assembly of objects.

In this configuration, I have told Rhapsody to build a main with a single Traffic Light Domain class instance running, and all its derived parts.

I can build and run the resulting application, and we can view the resulting sequences of interactions that occur between the connected parts.

It’s also possible to interact with the running application by injecting events. I can view information about the run-time state of the objects using simple panel diagram elements like these led panel elements.

Let’s go back to the Light Assembly class. To reinforce the value, I just want to show you how easy it is to plug-and-play parts. I’m going to delete the Tucan Controller part in the light assembly with a different controller that mimics a French rather than UK pedestrian light sequence. This will illustrate how the encapsulation provided by ports, parts and connectors enables you to plug and play different implementations of a class provided that the interfaces are compliant.

Having connected the new part, I can rebuild. Here we can see that an assembly that uses the same red yellow green light component but with a different controller where the light sequence goes straight from red to green, without flashing yellow. I’ll just go to an animated sequence diagram and drag on the Feu Tricolore Controller.

 … and then hit Go. Here we can see the creation of the objects, including the Feu Tricolore part communicating with the Light Assembly part. The loose coupling provided by ports and interfaces makes it easy to re-use components in different structures, irrespective of how complex their implementations are, and also acts as a façade pattern. Let’s just generate the press button event to view the light sequence.

In the resulting sequence we can see that the traffic light transitions straight from Red to Green, rather than having a ‘Red and Yellow’ steady light before the Red light in the sequence. The 3 light assembly and their associated controller, however, are the same and hence form a re-usable component that can be plugged into different builds.

Just to finish off then, I want to show you two further aspects. The first is that you don’t necessarily need to use a composite structure diagram to view the internal parts of a structured class. With Rhapsody you can switch the class to a structured view. You can drag or create parts in the structured view in the same way you can with the composite structure diagram.

The part shown on the above Object Model Diagram is the same as the part shown on the Light Assembly’s composite structure diagram. It’s important to note that can have multiple structure diagrams of the same element, perhaps showing different viewpoints or collaborations of interest.

Finally, I want to show you another advanced feature that relates to frames. I’m now going to change a General Graphics property on the model called StructureDiagramContext. If you don’t know about properties and you’re using Rhapsody then I suggest you take my training. I’m going to set the StructureDiagramContext to ClassOwner.

If I redraw the structure diagram underneath the Light Assembly class after setting the property, then you’ll notice that no class is populated.

This is because the frame is now taking the place of the class. If I right-click the frame, then I can choose to show ports.

If I drag on the parts, then they are shown as being in context of the class that the frame represents.

This only works if the structure diagram is underneath the class and it’s also one of the default settings made by the SysML profile upfront. This is because it mandates the use of diagram frames to represent the context of the diagram.

Hopefully that helps. My name is Fraser Chadburn. I specialise in tool-based training and consulting in IBM products, and in particular setting up Rhapsody using domain specific profiles. My other area of expertise is easing modeling by using Java automation and profiles to speed up and simplify modeling tasks so that users can focus on creative and fun systems and software engineering. If you do have any questions then feel free to contact me.