Re: Metaphor-oriented programming

Responding to Digehode...

I just wanted to draw your attention to an article on metaphor-
oriented programming. MOP seeks to go beyond objects and aspects by
revolutionising not just the partitioning of concerns, but also the
manner of interaction.

Read the article here: http://www.dis-dot-dat.net/?item=metaphor

What the article does not explain is how MOP differs from routine OOA/D or AOP. MOP may, indeed, be a revolutionary way or approaching software design but, if so, I don't think the article did a very good job of making that case.

For example, in an OOA model every object, responsibility, and relationship is an abstraction (analog of) of something in the problem space. When doing that abstraction one routinely employs techniques like anthropomorphization, delegation, and whatnot. One also strives to emulate the problem domain structure in the software structure. Finally, the OOA model is expressed purely in customer terms even though it is a specification of a solution in the computing space. IOW, the OOA model /is/ a metaphor of the problem space.

As a more detailed example, in the paper's anatomical example four metaphors were cited for the Right Leg: piston, pendulum, root, and knife. One can readily envision problem contexts where those would, indeed, be appropriate abstractions for a right leg. For example, in the Physics subsystem of a computer game the right leg of an Ogre might well be modeled as a Piston object.

We routinely do this sort of problem space abstraction in OOA models and quite often the objects are very different than the underlying problem space entity. Thus the notion of Account and Balance in a business problem space with be modeled as an Account object with a Balance attribute is a subsystem dealing with accounting. But in a GUI subsystem it will be modeled as separate Window and Control objects and in an RDB access subsystem it will be abstracted in terms of Table and Tuple. Window/Control and Table/Tuple are clearly metaphors for the problem space notion of Account/Balance.

Conversely, the four metaphors cited would be completely irrelevant in most other problem contexts. The point being that when we abstract the problem space in an OOA/D model our abstractions are tailored specifically to the problem in hand by selecting the correct metaphors. IOW, it is what we do.

I would also point out that every OOPL compiler and UML transformation engine in the world uses AOP techniques when generating Assembly or 3GL code. Things like relationships in the OOA/D are /always/ implemented as generic, cross-cutting concerns. At the level of OOA/D design patterns represent an abstract application of AOP across specific problems. Finally, in OOA/D one routinely seeks to identify problem space invariants and encode them while relegating details to external configuration data. An invariant is just an abstraction of a concern that cross-cuts the problem space and it is often realized in terms of metaphor abstractions.

Finally, the paper asserts that MOP allows the programmer to deal with the Right Leg in "vague, half-baked, and uncertain ways". I don't think that is a desirable approach for specifying software solutions. While it is certainly true that most customer domains are vaguely defined and even inconsistent, that is a problem for requirements specification, not software design. Before attempting to model a software solution, one needs a requirements specification that is complete, precise, and unambiguous. Once one has properly formed requirements, the software designer shouldn't be vague, half-baked, or uncertain about what to do.



*************
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: Object identity
    ... And it is equally clear a different object of the Employee set exists ... "date" is a well-defined problem space concept so it can be abstracted ... make a distinction between that abstraction and its instantiation at run ... context and how much is unique to the problem in hand. ...
    (comp.object)
  • Re: Havent done anything real with OOP yet.
    ... seriously complicated and developing an OO simulation would be ... responsibilities to objects. ... problem space in an OO fashion. ... simplified to the same level of abstraction as the simulation assumptions. ...
    (comp.object)
  • Re: Object identity
    ... And it is equally clear a different object of the Employee set exists ... space entities. ... The notion of "date" is a well-defined problem space concept so it can be abstracted as an object. ... an established OOA/D author who defines an object as anything other than an abstraction of an identifiable problem space entity and who does not make a distinction between that abstraction and its instantiation at run time as a memory image. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... You are surely correct that the domain allows categorization if I ignore maintenance. ... But when we abstract Person as an object we use abstraction to extract the invariant commonality of individuals _with respect to the problem in hand_. ... All I am suggesting here is that you can apply abstraction to the conceptual world of the game and identify useful classifications that will describe groups of game entities abstractly. ... Whatever you actually know about the problem space is fair game for abstraction, even if it isn't specifically in some SRS. ...
    (comp.object)
  • Re: Deinition of OOP needed for programming language documentation
    ... often devolves into a heap address without problem space semantics. ... > anyone doing programming irregardless of their knowledge of design. ... that is bleeding cohesion all over the map. ... >> was confused about the level of abstraction of your documentation ...
    (comp.object)