Following is the suggested process used by CoreLinux++ in regards to
Analysis moving into Design, as well as what the design will achieve. I
will follow this in later post From Design to Implementation.
Following any changes to this, I will begin to add this to the
CoreLinux++ OOA/OOD document.
The assumptions I am making about the reader at this point are:
A. That the effort of Analysis has is that the focus is on the problem
domain, not on a specific technical solution.
B. Class, Sequence, Collaboration, State, and Activity diagrams are
understood. If you are unsure about these let me know and I will post
links to where you can find out more. For immediate consumption
http://www.cetus-links.org has a tremendous reference list.
=====
In general, the design is a technical expansion and adaptation of the
analysis results. The classes, realtionships, and collaborations from
the analysis are complemented with new elements, now focusing on how to
implement the requirement.
All the details of how things should work technically and the
constraints of the implementation environment are taken into
consideration.
Typically the analysis classes are embedded in a technical
infrastructure, where other technical classes help them. In our case,
the libcorelinux++ features, and their respective designs, will
constitute some of the technical classes when we move on to frameworks.
Of course another benefit of the design phase is to recognize areas
where the requirement or analysis was not sufficient to complete the
design. In the true sense of Object Oriented methodologies, our
methodology will be iterative as well.
From Analysis to Design
=======================
1. Once a Analysis has been checked in it will move into the Design
queue and assigned a Task Identifier from the CoreLinux++ Design task
control in Source Forge. At this point, a fully qualified identifier for
the effort in regards to the originating requirement should be :
RequirementForumID.AnalysisTaskID.DesignTaskID
2. A directory will be created with the Design Task Identifier as part
of the name (TBD) and captured in CVS.
3. If not already done in the Analysis phase, analysis classes will be
divided into functional packages. This assumes the tool we use can
provide that.
4. Additional technical classes are added.
5. Concurrency needs are identified and modeled through active classes,
asynchrounous messages, and synchronization techniques for handling
shared (if applicable) resources.
6. A STRONG emphasis is placed on exceptions and faults in the design.
This includes both normal and abnormal where:
Normal : those that can be anticipated in the course of performing the
functions.
Abnormal: those that can't be anticipated and must be handled by some
generic exception mechanisms.
it is my assumption that, at a minimum, the UML tool we use supports
exception designation in the class specification.
7. A STRONG emphasis is placed on constraints. A constraint is a
restriction on an element that limits the usage of the element or the
semantics (meaning) of the element. Constraints are one way of enforcing
the "contract" by which the objects in a live system may or may not
interact. For example, if Class A is constrained to having at most five
(5) elements in a collection data member, a pre-condition constraint
would be put on the addElement( ElementCref ) method. Whether or not we
have access to a tool that supports constraint notation (Object
Constraint Language (OCL) 1.1 or greater) is TBD. In the abscense of the
notational support, text blocks should be specified.
8. The dynamic behavior of the design is emphasized. This is done
through class, collaboration, sequence, and state diagrams. The benefit
is that it will reduce the implementation time by having a clear
understanding of what the code should be doing.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
|
