Friday, 14 February 2020

Rational Rhapsody Tip #73 - Block Definition Diagrams in Rational Rhapsody (Simple)

In this 5th in a series of videos about the different diagrams in the Unified and the Systems Modeling Languages, I cover Block Definition Diagrams in SysML. This is really a follow on from my second video in the series which was on UML Class Diagrams. This is because BDDs in SysML do for systems engineer’s what class diagrams in UML do for software engineers. They both involve the classification of structural elements and the establishment of relationships between them. The key difference is that SysML uses a stereotyped class called a Block, and of course, Blocks conceptually will often be non-coding things such as organisational structures, physical elements, or systems, subsystems & components. As well as showing Block's features, Block Definition Diagrams, or BDDs for short, allow us to define and show relationships between blocks such as associations, compositions, aggregations, generalizations, and dependencies. An emphasis is often placed, however, on classification trees, i.e. the hierarchical decomposition of systems. This video illustrates the basic concepts and also hints at some of the more advanced features supported by Rhapsody such as the perspectives toolbar.

















This is the transcript:

Hi, in this 5th in my series of videos about the different diagrams in the Unified and the Systems Modeling Languages, I thought I’d cover Block Definition Diagrams in SysML.

This is really a follow on from my second video in the series which was on UML Class diagrams. This is because BDDs in SysML do for systems engineer’s what class diagrams in UML do for software engineers. They both involve the classification of structural elements and the establishment of relationships between them.

The key difference is that SysML uses a stereotyped class called a Block, and of course, Blocks conceptually will often be non-coding things such as organisational structures, physical elements, or systems, subsystems & components.

Each block defines a collection of features to describe a system or other element of interest.

As well as showing Block's features, Block Definition Diagrams, or BDDs for short, allow us to define and show relationships between blocks such as associations, compositions, aggregations, generalizations, and dependencies.

Although Class diagrams share the same relationships, it’s very likely that you would end up using different types of relationship when you build a SysML model than you might with a class diagram in UML.

For example, associations which are central to defining communication paths between collaborating objects in an OO design, are not something you’d use very often in a SysML BDD. Their predominance is replaced instead by one of composition relationships to enable hierarchical decomposition of types.

The composition relationship can be read as a “has a” relationship and is denoted with a filled in diamond.

Systems engineering is really about building highly cohesive and loosely decoupled components. As such BDDs tend to look like trees of Blocks and other classifiers.

This diagram is telling me that the Automotive Domain is an assembly of a system than comprises among other things of a Block representing a Hybrid Sports Utility Vehicle and a Block representing the Environment.

Furthermore, the Environment is decomposed into blocks representing Weather, a Road and an External Object.

The Hybrid SUV is further decomposed into parts typed by Blocks that represent subsystems of a vehicle such as the Body Subsystem and the Brake Subsystem.

I could show these by dragging on the Blocks from the browser, and Rhapsody would auto-populate existing relations on the diagram when I do this.

As with class diagrams, it’s the modelers choice what the scope of the BDD is. In this instance the BDD is nested under the Hybrid SUV and hence the frame tells us that the scope is the Package called the HSUVStructure.

You could also nest BDDs under a Block, if you want and this would be represented in the diagram frame. Diagram frames are a mandated part of SysML and convey the scope and context of the diagram. This is a bdd of a Block called the Hybrid SUV and the diagram is called the Hybrid SUV Breakdown.

Notice in this diagram there is an aggregation between the Power Subsystem and a Block called the Brake Pedal. This represents a SysML concept called a reference part. This is because the Brake Pedal is not owned by the Power Subsystem. However it is referenced and connected to it in the internal block diagram.

If I go to the IBD then you can see this reference part is linked with the owned parts, but that it’s represented by a dashed line because it’s not owned by the Power Sub system block. Note how this IBD is where the wiring between ports or parts is made, not on the BDD.

This can sometimes be a challenge for new users. The key things is that Blocks are types of things. If I had a Car with 4 wheels, then my BDD would define a Block representing a Car and a Block representing a Wheel. If I have 4 wheels then I don’t have a Block for each wheel, I have 4 parts typed by the same Wheel block.

Let’s go back to the BDD. I just want to cover a few things about Rhapsody’s implementation of SysML.

Block Definition Diagrams in Rhapsody, like Class Diagrams are defined by New Term stereotypes applied to Rhapsody’s base Object Model Diagram type.

But here's a thing, there’s a lot more diagram tools in the BDD toolbar than there are with a Class Diagram. Immediately it becomes apparent therefore that a BDD offers more choice than a Class diagram because SysML has lots of stereotyped element types. Some of these are legacy elements.

