Re: UML class diagrams: hiding the attribute list

Responding to Feldwisch...

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.


Yes, you're right; I'm not using abstract interface constructs though, but
I'm "modelling" interfaces as a class (C++), and want to visualize the
interface structure for a not really computer scientific audience too. So I'm just stereotyping the interface classes with <<interface>>, which is
quite self explaining.

I'd be cautious about these goals for a couple of reasons. First, C++ is a 3GL and, therefore, it makes a number of compromises with the hardware computational models. For example, 3GLs all employ type systems rather than class systems. While it is true the original Booch notation that was one parent of UML was sometimes known as Graphical C++, OOA/D has come a long way since the early '80s.

I'd also be concerned about trying to use UML to describe software designs to non-software people. The OO paradigm is not intuitive even for software developers so it becomes even more of a challenge to use it to communicate with non-software people. There is a lot of conceptual and mathematical baggage that underlies the bubbles & arrows. Notions like flexible logical indivisibility or even basic abstraction of problem spaces being limited to knowledge and behavior are not things people in most customer spaces are comfortable with. IME you spend more time explaining OOA/D to interpret the model than explaining the solution itself.

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.


As Ilja wrote - I want to burn the details down to the core. It's for a
thesis, describing some software design; and it's not possible to fully
explain all details.

If you are just trying to explain pieces of the design, fine. Then you omit what isn't necessary to a given piece and don't worry about rest. If it isn't relevant to the explanation in hand you don't need to indicate that it's there. Note that this is just a variation on IID; you only specify what you need for the current increment and ignore everything else.

But if your goal is to explain the full software design, then my push back is that it is a solution specification that must be complete, precise, and unambiguous at the OOA/D level of abstraction. If you leave things out the solution simply won't seem work in the audience's view. Think of your audience as a code generator. If the specification is incomplete or ambiguous or imprecise the code generator will need to fill in the details. Without assistance in doing that, the results are problematic. The same thing happens with people; to visualize the solution they will fill in the gaps from their own personal experience and that may lead them to misinterpret the solution design

Does anybody know wether there's a formal obstacle to just 'hide' the
attribute list? Is this commonly accepted?

As I said, just omit them. That's fine if you aren't describing the whole design but it is definitely not commonly accepted if you are.


*************
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



.