Task: Design the Solution | |
 |
Identify the elements and devise the interactions, behavior, relations, and data necessary to support some functionality.Render the design visually to aid in solving the problem and communicating the solution. |
Discipline:
Analysis & Design |
|
Purpose
The purpose of this task is to describe the elements of the system so that they support the
required behavior, are of high quality, and fit within the architecture.
|
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
Outputs |
|
Main Description
This task is about designing part of the system, not the whole system. It should be applied based upon some small
subset of requirements. The requirements driving the design could be scenario-based functional requirements, some
non-functional requirement, or a combination. Some scenario walkthrough will be necessary even when
non-functional requirements are being designed.
This task can be applied in some specific context such as the database access elements required for some
scenario. In this case the task might be applied another time to deal with a different context on the same
requirements. Keep in mind that to actually build some functionality of value to the users, all contexts
will typically need to be designed and implemented.
If this task is being performed on an architecturally significant element, the results can represent additions to the
architecture. Such designs should be harvested and put in the architecture.
|
Steps
Understand requirement details
Examine the relevant requirements to understand the scope of the design task and the expectations on the design.
If the requirements are determined to be incomplete or incorrect, work with the analyst to get the
requirements improved and possibly submit a change request against the requirements.
|
Identify design elements [visual modeling]
Find analysis classes from use-case behavior
To identify a candidate set of analysis classes which will be capable of performing the behavior described in use
cases. These classes will provide the necessary behavior to fulfill functional and non-functional
requirements.
Refer to Concept: Entity-Control-Boundary Pattern for guidance on how to identify these
classes. Another source for finding analysis classes are the analysis mechanisms and analysis patterns being considered
for this project. Once identified, then name and briefly describe the analysis classes in a few sentences.
Distribute behavior to analysis classes
For each scenario, express the use-case behavior in terms of collaborating analysis classes. This helps to determine
the responsibilities of analysis classes. You may find useful to capture the interaction between analysis classes (and
between classes and external entities such as actors) on diagrams like communication or sequence diagrams (tipically
one diagram for each scenario).
Describe responsibilities
Class responsibilities are either actions to be performed by an object or knowledge maintained and provided to
other objects. Each class will typically have several responsibilities; each responsibility will evolve into one
or more operations during design.
Responsibilities are derived from messages on interaction diagrams or from non-functional requirements that a class has
to convey. Document a responsibility by giving it a name, and optionally a brief description (what it does).
Describe attributes and associations
To perform their responsibilities, classes may depend on other classes to supply needed behavior. Associations in a
class diagram can be used to represent inter-class relationships.
A class may have to store simple data information, like: string, integer, and the like. For such simple type of
information, attributes are defined for classes. For a more complex or "behavioral' attribute, consider creating an
extra class and establish an association to it.
|
Identify design elements
Identify the elements that collaborate together to provide the required behavior. This can start with the key
abstractions identified in the architecture, domain analysis, and classical analysis of the requirements (noun
filtering) to derive the elements that would be required to fulfill them.
Identify elements in all perspectives being considered when performing this task. This could include identifying
user interface elements, control elements, data elements, and elements relating to interfacing to other
systems or devices.
Existing elements of the design should be examined to see if they should participate in the collaboration. It is
a mistake to create all new elements in each execution of this task.
This list of candidates must be expanded to include special-purpose participants that handle particular roles in
providing the required behavior such as transaction processing or adherence to some security specification. The
Entity-Control-Boundary Pattern provides a good start for identifying elements.
|
Design internals [visual modeling]
[TBD discuss creating components, defining interfaces, and designing internals.] |
Determine how elements collaborate to realize the scenario
Walk through the scenario distributing responsibilities to the participating elements. These
responsibilities can be simple statements of behavior assigned to elements; they need not be detailed operation
specifications with parameters, etc. This step is about ensuring that a quality model is being created that is
robust enough to support the requirements.
Identify the required relationships between the elements based on the walkthrough of the scenario examining
how the elements initiate each other's behavior. As with the responsibilities, these relationships can just
be defined at this step.
Look to the architecture and previous design work to create a consistent collaboration. Look to reuse existing
behavior and relations or to apply similar structure to simplify the design of the overall system.
Additional elements might be identified as behavior is found that cannot appropriately be assigned to any of the
existing elements.
|
Determine how elements collaborate to realize the scenario [visual modeling]
Create Use-Case Realizations
Create use-case realizations to better communicate the classes and how they collaborate to realize the behavior of
a scenario.
One use case will commonly have more than one scenario that can be modeled in a use-case realization. Even when
this task is being applied to what is conceptually one scenario, it might be necessary to create a number of scenarios
in the realization to show variant behavior of the design within what is conceptually considered one scenario.
Update Class Diagrams
TBD - talk about VOPC and updating other diagrams
|
Refine design decisions
Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the
architecture. In this step the design can take into consideration the actual implementation language and other
technical decisions. As refinement takes into consideration details at a lower level of abstraction, this might
necessitate revisiting the identification of the elements and the collaborations that realize the scenario.
In particular make decisions in regard to
-
specific details of relationships between the elements
-
operation detail
-
existence and detail of data attributes necessary
-
usage of inheritance and interfaces to improve the design
Incorporate design mechanisms from the architecture. Apply consistent structure of the elements and organization
of the behavior as in other areas of the design and use patterns identified in the architecture.
|
Design internals (for large or complex elements)
Design large or complex elements or some complex internal behavior in more detail.
This might just involve devising an algorithm that could be performed to produce the desired behavior. This could
involve another whole pass through this task where the scenario under consideration is one behavior element of an
element that requires significant design consideration. Add additional operations, attributes, and
relationships to support the expectations of an element.
The state of the element managed over the course of its lifetime can be designed to ensure proper behavior in
various usages.
|
Communicate the design
Communicate the design to those who need to understand it. Though this is described here toward the end of
the task, communication should be going on throughout the steps; working collaboratively is always better than
reviewing the work after it is complete.
Some ways to communicate the design are:
-
formal models specified in UML
-
informal diagrams that static structure and capture dynamic behavior
-
annotated code that communicates information about the static structure supplemented with textual descriptions of
dynamic behavior across code modules
Examples of individuals that will need to understand the design are:
-
developers who will implement a solution based on the design
-
an architect who can review the design to ensure that it conforms to the architecture or who might examine the
design for opportunities to improve the architecture
-
other designers who can examine the design for applicability to other parts of the system
-
developers or other designers who will be working on other parts of the system that will depend on the
elements designed in this task
-
other reviewers who will review the design for quality and adherence to standards
When considering reviewers, keep in mind that if someone can add value by reviewing the design, then they could have
added even more value by actively participating in the design effort itself.
|
Evaluate the design
Evaluate the design for coupling, cohesion, and other quality design measurements.
Consider the design from various angles to ensure that it is a high-quality, communicable design. Work with other
technical team members; an independent party can provide a fresh perspective.
|
Refine design decisions [visual modeling]
[TBD - reference updating diagrams with appropriate detail.] |
|
Key Considerations
Each step in this task can cause all previous steps to be revisited in light of new information and decisions.
Consider the architecture while performing this task. All design work must be done while regarding the
architecture within which the design exists. Furthermore, certain design elements will be deemed architecturally
significant; those elements will require updates to the architecture.
This task will be applied numerous times. Even when starting the design for a particular project it can be
expected that there will be existing frameworks and reusable elements. Every step of this task must give
attention to the existing design and existing implementation, utilizing existing elements when possible and emulating
or improving existing elements as appropriate while designing this portion of the solution.
Apply patterns throughout this task. Patterns represent proven designs and their usage promotes quality and
consistency across the design.
|
More Information
Copyright (c) 1987, 2006 IBM Corp. and others. All Rights Reserved.
This program and the accompanying materials are made available under the
Eclipse Public License v1.0 which
accompanies this distribution.
|
|