JReality
JavaTM Virtual Reality Applications and
Related Technologies
"Freedom" Service-Oriented Methodology
Object Design Process
Principles -- Object Design
- RDD Principle:
Requirements drive design
Identify modules first by analyzing the support needs of
the system requirements, then by analyzing the support needs
of previously identified modules, until closure is reached.
If the requirements appear incorrect, change them with
customer approval; do not ignore them.
- Reuse Principle:
Don't build when you can reuse
Check the reuse library for needed design modules before
specifying new design modules. Reusing, when possible, is
usually more cost-effective than building.
- No Prose Principle:
"Prose is the sign of an error"**
Avoid natural language prose in design. Prose leads to
ambiguous, incomplete, inconsistent, unverifiable specifications.
** Quote from David Parnas, former head of the Software
Cost Reduction project team that codified information-hiding.
Analyze Behavior
The
behavior tables for the current
release group
are updated to include
PDL for internal
behavior. The full (external plus internal) PDL behavior specifications
are then analyzed to identify objects and operations on the objects
needed to support the full behavior. The analysis comprises extending the
behavior tables by adding objects and operations columns, which are
used to record objects and operations mentioned in the PDL. The
objects and their operations from all behavior tables in
the release group are then combined into a composite list.
Create Object Model
An object model identifies all
common service objects that must be implemented and their
relationships to one another. The object model defines the design
architecture of the system, which is a necessary prerequisite to
object-oriented implementation. Freedom uses
object model tables (OMTs) to record the object model rather than
UML Class Diagrams because OMTs are less expensive to create and
more amenable to completeness checking.
The objects identified
in the
extended behavior tables are copied into the OMT, and their
relationships are defined. This leads to the identification of additional
objects, which are also integrated into the OMT. The identification
cycle is repeated until all objects so identified are already defined
either in the OMT or in the
reuse library.
As with other tasks, the
quality requirements are used to guide selection among
competing architectural alternatives in the object model.
Identify Reusable Classes
When the
common service objects
needed to support the required response behavior of the current
release group
of requirements are identified via an object model,
the
object model table
is examined for reusable common service objects.
Any such objects found are flagged for implementation as
reusable design components.
Create Interface Specifications
An
interface specification defines the operations (i.e., Java methods)
invocation protocols (arguments, return types, type value ranges,
exceptions) and hidden information (field data, data value ranges) of
each
common service object to be implemented. An interface specification
is created for each object (i.e., Java class) identified in the
object model table for the
release group. Interface specifications are most useful when used
as input to tools for automatic generation of skeletal
code,
regression tests,
API documentation, and skeletal
user manual.
As with other tasks, the
quality requirements are used to guide selection among
competing interface alternatives for interface specifications.
Create Behavior Tables for Classes with Complex Operations
Once the
interface specifications have been defined, the full behavior
(internal plus external behavior) of complex operations (Java methods)
are specified. A complex operation is one for which the full behavior
will likely require support services of other common service objects.
The full behavior is recorded in an
operation/method behavior table.
An
operation/method behavior table is similar to a requirements
behavior table except that each row in the table corresponds to
an operation on the object (Java method) rather than a stimulus.
The columns of an operation/method behavior table are the same as a
requirements behavior table except there is no "new stimulus set"
response column. The use of
PDL is identical.
As with other tasks, the
quality requirements are used to guide selection among
competing algorithmic alternatives when writing the PDL.
One operation/method behavior table is created for each object in the
object model table having complex operations.
The behavior of the complex operations is analyzed to identify
additional objects and their operations by repeating the Object Design
process starting with the
Analyze Behavior task until no new objects
are identified in the Create Object Model task.
home
about
downloads
gallery
goal
plan
products
e-commerce
future
science & engin
you & me
Copyright (C) 2000-2003 LDJ Trust
