Related
This is a generic post aimed at clarifying the differences among the relationships in Enterprise Architect.
There are a lot of relationships, such as association, dependency, realization, etc.
It would be probably very useful to get a clear overview for each so that it would be better understood and used in the most proper way.
If you have a best practice on the topic, please enrich our knowledge with your answer.
This question related to UML notation, not only to Sparx EA.
So, I suggest to check UML2 documentation, for example you can start from wikipedia
https://en.wikipedia.org/wiki/Class_diagram#Links
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
What is nice about UML is that it offers a unified suite of defined diagrams for expressing software architecture. However, the diagrams are about the system being built and do not help for helping represent requirements and understand user-level issues (use-case diagram is the highest level and it's still very specific, we are looking for diagrams to use as input into a use-case).
So we've been using a hodge-podge of diagrams leaning heavily on dataflow diagrams, but I was wondering if there was a standard with a suite of diagrams like UML in existence for gather requirements etc.
I've seen individual diagrams that are useful, but never a suite of them that are standardised and interwork.
Is there something like a RML "Requirements Modeling Language" which a family of related diagrams for requirements and other more abstract concerns?
Depends what you mean by 'Higher Level'. Dataflow Diagrams are good - but to a large extent still define 'how' things work, not 'why'. I assume that since you've looked at DFDs you've also looked at and rejected business process diagrams in some form, e.g. bpmn/bpml.
Some other suggestions that may (or may not) be useful to you:
Feature Models, particularly useful for understanding Software Product Lines and the variability/commonality among variants;
Business Motivation Models which model the 'why's; objectives, constraints etc.
SBVR. A formalism for capturing business vocabulary & rules. Note it's textual rather than diagrammatic so might not be applicable.
Behaviour Trees, a notation for Behaviour Engineering.
That's a pretty broad spectrum. If you can be more specific about needs then it can be narrowed down. Worth noting however that none of the above have widespread industry acceptance; certainly not to the level UML has.
hth.
The Archimate modelling language is used for enterprise architecture modelling and might address some of your needs. The language is standardised by the OMG.
OMG page: http://www.opengroup.org/subjectareas/enterprise/archimate
A very useful blog from an experienced user of Archimate is here: http://masteringarchimate.com/ He has also written a useful book, sold through his web site.
Orbus Software have created a very nice Visio stencil for Archimate diagrams: http://www.orbussoftware.com/downloads/visio-starter-packs/archimate-starter-pack
A freely available single-user tool for Archimate modelling is Archi: http://www.archimatetool.com/
There are also a number of commercial tools including those from Orbus, BizzDesign, Corso, Avolution and others.
Eoin.
OMG, the standardization body which maintains UML, has a higher-level language for systems modelling: SysML.
SysML is intended to be higher-level than UML. It includes a "requirement" element type and omits many of UML's low-level constructs, but is still closely enough related that someone familiar with UML will recognize most of SysML.
UML itself is a model in a higher modelling language: The Meta Object Facility (MOF) which you could consider the supreme abstraction, because MOF is defined by itself (i.e. there is a MOF model that represents the MOF language). You can use MOF to describe a modelling language which can then contain diagrams/classes that you can define.
Link to MOF homepage: http://www.omg.org/mof/
And wikipedia: http://en.wikipedia.org/wiki/Meta-Object_Facility
Although UML is billed as a low level language you can certainly use it for higher level concepts either through UML profiles (See UML Profiles) or through a more developed extension. One such extension is UPDM which takes UML and SysML and extends it for use in architectures in the Defence industry (also applicable to more general uses) by representing the DoDAF and MODAF frameworks.
Just because UPDM is typically used to model lower level software architectures it doesn't mean that its extension mechanisms like MOF can't be used to model anything you want.
There is a modeling language called RML developed by Seilevel (full disclosure- I work there) that is specifically designed for requirements. You can read about it in this book
http://www.amazon.com/Visual-Software-Requirements-Developer-Practices/dp/0735667721/ref=sr_1_1?ie=UTF8&qid=1463064250&sr=8-1&keywords=requirements+models
Our blog has a lot of posts about it
http://www.seilevel.com/requirements/
Models are designed to be friendly to business users. The categories of models are
Objectives (Business objectives model, requirements mapping matrix, objective chain etc)
People (Org chart, process flow, KPI model etc)
Systems (eco system map, system flow, system interface)
Data (business data diagram, data flow, data dictionary)
In my object oriented programming class, we learned some of the main concepts of UML and I was just wondering if UML is common in real world situations or are there more popular methods.
There are certainly organizations that rely on UML, including a few that may expect you to answer OO design questions with UML in an interview. Plus, documentation tools like Doxygen generate UML-like diagrams to describe a class hierarchy.
Beyond that though, most groups I've worked with in academia or industry don't really use it. If you want an explanation of why, read "Death by UML Fever".
Generally agree with #chrisaycock. Would add a couple of things:
You should distinguish using UML for specification versus documentation. At the peak of its hype curve, UML was touted as the former. So development processes mandated modelling in UML before moving into code. That use has diminished greatly (although there are still pockets using executable uml, notably in real-time/embedded environments).
As a documentation tool, UML is still popular. UML class diagrams, for example, can convey the structure of a module in a way that is much more revealing and intuitive than linear code can ever be. Similarly sequence- or activity diagrams are very useful for understanding flow of control for an action that transcends a number of classes.
In the documentation context UML diagrams are increasingly being generated automatically rather than being manually created, e.g. from doxygen (as #chrisaycock mentions).
However it's also still useful for sketching out designs ahead of development e.g. on a whiteboard.
hth.
I once attended a Q&A session on UML and MDA in embedded systems where the panel included authors Bruce Powell Douglass and Steven Mellor. Having previously studied and worked on RT-SSADM projects and the Ward-Mellor methodology, I challenged Stephen Mellor on why a new way of software design comes along every 10 years before practitioners have hardly gotten to grips or truly understood the last one. He responded rather too honestly perhaps with "this way I sell more books"!
To some extent therefore I suggest that the hype surrounding any particular notation or methodology is driven primarily by CASE tool vendors and publishing houses; often the authors are also employed by the tool vendors and have titles like "Chief Evangelist".
That is not to say that these tools have no value; we should all be wary of such marketing, but on the other hand we also need to communicate our ideas and designs in an unambiguous and clear manner, and using a defined notation however inelegant, will always be better than some ad-hoc "sticks and boxes" notation that has no definitive semantics. Given that need for communication, UML (and derivatives such as SysML) is currently the most widely accepted and used notation, and currently enjoys the widest tool support. It differs from much that has gone before by being defined as a standard agreed by multiple parties rather the work on a single author or CASE tool vendor, so it is likely to develop rather than disappear.
I think the article, linked by #chrisaycock, could also have corollaries e.g., "Death by Agile Fever", "Death by CMM Fever", "Death by RT-SSADM Fever", ... ;-)
As #sfinnie stated, it really depends upon the usage, but UML by itself is nothing more than a notation. In order to be really useful, you need to follow some development method. #Clifford's post not withstanding, I'd recommend a mature method. Executable UML started as Shlaer-Mellor and has been in use for 19+ years. Douglass' method (not called ROPES anymore, but ???) has been around for 11 years. The Unified Process is based on Booch, OMT, and OOSE methods, so it can be considered 19+ years old as well. Of course you might find some other UML or non-UML development method that better fits your needs.
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.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I'm trying to choose a tool for creating UML diagrams of all flavours. Usability is a major criteria for me, but I'd still take more power with a steeper learning curve and be happy. Free (as in beer) would be nice, but I'd be willing to pay if the tool's worth it. What should I be using?
Some context: Recently for graduate school I researched UML tools for usability and UML comprehension in general for an independent project. I also model/architect for a living.
The previous posts have too many answers and not enough questions. A common misunderstanding is that UML is about creating diagrams. Sure, diagrams are important, but really you are creating a model. Here are the questions that should be answered as each vendor product/solution does some things better than others. Note: The listed answers are my view as the best even if other products support a given feature or need.
Are you modeling or drawing? (Drawing - ArgoUML, free implementations, and Visio)
Will you be modeling in the future? (For basic modeling - Community editions of pay products)
Do you want to formalize your modeling through profiles or meta-models? OCL? (Sparx, RSM, Visual Paradigm)
Are you concerned about model portability, XMI support? (GenMyModel, Sparx, Visual Paradigm, Altova)
Do you have an existing set of documents that you need to work with? (Depends on the documents)
Would you want to generate code stubs or full functioning code?(GenMyModel, Visual Paradigm, Sparx, Altova)
Do you need more mature processes such as use case management, pattern creation, asset creation, RUP integration, etc? (RSA/RSM/IBM Rational Products)
Detailed Examples: IBM Rational Software Architect did not implement UML 2.0 all the way when it comes to realizes type relationships when creating a UML profile, but Visual Paradigm and Sparx got it right.
Ok, that was way too detailed, so a simpler example would be ArgoUML, which has no code generation features and focuses on drawing more than the modeling aspect of UML. Sparx and Visual Paradigm do UML really well and generate code well, however, hooking into project lifecycles and other process is where RSM/RSA is strong.
Watch out for closed or product specific code generation processes or frameworks as you could end up stuck with that product.
This is a straight brain dump so a couple details may not be perfect, however, this should provide a general map to the questions and solutions to looking into.
NEW - Found a good list of many UML tools with descriptions. Wiki UML Tool List
For sequence diagrams, only, try websequencediagrams.com. It's a freemium (free for the basic tasks, paid for advanced features) product, and lets you quickly bang out a diagram without any fussing around with lines and stencils.
Alice->Bob: Authentication Request
note left of Bob: Bob thinks about it
Bob->Alice: Authentication Response
For me it's Enterprise Architect from Sparx Systems. A very rounded UML tool for a very reasonable price.
Very strong feature list including: integrated project management, baselining, export/import (including export to html), documentation generation from the model, various templates (Zachman, TOGAF, etc.), IDE plugins, code generation (with IDE plugins available for Visual Studio, Eclipse & others), automation API - the list goes on.
Oh yeah, don't forget support for source control directly from inside the tool (SVN, CVS, TFS & SCC).
I would also stay away from Visio - you only get diagrams, not a model. Rename a class in one place in a UML modelling tool and you rename in all places. This is not the case in Visio!
For my simple & short UML working,
I've used this tool:
StarUML - http://staruml.sourceforge.net/en/
Great free software for UML drawing.
Although the original Star UML is no longer maintained, there's now a fork called White Star UML, which is actively developed.
As I usually use UML more as a communication tool rather than a modeling tool I sometimes have the need to flex the language a bit, which makes the strict modeling tools quite unwieldy. Also, they tend to have a large overhead for the occasional drawing. This also means I don't give tools that handle round-trip modeling well any bonus points. With this in mind...
When using Visio, I tend to use these stencils for my UMLing needs (the built in kind of suck). It could be that I have grown used to it as it is the primary diagramming tool at my current assignment.
OmniGraffle also has some UML stencils built in and more are available at Graffletopia, but I wouldn't recommend that as a diagramming tool as it has too many quirks (quirks that are good for many things, but not UML). Free trial though, so by all means... :)
I've been trying out MagicDraw a bit, but while functional, I found the user interface distracting.
Otherwise i find the Topcased an interesting project (or group of projects). Last I used it it still had some bugs, but it worked, and seems to have evolved nicely since. Works great on any Eclipse-enabled platform. Free as in speech and beer :)
As for the diagramming tool Dia, it's quite ugly (interface and resulting drawings), but it does get the job done. An interesting modeling tool free alternative is Umbrello, but I haven't really used it much.
I definitely agree with mashi that whiteboards are great (together with a digital camera or cellphone).
Probably some of the nicest tools I've used belong to the Rational family of tools.
You may be looking for an automated tool that will automatically generate a lot of stuff for you. But here's a free, generally powerful diagramming tool useful not only for UML but for all kinds of diagramming tasks. It accepts as input and outputs to a wide variety of commonly used file formats. It's called yEd, and it's worth a look
Visual Paradigm for UML http://content.usa.visual-paradigm.com/websiteimages/images/products/vpuml60/vpumltitle.gif
I'm very fond of Visual Paradigm for UML It's very powerful and has a free Community Edition and cheap Personal Edition as well.
Agilian http://content.usa.visual-paradigm.com/websiteimages/images/products/ag10/agtitle.gif
For Agile modeling there's also Agilian which is a bit more flexible, adds extra features to support smartboards and knows mind-mapping as well.
The thing I like most about their products is the flexibility. I'm using Enterprise Architect at work nowadays but I think it's not smart enough. I want to be able to quick-brainstorm some sequence diagrams and have the application keep my model up-to-date in the background, something VPUML does a very good job at.
In my opinion it's way better than Enterprise Architect, though that is a great tool as well :)
Take a look at BOUML: multiplatform (QT), works pretty well and supports colaborative work.
BOUML is a free UML 2 tool box (under development) allowing you to specify and generate code in C++, Java, Idl, Php and Python.
BOUML runs under Unix/Linux/Solaris, MacOS X(Power PC and Intel) and Windows.
From Wikipedia:
The releases prior to version 4.23 are free software licensed under GPL. BOUML 5 and later is proprietary software.
If you're looking to get out the door and working on UML without having to learn a complex new tool I would check out Violet UML. I've used it to some pretty great success in the past.
PlantUML is an open-source markup-language-to-UML-diagram tool in Java that deserves to be mentioned here. It ranks high on the usability scale because of its intuitive syntax for the various diagrams and diagram components.
Dia is a possible choice. It's definitely not the best tool, but it is functional.
Enterprise Architect from Sparx systems is the best tool I've used. A bit expensive at $199 (professional edition), but IMO it's worth it.
I will add UMLet which I haven't tried yet, but have been selected at my office to start doing diagrams.
Looks simple, diagrams aren't sexy, but it seems quite complete with regard to the kind of diagrams you can do. Seems to have good export capabilities too (important!), is flexible can support custom components) and can be used as Eclipse plugin.
Astah UML (ex-JUDE) is pretty good.
I haven't been able to find a top-notch free UML diagramming tool, but if you're interested in pure diagramming, as opposed to round-trip-engineering, I'd go with Microsoft Visio. If you want full round-trip engineering, Rational Rose.
This list of UML tools on Wikipedia might also come in handy.
Pen and paper. If you can get the scan into a vector format, that may be useful when making minor amendments.
You should try Creately. Runs in your browser and can do team collaboration.
supports sequence diagrams, class, ER, usecase etc. works great and has a free version available.
Creately.com
You can also check out Lucid Chart for uml and other types of diagramming.
Don't forget yuml.me, I love it.
http://plantuml.sourceforge.net/index.html
In my practice i use Sequence Diagram Editor. it is really fast and helpful tool. the one thing i don't like about it is that it is commercial product, not free.
I like VisualParadigm mentioned before in this thread. It's powerful and easy to use I think it gives most power comparing to other tools.
If you need something simple, quick and easy (and free) there is a great tool called UMLet - I highly recommend this. I've tried many of UML diagramming tools and this the simplest one (and it still allows to do great diagrams). This is my choice:)
Obviously if you are serious about UML in the long run you need to use a software UML tool like the ones suggested in the other answers, but I've found that a whiteboard is one of the best tools for UML diagramming, especially during the design phase, or when you are exploring different alternatives. Nothing beats a whiteboard for speed/flexibility in my mind. They are also great for collaboration assuming you are collocated physically.
In my opinion StarUML is the best.
I can't believe no one has mentioned NetBeans UML Editor, it's great and satisfied all of my Java based UML requirments.
This after I tested JDeveloper UML, ArgoUML and StarUML.
I recently conducted a poll "What UML Tools do you use?" in my blog. NetBeans UML was was the top opensource choice and Enterprise Architect was the top commercial choice.
You can create UML class, sequence, component, use case, and activity diagrams in Visual Studio 2010 Ultimate. You can link these diagrams to Team Foundation work items so you can plan and track development and test work. You can also create sequence, dependency graphs, and layer diagrams from code and use Architecture Explorer to browse and explore your solution.
I've posted more links on my profile for more info.
You might want to take a look at MagicDraw or Visual Paradigm for UML. Both offer community editions that, of course, don't span the full feature range, but may well be sufficient if you want to create diagrams only and not generate code or do full round-trip engineering.
Rational and Together/J are best-of-breed products, but expensive.
In my experience, I've enjoyed Eclipse Omondo and Sparx Enterprise Architect. Omondo integrates nicely with Eclipse for code generation, and has a very intuitive feel. However, it is strongly tied to Java. Sparx is a good tool for the price point, but lacks the full range of UML 2.0 diagrams.
Do NOT bother with Poseidon. It is buggy, bloated, and unusuable for all intents and purposes.
For sequence diagrams you can also try Trace Modeler. It's not free but it has a great interface, very friendly and productive. You can use it on any platform.
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 11 years ago.
In college I've had numerous design and UML oriented courses, and I recognize that UML can be used to benefit a software project, especially use-case mapping, but is it really practical? I've done a few co-op work terms, and it appears that UML is not used heavily in the industry. Is it worth the time during a project to create UML diagrams? Also, I find that class diagrams are generally not useful, because it's just faster to look at the header file for a class. Specifically which diagrams are the most useful?
Edit: My experience is limited to small, under 10 developer projects.
Edit: Many good answers, and though not the most verbose, I belive the one selected is the most balanced.
Using UML is like looking at your feet as you walk. It's making conscious and explicit something that you can usually do unconsciously. Beginners need to think carefully about what they're doing, but a professional programmer already knows what they're doing. Most of the time, writing the code itself is quicker and more effective than writing about the code, because their programming intuition is tuned to the task.
It's not just about what you're doing though. What about the new hire who comes in six months from now and needs to come up to speed on the code? What about five years from now when everyone currently working on the project is gone?
It's incredibly helpful to have some basic up to date documentation available for anyone who joins the project later. I don't advocate full blown UML diagrams with method names and parameters (WAY too difficult to maintain), but I do think that a basic diagram of the components in the system with their relationships and basic behavior is invaluable. Unless the design of the system changes drastically, this information shouldn't change a lot even as the implementation is tweaked.
I've found that the key to documentation is moderation. No one is going to read 50 pages of full blown UML diagrams with design documentation without falling asleep a few pages in. On the other hand, most people would love to get 5-10 pages of simple class diagrams with some basic descriptions of how the system is put together.
The other case where I've found UML to be useful is for when a senior developer is responsible for designing a component but then hands the design to a junior developer to implement.
In a sufficiently complex system there are some places where some UML is considered useful.
The useful diagrams for a system, vary by applicability.
But the most widely used ones are:
Class Diagrams
State Diagrams
Activity Diagrams
Sequence Diagrams
There are many enterprises who swear by them and many who outright reject them as an utter waste of time and effort.
It's best not to go overboard and think what's best for the project you are on and pick the stuff that is applicable and makes sense.
Using UML is like looking at your feet as you walk. It's making conscious and explicit something that you can usually do unconsciously. Beginners need to think carefully about what they're doing, but a professional programmer already knows what they're doing. Most of the time, writing the code itself is quicker and more effective than writing about the code, because their programming intuition is tuned to the task.
The exception is why you find yourself in the woods at night without a torch and it's started to rain - then you need to look at your feet to avoid falling down. There are times when the task you've taken on is more complicated than your intuition can handle, and you need to slow down and state the structure of your program explicitly. Then UML is one of many tools you can use. Others include pseudocode, high-level architecture diagrams and strange metaphors.
Generic work-flow and DFDs can be very useful for complex processes. All other diagramming (ESPECIALLY UML) has, in my experience, without exception been a painful waste of time and effort.
I'd have to disagree, UML is used all over the place - anywhere a IT project is being designed UML will usually be there.
Now whether it is being used well is another matter.
As Stu said, I find both Use Cases (along with the use case descriptions) and activity diagrams to be the most helpful from a developer point of view.
Class diagram can be very useful when trying to show relationships, as well as object attributes, such as persistence. When it comes to adding ever single attribute or property they are usually overkill, especially as they often become out of date quickly once code is written.
One of the biggest problems with UML is the amount of work required to keep it up to date once code is being generated, as there are few tools that can re-engineer UML from code, and few still that do it well.
I will qualify my answer by mentioning that I don't have experience in large (IBM-like) corporate development environments.
The way I view UML and the Rational Unified Process is that it's more TALKING about what you're going to do than actually DOING what you're going to do.
(In other words it's largely a waste of time)
Throw away only in my opinion. UML is a great tool for communicating ideas, the only issue is when you store and maintain it because you are essentially creating two copies of the same information and this is where it usually blows.
After the initial round of implementation most of the UML should be generated from the source code else it will go out of date very quickly or require a lot of time (with manual errors) to keep up to date.
I co-taught a senior-level development project course my last two semesters in school. The project was intended to be used in a production environment with local non-profits as paying clients. We had to be certain that code did what we expected it to and that the students were capturing all the data necessary to meet the clients' needs.
Class time was limited, as was my time outside of the classroom. As such, we had to perform code reviews at every class meeting, but with 25 students enrolled individual review time was very short. The tool we found most valuable in these review sessions were ERD's, class diagrams and sequence diagrams. ERD's and class diagrams were done only in Visual Studio, so the time required to create them was trivial for the students.
The diagrams communicated a great deal of information very quickly. By having a quick overview of the students' designs, we could quickly isolate problem areas in their code and perform a more detailed review on the spot.
Without using diagrams, we would have had to take the time to go one by one through the students' code files looking for problems.
I am coming to this topic a little late and will just try an clarify a couple minor points. Asking if UML is useful as far too broad. Most people seemed to answer the question from the typical/popular UML as a drawing/communication tool perspective. Note: Martin Fowler and other UML book authors feel UML is best used for communication only. However, there are many other uses for UML. Above all, UML is a modeling language that has notation and diagrams mapped to the logical concepts. Here are some uses for UML:
Communication
Standardized Design/Solution documentation
DSL (Domain Specific Language) Definition
Model Definition (UML Profiles)
Pattern/Asset Usage
Code Generation
Model to Model transformations
Given the uses list above the posting by Pascal is not sufficient as it only speaks to diagram creation. A project could benefit from UML if any of the above are critical success factors or are problem areas that need a standardized solution.
The discussion should expanded out from how UML can be over kill or applied to small projects to discuss when UML makes sense or will actually improve the product/solution as that is when UML should be used. There are situations where UML for one developer could sense as well, such as Pattern Application or Code Generation.
UML has worked for me for years. When I started out I read Fowler's UML Distilled where he says "do enough modelling/architecture/etc.". Just use what you need!
From a QA Engineer's perspective, UML diagrams point out potential flaws in logic and thought. Makes my job easier :)
Though this discussion has long been inactive, I have a couple of -to my mind important- points to add.
Buggy code is one thing. Left to drift downstream, design mistakes can get very bloated and ugly indeed. UML, however, is self-validating. By that I mean that in allowing you to explore your models in multiple, mathematically closed and mutually-checking dimensions, it engenders robust design.
UML has another important aspect: it "talks" directly to our strongest capability, that of visualisation. Had, for example, ITIL V3 (at heart simple enough) been communicated in the form of UML diagrams, it could have been published on a few dozen A3 foldouts. Instead, it came out in several tomes of truly biblical proportions, spawning an entire industry, breathtaking costs and widespread catatonic shock.
I believe there may be a way to utilize Cockburn style UML fish,kite, and sea-level use cases as described by Fowler in his book "UML Distilled." My idea was to employ Cockburn use cases as an aid for code readability.
So I did an experiment and there is a post here about it with the Tag "UML" or "FOWLER." It was a simple idea for c#. Find a way to embed Cockburn use cases into the namespaces of programming constructs (such as the class and inner class namespaces or by making use of the namespaces for enumerations). I believe this could be a viable and simple technique but still have questions and need others to check it out. It could be good for simple programs that need a kind of pseudo-Domain Specific Language which can exist right in the midst of the c# code without any language extensions.
Please check out the post if you are interested. Go here.
I think the UML is useful thought I think the 2.0 spec has made what was once a clear specification somewhat bloated and cumbersome. I do agree with the edition of timing diagrams etc since they filled a void...
Learning to use the UML effectively takes a bit of practice. The most important point is to communicate clearly, model when needed and model as a team. Whiteboards are the best tool that I've found. I have not seen any "digital whiteboard software" that has managed to capture the utility of an actual whiteboard.
That being said I do like the following UML tools:
Violet - If it were any more simple it would be a piece of paper
Altova UModel - Good tool for Java and C# Modeling
MagicDraw - My favorite commercial tool for Modeling
Poseidon - Decent tool with good bang for the buck
StarUML - Best open source modeling tool
UML diagrams are useful for capturing and communicating requirements and ensuring that the system meets those requirements. They can be used iteratively and during various stages of planning, design, development, and testing.
From the topic: Using Models within the Development Process at http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx
A model can help you visualize the world in which your system works, clarify users' needs, define the
architecture of your system, analyze the code, and ensure that your code meets the requirements.
You might also want to read my response to the following post:
How to learn “good software design/architecture”? at https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489
I see sequence diagrams and activity diagrams used fairly often. I do a lot of work with "real-time" and embedded systems that interact with other systems, and sequence diagrams are very helpful in visualizing all the interactions.
I like to do use-case diagrams, but I haven't met too many people who think they are valuable.
I've often wondered whether Rational Rose is a good example of the kinds of applications you get from UML-model-based design. It's bloated, buggy, slow, ugly, ...
I found UML not really useful for very small projects, but really suitable for larger ones.
Essentially, it does not really matter what you use, you just have to keep two things in mind:
You want some sort of architecture planning
You want to be sure that everyone in the team is actually using the same technology for project planning
So UML is just that: A standard on how you plan your projects. If you hire new people, there are more likely to know any existing standard - be it UML, Flowchard, Nassi-Schneiderman, whatever - rather than your exising in-house stuff.
Using UML for a single developer and/or a simple software project seems overkill to me, but when working in a larger team, I would definitely want some standard for planning software.
UML is useful, yes indeed! The main uses I've made of it were:
Brainstorming about the ways a piece of software should work. It makes easy to communicate what you are thinking.
Documenting the architecture of a system, it's patterns and the main relationships of its classes. It helps when someone enters your team, when you're leaving and want to make sure your successor will understand it, and when you eventually forget what the hell that little class was meant for.
Documenting any architectural pattern you use on all your systems, for the same reasons of the dot above
I only disagree with Michael when he says that using UML for a single developer and/or a simple software project seems overkill to him. I've used it on my small personal projects, and having them documented using UML saved me a lot of time when I came back to them seven months later and had completely forgotten how I had built and put together all those classes.
One of the problems I have with UML is the understandability of the specification. When I try to really understand the semantics of a particular diagram I quickly get lost in the maze of meta-models and meta-meta-models. One of the selling points of UML is that it is less ambiguous than natural language. However, if two, or more, engineers interpret a diagram differently, it fails at the goal.
Also, I've tried asking specific questions about the super-structure document on several UML forums, and to members of the OMG itself, with little or no results. I don't think the UML community is mature enough yet to support itself.
Coming from a student, I find that UML has very little use. I find it ironic that PROGAMERS have yet to develop a program that will automatically generate the things that you have said are necessary. It would be extremely simple to design a feature into Visual Studio that could pull pieces of the data, seek for definitions, and product answers sufficent so that anyone could look at it, great or small, and understand the program. This would also keep it up to date because it would take the information directly from the code to produce the information.
UML is used as soon as you represent a class with its fields and methods though it's just a kind of UML diagram.
The problem with UML is that the founders book is too vague.
UML is just a language, it's not really a method.
As for me, I really find annoying the lack of UML schema for Opensource Projects. Take something like Wordpress, you just have a database schema, nothing else. You have to wander around the codex api to try to get the big picture.
UML has its place. It becomes increasingly important as the size of the project grows. If you have a long running project, then it is best to document everything in UML.
UML seems to good for large projects with large teams of people. However I've worked in small teams where communication is better.
Using UML-esque diagrams is good though, especially in the planning stage. I tend to think in code, so I find writing large specs hard. I prefer to write down the inputs' and outputs' and leave the developers to design the bit in the middle.
I believe UML is useful just for the fact that it gets people to think about the relationships between their classes. It is a good starting point to start thinking about such relationships, but it is definitely not a solution for everybody.
My belief is that the use of UML is subjective to the situation in which the development team is working.
In my experience:
The ability to create and communicate meaningful code diagrams is a necessary skill for any software engineer who is developing new code, or attempting to understand existing code.
Knowing the specifics of UML - when to use a dashed line, or a circle endpoint - is not quite as necessary, but is still good to have.
UML is useful in two ways:
Technical side: a lot of people (manager and some functional analyst) think that UML is a luxury feature because The code is the documentation: you start coding, after you debug and fix. The sync of UML diagrams with code and analisys force you to understand well the requests of the customer;
Management side: the UMl diagrams are a mirror of the requires of the customer who is inaccurate: if you code without UML, maybe you can find a bug in requires after a lot of hours of work. The diagrams UML allow you to find the possible controversal points and to resolve before the coding =>help your planning.
Generally, all the projects without UML diagrams have a superficial analysis or they have short size.
if you're in linkedin group SYSTEMS ENGINEERS, see my old discussion.
UML is definitely helpful just as junit is essential. It all depends how you sell the idea. Your program will work without UML just as it would work without unit tests. Having said that, you should create do UML as along it is connected to your code, i.e when you update UML diagrams it updates your code, or when you update your code it auto generates the UML. Don't do just for the sake of doing it.
UML definetly has its place in the industry. Imagine you are building software for Boing aircraft or some other complex system. UML and RUP would be great help here.
In the end UML only exist because of RUP. Do we need UML or any of its related stuff to use Java/.Net ? The practical answer is they have their own documenation (javadoc etc) which is sufficient and lets us get our job done!
UML no thanx.
UML is just one of methods for communication within people.
Whiteboard is better.