Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: reddog on December 13, 2004, 07:20:55 am
-
Hi,
I have never used UML in a project before and I have been trying out EA for a few weeks now. I have decided to model a small 'demo' project which includes a user login package, which will manage system users, groups and rights.
Now with a “real developers don't do UML” hat on I might 'see' boundary, control, entity classes and a database access layer etc. I would then draw up some class interfaces, walk through the events of the module and decide what each class does, choose the architecture and tools and then start coding...
But holding myself back and putting on a “real analysts do UML” hat, I would need to create a use case model for the package.
Now I could:
a) Have a use case like 'manage users, groups, rights', with scenarios like 'add user', 'list users', 'edit user' etc. Then proceed to sequence diagrams, placing MVC classes in as required etc.. or
b) Have a use case like 'manage users, groups, rights' which 'includes' (using another diagram for detail?) other use cases like 'add user', 'list user', 'edit users' etc, proceeding as above to sequence diagrams etc.
It seems that scenarios, being textual in EA, are in effect 'hidden' from the use case diagrams (while living as sequence's). But if I place too much detail in use cases I can 'swamp' the diagrams.
So:
Q. Which, if either, of the above approaches is preferred ie do UML users tend to model with fewer use cases and more scenarios or create more use cases and then use includes?
(I am trying hard to look at this with an analyst hat on, honest... now where did I put my compiler?)
-
I think the confusion comes from trying to look at a use case as a diagram.
While UML does indeed include a use case diagram as a standard model, the textual information is what matters. The diagram is almost irrelevant.
In other words, it's not "EA" that makes them textual, EA reflects the reality of what a use case is.
The answer to your question depends on the level of detail you're looking to include in the scenario. A use case should address a single user goal from beginning to end, with all of the allowable variations in achieving or failing to achieve that goal documented within the scenarios or alternate flows.
-
reddog,
you should opt for a).
In short Use Case modeling is synthesis, not analysis. You should emphasise on removing superfluos use cases over finding new ones (okay - very simplistic, but with the right bias).
Also I'd encourage you to search this forum for "use case" (extend search range to 999 days!) and/or for "crud". There are some very helpful threads in here. Maybe you could come back with additional questions after further reading.
-
And yeah, Thomas is right, you should use a). The <<includes>> relationship should be limited to use cases that can stand on their own.
If you have a group of related use cases, don't include all of them into a single big use case, rather put them in a package.
-
c) "manage users, groups, rights" as a package. other use cases like 'add user', 'list user', 'edit users' etc, proceeding as above to sequence diagrams etc.
Consider: does "manage users, groups, rights" have a single unambiguous outome of value to the related actor? If not its IMO not a use case.
Refer other posts on use cases are not functional decomposition models.
Bruce
-
Thanks all,
Reading your comments has made me realise that as a UML newbe I had reached my first case of (use case) analysis paralysis:
"... the textual information is what matters..."
"... address a single user goal from beginning to end.. “
“... document within the scenarios or alternate flows."
"...Use Case modeling is synthesis, not analysis"
“...<<includes>> ...limited to use cases that can stand on their own. “
“...use cases are not functional decomposition models.”
I was hung up on 'use case diagramming' my way
to the sequence diagrams etc...
reddog
-
You're on the right way :)
-
As you sort out your use cases and scenarios be careful when taking the next step to sequence diagrams. Don't get hung up on the implementation details when drawing your diagrams. Instead focus on flow and relationships. Also, don't try and show so much in one sequence diagram. If you do all of your basic path and alternate path scenarios correctly, each scenario can be documented in a seperate sequence diagram very simply. I personally don't like diagrams with tons of conditionals or opt fragments all over the place. They get to hard to manage.
-
Thanks for that.
In my demo 'manage users, groups & rights' package it seems there are three main entities. Maybe user_group and group_rights as well - although I see them as tables, I am not sure yet if they are entities.
As each main entity requires add, delete, edit, list, find etc I seem to have no choice but to create several sequence diagrams. It was this that lead me to 'think' that I should divide the model into numerous use cases and why I had ignored the scenario text.
Thanks again to all.
-
It seems things like add, edit, list, ... would be more related to independent uses. A use case is used to describe a single function the system provides for an actor. So, I am not sure your example is the same as what I was sugggesting. Here's an example: The Add new user use case could have alternate path scenarios such as:
1) Database error
2) User already exists
3) Connection problems
4) User aborts
.
.
.
What you do in these scenarios all relate to the same use case. But, trying to show all of them in one sequence can get very messy. I was recommending that you try and design sequence diagrams for each scenario instead of one that handles all scenarios for a single use case. (It depends on how complicated your alternate path processing is).
-
The problem is that there are two completly different ways of "use case and scenario" methods/methodologies.
The Ivar Jaccobson one (also used in the book Advanced Use Case Modeling) and the Alistair Cockburn approach -- http://alistair.cockburn.us -- (also described in Bernd Oestereichers Book OOSE Object Oriented Software Engineering).
Rule of thumb:
A Use Case has a textual description with branches (alternate pathes, error handling). Such a description can be transformed into an activity diagram.
A Scenario has a textual description as well, but without any branch conditions. It has associated sample data (use able to make a test case). The "way" through the Scenario is one possible path through the Use Case (so you define which path is choosen at every branch point by defining suitable data). A scenario is best described with a sequence diagram.
Note: I never use sequence diagrams with branches (which are possible according to UML).
Both diagram types can be used to discribe more than I proposed above and both can be used to describe simpler or different stuff.
I would also opt for a) :D
However I did not understand the <<include>> remark.
Well ... the standard dependencies <<include>> and <<extend>> are defined different everywhere anyway ... <<extend>> e.g. has a complete different meaning depending wether you use Ivar Jaccobsons or Alistair Cockburns method to describe use cases.
So for <<include>> I can only say: the usecase which is included usually can not stand for it self. Include in terms of use case modeling is analogous to calling a function/method in terms of programming. While a function can stand alone ... it simply serves no purpose alone. A use case which is ment to be included often usually has no human actor associated, but only device actors. That means, it is never used individually as stand alone use case.
Example: famous ATM machine. Use Case might be: "withdraw money", "check account balance", "wire transfer money" and in USA: "deposite money". All can be triggered by the user/customer. So ... no "identify" use case so far. But all or one of the use cases likely has a <<include>> relation to "identify customer".
Rule of thumb: only "extract" use cases for later <<include>> reference which you plan to reference often and unchanged.
In short Use Case modeling is synthesis, not analysis
He he, I think that confuses the novice reader. But from a philosophical standpoint its right. You can "design/synthesize" with use cases as good as with classes. Every single method in classes can be split into more fine grained methods. The fine grained methods can be moved to (and delegated to) aggregated classes (<<included>> use cases) or to super or sub clases ((extensionpoint foo) and <<extend>>)
Anyway, what ever you want to do: keep the sequence diagrams aas simple as possible. It does not matter if you find 5 use cases with 6 scenarios each or wether you find 6 use cases with 5 scenarios each. The worst case is: you find X use cases with *one* scenario each!! But if your analysis is correct: all scenarios together show all ways to use your final system.
The art is t find a minimum set of usse cases with a suitable way to describe them and easy scenarios. Because then the implementation will be more easy.
Greetings,
angel'o'sphere
P.S.
TrtnJohn e.g. has his opinion because he (obviously to me) uses the Alistair Cockbun approach, sargasso likely as well. Their posts are fine nevertheless.
-
You caught me angel. I learned most of my use case analysis from Craig Larman's: "Applying UML and Patterns" book. He uses Cockburn's techniques. His book is a very nice UML and OO design for dummies, (like me). reddog, you should check it out.
-
Just an addition to <<include>>/<<extend>>. You should avoid using them unless you're a) familiar with use case modelling and b) those use cases are needed more than once! It does not make sense to expose these includes/extends unless you really need them. Simply for the reason that you are doing analysis (paralysis) instead of synthesis :)
-
Phew...
I think the comments about use case and methodologies is interesting and timely, as I have become a bit Confucius over all this:
I hear and I forget.
I see and I remember.
I do and I understand.
I expect that once I have completed my 'demo' package it will become clearer.
PS. I did a quick trawl through the EA UML forum for 'books', listed below by publication date. I make no assumptions about this small and incomplete sample, but Analysis Patterns (Fowler 1996) and Applying Use Case...(Rosenberg, Scott 2001) were mentioned most often. I have not read any of them, yet...
....................................
Analysis Patterns: Reusable Object Models (Martin Fowler, 1996)
Software Reuse (Ivar Jacobson and Martin Griss,1997)
Use Case Driven Object Modeling with UML: A Practical Approach (Doug Rosenberg, Kendall Scott, 1999)
Writing Effective Use Cases (Alistair Cockburn, 2000)
Applying Use Case Driven Object Modeling with Uml: An Annotated E-Commerce Example (Doug Rosenberg, Kendall Scott, 2001)
Patterns of Enterprise Application Architecture (Martin Fowler, 2002)
Applying UML and Patterns (Craig Larman, 2004)
-
Use Case Modelling (Bittner and Spence , 2003)
-
Hi reddog,
my tip: go with Larman!
Fowlers Application Integration book is another must-read, but for SOA, not for UML.
Enjoy,
Hans
-
Larman is good but dense, and somewhat developer-centric. He's probably the best starting point for a developer as long as you're not responsible for developing requirements that have to be approved by a large number of stakeholders.
If you need more info on requirements development than Larman provides, Writing Effective Use Cases by Cockburn is a good starting place, as are Managing Software Requirements by Leffingwell and Widrig or Software Requirements by Wiegers.
-
If you're looking for more active and practical help than a book can provide you then Dunstan Thomas provide UML consultancy using EA and they're UK based (I'm not affiliated to the company b4 anyone asks - I just know of them and their services and thought it may be of use).
If you're interested their webby is www.dthomas.co.uk.
P.S UML 2 For Dummies is an excellent book - I use it as a reference as its easy to read and full of excellent tips. Don't be put off by the Dummies bit - it sounds a bit silly but its actually amazingly useful for both novices and experienced practitioners alike.
-
Thanks to all again,
In fact on the strength of these EA forums I have today
paid out real money for the EA Corporate Edition, I consider it a Xmas prezzi to myself....
I can also see myself buying a few of the books that have been mentioned, once I've checked them out!
reddog