![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Exception Cases & Alternate Course Use Cases Topic Summary: Connecting an Activity Diagram to another Use Case Created On: 1-Oct-2008 20:40 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Here's an interesting scenario that I'd like someone to help me figure out a better/ different technique.
I like to create Use Cases, and then represent the Use Case scenario in an activity diagram. During the construction of the scenario, I first focus on the "happy day" scenario - when all goes according to plan. Then I go back through each step of the scenario (pause and reflect on each activity) and ask: what can go wrong? are there any alternatives or options? what happens if ...? The answer to those questions yields several more Use Cases - what I call Exception Cases or Alternate Courses - which I can also represent as a Use Case in a UCD, and I can also create an activity diagram to represent - sometimes a permutation of the original activity diagram, sometimes a completely different set of activities. Here's my issue: how do I create an association (or other relationship) between the orginal activity where I asked the question 'what might go wrong" and the exception case/ alternate course Use Case? I don't see an ability to create a relationship to show me this line of thinking. |
|
![]() |
|
![]() |
|
Hi Raymond,
I'm not sure what You're trying to do, but for me, it seems a little bit odd to "invent" new Use Cases based on the exceptions You find in the main Use Case. The main Use Case represents some sort of functionality, that the system provides. The exceptions to the "sunshine scenario" should be covered by the main Use Case, and described in the same or another activity diagram for that same Use Case. I think You are trying to bend the rules here, and that might be why Rhapsody does not allow the relation You describe. But hey, I might be wrong on this, but I have not seen Your approach before ![]() Regards Jesper Gissel Johnson Controls, Denmark ------------------------- Jesper Gissel Johnson Controls Denmark, Marine Controls |
|
![]() |
|
![]() |
|
Here's my issue: how do I create an association (or other relationship) between the orginal activity where I asked the question 'what might go wrong" and the exception case/ alternate course Use Case? I don't see an ability to create a relationship to show me this line of thinking. I guess my question is, are you asking whether there's a UML representation for such a thing or are you asking if there's a way to notate this in Rhapsody so that it does something (like creating slightly different code or perhaps demonstrating this relationship in ReporterPlus)? If it's the former, the extend dependency (formerly "extends relationship") may be what you're looking for, as it is essentially a conditional branching from the main use case. You would then use extension points in your decriptions and diagrams to show where the alternate use case begins and ends. You can see a brief description at http://www.agilemodeling.com/essays/useCaseReuse.htm (I'm not affiliated with the company. It's just one of the first results on Google). We used alternate use cases as error scenarios at my current job (although they were not explicitly added to the use case diagrams, just in the descriptions) and one choice bit of advice I'll give you is to standardize on your vocabulary before people start writing them, particularly how you notate what causes the branch and where in the base use case's events it happens (we had a particular bugaboo with the word "from" with some people reading "The alternate case starts from Step 4" as starting right after Step 4 and some that it started instead of Step 4). If you're looking for it to have an actual effect... I can help you if it's ReporterPlus you're looking for it to trigger in. And, if you explain exactly what you need, maybe someone can help you for things like code generation. |
|
![]() |
|
![]() |
|
I learned a slightly different use case & scenario approach before UML and UML use cases become popular. I've been attempting to see how I might "recreate" that approach using SysML in Rhapsody. I'm a systems engineer, so I don't care about the autocoding, auto-simulation capabilities. I use the tool to express analysis & design concepts.
I view the Use Cases as a hierarchy of usage definitions, and the activity diagrams as expressions of individual scenarios. So, in my understanding, I create several different scenarios for each use case - generally, a "happy day" scenario (the main scenario) and several variants to address exceptions, alternate courses, and extensions (more detail needed). I recognize how I can create a "super scenario" activity diagram that includes all the possible exceptions and alternate courses, but that can be a very busy diagram. I'd rather look at each scenario as one activity diagram, and build permutations of that diagram based on my analysis of exceptions and alternates. Right or wrong, this is the way I think through the progression. When I started finding that each activity may yield an alternate course or exception, then I realized that each activity may have a direct relationship to these "other use cases" (exceptions and alternate courses) - something like a branch, but more like an evolution from one activity to another "use case". I know how to create a Use Case diagram and show a relationship between the 'happy day' scenario and the exceptions and alterante use cases, but when I realized that the real relationship between the exception/ alternate courses was to the main use case activity/action level, I couldn't see how to create a relationship between those two objects. Probably, I'm just trying to use the tool "wrongly" from intention, and I'll have to figure something else out. |
|
![]() |
|
![]() |
|
Yes, the idea of using the extend relationship between use cases is what I'm attempting to do. (I don't care about the autocoding semantics.) I can illustrate the extend relationship between my 'happy day scenario' main use case, and all the exception cases & alternate courses. That's easy on the Use Case Diagram. The real power, however, is in the activity diagram.
When you create an alternate course or exception use case, how do you align/ create a relationship between the activity diagram for the main scenario and the activity diagram for the alternate scenario? How do you show the relationship between one activity gone awry and the Use Case that addresses that "awriness"? The article that you point to expresses the ideas that I'm exploring, but fails to go into the activity diagram level, where the practical scenario definition lives. A Use Case diagram is, frankly, useless without the activity diagram that goes with it. (I look at it as a general roadmap, whereas the activity diagram is a sequence of instruction.) The article also starts relating "inheritance" of uses cases, which I've never seen realized. Does that mean you also inherit the activity diagram? Can you create a slight variant of that inherited activity diagram? Lots of interesting ideas, but I don't see them realizable in the UML/SysML tools, yet. |
|
![]() |
|
![]() |
|
As no-one seems to have mentioned it yet, the recommended book on use cases is "Writing Effective Use Cases" by Alistair Cockburn --- although this was written for software engineering, it is mostly applicable to system engineering too. You can see extracts on Google books and you may find electronic versions of his drafts on the web, but worth buying the book.
Exception scenarios should be part of the main use case, which is why you can associate a number of sequence diagrams with a use case. Extension points have been mentioned by the previous contributors. If you want to use a given set of actions/messages in several other sequence diagrams, you use a reference sequence diagram (interaction occurrence). You can also place a number of activity views under a use case, each of which has an activity diagram (if you use the Harmony profile supplied with Rhapsody you'll find a stereotype called Activity View in there). Hence you have a number of activity diagrams for a use case. If you want to use a given set of activities in several other activity diagrams you use a reference activity. Thus if you want to use different activity diagrams for the exception scenarios, what you could do is: - Under the use case, e.g. Uc2MyUseCase, create your "top" activity view, e.g. Uc2_BBView (if you are modelling black-box, or Uc2_WBView for the white box stage) --- this may have all the "sunny day" activities, but branches where things may go wrong. - Also under the use case, create other activity views for the exception activities, e.g. Uc2_BBView1_FirstException. - After the relevant branch in the top activity view, add a reference activity that refers to the activity diagram that captures the exception handling. The reference activities don't have to be exceptions --- they can be chunks of the action that you simply want to move out of the activity diagram to make it less cluttered. A nice way to organise the activity views is to have them match the set of sequence diagrams. Hope this gives further food for thought. |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.