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.
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.
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.
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.
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.
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.