Use Cases Describing Interfaces

[ASP]

In a Use Case diagram, I have the following use cases, among others:

"Add An Annotation"
"Modify An Annotation"
"Delete An Annotation"

In turn, they form an association link to the use case, "Query Help Database".

Here's my problem. The system allows for three types of annotations: text, audio & audiovisual. It must specify what type of annotation to "add" or "modify" (ie, text, audio or audiovisual). Deleting an annotation requires no such specificity. Conceptually, I view the annotation types as public interfaces "implemented" by the "add" and "modify" annotation use cases, rather than "subclassing" the annotation types. The latter would later require multiple inheritance in C++, as both "add" & "modify" (in their eventual class forms), would provide the base classes to the annotation type subclasses (in their eventual class forms). As multiple inheritance is not widely implemented across programming languages, some other mechanism, such as delegation, would be needed. In short, I'd rather avoid using generalization links between the respective use cases and use interfaces instead.

What is the best approach to visually describe these "interfaces" in a use case diagram?

Thanks for your input.

[ASP]

Just a thought...

Disregarding my reasoning in the original post, is it accurate to state that a generalized association in a use case diagram simply notes a level of specialization but does not really advocate how the specialization is achieved?

In other words, is it safe to assume such a link can represent an interface and that including an <<interface>> stereotype clarifies that means of specialization?

Thanks.

[sargasso]

I, for one, cannot see how the "interface" can change the definition of the use case.  

AddAnnotation, ModAnnotation and DelAnnotation all seem to be standalone and, IIGYD, extensions of QueryHelpDB.  Whether a specific annotation be textual, audio or AV is IMO irrelevant when evolving, discussing or documenting the use case. Consider AddAnnotation, what difference is there regarding the outcome of the usecase between the "media" of the annotation?  I cant see one - the normal outcome is "annotation is added" and the alt is "annotation isn't added".  Next week, annotations may be allowable in holograms, nephograms, or xylophones. The use case doesn't change.

hth
bruce

p.s. Dont design in use cases, describe.  All three extensions seem to have a pre-condition "help topic selected", mod and del seem to have an additional pre-condition "annotation exists" (and probably / properly) "annotation is owned by user".  All three have a single outcome post-conditions "annotation table updated".  There are probably several scenarios you could consider above and beyond the obvious true/false outcomes such as "moderators can delete any annotation" etc etc.  These are the concerns of the use case model, not how the system needs to behave given a certain specific charateristic (medium) of a specific annotation.

[ASP]

sargasso,

Thanks for the reply.

> Consider AddAnnotation, what difference is there regarding
> the outcome of the usecase between the "media" of the
> annotation?
You're right. Once again, I'm guilty of letting my programming background get in the way.

> Next week, annotations may be allowable in holograms,
> nephograms, or xylophones.
Lol...

> Dont design in use cases, describe...
Excellent points all the way... thanks.

One trivial question. Even though the types of annotation are in fact irrelevant, would you describe them in the 'add' & 'modify' annotation scenarios, would you simply attach a note to those use cases with the annotation type descriptions, or would you specify the annotation types as requirements and omit them entirely from the use cases? Basically, I'm trying to determine the how to best notate these annotation requirements, so I don't forget them later when it is time to implement them.

Cheers...

[sargasso]

In a couple of ways, depends on the DE culture...

Glossary entry-
Annotation: Any additional informational content appended in any medium to a help topic by a user.

Requirement entry-
"the system shall support annotations to help topic items formatted and submitted in the following media: ..."

Physical Intervention entry-
<SMACK> I've told you, text, audio AND AV!!! <SMACK>


UML is a communication tool, like all tools how you use them depends on the job at hand!  
 


bruce

[ASP]

>  Physical Intervention entry-
> <SMACK> I've told you, text, audio AND AV!!! <SMACK>
Lol... There's been a ground-swell support for this approach. Who knows, it may be added to the UML 2.2 spec...

Thanks for your feedback.