Guidelines: Mapping Analysis Classes to Design Classes

• In general, there is a many-to-many mapping between analysis classes and design classes.
• An analysis class can become one single class in the design model.
• An analysis class can become a part of a class in the design model.
• An analysis class can become an aggregate class in the design model. (Meaning that the parts in this aggregate may not be explicitly modeled in the analysis model.)
• An analysis class can become a group of classes that inherits from the same class in the design model.
• An analysis class can become a group of functionally related classes in the design model.
• An analysis class can become a package in the design model (meaning that it can become a component.)
• An analysis class can become a relationship in the design model.
• A relationship between analysis classes can become a class in the design model.
• Analysis classes handle primarily functional requirements, and model objects from the "problem" domain; design classes handle non-functional requirements, and model objects from the "solution" domain.
• Analysis classes can be used to represent "the objects we want the system to support," without taking a decision on how much of them to support with hardware and how much with software. Thus, part of an analysis class can be realized by hardware, and not modeled in the design model at all.

Any combination of the above are also possible.