This is perhaps against the original intent of SysML which, if you recall with it’s Venn diagram overlapping with UML, had a smaller SysML circle to represent that SysML was smaller than UML.

It’s worth noting that Rhapsody has kept pace with SysML, including adding new concepts such as proxy, full ports and Interface Blocks.

Rather than manage multiple versions of SysML, there is a single SysML profile with the super-set of concepts. This has the benefit of supporting existing models without changing them, while allowing modelers to utilize the new concepts such as proxy ports, if they want to in either new or existing models.

It does mean that there’s a lot of things in the BDD toolbar though.

To get around this issue the Rhapsody development team added a customization feature called the Perspectives Toolbar. The perspectives toolbar enabled you to have a pull-down list that filters the Rhapsody menus, including the drawing toolbar. It enables you to change the palette to only a subset of the types in the profile. Reducing the menus makes it’s a bit simpler for users who are not SysML experts, but does - of course -mean than someone needs to make a choice on what tools you want.

For example, if I know that my modeling approach is not going to use associations and flow specifications, then it’s better to remove them from the toolbar before anybody see the tool, otherwise you have to tell people not to use it.

Here I’ve added a perspective toolbar to that hides some of the legacy tools from users.

Personally, I’ve seen a lot of companies benefit from simplifying Rhapsody menus upfront to reduce the training needs and improve modeling consistency. This is a greater challenge when when rolling out Rhapsody to a wider audience with less knowledge and experience of SysML and it's partly a challenge caused by using a generic language like SysML.

A second thing worth noting in Rhapsody's BDD implementation is more fundamental to SysML which is that when you draw a composition relationship then Rhapsody will create a part automatically in the browser based on the composition's role name. This is enabled by a property called RepresentParts. The same behavior can be added to Rhapsody class diagrams but does require a little property-magic up front, if this is the behavior you want.

Importantly for understanding BDDs, I just want to emphasize that you can’t draw connectors between ports on a BDD. The diagram you should use to do this is an Internal Block Diagram in SysML, which is known as a composite structure diagram in UML. Essentially, it’s an IBD where we do the wiring in SysML and connectors go between parts, rather than blocks.

Finally, SysML also puts a lot of emphasis of the use of compartments to show the features of a Block, and Rhapsody is very powerful in allowing you to choose which compartments you want to show, the order of compartments, and also what things to show in the compartments. To do this, you need to set the graphical node to specification view, and go to the Display Options dialog.

Rhapsody’s Display Options dialog isn’t bad at allowing multi-selection either. I’ll add a compartment that shows the parts on all of these Blocks.

Anyway, I hope that helps to give at least an overview of Rhapsody's implementation of the Block Definition Diagram in SysML.

Monday, 3 February 2020

Success Story: Simplifying Rhapsody & SysML for L3 MAPPS

I thought I'd share a success story from one of the many things that kept me busy the first half of last year. Although from the naval systems domain, this success has kicked started me into my 4th generation of Rhapsody profiling focused on making feature & function modelling simple for my automotive clients.



Wednesday, 8 January 2020

New 3 day course on Automotive MBSE with IBM Rational Rhapsody

