Re: Let's put this to rest
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Tue, 13 Jun 2006 17:14:05 GMT
Responding to AndyW...
I want some demonstration of why the OOA/D that MDA-based translationists practice is not the OOA/D that "most people" practice.
From reading thru the other posts so far, there seems to be some
confusion. MDA is simply platform independant (I assume you are
talking about the OMG MDA) analysis. Same kind of analysis carried
out in the old Yourdon/SSADM/Waterfall days.
An OOA model is a solution model for functional requirements that is expressed solely in customer terms. As such it maps directly into an MDA Platform Independent Model (PIM) because it does not depend on computing space mechanisms. Traditional OOD and OOP models map into Platform Specific models (PSM). PIMs and PSMs are software solution models.
Note that the 'analysis' from the SA/D/P days is not the same as OOA. Analysis in SA/D/P was more about requirements analysis and problem specification. Under MDA such a model would be a Computation Independent Model (CIM), which is not a solution model (at least not of a software solution). Under MDA things like Domain Models, Data Models, and Requirements Models map into CIMs.
I believe MDA is much more than platform independence. It is really a conceptual framework for transforming one representation into another. The basic paradigm is just
[Input Model] [Transformation Model]
| |
| |
V |
{transformation} <-----------+
|
|
V
[Output Model]
The CIM/PIM/PSM categories simply provide a mapping (and content constraints) to traditional OO development:
Requirements -> OOA Model -> OOD Model -> OOP Code -> executable
CIM PIM PSM PSM
The real keys to MDA are three fold. One is the use of meta models to describe the semantics of model representations in an abstract fashion that is independent of particular model subject matters. That enables generic transformation. The second is the conceptual framework for transformation where a Transformation Model provides tailoring via rules for a specific transformation. The Transformation Model provides a mapping between the meta models for the Input and Output Models. "Walking" that mapping enables unambiguous conversion between the representations. (There is also a Marking Model that allows "painting" for model elements to associate them with particular transformation rules.) Finally, MDA provides standardization, such has UML and XMI. That standardization is crucial to automation, plug & play tools, and the construction of tool frameworks like Eclipse.
In my view MDA really doesn't have much affect of the day-to-day activities of software developers. But it indirectly has profound affect on the tools they use and the supporting environment in which they construct software. So MDA is really about enabling better tools and IDEs rather than A&D methodology.
There is a trend tho, for people either not to do full analysis and go
straight into design, or to do analysis, but with an architecture
already in mind (ie. we shall develop a system and it will be in java
on linux).. Using this mechanism I feel there is a tendency for
people to do analysis by design - that is, produce a design and modify
it until it fits the problem.
True. Elaborationists typically do not provide the same degree of rigor to an OOA model that translationists do. That's because they feel they can always correct any deficiencies later on via iteration. However, a translationist does not have that option because code generators do what one says, not what one meant. I would argue, though, that the notion of getting it right in the first place has value so the elaborationists really should apply the same rigor as translationists to the OOA.
Back in the good old days, I used to do systems analysis where one
modelled the information flow thru the organisation and came up with a
model of the organisation (most organisations didnt have computer
systems and the projects were literally of the computerise this type).
The term system means the entire business including any computer
systems and the people and manual processes invovled.
Been there; done that. B-) (I was a Systems Analyst in the '70s.)
Effectively one is focusing on the enterprise level architecture,
business process, rules and actors in the system (which could be an
entire enterprise), rather than the operational mechanics of how an
existing computer system might work. It was typical to create the
analysis model using a case tool.
Right. It later evolved into Domain Modeling.
Once the platform independant stuff is done, a design is created that
then becomes platform specific (this may be done many times for each
platform supported - a feature of distributed systems and middleware
oriented systems). If a case tool was used, it was simply a matter of
generating code and tweaking it.
While Domain Modeling is platform independent, I don't think it is the same thing as OOA modeling. It is really related to defining the problem context and environmental structure rather than a specific solution.
That is highly valuable to OOA as an input since the software structure should emulate the problem space structure as much as possible. That's because customers don't like change any more than software developers do. So when change occurs in the customer's domain it is accommodated in a manner that will cause minimal disruption to the existing domain infrastructure. If the software emulates that infrastructure, then change will tend to have minimal impact when it filters down to the software because the customer has already recast it to minimize impact. But Domain Modeling is still an input to the OOA process.
This is different from the modern approach that is prevailant where
most developers create a perception of how an entity works (usually an
existing system) and then implement a perceived design directly in
code. My view (although slightly biased) is that more of these modern
techniques fail to use ideal process to correctly understand the
problem, hence the solutions usually are built with lifecycles that
foster rapid change (rapid mistake fixing I call it).
The modern OOP-based processes have a couple of advantages that we didn't have back in the Systems Analysis days. OOA/D has been greatly distilled into cookbook rules and guidelines over the years, culminating in books like Fowler's "Refactoring". In addition, the scale of OOP-based development is restricted to only what a single small team can produce. At that scale things like architectural drift and failure to emulate problem space structure tend not to result in massive rework. Finally, they are using OO technology whose whole purpose is to make maintenance easier. [Also the agile OOP-based processes do incorporate traditional OOA/D mechanisms like CRCs. So, to some extent, it becomes a matter of how much discipline the developers themselves apply.]
However, I agree with you in that I think the pendulum has swung too far away from traditional A&D. Most refactoring is really aimed at the developer's problem of code maintainability due to physical coupling problems in the OOPLs rather than the customer's problem. So unless one provides some sort of Systems Engineering discipline to the allocation of requirements, such processes are not scalable because of architectural drift away from problem space structure.
*************
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
.
- Follow-Ups:
- Re: Let's put this to rest
- From: Robert Martin
- Re: Let's put this to rest
- References:
- Let's put this to rest
- From: H. S. Lahman
- Re: Let's put this to rest
- From: AndyW
- Let's put this to rest
- Prev by Date: Re: OO and RDB war : in the advent of MRAM
- Next by Date: Re: Let's put this to rest
- Previous by thread: Re: Let's put this to rest
- Next by thread: Re: Let's put this to rest
- Index(es):
Relevant Pages
|
