Simple Approach to UML
Ranked #78,666 in Computers & Electronics, #1,211,843 overall | Donates to Save the Children
Keep things simple
UML is a large language. And just like English just because its large doesn't mean you should use all of it. You often see people expand it to make it more complicated.
My approach to UML has always been to use the simplest diagrams and solution I can. As I said to someone recently you only want to include information that helps the next step of development or MUST be done that way. Try not to trap the next person in the development to use your (maybe not so good) solution. You may think you know the ultimate solution and many times you will but for those you get wrong that can incur large costs to a project.
Over time I shall be using this lens to document my tried and tested approach to UML. It you have any questions or think I'm wrong then please used the Guestbook.
First you need a UML Tool to get you on your way.
My approach to UML has always been to use the simplest diagrams and solution I can. As I said to someone recently you only want to include information that helps the next step of development or MUST be done that way. Try not to trap the next person in the development to use your (maybe not so good) solution. You may think you know the ultimate solution and many times you will but for those you get wrong that can incur large costs to a project.
Over time I shall be using this lens to document my tried and tested approach to UML. It you have any questions or think I'm wrong then please used the Guestbook.
First you need a UML Tool to get you on your way.
Things About Simple UML
- Simple UML
- A diagram showing how the use cases are related to one or more sequence diagrams. But we don't what lonely sequence diagrams.
- Great Stuff on Amazon
- Use Case
- Example Use Case
- Sequence Diagrams
- Sequence Diagrams Tips
- Class Diagrams
- Automatic Documentation
- Great Stuff on Amazon
- General Hints and Tips
- New Guestbook
Simple UML
Quite key to a simple UML approach is to ensure traceability is maintained. If it doesn't flow it will not be used.
With this approach each Use Case with trace to a Use Case Diagram. Each Sequence Diagram will trace to a Use Case. Each Class Diagram traces to Sequence Diagram.
I remember the days working on Safety Critical software where you could be asked to leave a company for introducing something that didn't trace back to a requirement. So while that doesn't seem to happen these days its probably best to consider the rule.
With this approach each Use Case with trace to a Use Case Diagram. Each Sequence Diagram will trace to a Use Case. Each Class Diagram traces to Sequence Diagram.
I remember the days working on Safety Critical software where you could be asked to leave a company for introducing something that didn't trace back to a requirement. So while that doesn't seem to happen these days its probably best to consider the rule.
A diagram showing how the use cases are related to one or more sequence diagrams. But we don't what lonely sequence diagrams.
Great Stuff on Amazon
Use Case
I think I prefer defining them as User Stories and I like the idea of it being a story. Make the story interesting.
Don't have one for setting something, then one for editing it and then a final one for removing it.Have a single story that defines, edits and deletes it in one go. If things later get too complicated the pull section out into 'includes' and deal with it that way.
Its a bit like in the olden days when we used to do step wise refinement but even though we would not do that with code these days we are talking about analysis here!
Don't have one for setting something, then one for editing it and then a final one for removing it.Have a single story that defines, edits and deletes it in one go. If things later get too complicated the pull section out into 'includes' and deal with it that way.
Its a bit like in the olden days when we used to do step wise refinement but even though we would not do that with code these days we are talking about analysis here!
- Once we have our Use Cases they are ideal for using you our functional testing
Example Use Case
Here is a silly example of a Use Case using something we all know about.
- The <<actor>> thirsty Drinker switches on the kettle. The kettle boils and switches itself off.
- <<actor>> Thirsty Drinker empties the kettle into a cup. The Kettle is now one cup less full.
Sequence Diagrams
Sequence Diagrams are incredibly useful but usually neglected in favour of spending time on developing class diagrams (information that the code shows quite well).
Sequence can be used to show a number of aspects:
Sequence can be used to show a number of aspects:
- How different sub-systems within the system are used to provide the functionality required. Often done within the analysis stage of development and we don't want to be showing too much detail of messages/calls internal to any sub-system.
- How each subsystem is used to provide its features to the rest of the system. Often I will include a set of Use Cases (or rather they are 'includes') so none nerds can determine what is going on as well. Once again we don't want to show the internal workings of the sub-system.
- A detailed flow of control through the system to determine the location of a bug or to gain understanding. Would not systematically include these within the model but if the information exists then might as well include them unless it adds confusion.
Sequence Diagrams Tips
A few tips I would give to help you develop your sequence diagrams:
- Naming: To keep this simple and allow easy traceability from Use Case to Sequence Diagram I simply put the name of the use case as the start of the sequence diagrams name.
- Clutter: Try not to clutter the diagram up with too much information for what happens within a particular class. Sometimes it is useful though.
Class Diagrams
Class Diagrams are often what people spend the most amount of time on. But sometimes in the most waist full way. Ask yourself if you are going too close to the code as too much details will make it as complicated as the code.
-
Views into the Model: Treat Class diagrams should be interesting and helpful views into the Model. They are not the model itself. Much time can be spent creating (well formatting as reverse-engineering may have made the diagram) but I find they are of little use over and above your package explorer in your favourite IDE or something like javadocs.
I find it more useful to have views into the model with relate to a sequence diagram. We have spent time on the sequence diagrams because they are useful so some supporting information will likely to be important.
For example if our Sequence Diagram is showing how to use a particular feature of an API probably good is with have all the interface information along with it. This information may be in your javadocs but using tools such as Rational Rose we can pull this same information into the model so could print it from here.
Automatic Documentation
Something I stumbled upon while using using a Rational product called SoDA. Not the easiest tool to use but quite powerful. Or rather it is powerful because it allows you to harvest information from various rational products.
As much as we don't like doing them we often need documentation. But they are almost always wrong very soon after they have been printed. But still they are very useful and provide a stake in the ground.
So the answer is to make them cheap and easy to produce. Tools like SoDA do this. Producing and using these produced documents also have the advantage that at least periodically we have to focus on the quality, completeness and accuracy of the model.
As previously stated I believe the Sequence Diagrams are very much the centre or the start of the actual design of the system. They are (or a selection) of them are brilliant simple explanation of the way the system works.
So by using the Sequence Diagrams with the addition of Use Cases and Class Diagrams. Use Cases give a simple manager friendly explanation which proves we understand the problem. Class diagrams that give the guts of the information of the technical staff.
These documents when created can be taken as a stake in the ground to be developed against and a way of communicating the system to the rest of the company for little money.
As much as we don't like doing them we often need documentation. But they are almost always wrong very soon after they have been printed. But still they are very useful and provide a stake in the ground.
So the answer is to make them cheap and easy to produce. Tools like SoDA do this. Producing and using these produced documents also have the advantage that at least periodically we have to focus on the quality, completeness and accuracy of the model.
As previously stated I believe the Sequence Diagrams are very much the centre or the start of the actual design of the system. They are (or a selection) of them are brilliant simple explanation of the way the system works.
So by using the Sequence Diagrams with the addition of Use Cases and Class Diagrams. Use Cases give a simple manager friendly explanation which proves we understand the problem. Class diagrams that give the guts of the information of the technical staff.
These documents when created can be taken as a stake in the ground to be developed against and a way of communicating the system to the rest of the company for little money.
Great Stuff on Amazon
Some books to get you on your way.
General Hints and Tips
Don't Expand the Language
Well try not to. I have seen all kinds of colours and other embellishments added to the language to identify different aspects of design and code.
Often just placing a couple of comment on a diagram achieves the goal without the need to invent, define and most importantly keep consistent throughout your design.
Don't include too much detail
You don't need to model the int, boolean or Sting! They are quite standard items and if they where to change (very unlikely) you would be forced to update your model as well.
Views into the Model
Treat Class diagrams as interesting and helpful views into the Model. They are not the model itself.
This way it is not a problem to have a class or collection of classes on multiple diagrams as they are just different views into the same model.
Consistency between the views should be dealt with my the tool itself.
Well try not to. I have seen all kinds of colours and other embellishments added to the language to identify different aspects of design and code.
Often just placing a couple of comment on a diagram achieves the goal without the need to invent, define and most importantly keep consistent throughout your design.
Don't include too much detail
You don't need to model the int, boolean or Sting! They are quite standard items and if they where to change (very unlikely) you would be forced to update your model as well.
Views into the Model
Treat Class diagrams as interesting and helpful views into the Model. They are not the model itself.
This way it is not a problem to have a class or collection of classes on multiple diagrams as they are just different views into the same model.
Consistency between the views should be dealt with my the tool itself.
by SimonKiteley
SimonKiteley
Professional Software Engineer. Currently concentrates on Java Development, UML modelling and spending increasing amounts of time on Process Improveme... more »
- 0 featured lenses
- Winner of 3 trophies!
- Top lens »
Feeling creative?
Create a Lens!
Explore related pages
- Doodle Art Doodle Art
- 3D Designs Coloring Books & Pages For Adults 3D Designs Coloring Books & Pages For Adults
- Kolam - an Unique Floor Decoration of Tamil Nadu Kolam - an Unique Floor Decoration of Tamil Nadu
- How To Make An Effective Flyer How To Make An Effective Flyer
- How to Make a Wooden Gear Clock How to Make a Wooden Gear Clock
- Tattoos for Girls Tattoos for Girls
