Rational Software Architect – Nested Node Instances

Section 10.3.7, Device (from Nodes), in the UML 2.2 specification contains the following deployment diagram (see page 206).

Figure 1 – Notation for a Device

Clearly, all the nodes in this diagram are instances. With this in mind, let’s try and recreate a similar diagram using Rational Software Architect 7.5.

Creating the AppServer and J2EEServer elements is pretty straightforward. A graphical representation of the model looks something like the following. In the example below I’ve added some attributes to the AppServer device to highlight the fact it’s an element specification, not an instance.

Figure 2 – Deployment Model

If you selected the "Blank Deployment Package" template and default model capabilities in the model creation wizard, the ability to add node instances will be disabled. To remedy this you need to select the capabilities tab in the model properties panel and select the "UML Specific Instance Type 1" and "UML Specific Instance Type 2" options.

Figure 3 – Enabling Node Instances

Once this is done you can starting adding node instances to your deployment diagram. For example.

Figure 4 – Deployment Diagram

The problems arise when you try and add nested nodes to the diagram because, basically, you can’t. As the following figure shows, the properties panel appearance tab options for showing textual and/or graphical nested node compartments are absent for node instances.

Figure 5 – Node Instance Properties

Unfortunately, the help documentation is totally unhelpful as it contains the following section

Nesting nodes inside other nodes

In UML modelling, you can nest nodes within nodes to represent the hardware and software components in a system that contains other components.

A diagram must be open in the diagram editor, and the diagram must contain at least two nodes. The Nested Nodes compartment of the container node must be visible.

To nest a node in another node, in the diagram editor, click one node and drag it into the Nested Node compartment of another node.

As the following figure illustrates, a node named Node2 is displayed in the Nested Nodes Textual and Nested Nodes Graphical compartments of another node, named Node1.

Figure 6 – Rational Software Architect Help

What they fail to mention is that none of this applies to node instances. I raised this with Rational Support and after a month’s deliberation they finally confirmed that nested node instances are not currently supported.

Rational Software Architect – Java to UML Transformations

Over the past few weeks I’ve been evaluating IBM’s Rational Software Architect (RSA) for WebSphere 7.5 . Whilst RSA is an incredibly powerful piece of software, there are a number of features that are conspicuous by their absence. Perhaps the most prominent of these is the inability of the Java to UML transformation to generate relationships other than Generalisation or Realisation. For example, it won’t generate Association or Usage elements. This makes it pretty useless when it comes to visualising the structure of existing code

You could argue that RSA’s raison d’etre is not the reverse engineering of UML models from Java code, but rather the architecture and development of new applications. This is true, but it misses the point as a number of RSA’s design contract management protocols (notably, "Reconciled Modelling" and "Conceptual Models Drive Development") rely on the reverse transformation of Java code.

According to Rational Support this issue has been logged as a request for enhancement, but when or if it makes it into a future release is anyone’s guess. In the meantime here’s an illustration of the problem.

Step 1 – Create a simple UML model with a composite aggregation navigable from both ends

Figure 1. Class diagram view

Figure 2. Project explorer view

Step 2 – Run a reconciled UML to Java transformation on the model

This produces the following java classes (minus the auto-generated comments):

Whole.java

package uml;

import java.util.Set;

public class Whole {

	private Set part;
}

Part.java

package uml;

public class Part {

	private Whole whole;
}

Step 3 – Comment out both private fields in the generated source and run the reverse transformation

As you’d expect, the composite aggregation relationship has now been deleted from the model.

Figure 3. Class diagram view

Figure 4. Project explorer view

Step 4 – Uncomment both fields and rerun the reverse transformation

Unfortunately this doesn’t produce the results you’d expect. Rather than explicitly creating an Association element in the UML model, the composite aggregation becomes implicit via the generated attributes for each class. By itself this isn’t a major drama, but it does introduce an inconsistency in your model if you have existing relationships that are modelled explicitly, as was originally the case. To visualise the recreated association you have to filter the attributes to "show as association". However, this only produces uni-directional associations which results in difficult to read diagrams full of unnecessary clutter and noise. The only workaround is to manually recreate the association in the model, which at best wastes time and at worst introduces errors.

Figure 4. Class diagram view (show as attribute)

Figure 4. Class diagram view (show as association)

Figure 5. Project explorer view

The Kernel Package: Basic UML to Java

At first glance the UML specification can seem a little daunting. Java developers know all about classes, interfaces, and inheritance, but how do these concepts map to the UML? In Java terms, what are Elements, NamedElements, RedefinableElements, Classifiers, Features, etc.? This post aims to bridge the representational gap between some of the key UML Kernel package elements and the corresponding concepts that manifest themselves in a simple Java class.

The following code depicts a simple interface, abstract superclass, concrete subclass hierarchy in Java.

Operation.java

package math;

public interface Operation {
  double perform();
}

BinaryOperation.java

package math;

public abstract class BinaryOperation implements Operation {
  
  protected final double operand1;
  protected final double operand2;

