Prev: global variables in UML class diagrams (novice question)
Next: Creating a "toy" OO/AO language...
From: Alan on 30 Sep 2007 18:46
I have a question on recommended modeling practices. . . . I know
how to specify alternative flows for a use case. However, should
those alternative flows be added to the normal flow in an Activity
Diagram? Also, should there be a separate Sequence Diagram for each
alternative flow?

I`m thinking it best to incrementally develop things in this
order:

- Use Case

- Sequence Diagram (normal flow for a use case, at the system level
--- no classes yet, other than a "System" class)

- Activity Diagram (normal flow for a use case, system level)

- Class Diagram (initial)

- Sequence Diagram (normal flow, with System class decomposed into
other classes (from Class Diagram) relevent to this use case

- Activity Diagram (normal flow, with System class decomposed into
other classes (from Class Diagram) relevent to this use case

- Update all diagrams based on what was learned and make them
consistent

- State Machine Diagrams for each Class

- Add alternative flows into class-level Activity Diagram

- Develop Sequence Diagram for each alternative flow

- Update all diagrams based on what was learned and make them
consistent

Does this make sense? Thanks, Alan

From: Mark Woyna on 1 Oct 2007 10:06
On Sep 30, 5:46 pm, Alan <jalantho...(a)verizon.net> wrote:
> I have a question on recommended modeling practices. . . . I know
> how to specify alternative flows for a use case. However, should
> those alternative flows be added to the normal flow in an Activity
> Diagram? Also, should there be a separate Sequence Diagram for each
> alternative flow?
>
> I`m thinking it best to incrementally develop things in this
> order:
>
> - Use Case
>
> - Sequence Diagram (normal flow for a use case, at the system level
> --- no classes yet, other than a "System" class)
>
> - Activity Diagram (normal flow for a use case, system level)
>
> - Class Diagram (initial)
>
> - Sequence Diagram (normal flow, with System class decomposed into
> other classes (from Class Diagram) relevent to this use case
>
> - Activity Diagram (normal flow, with System class decomposed into
> other classes (from Class Diagram) relevent to this use case
>
> - Update all diagrams based on what was learned and make them
> consistent
>
> - State Machine Diagrams for each Class
>
> - Add alternative flows into class-level Activity Diagram
>
> - Develop Sequence Diagram for each alternative flow
>
> - Update all diagrams based on what was learned and make them
> consistent
>
> Does this make sense? Thanks, Alan

When are you going to get around to actually writing the software? :-)
Seriously, don't take this stuff too seriously. The goal of modeling
is to communicate the requirements to the development team, not see
who can create the largest collection of documents and diagrams. Who's
going to keep all this stuff updated? Is that time factored into your
estimates?

Now, answering your question. You should use a separate diagram
whenever it makes it clearer what you're trying to model. If adding an
an alternate flow to an existing diagram confuses the reader, then
it's time for a new diagram. Any decent UML modeling tool will support
multiple diagrams, so don't be afraid to use them.

Not all use cases need Activity Diagrams. If the use case is fairly
straightforward, the use case document may be sufficient.

Sequence diagrams with only the "System" class would appear to be
rather useless. A use case diagram depicting the actors interacting
with the system would probably be sufficient, unless the ordering of
the interaction with the system is significant.

Also, State Machine Diagrams are only needed for classes that exhibit
state-based behavior. Not all classes do, so you'll likely need very
few of these diagrams.

Mark

P.S. You should check out Agile Modeling.

From: H. S. Lahman on 1 Oct 2007 10:45
Responding to Alan...

> I have a question on recommended modeling practices. . . . I know
> how to specify alternative flows for a use case. However, should
> those alternative flows be added to the normal flow in an Activity
> Diagram? Also, should there be a separate Sequence Diagram for each
> alternative flow?
>
> I`m thinking it best to incrementally develop things in this
> order:
>
> - Use Case

Ideally this should be provided by someone else (i.e., the customer)
since it is a form of requirements specification.

>
> - Sequence Diagram (normal flow for a use case, at the system level
> --- no classes yet, other than a "System" class)
>
> - Activity Diagram (normal flow for a use case, system level)
>
> - Class Diagram (initial)
>
> - Sequence Diagram (normal flow, with System class decomposed into
> other classes (from Class Diagram) relevent to this use case
>
> - Activity Diagram (normal flow, with System class decomposed into
> other classes (from Class Diagram) relevent to this use case
>
> - Update all diagrams based on what was learned and make them
> consistent
>
> - State Machine Diagrams for each Class

If you are using statecharts for active objects and either abstract
action language or activity diagrams to describe what methods do, then
sequence diagrams are redundant. [For example, the translation tools
that do full code generation from OOA models routinely provide sequence
diagrams automatically for documentation. Also, abstract action language
has largely supplanted ADs for describing detailed dynamics because it
is a lot easier to maintain.]

The normal sequence of OOA/D development is:

(1) identify problem space entities that are relevant to the problem.

(2) identify problem space relationships that exist between the entities
in (1) that are relevant to the problem.

(3) identify knowledge and behavior responsibilities that are needed to
solve the problem in hand and associate them with the problem space
entities from (1) that would logically own them. (Some anthropomorphism
is usually required.) Identify classes to capture responsibilities that
are shared by more than one entity.

(4) capture problem space sequencing constraints among object behavior
responsibilities in object state machines.

(5) define the specific problem space rules and policies that are to be
implemented in each behavior responsibility.

(6) connect the dots of the overall solution flow of control with
messages between the behavior responsibilities from (3) and (5).

Note that the first three are all done in a Class Model that describes
the invariant static structure of the problem space and the last thing
that one worries about are sequences of operations for the specific
solution.

Naturally life is rarely so simple and identifying the objects and
responsibilities necessary to solve the problem requires some vision of
what the problem solution will look like. So most developers use a white
board sequence diagram to keep track of object interactions as they
develop the Class Model. But the goal is simply to record a high level
view of who needs to talk to whom and would not have a great deal of
message detail. IOW, that version of the Sequence Diagram is a throwaway
for just holding notes about the way the overall solution works.

Note that the process is completed when one can identify attributes,
methods, state machine transitions, and relationships that abstract
every business rule or policy captured in the use case AND one can trace
a path through those model elements that corresponds to each use case.
But the use case does not directly drive the abstraction of the problem
space in terms of objects, responsibilities, and relationships. That is,
there is no cookbook technique for deriving OOA/D models from use cases
any more than there is a cookbook technique for deriving OOA/D models
from traditional hierarchical requirements specifications. Doing that is
why software designers get the Big Bucks.



*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



From: EventHelix.com on 1 Oct 2007 20:58
On Sep 30, 6:46 pm, Alan <jalantho...(a)verizon.net> wrote:
> I have a question on recommended modeling practices. . . . I know
> how to specify alternative flows for a use case. However, should
> those alternative flows be added to the normal flow in an Activity
> Diagram? Also, should there be a separate Sequence Diagram for each
> alternative flow?
>
> I`m thinking it best to incrementally develop things in this
> order:
>
> - Use Case
>
> - Sequence Diagram (normal flow for a use case, at the system level
> --- no classes yet, other than a "System" class)
>
> - Activity Diagram (normal flow for a use case, system level)
>
> - Class Diagram (initial)
>
> - Sequence Diagram (normal flow, with System class decomposed into
> other classes (from Class Diagram) relevent to this use case
>
> - Activity Diagram (normal flow, with System class decomposed into
> other classes (from Class Diagram) relevent to this use case
>
> - Update all diagrams based on what was learned and make them
> consistent
>
> - State Machine Diagrams for each Class
>
> - Add alternative flows into class-level Activity Diagram
>
> - Develop Sequence Diagram for each alternative flow
>
> - Update all diagrams based on what was learned and make them
> consistent
>
> Does this make sense? Thanks, Alan

The sequence you have described makes sense. But sometimes you might
have to iterate between sequence diagrams and class diagrams.

Also, the state machine diagrams would be an overkill for simple
classes.

--
EventStudio 4.0 - http://www.EventHelix.com/EventStudio
Model in Plain Text; Generate Sequence Diagrams in PDF/Word

 | 
Pages: 1
Prev: global variables in UML class diagrams (novice question)
Next: Creating a "toy" OO/AO language...