Activity:  Develop Design Guidelines

Tailor the Design Guidelines

Before you start design you should tailor the Design Guidelines, so that it covers the areas that are relevant in your project. See section "Tailoring" in Design Guidelines. The development case will serve as one input, since it describes how the project will work in design. 

To be able to tailor the Design Guidelines you must understand the implementation environment. For example, your choice of programming language will affect the design model in terms of the way you document operations, use generalization, and use objects and classes. Other examples are which architectural styles to use, how to use significant mechanisms when implementing the system, and how to design a graphical user interface.

All decisions made regarding any guidelines and strategies for architectural design, design, and implementation should be documented in the Design Guidelines document. 

Capture Decisions

Make decisions regarding all the areas in the Design Guidelines document. 

The following are example of three areas where you normally need to make decisions. These decisions should be captured in the Design Guidelines.  

• Mapping from design packages to implementation subsystems.
• Mapping from design classes to code.
• How to represent reusable components.

Mapping From Design Packages to Implementation Subsystems

Decide how the packages in the design model should be mapped to subsystems in the implementation model.

It is recommended that you have a one-to-one mapping from design packages to implementation subsystems. This will make it easier to understand the traceability between design and implementation.

However, in some cases, it may be difficult to keep the mapping one-to-one. For examples of situations where the package hierarchies in design and implementation may differ, see the Activity: Structure the Implementation Model.

If you decide to let the package hierarchies differ between design and implementation, then you should minimize the differences as much as possible. Keep in mind that the issues to be resolved when deciding on the structure of implementation subsystems, relate primarily to the development of the software and the management of its construction, that is they fall under the implementation view of the architecture.

Mapping Design Classes to Code

You need to decide how each class should be mapped to the implementation; whether a class in design should be mapped to one, and only one, class in the implementation, or if the mapping should be one-to-many.

For a thorough discussion of the mapping from design classes to code, see Concepts: Mapping from Design to Code.

Decide How to Represent Reusable Components

You must decide how you should represent the use of reusable components.

There are many different types of reusable software components. Some have to be modeled in the design model, some have to be modeled in the implementation model, and some will not have to be modeled at all. The reason for bringing classes of the reusable components into the design model is that the structure of these particular reusable components affects the structure of the system and it would be harder to understand the scenarios if those classes were omitted. So if your diagrams become easier to understand create proxy classes for the reusable components and use them in the design model.

An example of software that usually is not shown in any model:

• Data base management systems (both object-oriented and relational). They will affect the design model, but they will not exist as classes in the model.
• General class libraries with basic classes.

An example of software that is usually just shown in the implementation model:

• Graphical user interface class libraries: there is no point in polluting the design with classes for different kinds of buttons, scrollbars, fields, and so on, but you need to structure your work before coding.

Thus, the decisions are different for each library, or system of reusable component that you have in your project.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process