  protected BinaryOperation(final double operand1, final double operand2) {
    this.operand1 = operand1;
    this.operand2 = operand2;
  }

  public abstract double perform();  
}

Addition.java

package math;

public final class Addition extends BinaryOperation {

  public Addition(final double operand1, final double operand2) {
    super(operand1, operand2);
  }

  public double perform() {
    return operand1 + operand2;
  }
}

Class Diagram

N.B. The remainder of this post assumes the elements are contained in model called "model".

Element

An element is a constituent of a model. The interface, classes, member variables, operations, parameters, etc. in the example code above are all elements. Elements can own other elements and have comments attached to them. The hierarchy of elements (listed outermost first) for the operand1 parameter of the BinaryOperation constructor is as follows:

• <package> model
• <package> math
• <class> BinaryOperation
• <operation> BinaryOperation
• <parameter> operand1

NamedElement (extends Element)

A named element has a simple name, a qualified name, and an optional visibility. The perform method in the Operation interface has following named element attributes:

• name = perform
• qualifiedName = model::math::Operation::perform
• visibility = public

PackageableElement (extends NamedElement)

The only difference between named elements and packageable elements is the requirement that packageable elements always have a visibility. For named elements the visibility attribute is optional. Classes and interfaces are both packageable elements.

Namespace (extends NamedElement)

A namespace is simply a container for named elements. In the code example, the following elements are also namespaces:

• <package> math
• <interface> Operation
• <class> BinaryOperation
• <class> Addition
• <operation> perform
• <operation> BinaryOperation
• <operation> Addition

This is all pretty straightforward. Packages contain named elements such as sub-packages, classes, and interfaces; classes contain named member variables and methods, and operations contain named parameters.

Package (extends PackageableElement, Namespace)

A package is essentially a namespace with the additional constraint that its directly owned elements must also be packageable elements. Because a package is itself a packageable element it can be nested within other packages. In the example the package math contains the packageable elements <interface> Operation, <class> BinaryOperation, and <class> Addition.

RedefinableElement (extends NamedElement)

A redefinable element is an element that has the capacity to be overridden. It adds a single boolean attribute, isLeaf. Setting isLeaf to true is equivalent to applying the final modifier, as is the case in the Addition class.

Type (extends PackageableElement)

A type constrains the values that may be represented by a typed element. In Java terms this equates to a primitive type, interface, or class.

TypedElement (extends NamedElement)

A typed element extends a named element by adding an optional association to a type. For example, the operand1 instance member variable in the BinaryOperation class is a typed element with an association to the type double<PrimitiveType>. The value it represents must be no less than java.lang.Double.MIN_VALUE and no greater than java.lang.Double.MAX_VALUE. Similarly, if we declared a variable of type Operation in some client object it would be constrained to referencing the set of Objects that directly or indirectly realise the Operation interface. (See StructuralFeature below).

Classifier (extends Namespace, RedefinableElement, Type)

A classifier is a namespace that can contain features (see Feature below). Classifiers also have the capacity to own generalisations, which in effect means they can extend other classifiers. In the example code, Addition owns a Generalisation relationship that targets BinaryOperation. Classifier adds a single boolean attribute, isAbstract. This is semantically equivalent to the abstract modifier in Java. The value for the BinaryOperation classifier is true.

Feature (extends RedefinableElement)

Features define the behavioural or structural characteristics of classifier instances. They can also be static, in which case they define a feature of the classifier itself. The following elements, owned by the BinaryOperation classifier, are all examples of non-static features:

• <property> operand1
• <property> operand2
• <operation> BinaryOperation
• <operation> perform

StructuralFeature (extends Feature, MultiplicityElement, TypedElement)

The structure of a classifier is defined by its structural features. In Java, a structural feature is an interface constant or a class member variable (static or non-static). StructuralFeature defines a single boolean attribute, isReadOnly. Supplying a value of true is equivalent to applying the final modifier to a Java member variable. In the case of the BinaryOperation classifier the following elements are structural features:

• <property> operand1
• <property> operand2

BehaviouralFeature (extends Feature, Namespace)

By defining a behavioural feature, a Classifier states that it will respond to a designated request by invoking a behaviour. A behavioural feature is also a Namespace in the sense that it may own zero or more named parameters. BehaviouralFeature defines an association to zero or more Types representing the exceptions that may be raised during its execution.

Interface (extends Classifier)

The UML concept of an interface and the Java concept of an interface are pretty much identical. As with Java, all the features of a UML interface must have public visibility.

Class (extends Classifier)

As in Java, a UML class defines a set of objects that share the same specification of features, constraints, and semantics. A class owns a set of attributes and a set of operations. These are represented by instances of Property and Operation respectively.

MultiplicityElement, Property, Operation, Parameter, and other elements

Like Interface and Class, many of these elements are self explanatory. The aim of this post has been to focus on the more abstract elements of the Kernel package, so I won’t list their details here. If you’d like further information, please consult the UML specification.