Re: UML class diagrams: hiding the attribute list

Responding to Salt...

"flexible logical indivisibility"? A couple of minutes with Google fails to turn up any use of it by anyone else but you. Do you mean anything by it beyond the observation that "real systems have no top"?

It's a notion that is implicit in most OOA/D books, but isn't given a lot of explicit press. More commonly the books will talk about "level of abstraction".

Spaghetti code arose from functional decomposition trees when the higher level nodes were reused, turning the tree into a lattice of dependencies. That was due, in part, to the fact that in traditional functional decomposition the only indivisible operations were at the 3GL operator level. So the OO paradigm eliminates the traditional hierarchical flow of control for functional decomposition by insisting on peer-to-peer collaboration -- one sends a message from the client directly to the service rather than through a middleman.

However, that sort of flattening of the decomposition tree would be insufferably tedious if the only indivisible behaviors were at the level of language operators. So the OO paradigm introduces the notion of flexible indivisibility that varies with the level of abstraction. That is manifested in a variety of ways.

Structurally there are three distinct levels of indivisibility in the OO paradigm: subsystem, object, and responsibility. In the OO paradigm each of these can be abstracted as logically indivisible. Thus in a UML Package Diagram the Payroll subsystem is logically indivisible relative to General Ledger, Accounts Payable, and other subsystems in an Accounting system. The Payroll subsystem can even be subdivided into Benefits, Taxation, and other subsystems. Each represents a unique logical subject matter at a particular level of abstraction with its own unique requirements.

We define interfaces to encapsulate subsystems and hide their implementations in the same way we abstract objects. (One description of a subsystem is an object on steroids.) At the level of a UML Package Diagram subsystems communicate with one another as peers.

Within a subsystem we have a bunch of collaborating objects. Each object abstracts a single, identifiable problem space entity. While the object collects multiple responsibilities, it still represents a logically indivisible, identifiable unit in the problem space and in the subsystem. IOW, the /collection/ of properties is not further divisible at the subsystem's level of abstraction. All flow of control in the solution is done between objects, as represented in the UML Interaction Diagrams. IOW, all collaboration is peer-to-peer between objects through direct message passing.

Each object, though, has distinct responsibilities. Each responsibility is, in turn, logically indivisible at the object's level of abstraction. Each represents a single /intrinsic/ property of the underlying problem space entity that is necessary to solve the problem in hand. Those properties are supposed to be self-contained and, because they are intrinsic, they should not depend on specific solution context (flow of control) outside the object. At the OOA/D level we use messages for collaboration because that decouples the sender of the message from knowing what the receiver will actually do in response to the message. IOW, the mapping of message to operation is an internal object responsibility.

[That leads to another fundamental difference between the the OO paradigm and procedural or functional paradigms. In the OO context flow of control is done by connecting the behavioral dots with messages that are announcements (I'm Done) rather than imperatives (Do This). To execute any operation some set of preconditions must prevail in the overall solution. A message announces that set of preconditions, so one can use rigorous DbC to determine where the message that invokes a particular behavior should be generated. (The preconditions must match the postconditions of the behavior generating the message.) That's why in OOA/D one defines the origin of collaboration messages in an Interaction Diagram, which is at a quite different level of abstraction than individual classes.]

Another manifestation of this notion lies in delegation. In delegation we essentially split up an object and delegate some of its responsibilities to other objects. We do that through a form of decomposition. In effect we subdivide an entity at one level of abstraction into multiple entities at a lower level of abstraction. When we do so, though, the new entities must still be identifiable in the problem space and they must be logically cohesive, unique, etc. The difference lies in the level of abstraction. The OO paradigm ties things together by insisting that each subsystem be at a single level of abstraction. Which segues to...

However, the real power or flexible logical indivisibility shows up when one looks at collaborations across subsystems. Since subsystems can be at very different levels of abstraction, one can abstract the same problem space entity in different ways (e.g., different levels of detail) depending on the subject matter context and level of abstraction. I have worked with a situation where a single scalar attribute in the high level control subsystem expanded into more that a dozen classes with thousands of instances, each having multiple attributes in a lower level subsystem.

This segregation of views at different levels of abstraction is hugely important to large, complex applications. That's because it allows one to focus on a very narrow set of concerns in each subsystem. In addition, it works to greatly simplify each subsystem's view of the problem space. That leads to easier development and more robust systems.

You will note that one is still doing a form of decomposition here. However, it is a quite different paradigm than that of traditional functional decomposition because it is based on problem space abstraction. In fact, one can argue that the only truly unique thing the OO paradigm brings to the table is problem space abstraction. So the use of levels of abstraction is absolutely crucial to good OOA/D.


*************
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
(888)OOA-PATH



.

Relevant Pages

  • Re: Attaching a behavior only to multiple classes.
    ... > so there are 2 levels of abstraction in the example, we may be agreeing, my ... It is about abstracting the problem space. ... entity then that entity owns the responsibility. ... is explicitly abstracted as a peer of [Context]. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... the abstraction is tailored to satisfy the requirements. ... between responsibility and requirement is a rather subtle one. ... Another example is the game I am designing, ... providing a request forwarding service. ...
    (comp.object)
  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... because abstraction is a great way to deal with different views. ... application that can be quite different from one subsystem to another. ... In practice the problem space entities that are being ... but, alas, prior to some of the design changes made in Java 2, it was not so ...
    (comp.object)
  • Re: Abstract public member variales?
    ... I can easily write the client without the burden of knowing how to make good moves, I will merely pass off that burden and make it a responsibility of the entity. ... My point is that problem space abstraction will lead to a quite different allocation of responsibilities. ... Apropos of the current context, I would also argue that looking at each of these individual tasks closely enough to identify individual requirements will make the lack of cohesion and logical indivisibility of your description of Entity.move more clear. ...
    (comp.object)
  • Re: new here, my lang project...
    ... /implementation/ of the responsibility that is changing, ... My assertion is that these standard OO abstraction techniques will ... > Again this is related to the type of dynamicbehaviour change at ... Here I was talking about functions being first class objects. ...
    (comp.object)