We've got a round of hiring coming up and something that the brass wants to emphasize in the phone screen is UML experience.
Does anyone have suggestions for UML questions to ask in a technical phone screen?
I'm more of an in-person interview guy than a phone screen guy, so "normally" with something like UML I'd have the candidate knock out some simple diagrams on paper. However, I'd rather not have the candidates try to describe an UML diagram over the phone (mostly because I'd be terrible at that, and partly because I'd hate to try and judge them on their UML skills based on my napkin drawing for their description.)
How do other people phone-screen for UML?
Rather than have the candidate draw a diagram, you could have him interpret, implement, or find errors in given diagrams. My impression is that those who understand UML can create and understand diagrams, and those that don't use it much fail on both.
If you trust the candidate enough to not distribute the questions (e.g., this is a late interview), you may want to send him a few moderately complex diagrams by email during the phone screen and see in real time whether he can interpret them. You can send a diagram with an error and ask the candidate to find it. Or you could ask the candidate to code something specific (e.g., class definitions).
If you want to avoid sending questions, setup some web site that will tempoerarily show the diagram (E.g., via flash) but that the diagram cannot be captured without actually capturing the screen (which the candidate should be too busy to do during the interview).
Of course, you can also use a real time shared whiteboarding application and have the user scribble. Most UML in collaborative design is initially generated as freehand sketches, not with formal case tools.
Also, if you like puzzles, one way to do an informal UML interview (assuming you have real-time drawing) is to play "UML pictionary". There was a company in DC that did this at a recruiting event, where candidates had to either draw a phrase in UML, or interpret it.
There is a big difference between the level of UML experience required for a site doing model-driven development and somewhere that wants to use UML just for more formal design and documentation.
You should be in agreement with management about which category you fit or aspire to ;-)
1) ask them which diagram types they use most often and to describe the last occasion on which they used each of those diagrams. If they are really using UML regularly, they should be able to come up with a realistic scenario.
2) ask them to talk about using whiteboard UML vs tools, which can lead into a discussion of their favourite tool and its benefits/weaknesses as well as the need to retain whiteboard diagrams or not.
Anybody who uses UML regularly to think and especially to work out design collaboratively should be able to talk to these points without much hesitation.
Instead of focusing on the details of UML, you could focus instead on the question of why. As in Why would you use UML in this situation? What is the purpose of UML? that kind of question would probably work well over the phone.
Another good question is some variant of "What do you feel are the main limitations of UML?"
Anybody who used UML enough will have a whole list of little annoyances and things that it's just not expressive enough for. Someone who just learned the shapes wouldn't succeed here.
How about some gross UML options which are easy to explain?
Describe the difference in a UML diagram of private vs. public inheritance?
Describe your most used / favorite dynamic diagram and why?
Describe your most used / favorite static diagram and why?
What level of detail have you found UML to be most useful in your development?
What things DON'T go into a use case diagram?
"Have you used UML? For what purpose? What did you think of it?"
The phone screen, IMO, isn't necessarily to detect whether people are lying: in which case there's no need to 'test' people over the phone.
Instead, the phone screen is to see whether (assuming that the person isn't lying) their experience and desires seems like a sufficiently good fit that it's worth their travelling for an in-person interview.
If they were being untruthful during the phone interview, you can detect that later during the in-person interview or on-site test.
I agree with Soldier.moth most people just misuse UML overcomplicating it instead of using it as a communication tool with Users.
So asking WHY is the best question. It is an open question but personnaly that's how you see if the candidate is not a robot learning by rote.
Related
I'm trying to create a UML diagram from the command line without preexisting code.
Eventually I'll write code in C++/Java, but I need to create a diagram first.
I'm thinking of a header-like file, which could be read and could generate a diagram.
Of course, I could just create a header and generate it. However, I'm not supposed to write any code until I've submitted my diagram (I'd also just like to have an efficient way to do this for the future).
UML does not require application to draw. On the contrary one of the main usages of UML is to model the application that you're going to build to understand it better and make a better code as a result.
You also don't use application you create to draw UML diagram. You can use any application that supports UML modelling. Simple Google search or visit on Wikipedia will give you tons of options. You may even take a sheet of paper and a pencil. I've seen a course of UML, where participants did not use computers. They were supposed to learn UML, not tools that allow to draw it.
Finally (answering the question stated in the question topic), UML is in no way limited to model only graphical applications. Static structure and dynamic behaviour of the system exists regardless if user communicates with it through a GUI or command line.
Are you sure you understood the reason why you are supposed to make a UML diagram or do you disagree with that reason? What I can definitely suggest is to find a good book about IT business analysis using UML. This site is not to recommend specific books, but again Google will be your friend here.
As according to the comment the goal is to actually generate a UML class diagram from text let me add a second part of answer
First disclaimer. In general SO is not a place to ask for tools and that question is brushing it. Let me make my answer more generic though.
UML is in general graphical language so technically what you need is something that will parse text version of your "diagram" into a nice picture.
Most if not all tools keep UML in some textual format, be it XMI or some internal legacy solution. The problem with that is that the format is usually pretty complex.
There are some tools that are intended to "draw" diagram by typing text and that's probably something that would suit you best. In general I definitely prefer "normal" GUI but if you insist yuml.me has a nice and easy to understand textual layer based on which it generates really cool diagrams. You may expect you will find others as well, so as usually, ask uncle Google. As suggested by Thomas Kilian in a comment, PlantUML is another example as it can work without GUI and "is an open-source tool allowing users to create UML diagrams from a plain text language." (quote after Wikipedia)
UML is a great language to model software for business requirements, but there is a growing community that points some disadvantages for some lacking features.
What are the most significant disadvantages that you find crucial for UML and what could it be a good alternative to solve this lacking features?
The biggest one is that it's yet another layer of red tape that gets in the way of just $#%$#% coding the thing and making it work.
The fact that people use it to "model software for business requirements", as you put it, and other such process-oriented claptrap. UML started out as a conventionalised way for programmers to communicate software to other programmers in a pictorial form. In that sense it's just formalised napkin-scribbling - and as such it is very effective. You can draw a UML class diagram on a whiteboard and I can understand it without quibbling over notation.
But somewhere along the line someone got the idea that a drawing notation could somehow be a process in it's own right, or at least a formal part of a larger process. And that's just silly. UML diagrams are a fine way to illustrate books, and quite useful as a means for engineers to scribble ideas back and forth. But that's where it should have ended.
I can say at least three:
It takes a lot of time to keep the diagram reasonable and synchronized with the actual code. UML diagrams don't run, but require a lot of time. So they are good only if your organization size can manage them
You cannot represent every condition in a sequence diagram. It's impossible if you want to deliver. So state diagrams should convey basic facts, not all the possible outcomes.
Good UML software costs money and it takes some time to master properly.
So, I think UML is good as a complementary documentation role, and only if the size of your organization allows it.
Solutions... well, in the end, diagramming is just a way to convey high level information to another person, in space or time (e.g. could be you in some year time). Extreme Programming shifts the burden of information retrieval from dead tree to living brain. Of course, it assumes that the living brain never forgets, and never quits. Extreme programming uses redundancy to reduce the impact of such occurrences. In a large company, a strong layoff round could wipeout entire teams, so storing information into brains can be risky. On the other hand, large companies have human power to waste, hence the diagramming.
Also, as WDuffy points out, if you are a designer, and you have to communicate to a team of programmers what they have to implement, it's much easier to use a UML diagram. Of course, a small company with a small team has generally small goals, and you can organize people with a different style. A small company UMLing will only produce UML diagrams of their revolutionary product, and then it will be bankrupt.
UML is not good nor bad. It can be a good tool, but it must be used in the proper context.
Lacking features?
well, I found that UML is strongly aimed at an Object Oriented vision of the world. Our company mainly developed in python, with a strong focus on module level routines. Objects were lightweight data containers, but all the logic was done at the module level. It's difficult to properly model this implementation style at the UML level, unless you resort to some "hacks" in the terminology. I guess it's difficult to model in UML for functional or procedural languages.
Another thing I find annoying is the assumption of use case modeling as a diagram. My experience is that the best way to convey a use case is to write a short story or a short code tingling the feature you want to convey. The story should be short, one page maximum.
This approach has two advantages: if your story is a written prose, the Q/A team can read and test it easily. If your story is code, you can put it as a functional test and let it run during the night. A diagram does not satisfy any of these value added needs.
One issue with UML is due to its universality: things in UML cannot be always implemented directly in the target language, or some languages have capabilities that cannot be expressed in UML. So it can be better to know the implementation language beforehand, which restrain its universality.
See also the criticisms section on UML wikipedia page:
Standards bloat
Problems in learning and adopting
Cumulative Impedance/Impedance Mismatching
Dysfunctional interchange format
It's not Agile
What should have been the last word on UML was written by frustrated student "Candide Smith", well, really Eiffel author Bertrand Meyer.
Another disadvantage of UML is that it tends to overemphasize design, which can lead to 'analysis paralysis' (people over-analyze their problem) and feature creep (loosing sight of the actual problem). A UML design can only take you so far in solving a problem, and you have to be careful to jump into the code soon enough (but not sooner ;-).
UML is somewhat less applicable to the brave new world of loose typing and NoSQL databases. It has OO ideas of Class as a data structure rather than classification embed in it.
Another disadvantage, although not self-inflicted, is that it doesn't explicitly to facilitate abstraction. Everyone I know uses UML tools for more abstract modelling, but the way standards are written that is not obvious.
Another problem with UML (and big design up front in general) is that it's sometimes hard to anticipate all the nitty gritty implementation problems that you'll run into that may affect your design until you actually start implementing something. Granted, I'm a bioinformatics research programmer that works on small one-man projects, but I don't even believe in any design up front, at least for small projects. I believe in the following:
Make it work. (Just get a prototype up and running that has all the basic functionality, no matter how much it sucks. This forces you to see all the little nitty gritty details that might not come through in a formal analysis. Having an actual implementation of your idea makes it easier to see whether the idea was even really worth doing in the first place or whether it should be scrapped altogether.)
Make it right. (Only now, when you have a working prototype and you know that all the nitty gritty implementation problems are at least in principle solvable do you worry about good design. Refactor the heck out of it to follow good programming practices, reduce coupling, do proper error handling, yada yada yada.)
Make it fast. If it's application code, you'd better have proof that you've found the slow part. If it's generic library code, you'd better have good reason to believe that the piece of code could reasonably be the slow part in some use case for the library, i.e. don't optimize a function that noone would ever call in a loop.
For Class Diagrams in UML it only makes sense to use them if there is automated way to generate code directly from diagram. I have implemented such UML editor tool based on 4-tiers meta levels recommended by OMG (Object Management Group) and we had great success using UML in team of 5 devs over 2 years doing around 20-30 architectural iterations. The diagram was the root artifact of automated build chain making impact on hundreds of derived artifacts, APIs, generated Docs, DDLs, projects, tests etc.
So by itself UML in Class Diagrams part is great "programming" language if you actually do programming in it.
For Class Diagrams in UML if it is not translatable in automated way, then its fail.
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.
So what are the UML diagrams (if any) Stackoverflow has been using for documentation and/or for communication with developers?
From what I see, Stackoverflow is something original that also provides rich user experience.
Just wondering what does it take (what helps) to realize a great thought into real life? I`m just a student graduating seeking for advice/experience/suggestions/examples from senieors.
How much these diagrams help in real life and in what volume (the diagrams), I wonder...
UML is a "standard" defined way to communicate something. Being well defined it removes ambiguities that may exist when using other methods.
Having said that I don't use them with my team. I find that the overhead in doing proper UML is too high.
Since I work in a small team (about 5 people) that works in the same location, we'll often sit down and sketch diagrams in discussions. If we need to reference these diagrams, we'll scan them and post them to a repository for later reference.
UML is probably more beneficial in teams that don't communicate well, and may not be co-located.
I really expect all my co-workers to be able to read a UML diagram properly; it's become a kind of universal language for speaking about OO designs.
Back in the days of big design we made tons of models that we put in big binders. Especially sequence diagrams were really nice for detailed designs. These binders would look really impressive on some shelf, but it turned out most of the value in these models are in the process of making them
So now we mostly just draw boxes with lines between them on whiteboards. But whenever we resort to explicit notations to be precise, it's always UML. Usually we photograph them with our phone if they seem like they're worth keeping. Sometimes we just leave them on the whiteboard because they kind-of burn into the whiteboard if they stay there for some days ;) [And you have to be especially daring to use the smelly strong cleaner]
I read an article in Inc Magazine about this site, which is how I found out about it. Apparently very little formal process was followed. Basically, the guys who did it were just really good. My money is also on no UML. I wonder if they use OO?
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.