JReality
JavaTM Virtual Reality Applications and
Related Technologies
"Freedom" Service-Oriented Methodology
Abstraction Levels
Unlike most software methodologies, which consist mainly of a process
and associated rules or guidelines, Freedom is based on
levels of abstraction for software methodologies as advocated by
Dr. Charles McKay.
A methodology constructed according to abstraction levels has at its
foundation mathematically valid models, concepts, or principles.
Higher-level abstractions are then based on, or derived from, this
firm foundation. While the resulting methodology cannot, of course,
be guaranteed to be perfect, the fact that it derives from a firm base
bodes well for its ability to endure over time.
The Freedom methodology consists of six abstraction levels:
| Level 6 |
| Level 5 |
| Level 4 |
| Level 3 |
| Level 2 |
| Level 1 |
|
|
Level 1: Concept Models
Underlying the entire Freedom methodology is the concept that software
may be viewed using
box-structured models, as noted by
Dr. Harlan Mills.
Box-based models have been proven valid and effective in other engineering
disciplines such as avionics, systems engineering, and electrical engineering.
Freedom is founded on three box-structured concept models -- the
black box model,
gray box model, and
white box model.
Level 2: Definitions
The concept model foundation offers a firm basis from which to
derive definitions for key terminology. Freedom derives definitions
for the key terms of
requirements,
design, and
implementation
from the models. This terminology serves to segregate software engineering
information into three groups or categories.
Level 3: Principles
Principles are assertions regarding good software engineering practice that
are backed by solid rationale. Definitions and principles guide creation
of a robust rational process. The Freedom process is based on principles
for
build versus buy,
requirements,
object design,
implementation and test,
release, and
evolution,
Level 4: Processes
With software system information categorized based on the definitions,
processes for developing this information, and notations for recording it,
are specified consistent with the stated principles. The definition-based
information categorization determines precisely which information is within
the scope of which processes.
Level 5: Products
Freedom applies different semantics to its process than other
methodologies. Freedom's process charts do not specify rigorous
steps that a developer must take when creating software. Rather, they
follow the principle described in the 1986 Parnas paper
"A Rational Design Process: How and Why To Fake It". This paper
states that rational processes are impossible to follow rigorously, so do
not try. Rather, developers should "fake" the process by producing the
desired work products any way they can. The only caveat is the products
delivered to the customer must be the same as would have been produced had
the rational process been followed rigorously. When viewed from this
perspective, processes do not exist to control people, but to more clearly
define the nature of the work products to be produced.
Level 6: Tools
One of the most common mistakes made by developers of software engineering
tools is developing such tools in isolation from a specific software
development process or methodology. The result is tools that attempt
to be process or methodology independent. While tools can be
developed in this manner, in general they are not as powerful or
high-leverage as tools targeted to a specific methodology.
Thus, Freedom reserves the uppermost abstraction level for tools
specific to Freedom's notations and processes. Sets of tools
constructed in this way integrate well and are very high-leverage.