Overview

In the tool mentor, the following steps are performed for the use cases to be designed in the current iteration:

• Identify Events/Triggers and Signals
• Identify Classes, Active Classes and Subsystems
• Identify Subsystem Interfaces  
• Identify Capsule Protocols  

Additional Tool Information

Architecturally significant design elements may be documented in a separate Logical View, that is maintained as design elements are identified. The general recommendation is to use <<perspective>> packages. See Model Structure Guidelines for RSx for more information on this topic.

Identify Events and Signals

The characteristics of events, also called triggers in UML 2.0 should be captured as needed to drive the identification of the design elements that handle them. This information can be captured informally, such as in a separate document, rather than as part of a model.

Asynchronous communication events can be modeled as signals to express the data that they carry, or to express relationships between signals, such as a generalization relationship. The following substeps describe how to model signals:

1. Create class diagrams as needed. See Adding Class Diagrams to Model Elements.
2. Add signals. See Creating and Modifying Class Diagrams.
3. Add a brief description to each design element. See Documenting Model Elements.
4. Add generalization relationships between signals, if applicable.  

For more information about class diagrams, see Modeling Static Structure by Using Class Diagrams.

Identify Classes, Active Classes and Subsystems

Design elements are generally created in the following three ways:

• Expanding a pattern
• Modeling
• Coding and reverse engineering 

These approaches are explained in the sections that follow.

Expanding a Pattern

A pattern is a special kind of transformation that is optimized for interactive, piece-wise elaboration, primarily in a single meta-model and within the same level of abstraction, and often within the same model. For more information, refer to Analysis Mechanisms.

See Authoring Patterns and Applying Patterns in the online Help.

Modeling

This tool supports a model-driven approach to software development (see Model Driven Development and Model Driven Architecture and Analysis Mechanisms), wherein you construct a set of models that eventually includes a design model and generate implementation artifacts such as 3GL code, descriptors, etc. These are derived from the design model using Transformations. In some cases the code-generating Transformations will take analysis classes as inputs, but primarily they will be driven by design elements. For more information, see: Applying Transformations.

In a traditional development approach you will create class diagrams in the Design Model to capture design elements. If you decide to maintain the analysis classes, then you may want to establish traceability by using "trace" dependencies to the analysis classes.

1. Create class diagrams as needed. See Adding Class Diagrams to Model Elements .
2. Add subsystems and classes. See Creating and Modifying Class Diagrams .
3. Add a brief description to each design element. See Documenting Model Elements .
4. (optional) Add traceability to analysis classes by using "trace" dependencies from your design elements to the analysis classes on which they were based.See Abstraction Relationships in UML Modeling.
5. Organize the design elements into subsystems and packages. Refer to the white paper Model Structure Guidelines for RSx.

For more information about class diagrams, see Modeling Static Structure with Class Diagrams .

Coding and Reverse Engineering

Note: some of the tool capabilites mentioned in this section are not supported in RSM.

A different approach is a "code first" approach: the code is the main driver either because already exists (for example in a non-greenfield development cycle) or the team needs to tackle some specific project risks by coding a prototype to validate a complex concept. As part of the support for Architecture Discovery and Recovery (see the Architectural Discovery, Analysis and Control guidelines), the tool's code visualization capability can automatically populate topic diagrams, such as package structure, class internals, inheritance trees, and collaborations. The goal of this task is not only to understand the existing code, but also to extract a model of the application, which could be used in conjunction with other specific models to generate the new version of the application, by using transformations.

Once you have generated or composed a UML diagram of existing code, you have these options for leveraging the code depictions as part of your design model:

• Harvest a UML depiction of a code element into your design model, as a true semantic model element. This creates a new UML element in the design model that has no connection to the code item that was harvested. It does however have properties (for instance attributes and operations) that reflect the properties of the harvested code item. Because it is a true UML semantic element, new code can be generated from it (in other words it has the same status within the design model as any design element that was defined through the greenfield modeling process described previously earlier.)
• Place a visual reference to the code element into a diagram that resides within your design model. This reference itself has no semantic meaning within the design model, and no new code will be generated from it. It is, as its name implies, just a reference to the actual code element. However, you can draw relationships between the code reference and the semantic design elements in the design model. Those relationships do have semantic meaning within the design model and they do affect code generation.

For more information, refer to Modeling Static Structure with Class Diagrams in the online Help.

Identify Subsystem Interfaces

The following steps apply to large-granularity subsystems:

1. For each subsystem, identify a set of candidate interfaces. If you previously created analysis classes, and did analysis-level use case realizations, you will now decide how those operations are to be grouped together and exposed as the interfaces of particular components or services. Add interfaces to an existing component diagram, or create new component diagrams as needed. See Adding Interfaces to Modeling Diagrams.
2. Add interface dependencies. 
3. Map subsystems to interfaces by adding a realization relationship from the subsystem to the interface.
4. Document the interface, including required behavior. See Documenting Model Elements .
5. Add operations to the interface. See Adding Operations to Classifiers in Diagrams .
6. Add a description to each operation. See Documenting Model Elements .
7. Add parameters to each operation. See Adding Operations to Classifiers in Diagrams .
8. Organize the interfaces into packages. 

In UML 2.0 subsystems are large components and could be represented as structured classes with ports and/or interfaces. See the on-line help specific UML 2.0 topics. 

Identify Capsule Protocols

Capsule and protocol modeling are not supported.

Additional Tool Information

Tutorials:

• Apply a Pattern

Samples:

• Patterns - Simple UML Model