Architect Assistant v1.2.2

Copyright @2005-2007 IBM. All Rights Reserved.

This plug-in provides architecture control in models developed in IBM^® Rational^® Software Architect (RSA) / IBM Rational Software Modeler (RSM) Version 7.

Overview
Known Limitations
Understanding Access Violations And Package Dependencies
Using the ArchitectAssistant Profile
Fixing Access Violations

Overview

Architect Assistant consists of a menu item Architect Assistant in the pop-up menu of the Model Explorer view and Diagram area of the Modeling perspective in RSA/RSM. This menu item has four commands:

Promote to Interface will create an interface from the selected class, create the interface realization to the class, duplicate all public operations and migrate all relationships from the class to its interface. The command can be applied repeatedly to the same class. All changes performed by Promote to Interface are logged to the console. These changes should be carefully inspected before committing them.
Show Orphaned Links will inspect all interaction diagrams in the selected package(s) and report a message in the console if a link between two objects does not have a matching relationship between the two corresponding classifiers.
Show Access Violations identifies access violations in the selected models and/or packages. See Understanding Access Violations and Package Dependencies.
Fix Access Violations identifies the access violations and attempts to fix them based on the model layered architecture and/or by prompting the user. See Fixing Access Violations.

Unresolved violations are reported both in the Console view and in the Problems view. The markers in the Problems view are transient : they do not persist if you re-start RSA/RSM.

A UML profile is included in the plug-in. See Using the ArchitectAssistant Profile.

Known Limitations

Association classes are not handled.

Understanding Access Violations and Package Dependencies

What is an access violation? If a UML element (class, interface or component) in a package (the client) has for instance a valid relationship with another UML element in another package (the supplier), and the client package does not have a UML dependency to the supplier package, the relationship is considered illegal. This is an access violation. The access violation can be solved either by adding a dependency from the client to the supplier, or by moving one of the UML elements (or both) to another (valid) location.

Access violations can originate in:

A UML element having a relationship to another UML element (as already mentioned).
A UML element having an attribute whose type references another UML element.
A UML element having an operation with at least one parameter (possibly the return result) referencing another UML element.

Show Access Violations will log an information message in the console whenever one of this situation occurs AND:

Either the dependency from the client to the supplier does not exist,
Or the client package does not have access to the supplier package (for instance because the supplier package has private visibility).

After executing Show Access Violations, you can either intervene manually to take the appropriate action (for instance add a dependency or move the target of a relationship to a different package), or execute Fix Access Violations. (Of course, you can also execute Fix Access Violations directly.)

Dependencies between components and layers. Most architectures today, including J2EE, are organized in layers (for instance presentation , business, and integration). A layer may access lower-level layers, but not layers above it. Ideally, a layer only has access to the layer immediately below it, and possibly "common" layers (for instance a data transfer objects layer). Layers are themselves divided in components, which are represented by packages or sets of packages. Controlling the dependencies between components and layers is essential for the reusability and maintenance of software systems. Some of the components are read-only third-party components (for instance org.apache.struts) or common libraries (java, javax, etc.).

The next section explains how to use the profile provided in the plug-in to describe your architecture.

Using the ArchitectAssistant Profile

The ArchitectAssistant profile provides some package stereotypes that will allow you to specify some of the high-level units of your architecture:

The <<layer>> stereotype is applied to a package that represents a layer of the architecture. Once you have indicated the (few) layers of your architecture, you should draw dependencies from each layer to the other layers it is allowed to access. (If a layer is accessed by all others, use the <<global>> stereotype below instead of drawing dependencies from each possible layer.) The resulting information is used by the Show/Fix Access Violations commands to automatically detect "authorized" and "prohibited" dependencies. This reduces significantly the number of cases for which either a violation is reported (Show Access Violations) or a human intervention is requested (Fix Access Violations).
The <<externalLibrary>> stereotype is applied to a package that represents an external, read-only component such as java, javax, org.apache.struts or any user-defined "external" component. Note that the standard stereotype <<modelLibrary>> is processed like an <<externalLibrary>> stereotype. (If a component is accessed by all others, use the <<global>> stereotype below instead of drawing dependencies from each possible client.)
The <<global>> stereotype simply indicates that the package it applies to can be accessed by all other packages. This stereotype can be combined either with a <<layer>> or a <<externalLibrary>> package.

Here is a simple example of what a layered architecture could look like:

It is not mandatory to use this profile. However, if you want to take full advantage of this plug-in, you should strongly consider it. As explained above, specifying the allowed layer dependencies will significantly reduce the number of ambiguous cases. In addition, when using Fix Access Violations, it will allow you to automatically create at the layer and/or component levels the dependencies that result from creating dependencies between client and supplier packages at any lower level of nesting. This behavior is explained in the next section.

Fixing Access Violations

So, resolving access violations will eventually lead to a set of dependencies. In the example below (please note this is a very simplified view not representative of a complete architecture), the relationships from class CreateAccountAction (association role accountManager referencing IAccountManager and generalization to Action) result in two access violations.

These access violations are easily resolved by adding dependencies from com.ibm.jps.presentation.actions.accountManagement (which contains CreateAccountAction) to com.ibm.jps.business.custServices.accountManager (which contains IAccountManager) and org.apache.struts.action (which contains Action) respectively. The resulting model is shown below (the top level package com.ibm.jps is not represented for clarity). This however does not provide any indication as for dependencies between higher level packages.

To get a complete picture of dependencies requires percolating the dependencies to the higher level packages. Thus, if accountManagement depends on org.apache.struts.action, it also depends on org.apache.struts, org.apache, and org. Similarly, actions, which contains accountManagement, would depend on the same set of packages, etc. This quickly leads to a very confusing picture.

The command Fix Access Violations, in addition to solving access violations, will create additional dependencies but only at the layer and component levels. The end result is shown below (the top level package com.ibm.jps is not represented for clarity). The "component" com.ibm.jps.presentation.actions depends on components com.ibm.jps.business.custServices and org.apache.struts. The "layer" com.ibm.jps.presentation depends on layer com.ibm.jps.business and on component org.apache.struts.