Advice on use case diagram and corresponding textual description
DesperateDan
cases.
I then have a textual description which expalins the actor's steps of
interactions with all three use cases.
I've described all the steps under ONE use case heading.
My question is: Should I have layed out my text under 3 separate use
case headings?
Ken Lloyd
A Use Case references a category of Activities, and Activities reference a
category of Actions.
You can put the Activities for one Use Case under its own Activity diagram
and each Activity can have its own Activity Diagram full of individual
actions, etc.
Ken
> --
> You received this message because you are subscribed to the
> Google Groups "UML Forum" group.
> To post to this group, send email to umlf...@googlegroups.com.
> To unsubscribe from this group, send email to
> umlforum+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/umlforum?hl=en.
H. S. Lahman
> I have a use case diagram with an actor associating to three use
> cases.
>
> I then have a textual description which expalins the actor's steps of
> interactions with all three use cases.
>
Lloyd made an assumption about your problem that wasn't as obvious to
me, so I would like to push back on whether that was really what you
were doing.
A use case captures a logical context for the actor interacting with the
system. That high-level interaction may be broken up within the use case
body into multiple steps for detailed interactions with the actor (e.g.,
selecting menu items) that are always done in the overall context. Those
steps are defined within the use case body.
The thing I want to be sure about is that the "actor's steps of
interaction" you are talking about are at a higher level of abstraction
than an individual use case's steps. That is, they describe an overall
context that has its own rules for when the use case contexts come into
play. IOW, a high-level use case to describe interactions among
lower-level use cases in a broader context.
If so, then Lloyd's suggestion of using an AD seems reasonable to me,
even though mapping use cases as processes seems a stretch. (Probably
because I am biased by using UML only for design and never for
requirements specification.) However, I would point out that you doing
something that Jacobson did not have in mind when introducing use
case-based OOA/D. Those rules you are describing govern how the user's
problem space works, not how the software works. IOW, they represent
Domain Modeling of the context of the software usage.
FWIW, I don't think UML is a good tool for that. You will note that in
UML there is no way to specify the content of use cases. That's because
they were regarded as requirements specifications and UML was
<originally> created as an OO software design notation. Use cases were
only added to UML to provide some degree of traceability of the design
to the original requirements. The domain context of the user's overall
use of the software is even further removed.
I guess what I am saying is that you are well beyond the ken of software
design. So whatever works for your development environment (i.e.,
whatever communicates the relevant information best) is Just Fine and I
really wouldn't worry much about whether your usage is using UML
properly. IOW, as long as everyone with a stake in the information is on
the same page about what is being specified, you are good to go.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html