It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Is it essential to have all 9 diagrams of UML to describe a system?
I know that sequence and collaboration diagram are isomorphic so one can be eliminated here, Is it OK if i represent it by only one diagram for dynamic part and one diagram for static part?
Actually UML 2.x has 14 diagrams.
But you do not have to use all diagrams in order to describe your system.
As a general advice:
Model and apply the UML for the smaller percentage of unusual,
difficult, tricky part of your design space [ Larman, Applying UML and
patterns]
Before drawing a UML diagram ask yourself : Why am I drawing this diagram? What is my real purpose? What kind of benefit will it give me? If you do not have solid answer or benefit, just do not draw any diagram.
Use UML diagrams for understanding nature of your problem-solution space,to explore your problem space , to explore new design ideas,to communicate ideas with team members, but not for just documentation.
So technically it is okay to have just two diagrams: one static
diagram like class diagram and a dynamic diagram like a sequence
diagram.
But technically correct does not mean it is the right thing to do
All diagrams should have a purpose-benefit for to draw it.Otherwise it will be not a modelling activity. It will be drawing exercise :-)
Use small number of diagrams which gives you most benefit-help you while developing your system.
Do not forget that the important thing is not drawing UML diagram. The important thing is finding right abstractions, assigning right-balanced responsibilities to objects, making your system flexible and extensible.
Finally
No UML diagrams can make your design "innocent-sinless". All design ideas that are on papers are "guilty", until their "innocence" is proven by working code. :-)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 12 months ago.
Improve this question
UML has come into many projects with object-oriented programming and is widely taught in colleges. However, today many software projects use a more or less agile approach, avoiding up-front in-depth analysis and leading to many changes ("welcome change"). In contrast, creating correct and readable UML (class) diagrams is still time-consuming; hence the value of documenting the model is in practice often considered time waste, as it changes often.
Even autogenerated (from source code) diagrams are not solving the problem, as they cannot correctly resolve class relationships often have insufficient graph layouts and distracting extensions.
Can UML be used in an agile context in a way that avoids the overhead of frequent manual updates? Or are other lighter alternatives to UML more suitable in such a context?
UML can be used in a light way in an agile context. The key is simply to be clear about its purpose and what you expect from modeling in your project.
Class diagrams and sequence diagrams are proven to be good candidates for helping teams to discuss points of concerns. It can express clearly ideas that are not obvious in the code (or scattered across many source files).
Scott Ambler for example wrote a lot on agile modeling, based on UML. Of course, you will not use it for producing an exhaustive model with all classes and all properties. But you'd sketch the core with some relevant classes, and only a few properties that matter in the discussion (Ambler says "Just barely enough" modeling).
However, for architectural modeling (deployment diagrams and the like), UML requires a degree of precision that is not always possible in early stages. Here C4 models has established as a convenient and flexible alternative. But C4 relies on UML for the OOP design discussion. There is simply no alternative that allows to easily show classes and interaction between them, and that would be sufficiently widely known.
Conclusion: In an agile context, don't get misguided thinking that UML would require an exhaustive up-front design. Don't use it as for visual programming either, slavishly replicating details of the code. But use it as a communication tool to highlight key ideas and allow everyone to grasp the design and contribute productively.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm going to start learning and using UML.
I need to know what considerations do you suggest for me? What is the best way to learn effectively it do you think?
Thank you
In a class named SE101- Software Engineering 1A at CPIT in New Zealand.
In my opinion, you'll find that sequence and use case diagrams will be essential for getting ideas across to non-programmers, and class diagrams (and object diagrams, to a lesser extent), for communicating ideas to other code-monkeys.
Plus, many programming books that you may read in the future, Design Patterns, for example, will use UML diagrams (class and object, mostly) to show the structure of the patterns. Knowing UML will make understanding these books a lot easier. Documentation, too, to a lesser extent.
I never did, and I never will. Modelling is not about mastering a type of discipline, good models don't need UML to be understood.
First, get a book/tutorial and try to understand the basics (definitions, models drawing, ...)
then, learn by example and practice, imagine or use a real problem and try to model it.
I started by reading an introductory book - Martin Fowler UML Distilled was quite good. Than I decided I really want to know how to use it, so I read a book about UML2 and UP (Unified Process) by Jim Arlow and Ila Neustadt. Afterward I had opportunity to take software engineering basics lecture at university which made me create simple specification with few diagrams. Afterward I took UML lecture, where I had again to create some UML diagrams. Now I am in the phase when UML is clear and I feel I need more knowledge about OO modeling, so I read a book on object oriented data modeling and object oriented programming and there are Use Cases by Alistair Cockbourne and some analytical patterns ahead for me. In between I read much of the model driven stuff and listened to SE Radio about all UML stuff - http://www.se-radio.net/tags/uml .
UML Distilled by Martin Fowler together with Applying UML And Patterns by Craig Larman, makes you understand the concept of UML and how to use it - as well the whole process with UP and so forth.
http://www.smartdraw.com/resources/tutorials/uml-diagrams/#/resources/tutorials/Getting-Started
This link was very helpful for me to learn modeling with UML.
For open source solutions check out Dia, and dia2code.
I read Martin Fowler's UML Distilled. That's all you need. It's thin, dense book that's unmatched on that topic.
I have several UML books, UML Distilled book from Addison Wesley comes to mind,
then it all gets familiar when you start reading Design Pattern books that illustrates the concepts using UML Diagrams.
I also use UML when I sketch a design.
You can only focus on 2 diagrams and start modeling almost immediately.
Usecase diagrams require reading but class diagram can be done at the same time as the code. It means that in less than 3 hours you can model.
Usecase diagram is simple and will help you to define the scope of your project.
Class diagram will define the physical architecture and can therefore be learned at the same time as codding if you use a tool having live code and model synchronization.
Don't spend time on model driven and code generation from a model because nobody really use it today !!
Inventor.
Sequence diagrams look more like business processes and usecases rather unstandardized.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
How to Describe "Use case Diagram" in formal style?
Anyone have template ?
If you mean by "describe a use case diagram" describing each use case individually, there is a "procedure" in RUP methodology.
CASE tools like Enterprise Architect or MagicDraw support it by built-in forms for specifying preconditions (what must be fulfilled before the use case takes place), postconditions (what is fulfilled after taking place) and scenarios (what is particular flow of events or actions, and it alternatives) etc.
But if you are serious about describing your use case, filling all its details into those tiny forms is quite uncomfortable and not-providing-easy-survey. You may produce a .rtf generated by the tool from your use case model (providing a template already present in the tools, usually not very good-looking:).
Another way (and my preferred) is describing use cases in a separate Word document by hand (and paste the use case diagram into it). This guy wrote an amazing book "Writing effective use cases". I personally recommend it to everyone coping with use cases in his every day job. Here you can find a "compressed" guidelines extracted from the book.
I believe most of the UML drawing packages will have templates for UC diagram. For example see "dia" or eclipse with modelling framework
Other non-free tools include MS visio, MagicDraw and so many more
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What diagramming technique(s) do you use while programming to help you
or others understand your program or design. I am not talking about a person's
favorite tool, though a good tool probable helps a person greatly with
diagramming.
My intent in this question is to find the simple useful diagramming techniques
people actually use and find new ones to learn.
Do you use flow-charts, Data Flow Diagrams, ER diagrams, etc?
The web is full of recommendations! But what do real programmers, designers,
and code maintainers actually use in their day to day work.
Thanks for your feedback
Very High Level Discussion - Context Diagrams where the boxes might represent classes, packages, or sub-systems.
High Level Design - Sequence diagrams which show the interface between sub-systems, still no classes directly used but may be implied from this.
Detailed Design - Sequence diagrams which are at the class level.
If there is a tricky algorithm for something such as the correlation of multiple data streams into a new stream then I will generally use a Flow Chart to work out the algorithm.
If the solution requires knowledge of state then a State diagram is also used.
Those are the ones I use most.
When doing Data Warehouse design I draw Star Schemas to work out how to store the data. When doing Transactional DB design I use Entity Relationship diagrams to work our data storage.
When designing a UI I just sketch it out. Once I start to get some parts of the UI worked out and want to play with some areas I will make a template, print out a copy copies and then use that as a guide to work on sub-sections. For colour schemes, it can be handy to make a graphic using the gimp and have layers for each piece of the design and then play with the layers colouring each one to find the right balance.
What do we really use? Maybe other people actually create formal diagrams, but for the most part I just scribble bubbles, boxes and lines on a sheet of paper.
I use a whiteboard for modeling, so I guess "whiteboard modeling language" would be my answer.
I will do a UML Class diagram for anything i'm designing that is bigger than a couple of classes. Drawing a class diagram makes me take time out to think over the design instead of ploughing straight into the code and always produces a better result.
For bigger and more complicated architectures I find that Sequence diagrams are a good way to communicate behviour, especially for multi-threaded systems.
I use diagrams as a way to quickly understand legacy code. It takes some work to create the diagram, but it always pays of in the end.
Normally I use class diagrams to get the big picture. Sometimes sequence diagrams and even dataflow diagram if a piece o code is extremely hard to understand.
In the design phase I use class diagrams, and often state diagrams. State diagrams are perfect if a class behaviour differs with its state.
I use Sequence Diagrams a lot (drawn on paper). I find they give me a nice visual representation the logical flow of method calls and information between various systems and components in our applications.
I have a Flow chart of the main product I work with and develop.
My team also often uses UML diagram sketches on white-boards while designing new parts for us to implement. They're very useful in creating design patterns and modeling the high-level structure of the classes which will be needed. These are never full blown UML though...
Whiteboard for discussions.
Pen and paper for less temporary record.
Code stubs for 'Things to impelement'.
Tested and Working code (with extensive comments) for posterity.
I use ER and class diagrams on paper and whiteboard for any project that's bigger than a shell script.
Flow charts, only when I need to explain a process to a non-programmer (or if it's a really complicated process and I need to understand it first).
My old boss used to say "the guy just loves drawing stuff."
I work in an AJAX development environment, and most of the backend code I write works like a pipe between a relational database and the frontend javascript (user interface). So, the most used 'diagram' per say that I use are JSON objects to describe how data should be passed back and forth between the database and the interface. They are simple, universal and easy to understand data structures.
Example:
{
"id": row['id'],
"name": row['name'],
"mandatory": row['mandatory'],
"rangeDescription": "This is the Range",
"globalRate": row['global']
}
I draw bastardized versions of UML class, object and sequence diagrams. While I try to be true to the syntax, I am much more concerned about expressing the main idea behind particular feature. So, I'll draw up something, ask a colleague to take a look, and if it seems clear enough, we might even scan it and post it in our Wiki.
Then, when it so happens that we actually get some time to work on the documentation (and that is almost never), I'll use BOUML and redraw the scribbles into a proper diagram.
Now, to put is all in context, I'm working at a relatively small team (5 developers), making trading and product configuration platforms in Java. We have our two products that we then additionally customize to customer's requests. Being a close-knit community, with low (zero) turnaround for a few years, we use the documentation primarily as a remainder to ourselves. And in this setup, the above approach works quite well.
I like Data Flow Diagrams. A lot.
I use whatever is needed for communicatation. Usually that's nothing at all. Sometimes it's a whiteboard.
From time to time, I use Sparx Enterprise Architect, which is a UML modeling tool, though it produces decent diagams while it's at it. I've used it for requirements, use case, activity, sequence, domain, and even class modeling, and sometimes some reverse-engineered ER diagrams. Whatever it takes to get the point across.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is a great way to learn good UML design? How often do you draw diagrams (other than static diagram of classes)? What is the best source for learning it?
I think Martin Fowler's "UML Distilled" is the best book for learning UML syntax. It's succinct and dense with information.
Unfortunately, knowing UML syntax well is not the same thing as knowing how to design.
Practical UML
UML Overview
I dunno, it depends on how big team is. Class/Sequence/Use cases is what mostly used for me I think. The most important thing is not overuse diagraming, couse the main goal is to help comunicate among team, help understand things same way, not just to make some useless diagrams papers and not use them.
However very complex system developed by group of teams, obviously require more diagrams I think, just to make sure everyone knows what they are doing and how things relate in system. There's quite lot good tools these days that help in modeling.
There was one project make I worked on where we used Enterprise Architect to make UML diagrams which we round-tripped (forward- and reverse-engineered) with the C# source code.
It (UML) wasn't good at defining the implementation of each method (using sequence diagrams), but it was OK defining the signatures of interfaces and of classes (i.e. the declarations, not definitions, of methods).
It was useful because you could have:
A diagram which shows how a group of classes interact (whereas with source code you see classes one at a time)
Different diagrams with different groups of classes; and sometimes the same class can appear on more than one diagram.
This was for a project where it was a requirement to create design documentation, with traceability from the use cases though design.