Re: Use Case Alternative Flows and Activity & Sequence Diagrams



On Sep 30, 5:46 pm, Alan <jalantho...@xxxxxxxxxxx> 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.

.



Relevant Pages

  • Use Case Alternative Flows and Activity & Sequence Diagrams
    ... how to specify alternative flows for a use case. ... should there be a separate Sequence Diagram for each ... Sequence Diagram (normal flow for a use case, ... other classes (from Class Diagram) relevent to this use case ...
    (comp.object)
  • Re: Use Case Alternative Flows and Activity & Sequence Diagrams
    ... how to specify alternative flows for a use case. ... should there be a separate Sequence Diagram for each ... Sequence Diagram (normal flow for a use case, ... other classes (from Class Diagram) relevent to this use case ...
    (comp.object)
  • Re: Use Case Alternative Flows and Activity & Sequence Diagrams
    ... should there be a separate Sequence Diagram for each ... Activity Diagram (normal flow for a use case, ... identify problem space relationships that exist between the entities in that are relevant to the problem. ... Identify classes to capture responsibilities that are shared by more than one entity. ...
    (comp.object)
  • New module to generate ladder diagrams
    ... generates lader diagrams (aka callflow diagram, call sequence diagram, ... The module's synopsis is below. ... # The file must be of a recognized format: ...
    (comp.lang.perl.modules)
  • Re: Text-based sequence diagrams?
    ... Check out Sequence Diagram Editor. ... > I've tried a few existing drawing tools which claim to have UML support ... > me from having to waste the same week figuring it out all over again). ...
    (comp.object)