Following is the process that will be used by CoreLinux++ in regards to
Requirements moving into Analysis, as well as what the analysis will
achieve. I will follow this in latter posts with From Analysis to Design
and From Design to Implementation.
THIS IS OPEN FOR DISCUSSION!!! I just felt we needed to start drawing
the lines in the sand as to the rules of engagement (ROE).
Following any changes to this, I will begin to add this to the
CoreLinux++ OOA/OOD document.
From Requirement to Analysis
=======================
1. All things start with a Requirement statement (e.g. CoreLinux++
should have a Thread class) regardless of the origin. If it is not
entered into the Source Forge CoreLinux++ Requirements Forum, it will be
placed there and assigned a Requirement ID (the Requirement Forum
message identifier).
2. All Requirements will be discussed for acceptance (review).
3. If we decide that NO, it is not a valid requirement (scope exceeds
the goals of the Project for example), it will be marked as INVALID with
an explanation.
4. Requirements that are accepted will need a Requirement document. I
will detail this in a later post.
5. Once a requirement has been checked in it will move into the Analysis
queue and assigned a Task Identifier from the CoreLinux++ Analysis task
control in Source Forge.
6. A directory will be created with the Task Identifier as part of the
name (TBD) and captured in CVS.
7. Analysis will proceed starting with Use-Case Modeling. In use-case
modeling, the system is looked upon as a "black box" that provides use
cases. How the system does this, how the use cases are implemented, and
how they work internally is not important. In fact, when the use-case
modeling is done early in the project, the developers have no idea how
the use cases will be implemented Use case objectives are
A. To decide and describe the functional requirements of the system,
resulting in an agreement between the team members.
B. To give a clear and consistent description of what the system should
do, so that the model is used throughout the development process to
communicate to all developers those requirements, and to provide the
basis for further design modeling that delivers the requested
functionality.
C. To provide a basis for performing system tests that verify the
system. For example, asking, does the final system actually perform the
functionality initially requested.
D. To provide the ability to trace functional requirements into actual
cases and operations in the system. To simplify changes and extensions
to the system by altering the use-case model and then tracing the use
cases affected into the system design and implementation.
8. The actual work required to create a use-case model involves defining
the system, finding the actors and the use cases, describing the use
cases, defining the relationship between use cases, and finally
validating the model.
9. The use-case model consists of use-case diagrams (tool TBD) showing
the actors, the use cases, and their relationships. These diagrams give
an overview of the model, but the actual descriptions of the use cases
are typically textual. Both are important!
10. The use-case model will be used to realize the use case. The UML
principles for realizing use cases are:
A. A use case is realized in a collaboration: A collaboration shows an
internal implementation-dependent solution of a use case in terms of
classes/objects and their relationship (called the context of the
collaboration) and their interactions to achieve the desired
functionality (called the interaction of the collaboration).
B. A collaboration is represented in UML as a number of diagrams showing
both the context and the interaction between the participants in their
collaboration. Participating in a collaboration are a number of classes
(and in a collaboration instance: objects). The diagrams are
collaboration, sequence, and activity. The type of diagram to use to
give a complete picture of the collaboration depends on the actual case.
In some cases, one collaboration diagram may be sufficient, in other
cases, a combination of different diagrams may be necessary.
C. A scenario is an instance of a use case or a collaboration. The
scenario is a specific operation path (a specific flow of events) that
represents a specific instantiation of the use case. When a scenario is
viewed as a use case, only the external behavior toward the actor is
described. When a scenario is viewed as an instance of the
collaboration, the internal implementation of the involved classes,
their operations, and their communication is described.
---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://www.colconsulting.com
Object Oriented Analysis and Design |Java and C++ Development
|
