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

@ the INCOSE's Annual Systems Engineering Conference (ASEC) in Leeds, UK this week

This week I had a little trip to the UK INCOSE ASEC in Leeds. Actually, I found it quite interesting. There were a few sparks of interest, some enlightening conversations, and the dinner was a scream (the main reason for going, I think).

INCOSE is the International Council on Systems Engineering, a not-for-profit membership organization and professional society in the field of Systems engineering. INCOSE has about 17000 members.

The Annual Systems Engineering Conference (ASEC) is INCOSE UK's flagship event that brings together a wide range of professionals from a variety of backgrounds, with the common interest of building upon their Systems Engineering knowledge and sharing ideas with their peers. I didn't present this time, but it was fun and great to meet up with a few people I've not seen in a while.

Monday, 11 November 2019

Rational Rhapsody Tip #69 - Timing diagrams in Rational Rhapsody (Simple)

In my effort to get to 100 Rhapsody tips and tricks video's this 8 min video is the first in a series covering the different diagram types in UML and SysML. I provide Rhapsody training for both systems and software engineers, focused on getting the best of the tool in different domains such as automotive, defence/aerospace and industrial real-time and embedded markets (www.mbsetraining.com). Timing Diagrams are a type of Interaction diagram in UML. They were first added in the major revision known as UML 2.0 (in 2005). The video shows both the compact and elaborated form of the diagram in Rhapsody. I use Rhapsody 8.4 here (2019). The compact form of the diagram was first added to Rhapsody in 8.0.5 (2013). The diagram is much like a sequence diagram on its side. Lifelines represent classifiers like classes/objects, actors or use cases. They show how the condition of the lifeline changes with respect to time. The sequence can be annotated to show both the messages or events that cause the conditions of the classifier to change over time, and observations or constraints about the time or duration in the sequence.
















Timing Diagrams are a Unified Modeling Language (UML) diagram. They were first added in the major revision known as UML 2.0 (in 2005). They are a type of interaction diagram.

To create a timing diagram right-click the project folder, then select Add New > Diagrams > Timing Diagram. On the New Diagram dialog specify whether the diagram should be a compact or elaborated timing diagram.

Compact timing diagrams were first added in 8.0.5 (2013). Elaborated Timing Diagram were first added in Rhapsody 8.1.2.

The diagram is much like a sequence diagram on its side. Lifelines represent classifiers like classes/objects, actors or use cases. You can set them to realize existing elements, or you can drag the existing element to the drawing area.

To draw an event or operation we need to bind it to a state invariant (condition marker). The state invariant shows the state of the lifeline. For example, here we’re showing the tap changing state from Off to On. You can also bind markers to existing states.

There are various annotations that can be used. For example timeouts.

Of, course, we can also access common tools like Requirements. E.g the tap will turn off automatically after 10s.

The time axis settings can be changed in the General tab of the diagram. The General tab settings here are persisted as properties.

The default display options can therefore be set up in profiles or stereotypes with desired settings.

You can use the property TimingDiagram::General::DefaultDiagramForm at Project level or in a Profile to specify the selected default diagram type.

When using elaborated timing diagrams, you add and remove state invariants by right-clicking the rectangle at the beginning of the lifeline and selecting Manage Invariants... from the popup menu.

The are various types of annotation. To add a duration constraint or duration observation, Rhapsody adds duration brackets around the event. Add the necessary time measurements. For constraints, add a minimum and maximum time; for observations, add a single unit of observed time.

To add a timing constraint or timing observation, Rational Rhapsody adds brackets around the event. Add the necessary time measurements. For constraints, add a minimum and maximum time; for observations, add a single unit of observed time.

To add a lifeline destruction event, on the drawing palette, click the Destruction event icon, then click the end of the lifeline.

Thursday, 7 November 2019

Rational User Group – Persistent Engineering Lifecycle Roadshow - Nov 27 2019

Following on from last year's user group roadshow in London, Persistent are re-running their 'supercharged' Rational User Group which they've re-branded as the Persistent Engineering Lifecycle Roadshow. It's in London at the Royal Academy for Engineering on November 27th.

