Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

UML Analysis structure 1

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
I have a small project that involves analysis (using UML).
Is there a standard list of documents that should be delivered in order to complete the analysis? (I have use cases, class diagrams , activity diagrams etc. Is there anything else?)
 
Hi I am a 3rd year IT student sitting at my desk with OOAD this morning so in ignorance and for need of a breather in a section covering frameworks and patterns, I send you a peanut's worth ... Interaction diagrams?

Perhpas you would like to share an aspect of your project work with me for my enlightenment's sake!

Regards
[cat]
 
Getting close. Different people have different ideas, but I believe you need:
Use Cases - close to user requirement - needed for:
Users to understand what is happening
Testers to see what User Acceptance tests are needed
Developers, to get dynamic understanding of class diagram
Class Diagrams - close to design
Users if they follow it down this far
Testers to build System/component tests
Developers, to get OO structure, design and architecture
Data Analysts , to get data structures
Sequence Diagrams - show the consistancy of the above two.
Anyone who is not convinced by the consistancy between the above two.

These can be supplimented with
OCL - to define business rules (I prefer plain english)
Entity Relationship Diagrams - not part of UML but nearly always required. Most good CASE tools create it.
Collaboration Diagrams - These are very similar to sequence in informational content and so should not be drawn unless there is good reason. These two diagrams (Sequence and Collaboration are the Interaction Diagrams the previous writer referred to). Good reason is when dealing with singleton classes (individual specific objects) (I use them gor GUI Navigation, showing how you get from one screen to another.
Activity/State Diagrams - used to describe classes when they are complicated. Only draw them if the class needs them.
Component Diagrams - if your programs identify components.
Deployment Diagrams - Ditto.

My whole philosophy is dont draw anything that is not needed.
Always deliver the first set. Only draw those in the second set if you have to; then decide who will read it and decide if that is what they really want.

Dont draw diagrams because they are there. Only draw them if several people are going to use them 'Are going to' NOT 'might'. Keep it simple.

Gil
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top