[oclug] [OT] UML question -- not UserModeLinux, the modeling language

[Gilles J. Seguin]

When drafting a class hierarchy should one show that a class 
overrides a method from a super class?
> level of details is up to designer

+---------+            +--------------+   
+  A      |            + <<abstract>> + or <<interface>>
+---------+            +      A       |   
+ +foo()  |            +--------------+   
+---------+            + +foo()       |   
    ^                  +--------------+
   / \                     ^   
   ---                    / \	
    |                     ---	
    |                      |   
+---------+                |         
+  B      |            +---------+   
+---------+            +  B	 |   
+ +foo()  |            +---------+   
+---------+	       +---------+

Which is correct?

Next question: 
-  the '+' that precedes a class member means it is public.
-  A '-' means private, 
-  and a # means protected.  
>- '/' derived attribute

An absence of a prefix means it is an implementation.
> that is news to me, previous spec. says
> for operation
> visibility name(parameter-list): return-type-expression {property-string}
> for attribute
> visibility name : type-expression=initial-value{property-string}
> where visibility is # + -
> The vivsibility marker MAY BE suppressed.
> The absence of a visibility marker indicates that the 
> visibility is not show(not that it is undefined)
>
> Additional kinds of visibility might be define for certain
> programming languages, such as C++ "implementation" )actually 
> all forms of non-public visibility are language-depenedant).
> Such visibity must be specified by property-string or by 
> tool-specific.
> for C++, a static class attribute is
> -tata : unsigned int {static}

I am ok with the first 3 as they map well to Java.  
What is an implementation member function/attribute?

> needs to confirm this, see refinement relationship.
> It is a commitment to certain choices consistent
> with the more general specification but not require 
> by it.

In my hierarchy above, class A is simply an abstract interface class
with some generic functionality (ie it returns 'not implemented' from
most of it's member functions) which are overridden by the subclasses.
Is it appropriate to make foo() an implementation member?

> level of details is up to designer

TIA.