Re: Let's put this to rest

On Tue, 20 Jun 2006 11:09:11 -0400, Robert Martin
<unclebob@xxxxxxxxxxxxxxxx> wrote:

On 2006-06-14 13:47:57 -0400, "Davor" <davorss@xxxxxxxxx> said:

OOA model should not be a "solution" for the system we are building.

The system we are building is already a solution of some problem.
Every solution is really a problem at the next level. So is an OOA a
statement of the problem we are solving, or a description of the system
that solves that problem? Or a description of the subsystems within
the system that solves that problem?

This recursive descent of problem-solution pairs is one of the reasons
that I think analysis, design, and implementation are inextricably
coupled. It is often useful to take a step back and try to describe
the problem; but it is also virtually impossible to do this in terms
that lack some assumptions about solution and implementation.

To me in a perfect world when a system is created so would the OO
Analysis model, when the system evolves with all its changes, so would
the analysis model. That model exists to be a snap-shot of the
current system at any given point in time.

OO Design is a mechanism to see how the snap-shot would work at some
point in the future 'with' the set of given changes having been made
to it.

I consider that OO Analysis is not a statement of a problem, not a
description of a system that solves a problem. It is simply a
description of a system for the purpose of understanding.

However, it is not a perfect world and OOA models do not always exist,
one needs to create them, and it is also possible that the system may
evolve after or even during the time that the model is created (hence
change control is important).

OOA to me is a model of the system that you are looking to change, not
the problem nor the solution. OOD is the model of the system with
the problem solved. Requirements analysis/management is the working
out of the problem.

Remember it is perfectly possible to build an analysis model of the
existing system and once it is at a point where the it can be
understood, to realise that the solution simply requires a change to
the people process/componant rather than to the software componant.
There have been a few projects I have seen that have ended during the
needs analysis phase of requirements gathering for this very reason.


Im not keen on coupling on coupling of
analysis/design/implmenentation, but thats becasue of quality process
concerns, rather than technical merits of either mechanism. Coupling
often works well in small software project, whereas separation could
be considered a requirement of large scale systems (with very good
change control).

I think if one tries to go from a platform specific analysis to a
platform specific design and implementation as often happens in small
project one is going to end up carrying legacy artifacts from one to
the other and will most likely end up viewing the target system in
terms of the source system (or the other way round).

Perhaps the benefit of MDA is that is forces the decoupling, that is,
one starts with a platform dependant analysis model, makes it
platform independant (and therefore drops off the legacy artifacts),
transposes it into a platform independant design, then applies new
platform dependancy for the new target platform(s).

In effect I think with MDA, one is really creating a software pattern
out of the problem and solution (to use a deisgn pattern metaphor) so
that when ones pattern library fills up, one con produce software
solutions in a more factory production line style process.








.

Relevant Pages

  • Re: This iPhone SDK thing is a pretty big deal...
    ... An extremely capable and flexible hardware platform (with tech specs ... Great marketing and amazing industrial design. ... On top of all of this, the iPhone and the iPod Touch are, of course, ...
    (comp.sys.mac.advocacy)
  • Re: sysgen_capture and cloning questions.
    ... BSP, so it's easy to reuse those changes over and over in new designs (the ... making changes to the platform aren't ever the actual reason but in my case ... Putting a cloned item in the OS Design would only be ... Wouldn't that be the project root under pbworkspaces? ...
    (microsoft.public.windowsce.platbuilder)
  • Linux embedded system based on MX51
    ... Starting from Oct., 2009, Yuan-ying Technology invest to ... i.MX35 development platform and the related turn key solution. ... Support multiple format of HD720P video decode ... Computer, Factory Automation, HMI design. ...
    (microsoft.public.windowsce.embedded)
  • Re: dotnet speed
    ... see performance problems at the level that abandoning the .NET platform ... The best advice I can offer on the efficiency front is: ... everyone writing your kind of program is writing in C# or VB.NET, ... either by adjusting your design or improving your code. ...
    (microsoft.public.dotnet.csharp.general)
  • Re: Why compiler not generating any warning ?
    ... > So why not tell him that the actual bit pattern and structure layout ... > varies from platform to platform, ... It looked like portable C99 code to me. ...
    (comp.lang.c)