Object-Oriented
Design
Context
Begin by reviewing: software engineering lectures.
In these lectures object-oriented design is presented as one of several software engineering processes:
All stakeholders (customer, users, and developer) participate in the requirements gathering process, while only developers participate in the subsequent processes.
Review: Summary of Object-Oriented Analysis
A Model of the
Design Process
The input to the design process is the analysis model, which is the output of the Requirements Analysis Process and usually takes the form of a requirements analysis document or RAD:
Requirements Analysis Document
Functional Specification (from the Requirements Gathering Process)
Analysis Object Model (from the
Analysis Process)
Dynamic Model (also from the Analysis
Process)
The output of the design process is a two-level design model. The top level consists of components connected through interfaces:
The next level consists of UML class diagrams showing how the level one components are designed.
The design model is manifested by the System Design Document (SDD).
Only the system developers participate in the design process, which consists of two sub-processes: system design and component design:
More Preliminary
Material
Although covered in excruciating detail later, it might be necessary to review basic UML diagrams.
Object-oriented design shares many of the underlying principles of functional design:
It's instructive to see how design principles can be
quantified into design metrics:
The Design
Sub-Processes
In the system design sub-process, the major system components are identified. This includes the services they will provide to other components as well as the services they will require from other components.
In the component design sub-process the internal structure of each component is specified. This takes the form of a collaboration of sub-components or a collaboration of objects.