Re: Where to make tradeoffs in OOA/D

Responding to Kowalski...

This led me to a new question: There should tradeoffs between
domainspecific design and technical requirements be done? At which
point in design you would take a look at the technological
requirements, like certain response times in an RT application or the
maximal memory usage (for embedded systems)?

One of the things the OO paradigm brought to the table was a clearer definition of the different stages of a software problem solution as it bridges the <often rather vast> gap between most customer domains and the computing domain. For example, in traditional SA/D/P the answer to you question was actually rather blurred because the notion of 'analysis' was more akin to requirements (problem) analysis than to software solution design.

However, in the OO paradigm, the OOA solution is pretty well-defined. It is a software solution specification that is independent of the particular computing environment. (It is also abstracted purely in problem space terms.) Such a solution can only deal with functional requirements because all solutions to nonfunctional requirements depend upon the facilities, technologies, etc. that are available in the computing space.

So -- assuming that by 'technical requirements' you mean nonfunctional requirements on performance, size, security, etc. -- the answer to your question is that OOA does not address them at all, OOD provides a strategic resolution, and OOP provides a tactical resolution.

For example, in an OOA solution one ignores concurrency and things like RT constraints or distributed boundaries. One is focused purely on the functional correctness of the solution. To provide that all one needs is an asynchronous model of behavior communication and some rigorous methodological rules around things like encapsulation. [Using interacting state machines to capture things like sequencing constraints helps a great deal. B-)] Those methodological practices happen to lead to things like good application partitioning that will inevitably line up with things like distributed boundaries.

Once one is into OOD/P, one can start introducing infrastructures like threads to deal with concurrency and isolate the scope of RT constraints. IOW, one gets to migrate the OOA solution into a specific technical implementation context. So long as the OOA specification is complete, precise, and unambiguous for resolving functional requirements, the resolution of nonfunctional requirements then becomes deterministic. (In fact, full code generators for translation routinely provide exactly this sort of automation and optimization.)


I guess we can agree on that this kind of things should not be taken
into account while modelling the domain, but should clearly be
addressed during some time in design. OO helps to simplify the
translation of a domains workflow into code, by enabling us to find a
representation that is as close to "real life" as possible. An
algorithm or workflow is created by the colaboration of different
classes.
But programming actually means to me, finding a way to explain the
computer what to do that even a human can understand. It implies to
make decisions and tradeoffs between different qualities.There can a
novice like me find a good point to address technical requirements
without sacrificing too much of the original view on the domain?

For example lets take maintainabilty. This one seems to be the most
difficult requirements ince it consists of many subrequirements:
a) The code needs to reflect the problem domain in order to be
understandable by "domain experts". Which is somehow central because
they are the people actually using the software.
b) Workflow should be clearly visible, which usually is a result of a).
c) The code shoud provide a certain amount of flexibilty for future
changes. This basicly means that the classes/ components should be
lossly coupled, means that they just interact with as few other classes
as necessary.

Maintainability is something one gets "for free" with good OO methodologies for OOA/D/P. The paradigm itself is designed around ensuring good maintainability. So to me this is pretty much a tautology. The OO paradigm makes use of things like abstraction, encapsulation, implementation hiding, peer-to-peer collaboration, separation of message and method, and all the rest of those OO practices to ensure that the /construction/ of the the solution will be done in a maintainable fashion.

For example, we avoid traditional spaghetti code because the OO paradigm almost completely eliminates the sort of hierarchical specification dependencies that were commonly found in procedural applications constructed around top-down or bottom-up functional decomposition. OO applications are still functionally decomposed but the manner in which it is done is very, very different than the way it was done in SA/D/P.

At some point a) and c) might seem to be conflicting requirements, e.g.
people tend to implement "manager" classes that are not really part of
the problem domain but still might be usefull in some way.

That's one reason why OOA, OOD, and OOP solutions are derived from one another but have distinct goals and activities. The OOA solution provides the pristine logical view and it will be the most maintainable. However, the final OOP solution may look very different from that view because it must deal with a host of compromises around resolving nonfunctional requirements. Those compromises arise because of the need to represent the solution in a fashion that is consistent with the hardware computational models.

That view will typically be less maintainable than the OOA view because of the compromises. The key is that however OOD/P may modify the solution, they must still satisfy the /specification/ defined by the previous stage. IOW, they can evolve the solution to deal with specific requirements arbitrarily and they don't modify it any more than they must.

One sees this most clearly in automatically generated code. It is not unusual for such code to be barely recognizable -- not unlike trying to trace the 3GL source in highly optimized Assembly language. In a translation environment that isn't a problem because one never maintains the 3GL code; one just modifies the OOA model and regenerates it.

However, if one must manually maintain the 3GL code, one needs to provide an additional transformation to the 3GL code after a correct solution for all requirements has been implemented. IOW, one needs to apply dependency management to refactor the 3GL code to make it more maintainable. Dependency management addresses a pure developer problem by addressing things like physical coupling problems that plague all 3GLs to varying degrees. The principles and guidelines that govern dependency management essentially represent a distillation of good OOA/D practice to ensure that the correct solution does not become broken in the process.



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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Lahman, how ya doing?
    ... One also has to be careful about books with 'UML' or a specific OOPL in the title; they are good at describing how to express your design in the UML or OOPL syntax but they tend to be short on advice about coming up with a good design in the first place. ... The author has made clear in an early chapter that the book is about OOA, and what UML is introduced will serve that purpose. ... When we talked about things like hardware propagation delays before you didn't seem to think they were relevant (i.e., all the controller processing could be completed in a base clock tick interval (100 ms) in the real controller). ... But speaking of maintainability, if it were to be used in a real-time system with Timer reading the system clock rather than incrementing a counter, could it easily accomodate that? ...
    (comp.object)
  • Re: defining quality of OOA and OOD models
    ... must be done) while an OOA model describes the solution (How it should ... Using the term "analysis" to mean "design" should, if nothing else, not ... bridge the chasm between customer problem spaces and the computing ... the problem space abstraction that dominates OOA is ...
    (comp.object)
  • Re: OOA and OOD
    ... > I'm using OOA to analyze my requirements most folks I speak to ... Requirements analysis. ... >>reconciled with the notion that OOA is not a software design activity? ... like Rhapsody that use an augmented 3GL as an abstract action language ...
    (comp.object)
  • Re: Lets put this to rest
    ... What names would call the design activities involved in developing an abstract resolution of functional requirements in pure customer terms and developing an abstract resolution of nonfunctional requirements in computing space terms? ... It's not me who coined the terms to distinguish OOA and OOD activities. ... I can easily cite plenty of examples from classic OOA/D authors who provide a similar mapping of OOA to solutions -- those were literally just the first two books I pulled out of my bookcase. ...
    (comp.object)