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