Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Marvis on March 01, 2005, 02:53:58 am
-
I created a lot of Use Cases that exists of more Use Cases thru the Composite Element feature.
I made also many activity diagrams, that realizes the Use Cases. But I don't know how to relate both diagrams.
My first thought is to make an hyperlink on the Use Case diagram to the Activity Diagram and draw a dependency, but the Use Case diagram get filthy with hyperlinks. Is there a better way?
Please help!
-
Hi,
you can create the Activity diagrams as child diagrams underneath a Use Case.
I am not sure what you mean here:
I made lots of Use Cases, that exists of more Use Cases tru the Composite Element feature.
Thanks,
Bruno
-
The *real* way should be to create Use Case Realizations or Collaboration (at least one per Use Case) that relate to the appropriate Use Case via a Realize relationship. Underneath the collaboration you can place the Activity diagrams as child diagrams.
According to the Use Cases that consist of many Use Cases via Composite Elements you are probably on the wrong path. You should likely spend some time in reading about Use Case analysis (or better synthesis!) in order to set up a correct Use Case model.
-
Bruno:
"I made lots of Use Cases, that exists of more Use Cases tru the Composite Element feature."
It means that I have a browsable component to another Use Case Diagram. But it is only another level of detail for that Use Case and not a realization.
thomaskilian:
I already tried to use collaborations. But if I add an Activity diagram to that collaboration, the way to get there is or a hyperlink, or via the project view. I would like to browse (double-click) the collaboration and see it's realization. But I think that is not inside EA?
-
Try right-clicking on the collaboration. You'll find a context menu with "New Child Diagram". That will place arbitrary diagram types below the collaboration. There is no way I know of to directly open the diagram from the collaboration icon. Instead select it, press Alt+G and open it from the browser then.
-
hmmmm....too bad. Then I think ill keep continuing using hyperlinks to the Activity Diagram.
Thanks for the advise.
-
Again, why not to make the Collaboration a Composite Element? Then double-clicking the Collaboration will automatically bring up the child activity diagram.
Bruno
Try right-clicking on the collaboration. You'll find a context menu with "New Child Diagram". That will place arbitrary diagram types below the collaboration. There is no way I know of to directly open the diagram from the collaboration icon. Instead select it, press Alt+G and open it from the browser then.
-
Ah, this works ok, but the problem still exists. But it is a more structural problem then I thought of in the first place.
I have at least 2 diagram per Use Case.
1. A more detailed Use Case diagram
2. An Activity diagram
I can't make them both browseable in one component. So either way, you need 2 items on your diagram.
I like the way of the collaboration, so I think about it to redesign the model structure.
Many thanks for your time!
-
Hi,
I am generally a bit suspicious about a Use Case with a more detailed Use Case diagram underneath. It sounds like you are trying to turn Use Cases into hierarchical elements, which they aren't. You may want to rethink the approach.
Having said that, it is certainly possible having multiple child diagrams underneath a Use Case, but double-clicking UC marked as a composite element will automatically take you only to the first one of the diagrams. You may not be able to avoid the hyperlinks after all :-) What you could do is to add one more child diagram and place nyperlinks to all the other child diagrams on it. Clicking on the Use Case will automatically bring up the diagram with the hyperlinks then.
Hope this helps!
Bruno
-
Since I use Use Case Scenarious, my Use Cases are much smaller - I didn't know about scenarios before reading "Applying UML and Patterns" recently.
I organize all accompaniing models of a Use Case in a package with the same name as the Use Case - EA has a great implementation of packages, I use them to structure my models everywhere.
So for each Use Case, I have at least on realization either to one diagram reference (if no more is needed) or to a package which then contains further diagrams.
-
Bruno:
This is something I thought about too. I will discuss this in my team.
I don't know why you are suspicious about detailed Use Cases. Hopefully I can explain a little bit more about it, because I don't know if I am doing the right job.
I have a model with Use Case that include/extend more Use Cases that include/extend more Use Cases. Different actors can use the Use Cases. To keep overview, ths first diagram shows the primary Use Cases. To see a Use Case, you browse to is Use Case diagram. Now you see one specific Use Case with it's included/extended Use Cases.
This is the right way to do it?
-
Rolix:
I model my scenarios with an Activity diagram. I still use the rules for scenarios. But the reason to use Activity diagrams is that one picture says more than 1000 words.
So it is possible to convert the Activity one-on-one to the scenarios of the Use Case.
-
Hi Marvis,
do I understand it right that you a Use Case, for example "Open Account" and underneath the Use Case you have a child diagram that contains the same UC Open Account, together with all the inclusions, extensions etc? I see, that actually does make sense.
The way I originally understood it was that you had a UC that you would then be breaking down into more detailed ones, which generally does not work. Sorry about the confusion!
Bruno
Bruno:
This is something I thought about too. I will discuss this in my team.
I don't know why you are suspicious about detailed Use Cases. Hopefully I can explain a little bit more about it, because I don't know if I am doing the right job.
I have a model with Use Case that include/extend more Use Cases that include/extend more Use Cases. Different actors can use the Use Cases. To keep overview, ths first diagram shows the primary Use Cases. To see a Use Case, you browse to is Use Case diagram. Now you see one specific Use Case with it's included/extended Use Cases.
This is the right way to do it?
-
That's right. I think I did not explained well enough. But I am glad that I am doing the right job.
Many thanks for your help.
Maurice
-
Since scenarios aren't really element in the diagram there isn't any way to make them composite elements. Personally, I don't find the Use Case property window sufficient myself and often build a seperate Word document for detailing the Use case. If you do that you can include diagrams generated with EA into the document to produce a very nice design specification. Another option is to create Use case elements for each scenario and use the realize association between the primary Use case and the scenario. You could then make each element a composite element and navigate to the diagram that goes with each. (Not sure if this is really UML compliant though).
-
Another option is to create Use case elements for each scenario and use the realize association between the primary Use case and the scenario. You could then make each element a composite element and navigate to the diagram that goes with each. (Not sure if this is really UML compliant though).
Neither do I - but when it's use is justifiable it really works well!
One time I felt it was justified was when the outcomes of the scenarios were so wildy different that they really needed to be separate use cases. However from the users point of view they were the same use case. Using the <<scenario>> realises use case technique allowed us to progress the analysis phase with a good agreement and communication between the designers and the users.
bruce
-
Another point to consider is that if your Use Case is getting too complex maybe you aren't factoring them correctly. I start to get nervous if my scenarios get too complex. This is usually an indicator to me that I am starting to become less user/actor centric and more system oriented when defining my Use Cases. In these cases I usually started with something too broad. To fix this I try and rethink the user point of view and break the cases into more simple tasks. And then I use the <<include>> association to tie the Use Cases together. I really don't like having huge scenarios that need an Activity diagram in order to understand them.
-
I find Use Case modelling always a bit touchy. The simple reason is that you interface between REAL world and ABSTRACT model. This abstraction process has been described in many informal ways so far. Unfortunately you will never reach a stadium where you can have a complete formal way to transform REAL to ABSTRACT (as far as I understood the main thesis of Gödel). So you will always have to use your stomach to decide about the process and how you use it.
-
I thought Gödel said that you couldn't have a complete AND self-consistent system ?
As I have said, I did like the Shlaer-Mellor OOA approach.
-
No. It's simpler. You just can't have a complete axiomatic system. This BECAUSE you can put an axiom inside which will crash your system. So my intention is to say: you will never have a formal way to come from reality to abstraction. (I'm no mathematictian though, only an old computer scientist. Read: old 'computer scientist', not 'old computer' scientist.)
-
I thought (old (computer scientists) ) were just practical mathematicians anyhow !
PS. Did you get to the end of G.E.B. http://www.amazon.co.uk/exec/obidos/ASIN/0140179976/
-
I got by without any mathematics except for parts of my school knowledge (btw. my wife has a doctors degree in Applied Numerical Mathematics and I can ask her whenever it's neccessary).
And yes: I read it (understandig parts of it) in the year G.E.B. was published. Some 2 or 3 years ago I read it again and was even more impressed than the first time. I like Eschers mind puzzling pictures. I have about a hundred CD with Bachs music which I listen regularly. And maybe I'll *really* understand Gödels thesis when I'll going to read G.E.B. the third time ;)