>Is there a way in some standard UML diagram to indicate which classes actually have code to implement the methods?
>
>I'm faced with several situations in documenting and fixing an existing class hierarchy designed and developed by another developer that is no longer around. where I need a diagram to make life easier
>
>1) an abstract method is defined in a superclass and whether or not it's implemented in each subclass
>
>2) a subclass contains code for an inherited method
>
>3) a class defines a method, but doesn't have code in the method (it's not really an abstract method it's an error in the design)

1) The method should be in italics.

3) Um, don't know, use the info notation I guess.

2) A glance at the UML spec shows that there is no specific notation for whether a method had implementation code in it or not. Only that an abstract method name should be noted in italics.

However, it appears that you can attach a note to the method drawing a line from it to a curly bracked line of text which can describe implementation details or language specific info.

Here is a paste of the UML spec taking about notating Operations in a Class Diagram. (This is the only diagram I know of where this would be valid.)

****************

3-44 OMG-Unified Modeling Language, v1.4 September 2001
3.26 Operation
Entries in the operation compartment are strings that show operations defined on
classes and methods supplied by classes.
3.26.1 Semantics
An operation is a service that an instance of the class may be requested to perform. It
has a name and a list of arguments.
3.26.2 Notation
An operation is shown as a text string that can be parsed into the various properties of
an operation model element. The default syntax is:
visibility name ( parameter-list ) : return-type-expression { property-string }
• Where visibility is one of:
+ public visibility
# protected visibility
September 2001 OMG-UML , v1.4 Operation 3-45
3
- private visibility
~ package visibility
The visibility marker may be suppressed. The absence of a visibility marker
indicates that the visibility is not shown (not that it is undefined or public). The
visibility marker is a shorthand for a full visibility property specification string.
Visibility may also be specified by keywords (public, protected, private, package).
This form is used particularly when it is used as an inline list element that applies
to an entire block of operations.
Additional kinds of visibility might be defined for certain programming languages,
such as C++ implementation visibility (actually all forms of nonpublic visibility are
language-dependent). Such visibility must be specified by property string or by a
tool-specific convention.
• Where name is an identifier string.
• Where return-type-expression is a language-dependent specification of the
implementation type or types of the value returned by the operation. The colon and
the return-type are omitted if the operation does not return a value (as for C++
void). A list of expressions may be supplied to indicate multiple return values.
• Where parameter-list is a comma-separated list of formal parameters, each
specified using the syntax:
kind name : type-expression = default-value
• where kind is in, out, or inout, with the default in if absent.
• where name is the name of a formal parameter.
• where type-expression is the (language-dependent) specification of an
implementation type.
• where default-value is an optional value expression for the parameter, expressed
in and subject to the limitations of the eventual target language.
• Where property-string indicates property values that apply to the element. The
property string is optional (the braces are omitted if no properties are specified).
A class-scope operation is shown by underlining the name and type expression string.
An instance-scope operation is the default and is not marked.
An operation that does not modify the system state (one that has no side effects) is
specified by the property “{query}”; otherwise, the operation may alter the system
state, although there is no guarantee that it will do so.
The concurrency semantics of an operation are specified by a property string of the
form “{concurrency = name}, where name is one of the names: sequential, guarded,
concurrent. As a shorthand, one of the names may be used by itself in a property string
to indicate the corresponding concurrency value. In the absence of a specification, the
concurrency semantics are unspecified and must therefore be assumed to be sequential
in the worst case.
3-46 OMG-Unified Modeling Language, v1.4 September 2001
3
The top-most appearance of an operation signature declares the operation on the class
(and inherited by all of its descendents). If this class does not implement the operation;
that is, does not supply a method, then the operation may be marked as “{abstract}” or
the operation signature may be italicized to indicate that it is abstract. A subordinate
appearance of the operation signature without the {abstract} property indicates that the
subordinate class implements a method on the operation.
The actual text or algorithm of a method may be indicated in a note attached to the
operation entry.
If the objects of a class accept and respond to a given signal, an operation entry with
the keyword «signal» indicates that the class accepts the given signal. The syntax is
identical to that of an operation. The response of the object to the reception of the
signal is shown with a state machine. Among other uses, this notation can show the
response of objects of a class to error conditions and exceptions, which should be
modeled as signals.
The specification of operation behavior is given as a note attached to the operation.
The text of the specification should be enclosed in braces if it is a formal specification
in some language (a semantic Constraint); otherwise, it should be plain text if it is just
a natural-language description of the behavior (a Comment).
A stereotype keyword in guillemets precedes the entire operation string, including any
visibility indicators. A property list in braces follows the entire operation string.
3.26.3 Presentation Options
The argument list and return type may be suppressed (together, not separately).
A tool may show the visibility indication in a different way, such as by using a special
icon or by sorting the elements by group.
The syntax of the operation signature string can be that of a particular programming
language, such as C++ or Smalltalk. Specific tagged properties may be included in the
string.
A method body may be shown in a note attached to the operation entry within the
compartment (Figure 3-24 on page 3-47). The line is drawn to the string within the
compartment. This approach is useful mainly for showing small method bodies.
September 2001 OMG-UML , v1.4 Operation 3-47
3
.
Figure 3-24 Note showing method body
3.26.4 Style Guidelines
Operation names typically begin with a lowercase letter. Operation names are in plain
face. An abstract operation may be shown in italics.
3.26.5 Example
Figure 3-25 Operation List with a Variety of Operations
3.26.6 Mapping
A string entry within the operation compartment maps into an Operation or a Method
within the Class corresponding to the class symbol. The properties of the operation
map in accordance with the preceding descriptions. See the description of Section3.25,
“Attribute,” on page3-41 for additional details. Parameters without keywords map into
Parameters with kind=in, otherwise according to the keyword. Return value names map
into Parameters with kind=return.
If the entry has the keyword «signal», then it maps into a Reception on the Class
instead.
report ()
BurglarAlarm
isTripped: Boolean = false
PoliceStation
1 station
*
{ if isTripped
then station.alert(self)}
alert (Alarm)
+create ()
+display (): Location
+hide ()
-attachXWindow(xwin:Xwindow*)
3
The topmost appearance of an operation specification in a class hierarchy maps into an
Operation definition in the corresponding Class or Interface. Interfaces do not have
methods. In a Class, each appearance of an operation entry maps into the presence of a
Method in the corresponding Class, unless the operation entry contains the {abstract}
property (including use of conventions such as italics for abstract operations). If an
abstract operation entry appears within a hierarchy in which the same operation has
already been defined in an ancestor, it has no effect but is not an error unless the
declarations are inconsistent.
Note that the operation string entry does not specify the body of a method.