In the tool mentor, the following steps are performed for the use cases to be designed in the current iteration:
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.
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
Create class diagrams as needed. See Adding Class Diagrams to Model Elements.
Add signals. See Creating and Modifying Class Diagrams.
Add a brief description to each design element. See Documenting Model Elements.
Add generalization relationships between signals, if applicable.
For more information about class diagrams, see Modeling Static Structure by Using Class
Design elements are generally created in the following three ways:
Expanding a pattern
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.
Patterns and Applying Patterns in the online Help.
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.
Create class diagrams as needed. See Adding Class Diagrams to Model Elements .
Add subsystems and classes. See Creating and Modifying Class Diagrams .
Add a brief description to each design element. See Documenting Model Elements .
(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.
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
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.
The following steps apply to large-granularity subsystems:
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.
Add interface dependencies.
Map subsystems to interfaces by adding a realization relationship from the subsystem to the interface.
Document the interface, including required behavior. See Documenting Model Elements .
Add operations to the interface. See Adding Operations to Classifiers in Diagrams .
Add a description to each operation. See Documenting Model Elements .
Add parameters to each operation. See Adding Operations to Classifiers in Diagrams .
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.
Capsule and protocol modeling are not supported.
Patterns - Simple