I tried using UML with rational rose in my last project. It seems to me that sequence diagram is more useful than the use case diagram. In fact, I don't know what is the point to draw use cases diagram in the first place. I have to create the sequence diagrams from the scratch even though I had the use case diagrams already. Am I correct? Regards
Good Question! I have been also struggling to make best use of UML in design. The greatest goal in design i see is to find the objects and their collaboration among other things. use case digram helps me to see the whole system from a helicopter view or bird's eye view. writing the whole use case in form of user response and system response clarifies the workflow and scenarios, sub-scenarios. but next when i go to interaction diagram, the biggest decission i have to make is what r the objects? I find this the most difficult and doesn't know how best we can explore the objects. Book says CRC Diagrams help but then, for drawing CRC u need to know the classes and that is as good as knowing the objects. can some of you tell how you ppl go abt the whole design process. regards
So far I have adopted a hybrid approach, albeit using OMT rather than UML. I start with a Data Flow Diagram (which probably reflects baggage I carry from Structured Design) because I find that I can develop and walk thru these with users. I then move to a class diagram with the source/sinks and data stores from the DFD becoming an initial set of classes. The processes from the DFD are usually allocated to whichever class's state is most affected. I have not begun to use Use Case / Sequence diagrams but have used a statechart in an event intensive situation so can see some merit. However my area tends to be information driven, or state rather than event, so that's rare. I also use an IDE to produce HCI prototypes early on because users respond to those productively. If the point of modelling is to understand the requirement, capture it and then communicate this to implementers its contribution can't be taken out of context. That is to say you have to work with the environment you're in. If they are not ready for UML you have to go with the flow but look for opportunities to influence progression and adoption. I'm sure I will finish up selecting a few notations that I'll use often and the others will be history.... sorry three amigos @ Rational! ;-)
Use cases are for user analysis. You go to the user and say, "how do you do this" and turn it into a use case. ultimately, these use cases can serve as test scripts. The use cases help you to determine classes that you will need. Certain phrases come up during the use case development, "Office", "Customer", "Purchase", etc that turn into either classes or possibly methods in classes. Once candidate classes have been identified, you can start looking at sequence diagrams. ISTM that if you skip use cases and go right to sequence diagrams, you are making too many assuptions about how the users will use your application.
Hi all Here is a thumbnail sketch of my personal variant of the RUP 1 Gather raw requirements from the stakeholders 2 Use the high level use case diagram to describe the system's users and the value they get from the system 3 Validate with the stakeholders and revise 4 Use activity diagrams (1 per use case) to capture the interactions between the actor and the system for each use case 5 Use a text flow of events to capture the details for each use case 6 Capture supplementary specs for security, performance, scalability, etc 7 Review and revise
8 Pick a few use cases for analysis 9 Discover some classes in a class diagram 10 Use sequence diagrams to describe the interactions between objects for a use case 11 Cycle back and forth between the sequence diagrams and the class diagram until the sequences seem coherent and the responsibilities of the classes make sense. 12 Repeat for other use cases 13 Review and revise with other developers 14 Select technologies based on the analysis model 15 Use a class diagram to describe the packages and layers for the system and their dependencies 16 Review and revise with other developers and stakeholders 17 Use class diagrams and sequence diagrams for each use case to describe the object interactions and the responsibilities of each class 18 Review and revise design 18 Produce Java from UML (forward engineering) 19 Elaborate code 20 Unit and integration test 21 Revise / refactor design and repeat
Here is my understanding: Identify classes from and draw class diagram for each user case. Draw sequence diagram based on the identified classes. Am I correct? Shall we identify classes from sequence diagram too? Given the design manner described in the textbook, I wonder anyone has really followed those steps. I am not saying that those steps are not good. But can anybody who thinks UML great helpful in the real world design give us some practical, not necessarily aesthetic perfect manners? Regards
I counted 3 "review and revise" in Mr. Arrington's list above. Plus 1 "review and refactor". It's all very good advice, but on my job people cringe from a single "revise" word. When I say "refactor" I get a pat on the shoulder and advice to take it easy. Ugh! Could people from trenches describe the practices in their cubicles? Recipies for getting others into refactoring?