It's a good opportunity to meet up with the product development managers for DOORS and Rhapsody, and like-minded clients in the complex systems and software engineering space. Hopefully I'll be there if anybody wants to chat or meet up.

The Rational tools customer registration page is here:
https://www.persistent.com/persistent-engineering-lifecycle/london/

Monday, 4 November 2019

Updated training courses page with 1-day masterclasses

I've updated my training courses page to detail a new series of 1-day "masterclasses" on IBM Rational Rhapsody. These are Rhapsody tool-focused advanced topics.

  • Key focus is raising the productivity and effectiveness of an existing Rhapsody user-base. 
  • They are applicable to both software (UML) and systems (SysML) users.
  • They can be delivered web-based (instructor) led to any geography (USA, Asia, Europe, UK).
  • Up to 20 participants.

The 1 day topics include:
  1. MBSE#1D1: Masterclass in IBM Rational Rhapsody core fundamentals.
  2. MBSE#1D2: Masterclass in modeling with requirements and external Requirements Management tools.
  3. MBSE#1D3: Masterclass in hierarchical system decomposition and component-based design with SysML.
  4. MBSE#1D4: Masterclass in model-driven development (MDD) for C or C++ development using IBM Rational Rhapsody Developer.

Tuesday, 29 October 2019

Rational Rhapsody Tip #68 - Installing the Rhapsody integration for RTC plugin (Intermediate)

The IBM Rational Rhapsody integration for Rational Team Concert plugin is installed into the RTC Eclipse client to enable a direct and supported integration between RTC or Rhapsody Model Manager project and IBM Rational Rhapsody. This short tips and tricks video shows you how to install it.


Check out the help here:

Wednesday, 23 October 2019

Rational Rhapsody Tip #67 - What are implicit classes? (Intermediate)

In this short tips and tricks video for IBM Rational Rhapsody I give an overview of how objects in Rhapsody can be used for modeling software or systems architectures without using classes. I then compare this with the benefits of using classes. The key thing is that if you create an object in Rhapsody that is not typed, then it can support all the concepts that a class can. It does this by creating an implicit class under-the-hood, but just showing the object in the browser. The key reason you expose classes is where you need to enable re-use, or a separation of concern between the definition of an element and its usage. This is why I tend to recommend always using classes (in UML), or blocks (in SysML), if you can. It means you can have a consistent approach that copes with the future.
















Rhapsody creates an implicit class under-the-hood whenever you create an untyped Object. This enables Objects to have ports and statecharts. They can also have operations and attributes.
































This is the basis of Rhapsody in C's optional File rather than Class-based mapping to the C programming language. A File in Rhapsody in C is a type of Object where the attributes and operations are mapped to variables and functions in .h/.c files.










Using only objects you can created nested hierarchies to visual a software or system architecture. The implicit class under the hood enables you to exploit composite structure notation with ports, parts and connectors without needing to expose classes in the browser.








There are good reasons, however, to expose classes. The main reason is to enable re-use of the underlying classes features in a different context. Suppose, for example, that you want to do represent a Function block that has inputs, outputs and requirements, but is used by two different features. Well, by exposing the class you can re-use the function in a different composite structure.



















Two parts are now typed by the same class. The visual representation of each part (it's operations, attributes, statecharts and ports etc) are defined by the class.












A flatter browser results when you do this and it also means that you can move classes/blocks that define the properties of an element to a different package in the model from the classes that use them. This can assist with re-use of library functions/blocks/classes, or the creation of blocks/classes by different users than the modeler who is using them.











Of course, the user now needs to be aware of the different between objects/parts and classes in UML. Note: A part is the name given to an object that is declared in the context of another class, and is the basis of component-based design in UML (and SysML).













Connectors and links are used in a composite structure to wire together parts. They are created in the context of the owning class. These work when both implicit and explicit classes are used because the connector is a link between parts/objects, rather than classes.