Re: Let's put this to rest

Responding to Davor...

I did not have the opportunity to follow the discussions in this group
for quite some time, but I remember that we had a discussion that might
be related to this issue, and that is that you were interpreting
"analysis" as what I, and probably many others, see as some form of
"high-level design". To me they are, and always will be, different
activities. To give an example, let's say I want to reorganize my
workspace. I perform following activities that give me following sets
of data:

OOA = {desk, 6 pens, 3 notebooks, 1 cup, stapler}

So, OOA models is purely what I can observe in terms of
objects/concepts within my workspace that I'm analyzing.

This view is more akin to traditional requirements analysis or the notion of problem analysis from Structured A/D/P. However, OO development is quite different than SA/D/P development.

An OOA model is a complete solution specification for functional requirements. It is expressed in problem space terms rather than computing space terms. In MDA terms an OOA model maps to a Platform Independent Model (PIM) because it does not depend on the particular computing environment where the application will be implemented.

OOD is generally regarded as an elaboration of the OOA specification to deal with nonfunctional requirements at a strategic level (caching, concurrency, memory management, etc.). OOP is an elaboration of the OOD model to deal with nonfunctional requirements and specific computing space technologies at a tactical level.

IOW, an OOA model would map to high level design in SA/D/P. However, one needs to be cautious with trying to map to traditional SA/D/P because OOD would also map into high level design. The mapping ambiguity lies in the fact that <most> SA/D/P made no distinction between functional and nonfunctional requirements.

One of the things the OO paradigm brought to the table was a more coherent set of step stones between the problem space and the computing hardware. So in the OO approach we have:

Requirements -> OOA Model -> OOD Model -> OOP Model -> Executable

where everything to the left of Executable is a specification for the implementation to its immediate right and everything to the right of Requirements is an implementation of the specification to its immediate left. Each arrow represents a different intellectual contribution to refine the solution. This duality of specification and implementation, combined with partitioning based on functional (customer) and nonfunctional (computing) requirements, was one of the unique contributions of the OO paradigm. Thus OMG's MDA initiative represents a logical refinement of that aspect of the paradigm.

However, OOA and OOD are not very different from a methodological viewpoint. The difference lies primarily in the subject matter: functional vs. nonfunctional requirements. That's why UML is the standard notation for both OOA and OOD but one needs quite different notations (OOPLs) for OOP models and yet other notations for things like Systems Engineering (e.g., SysML). Thus the semantics of the OOA and OOD models is the same. IOW, the only way to tell an OOA model from an OOD model is by looking at the actual model content.


[... skipping all functionality/goal related analysis that has to be
performed ...]

Abstracting OOA model and intersecting with functional/goal model =
{writing device}

OOD (high-level) = {computer, editor}
OOD (more concrete} = {desktop computer, monitor, keyboard, mouse, text
editor}
OOD (even more concrete} = {dell machine, samsung monitor, ibm
keyboard, ms mouse, vi-clone}
OOD (or what would be OOP} = {Dimension 1100, syncmaster 213, IBM Model
M keyboard, intellisense mouse, vim}

As you can see, for me there is a huge difference between OOA and OOD.
OOA models is a view into an "existing" domain system, and by no means
something that I would like to see in a system that I'm building or
even something that is supposed to be "correct" - in fact, it's more
often something that should be changed and something that we are moving
away from than a reliable foundation based on which we should build our
(new) system. This is also why I believe MDA (that I do not know much
about) and "translational ism" might work fine within OOD range of
activities and making models more concrete, but I'm having issues with
it when it comes to moving from OOA to OOD, as to me the main activity
for moving from OOA to OOD is *problem solving*, which I believe very
rarely or probably never can be equated with *translating*. So, if in
MDA you are really trying to move from OOA to OOD through "translation"
rather than "problem solving", maybe that is the problem and the cause
of the differences in the solution models (OOD)? Refering back to the
problem above, the "translation" move from OOA to OOD above would be:

The model above defines traditional OOA/D/P elaboration. All translation brings to the table is automation within that process. The computing space is largely based on mathematics so it is highly deterministic. Translation uses that to automate OOD and OOP. This is just a logical migration of automation through the computing space that started with linkers and loaders in the '50s. It took awhile to get to OOD because the computing space is enormously complex (i.e., optimization for OOD is much tougher than for a 3GL compiler).

MDA supports both elaboration and translation. The basic idea behind MDA is transformation (as opposed to translation) between representations (models):

[Input Model] [Transformation Model]
| |
| |
V |
{tranformation} <---------------+
|
|
V
[Output Mode]

Thus any representation can be unambiguously converted to another representation provided (A) both representations are of the same basic subject matter, (B) both representations have well-defined semantics, and (C) there is some set of transformation rules to guide the transformation. The transformation itself can be automated or manual.

MDA is more general than the OO paradigm but its mapping to OO is:

Requirements -> OOA Model -> OOD Model -> OOP Model -> Executable
CIM PIM PSM PSM

CIM = Computation-independent Model
PIM = Platform Independeent Model
PSM - Platform Specifc Model.

(BTW, there is nothing in MDA to preclude having multiple CIMs and PIMs as well; there is just no need for them in OO development usually.)

The power of MDA is the conceptual framework that formalizes the notion of semantic specification through meta-models. This enables a mapping function (Transformation Models and Marking Models) between meta-models to be rigorously defined. That mapping is then "walked" by the transformation to convert specific representations that instantiate the meta-models. MDA also provides supporting standards for things like UML and XMI.

MDA actually has very little impact on the application developer. The intellectual content reflected in the models is provided in a tradtitional A&D manner. But MDA profoundly affects the tools the developer uses (e.g., elaboration round-trip tools or translation code generators) through standardizing plug & play interoperability and a semantic framework. MDA standards also enable more elaborate development environments like Eclipse by providing a "backplane" architectural specification.

Bottom line: neither translation nor MDA affect the application developer's intellectual content in the final solution. That is dictated solely by the A&D methodology de jour. All existing translation approaches employ a basic OO A&D approach but MDA can be applied with any A&D approach. The single most significant difference between translation A&D methodologies and other OO methodologies is a stronger emphasis on using state machines to describe behavior.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Lets put this to rest
    ... An OOA model is a complete solution specification for functional ... the OOA model does not describe how the application will be implemented in the computing space. ... At the same time, though, that Java program is clearly a concrete implementation of How the OOD specification will be met. ... There is also a useful separation of concerns that supports specialization, which becomes very obvious in translation where the application developer and transformation engine developer essentially belong to different unions. ...
    (comp.object)
  • Re: Lets put this to rest
    ... Abstracting OOA model and intersecting with functional/goal model = ... OOD (more concrete} = {desktop computer, monitor, keyboard, mouse, text ... MDA you are really trying to move from OOA to OOD through "translation" ... what you call OOA/D is not what most people call OOA/D. ...
    (comp.object)
  • Re: Lets put this to rest
    ... An OOA model is a complete solution specification for functional ... MDA methods and techniques. ... OOP is an elaboration of the OOD ... Translation uses that to automate OOD and OOP. ...
    (comp.object)
  • Re: OOA and OOD
    ... Responding to J0mbolar wrote: ... > they understand OOA and OOD. ... I would be cautious about reviews. ...
    (comp.object)