Activity: Develop Design Guidelines

Before you start Design, you must make several decisions about 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.

Before you make these decisions, you should review specifications of the implementation environment. All decisions made regarding any guidelines and strategies for architectural design, design, and implementation should be documented in the Design Guidelines document.

Use the Design Guidelines as a checklist, to make sure that you cover all design aspects.

The following three areas are discussed in the following sections as separate 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.

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.