This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
For small applications (30 to 40 man months), is it really worth the effort to use UML process or can we just describe how our application is designed using simple english and some flow charts.
UML is only a way to express a design in drawings, not a methodology or process. The most important thing when you do software architecture is to think. UML won't help you do that. If you think first, UML will help you express what you have in mind so it is clear to others as well. see UML is a communication tool. If you are the only guy in the shop that knows UML, it's not as useful (you can still do prototyping tough).
I asked something similiar question awhile ago see this thread for the responses I got [This message has been edited by Johannes de Jong (edited October 04, 2001).]
Few months back I got an opportunity for analysis and design for a small size project.We were a team of two and we ran our brains in all possible ways to make the design as elaborate as possible,with page size descriptions and comments for the developers.However during the production,there were so many changes-- we wanted new data structures,methods and even some new classes to meet what the customer wanted.The final project design was considerably different from the original in details, though the overall structure remained. The essence::While a design might not be able to cover all the distinct minute areas,still it gives the developers overall direction.For the rest they need innovation and ofcourse some brains:-) Mahesh
UML is just a set of diagrammatic conventions. As mentioned earlier, UML is not a process. Personally, I like UML -- it's a good way to describe the way that Java classes interact. Of course, I don't use all of it -- I'll usually draw class diagrams and interaction diagrams (and occasionally the rare package diagram) and leave it at that. I have friends that have done just as well when using CRC cards instead of UML. I used to use CRC cards, but I've just found that since I'm more visually oriented, that UML suits my style better. However, if you are using an OO language (Java, C++, etc.) I really believe you should use an OO design notation. UML works great with that. Flow charts aren't OO -- they can't convey the ideas of inheritance, polymorphism or other OO specifics. For that reason I would strongly discourage you from using flow charts to describe an OO program.
I strongly agree with Kyle. I can't imagine using a flowchart to describe event-driven programming. I tend to use class diagrams the most, but sometimes will create a sequence or activity diagram to illustrate simple program flows. I guess they take the place of flowcharts when a part of your program is sequential. - Karen
Originally posted by prince alex: For small applications (30 to 40 man months), is it really worth the effort to use UML process or can we just describe how our application is designed using simple english and some flow charts.
A picture is worth a thousand words. Flow charts are better suited to proceedural languages. True, at a high level, flow charts are useful here, but it is no substitute for an object model. Bottom line, you need to use something. Keep in mind, there are alternatives to UML. One criticism I've heard of UML is that it is too heavy weight. So for small projects you may want to consider an alternative modeling language. --Mark
Kyle Brown
author
Ranch Hand
Joined: Aug 10, 2001
Posts: 3879
posted
0
Originally posted by Mark Herschberg: A picture is worth a thousand words. Flow charts are better suited to proceedural languages. True, at a high level, flow charts are useful here, but it is no substitute for an object model. Bottom line, you need to use something. Keep in mind, there are alternatives to UML. One criticism I've heard of UML is that it is too heavy weight. So for small projects you may want to consider an alternative modeling language. --Mark
Rather than an alternative modeling language, you should probably just discard those parts of UML that you don't need. See Fowler's UML Distilled for a good "lightweight" version of UML.
I've never used UML in a professional envirnment (hell, I've never done anything in a professional environment), but I think it's a great weapon. When I was first looking into UML, I downloaded an incredibly lightweight tool from Sourceforge called UMLSculptor and started to redesign and old project. UML helped me to find lots of design flaws and replace them with more flexible, effective, and well designed OO patterns. Now I use it all the time. UML is good stuff.
The other posters make some good points about UML. You can pick and choose the parts that you use, and select the level of detail that suits. Some (most?) people are happy with class diagrams and a few interaction diagrams, while others delve into meta-models and collaborations. One advantage which I have experienced, and is less discussed, is from an educational perspective. It can help provoke questions in your design work - e.g: - why does UML separate type and implementation classes? Maybe I should be looking more at using interfaces, and less concrete classes? - why does UML have notation for visibility? Maybe all those attriutes shouldn't be public after all... - what are Parameterised classes? Maybe that could be useful for my collections framework...? Personally, I find UML to be invaluable. It strikes a good balance between rigour and informality - I cannot imagine working on an OO project without using UML. There are problems and limitations of course, but you can usually work around them ('sticky notes')! regards, paul.
0
