Re: UML class diagrams: hiding the attribute list

Responding to Feldwisch...

I want to design some simple class diagrams, and in order to further
simplify them I want to exclude the attribute lists of the classes -
to show class name, specifiers and operations only. That's often
done for interface classes etc., as far as I know; and I hope it is
perfectly legitime for normal classes too, formally?

And is there any standard way to mark the fact that the method list
isn't completetly shown, e.g. with an ellipsis?

Not really. You can leave them off but the static model will be incomplete. AFAIK, UML does not provide a model element to indicate incompleteness.

What you describe is done for Interface elements (the lollipop symbol) on the Class Diagram. But an Interface is not a Class; it simple provides a mapping of external messages to internal class operations.

Why would you want to omit class properties? Classes define object sets and the only distinguishing aspect for set membership are the object properties. Without a complete list of properties there is no way to determine unambiguously which objects should belong to the set.

[Note that at the OOA/D level a class name is simply an identifier of a collection of properties, not a collection of objects. By convention we name classes as a problem space abstraction of the collection of objects but that is really for the convenience of the developer. Note that this becomes more obvious when one looks at subclassing. An object is a composite of properties in a complete line of ascent from leaf subclass to root subclass. The classes along that path simply define relevant property sets that are incorporated into the object.]

*************
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: SoA Vs OO
    ... data type, they are just functions that operate on a data type, and if ... When doing functional design, you start with what you want done. ... mostly it's lists and trees (there isn't much need felt ... so the subclass can't even access it. ...
    (comp.object)
  • Re: SoA Vs OO
    ... data type, they are just functions that operate on a data type, and if ... When doing functional design, you start with what you want done. ... mostly it's lists and trees (there isn't much need felt ... so the subclass can't even access it. ...
    (comp.programming)
  • Re: Features that can only be provided by the implementation?
    ... specific behaviors of standard CL functions allow but not mandated ... such as an interface to sockets.) ... Built-in Functions ... Getopt Parameter lists ...
    (comp.lang.lisp)
  • Re: Naming conventions?
    ... I don't think there is a single widely used convention. ... lists are generic enough that this seems quite plausible, ... are good reasons for not allowing type and variable names to conflict. ... I don't recall all the exact proposals or the exact votes, ...
    (comp.lang.fortran)
  • Re: SoA Vs OO
    ... Say the task is to have a list of things that can display on a screen. ... It's difficult to replace code that uses lists ... in the idea of "abstract everything in classes, and if a new subclass is ... > Remember also we're talking implementation inheritance here, ...
    (comp.programming)