More about "realize" ...
I'm establishing dependency from my User Interface elements and my "System Services" ...
What about in the other direction (upward?)
When I model a use case in what I call my "overview" diagram, I would:
- Place UC in middle of diagram
- Place Actor to left of UC
- Add an association (not use) from Actor to UC, then on association property target, change to navigable (this makes the arrow appear)
I do this to clearly indicate that the actor intitiates the UC. Rarely do I have two actors, but sometimes I do (kind of old school on that point - <<uses>> does not display the specified navigation info. Not that important but I do use it as a source of information that I can mine for training, and some other doc gen tricks...)
- Place the business domain element (identified from the UC's verb-noun forms) and draw a dependency FROM domain element to UC
- Directly below the UC I drop a stereotyped element (screen, from the Custom tool list) and then add dependency from Screen to UC)
- IF, and rarely there are, you have an association between that UC and another UC, I then drag these onto the diagram and place on the right side so the association links lead to the UC.
Sometimes I will see additional links that were added somewhere else, so I just set their visibility on the diagram to not show.
If there are quite a few related UCs (like when I am diagramming the general form, and I have several specialized UCs) then I will show that "view" on another diagram and just place a hyperlink to it.
BTW I use a consistent pattern of hyperlinks (both name and location) to allow you to quickly navigate the UC's related diagrams, like:
- Return to Catalog,
- Overview,
- Domain, - Class diagram with only those elements that have context with the UC
- Requirements, - Display Stakeholders associated with the UC and their Needs (requirement stereotype used during stakeholder analysis. You might want to see my post on the {search term}Onion Model {search term} of stakeholders.) The actual requirements that this UC must deliver are usually associated with the activities in my Flow diagram.)
- Flow, - Activity diagram that diagrams the flows through the use case, formatted to easily show Basic and Alternate pathways leading to the UC's desired result, and Exception flows that lead to the UC's undesired result. Note: If you follow good modeling practices, then you should ONLY have 1 partition defined for each UC actor. Then when you document the flows, each actor that participates has their own partition (aka swim lane) in the diagram.
HINT: This info can be mined for testing, discussing and identifying security roles, building scenario data sets, and of course TRAINING documentation and scope…
- UI. - Class diagram, the "Screen" element, that I name with the UC's name - format "UC Name-UI". This class is then where the high level requirements of the UI are placed. The lower level requirements are either attached to a wireframe built in EA, or to a Class that "Stands-In" for the UI - attributes (elements both displayed and not displayed and operations (features) of UI.
This VIEW has great use to the UI developers...
[/list]
I just believe it is so critical to document the UC clearly and have the views (diagrams) that each stakeholder group needs and wants.
Think this should become a separate topic? (e.g. Diagramming Approaches to UCs)
As always, if anyone wants to see some examples or talk offline, just send me a message.
David aka Bioform