Just added a new Automotive MBSE with IBM Rational Rhapsody 3 day course option to my course itinerary page (MBSE#3D3). After many years of training automotive engineers in the general purpose language concepts of UML/SysML and then watching them struggle, I've decided instead to focus on teaching them a method to model automotive concepts such as Features and Functions directly in Rhapsody. This method-based training course uses a profile to add automotive concepts directly to the Rhapsody menus, together with a suggested starting meta-model that they could then take-away and extend. The intent is to short-cut the need to understand the full breadth of the general purpose language and tool and instead focus on the work products that are needed for automotive MBSE.

Thursday, 2 January 2020

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.

Thursday, 12 December 2019

Rational Rhapsody Tip #71 - Use case diagrams in Rational Rhapsody (Simple)

This is the 3rd in a series of videos I'm created showing Rational Rhapsody's implementation of diagrams in the Unified and Systems Modeling Languages (UML/SysML). This video, which includes narration, covers the use case diagram. Use case diagrams are a core notation in both UML and SysML. However, I often find them one of the notations that is both simple but easy to get wrong, particularly when engineers forget that the use case isn't actually described in the diagram, just its relations. In this 10 minute video I show the creation of a use case diagram, explain the concept of actors, and then explore 3 relations that you might use on a use case diagram; generalization, include and extend. At the end of the video I highlight the importance of understanding the scope, or subject, of the use case and hint on the complementary relationship between use cases and textual requirements. As an expert in Rhapsody, I work with clients across the world to help them extract increased value from modeling by speeding up and directing modeling tasks using profiles and different model-based methods for systems and software engineering.

















Here's the transcript:

Hello, in this third in a series of videos about different UML and SysML diagrams in Rhapsody, I'm going to cover use case diagrams.

Use case diagrams are a type of behaviour diagram, and they go right back to the origins of the Unified Modeling Language in 1996.

Use cases came from a methodologist called Ivar Jacobson, whose Object Orientated methodology at the time focused on understand the usage of a system as a series of steps called use cases, and using these to identify objects that might be realised in an object orientated design.

If I was going to build an air traffic control system, for example, I might write the use case of how an air traffic controller performing a series of steps to control a flight, and then using these steps to identify candidate classes that might exist in the design, such as aircraft, aircraft routes, flight plans, and airspace's such as special use air spaces.

I'll show you this with Rhapsody 8.4 and I'm going to quickly use one of helper profiles I've created called the ExecutableMBSEProfile, because it has a method based on use cases.

So let's create a project called UseCasesExample.

Essentially the Profile helper here uses Rhapsody's Java API to automate steps to bootstrap the model with the SysML profile and a package structure that includes a use case diagram and a shared actors package.

Let's create a use case diagram for a Dancer. A Dancer is system that exhibits emergent behaviour based on a combination of components that includes legs, arms, hands and a torso.

The use case diagram essentially gives a functional context diagram, where the use cases are stories about how the system is used, and actors represent roles played by elements outside the system that interact with it.

If this system represents a dancer, then outside the system interacting with the system, or getting value from the system, might be the audience. Another actor that the system interacts with, or participates in the use case, might be the dance floor.

A use case for the dancer system, where the audience gets value, might be to Perform a dance.  Use cases define the offered behaviours without reference to the internal structure of the system. These behaviours, involving interactions between the Actors and the subject, may result in changes to the state of the system.

If we work our way through some of the elements in the toolbar, an association between an actor and a use case tells us that the actor participates in the use case.

The main thing for me is that the use case diagram doesn't tell us the steps in the story, just that the use case exists. The diagram is therefore a 30,000 ft view of the system, and it's a bit like the index of a library where each use case here represents a book describing a story of how the system is used.

Actors by convention are always outside the system, however, we can add a boundary or subject box here to make the subject of the use case clearer. In this case I'm saying the subject for the use case is the dancer. It's important that you don';t put the system or anything inside the system as an actor.

Of course, it's possible for the system to interact with another dancer.

The role that that dancer might play with respect to the system in this case is as a dance partner. The same person may also play other roles, for example, as a Spouse but the use cases would be different.

A use case is an end-to-end use of the system to perform something of value with respect to an actor, and we should try keep the use cases as big as possible. It's very easy with use cases to turn a steak into mincemeat.

Let's look at these three different types of relationship we might use between use cases; generalisation, include and extend.

Suppose that there are different types of dances and that each type of dance has a fundamentally different set of steps, but they all involve an audience and a dance floor.

Well, I could call each of these dances out as a separate use case, and then use a Generalisation relationship to say that they are all types of a Perform a dance use case.

Gangnam style, and performing a Waltz are both types of Performing a dance. However, the steps are very different, and the Perform a Waltz involves a partner.

Note how the Generalization means that the specialised use cases inherit the relations of the base use case. If we didn't use generalisation then we'd need to draw associations to both the Perform Gangnam Style and Perform a waltz for both the Dance Floor and Audience actors. We'd lose some of the meaning conveyed by the generalisation relation and we'd end up with lot's of crossing lines, making the diagram less easy to understand.

By pulling them out I can say that Performing Gangnam style is associated with a YouTube video camera actor, whereas Performing a waltz needs a dance partner.

The include and extend relations are also ways in which we can show relationships across use cases.

If we define a use case as a set of steps including alternate steps that yield an observable result to an actor, then we sometimes want to write some extensions to a set of steps without polluting the original use case.

We can do this by adding an extends use case. For example, dealing with sprain might include quite a lot of steps such as icing the limb and elevating to reduce circulation, but we don't really want to write these steps as part of the perform a dance use case, so we've factored them out, and we're going to draw an Extend relation from the use case defining the extension steps to the use case it extends. Note the direction of the dependency here, the Perform dance use case is not dependent on dealing with a sprain.

Let's make a little more room. In Rhapsody if I hold down the alt key then I can resize a container element without re-sizing it's inner elements.

It's important to remember that a use case is defined as a set of steps including alternate flows that yield an observable result of value to an actor. It's essentially a story that shows the use of the system. The use case diagram does not describe the steps of the story, and hence really just tells us that the story exists.

We can describe the use cases in many ways. I often like to use activity diagrams. My free helper here, conveyed by my profile, works on the double-click hook and creates a new diagram from a template.

I might say that the trigger for the use case is dance partner taking the dancer by the hand.

And, as you all know, to dance the waltz you need to

Step forward with the left foot
Right foot step sideways to the right
Bring your left foot next to your right foot
Step back with the right foot
Step back sideways with the left foot
Bring your right foot next to your left foot

Of course, you might not have known this, or you may have got them wrong, and hence it helps to write them down and review them with experts.

This is only if you are the lead, of course, if you're the follower then you do something different. This is where an alternative flow might come in.

When playing the female, the dancer would start by putting their right foot backwards (or do we?).

Let's return to the use case diagram.

Now sometimes we have a set of steps that get reused in more than one other use case, which is where the include relation comes in.

I'm not saying I would do it like this, nor would I recommend using include relations if you can get away without them. However, suppose that I determine both gangnam style and performing a waltz need to start with a warm up. Well I could write the steps for a warm up separately, and then include them from the use cases that require them.

My tips are really that you should on;y do an include when you've written steps that you think need to be factored out, and when you have identified that two or more use cases need them. Resist the erge, if you can.

Secondly, make sure that the included use case is 'chunkey' enough to factor out the steps. As soon as I start to use relations, then I make my diagram less clearer, and more esoteric. This works against the original goal of the use case diagram which is to work with customers and users to understand how the system will be used, before you start to build it.

So that's it, the use case diagram, a high level functional context diagram giving a 30,000ft view about what the system does for whom.

I particularly like the idea that use cases are very complementary to requirements. I often put the goals of the system as textual requirements, e.g. The dancer shall be capable of leading a Waltz.

Also, I like the idea that use case diagrams should be created collectively, and are a good requirements elicitation vehicle if done well, particularly as they focus on clearly understanding the system boundary.

If I changed the system boundary then it could quite dramatically change the actors and the use case. As the dance partner would no longer be external to the system. And Perform Gangnam style would not be a use case of the system, as it's not an emergent behaviour realized by a dance couple.

Hopefully that helps. If you feel inclined then feel free to go away and try the steps yourself, or with a partner. 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 modelling by using Java automation and profiles to speed up and simplify modelling 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 on my email address.

Automotive features and functions

Over the last couple of weeks I've been working with a US-based client on feature and function modeling, a common theme for automotive customers. A key question is often what is the best underlying UML/SysML model for capturing these kinds of concepts, and how much domain-specific language (DSL) to exploit within the tool. Having tried to convince automotive clients of conventional UML/SysML approaches in the past, I've begun to err on the side of creating function and feature concepts as first level elements. It's interesting because it breaks down the barriers to consumption of the models, and also means that you have the flexibility to build profiles that directly fit the customers needs and wants.

Thursday, 21 November 2019

Rational Rhapsody Tip #70 - Class diagrams in Rational Rhapsody (Simple)

This is my second in a series on the different diagrams in UML and SysML. Class diagrams are a stalwart of the Unified Modeling Language and date right back to it's origins in 1997 as a way to describe the relationship between classes in an object orientated design. This video takes you through the core relationships between classes or classifiers; namely compositions, aggregation, associations and generalizations. I expand on this a bit to also show Interfaces with realizations and dependencies, together with a bit of C++ code generation to make it all seem a bit more real and a little less abstract (so to speak) ;-)
















This is the script:

Hello and welcome to this second in series of quick videos about the different UML/SysML diagram types in Rhapsody. In this one I'm going to show class diagrams, a stalwart of the Unified Modeling Language since 1997

I'll start by creating a completely new project, and I'll choose a Project Type as Default, which really means in Rhapsody, create a UML project. Which I'll do in my Rhapsody84Projects folder here.

I've chosen not to add the perspectives toolbar, as I really don't want to confuse people as to what is or sin't available in the drawing toolbars.

As you can see when I create a new project, Rhapsody always creates a Object Model Diagram at the root of the project, however, I'll delete it.

I'll then right-click the Default package and choose to Add a new Class diagram.










So I'm using Rhapsody 8.4 here but the Class diagram has been draw-able since it's first version on 1996, and that's a long time ago.

As an aside for those who know a bit more about Rhapsody, you'll notice that a class diagram is a new term stereotype applied to the base type of diagram called an object model diagram.

The object model diagram in Rhapsody has both objects and classes available in the toolbar. The class diagram is therefore a subset of this, which concentrates the focus and therefore simplifies things a little. There is nothing to stop you from creating a class diagram using the object model diagram.

Fundamentally, Class diagrams in UML are a notation for describing object-orientated relationships between, not surprisingly classes. Classes are types of things. I might, for example, describe that within my design there is a type of thing called a House, and there is a type of thing called a Door.

I can then use the class diagram to show relationships between these types of things. For example that a House has a door that it knows of in the role of it's front Door.

The filled in diamond here is a type of object orientated relationship called a composition, and we can read it as a "has a" relationship. A House has a door. It knows of the door as it's front door. It may have another Door with a different role, of course, a back door.










Within an OO design there are 4 core Object Orientated Relationships. Association's are a key one, particularly in an Object Orientated Software design, typically between peer types.

Using an association I can say that a House is associated with a Road. The road is associated in the role of it's Road, which represents the road that it's on. It doesn't own the road, it's more like they are peer objects. An object orientated software design can be built up by establishing relationships between collaborating objects such as these.



















There's also the idea of Generalization. The "is a" relationship. For example, a semi-detached house "is a" house. This means that it inherits all the relationships, attributes and operations of the house. This means that it has a front door and it has a road it's on, but also has new relationships.



















A semi-detached house is actually half of a building. For those in the UK that live in them, they know that a particular instance of a semi-detached house shares a wall with another semi-detached house.

We could show this is as a third type of OO relationship called aggregation. I could say that the semi detached house has an aggregation relationship to a Wall class, in the role of it's adjoining wall. Aggregations are like shared composition, and the notation is a diamond that is not filled in. We read it as a "has a" relationship where the particular object is shared. It's a bit of modeling placebo really, particularly if you're doing code generation, as they're treated in the same way as associations.










There's two other relationships I'll quickly show. The first is realization which is a type of Generalization. We use this relationship when we're working with Interfaces.

Interfaces are a concept in UML that allows us to describe a group of method signatures independent to their implementation. They have a direct relationship with programming language implementations. For example, I could create a type of Interface called an iLock with two operations in it, lock and unlock. The iLock interface here is shown in italics, which means that it's abstract and doesn't define any implementations for these operations. I could then define a concrete class called Lock that will realize these operations.

You can see that Realization is a new type stereotype that is applied to the base Generalization type in Rhapsody. This stereotype also conveys some formatting so that the line is shown with a dash rather than solid display format.

I can use the Realize Base Classes wizard to copy the unimplemented operations if I wish. I need to set the Display Options if I want to see them on the diagram though, as Rhapsody will only show Explicit operations by default.  These operations are not shown in italics as they will have generated implementation bodies.








It's worth noting that UML is more than a visual notation. UML models can be used to generate code. That's one of the values you can get from using a modeling tool like Rhapsody Architect for Software or Developer Editions.

I'll just change this to compile with the Cygwin gcc compiler and then click the Generate Make Run button. I can then use the Active Code View to view the generated C++ code, as C++ is the Unit type for these elements in this model.

There's an obvious relationship between the UML classes and C++ because C++ is an object orientated programming language, and it has the concept of classes.

For example an composition relationship is captured as an data member of the owning class which means that it will be constructed at the same time, whereas an association or aggregation is captured as a pointer to an object.

The Generation is obviously captured as an inheritance relationship, as is the realization. These are all essentially object orientated relationships. Finally, let me just show you another type of relationship we might draw on a class diagram that is not really an object orientated relationship.

I'll create an example here called stdio. A standard library that contains functions and types for input and output that I might want to do an include of in my C++ design. I can represent the include as a dependency, and in C++ to make this explicit we would stereotype the dependency with the Usage stereotype which also gives the ability to specify whether the hash include should be generated in the specification or implementation file.










If I mark the class with the property UseAsExternal then Rhapsody would not generate code for it, and would also mean that Rhapsody would generate the directive with angular syntax rather than quotes so that the pre-processor would look in the system directories first.

Dependencies are not really object orientated as we would not invoke methods on an object related to the relationship. However, they do come up even in a OO design. If we reverse engineer C code then it's also the relationship that we'll get the most.

So that's it. The class diagram is really the core diagram that allows us to express object orientated relationships between classes, and there are 4 core types of object oriented relationships you might draw; associations, compositions, aggregrations, or generalizations (plus derivatives such as realization and non-OO relations such as dependencies).