Have you ever found graphical modeling (UML, CASE tools) to be useful in software development?

Question

I am curious if you might share your experiences developing software using graphical models of any kind. Flowcharts, state diagrams, whatever. Have you found any graphical tools that dramatically increased your productivity over working in pure code?

Answer 1

These tools aren't meant to simply replace some of your programming time. They are tools to aid in the analysis and design phases of software development. Even if you don't use any of the CASE elements (code generation), then UML certainly has its place as a universal graphical language of software analysis and design.

How do you measure productivity? If you mean lines of code per minute, then no, not particularly. But this is just programming - software development is much more than that!

Answer 2

I found those useful as sketches, to communicate my ideas quickly; sequence diagrams, some state machine diagrams are useful to document a project also.

Answer 3

The great thing about graphical representation is that you get a feel for how the application is going to look and feel before you jump into coding. This, in fact, speeds up the programming process because you dont have to stop and think (for the most part) about what a class is going to do or how they are going to relate to other classes and the application.

A good tool to use us Visio. I think its fun to use and its pretty easy.

Happy Coding!

Answer 4

Yes it becomes very apparent to me how to work new features into my database schema when I draw out a crowsfoot ER diagram. Solutions or a current problem become obvious and easy to spot.

I will add that pencil and paper is all I use for this, so my answer to your question about "graphical tools" may be no, never used them.

Answer 5

I like Visio for visualizing solution, especially useful when writing specs and explaining my thought patterns for other developers. UML is also very useful to know as it gives you a language to express yourself that is easily understood (once you learn it).

Answer 6

In a word: No.

I've found that they don't warrant the time it takes to create them and since things in business change rapidly, keep them up to date.

The best modeling technique I've found most efficient is a large pad of paper and a sharpie. It serves the purpose of getting the ideas out, figuring out hierarchies, where things belong, etc...

Its cheap and fast and you don't get attached to it. And, its very easy to create new ones if someone comes up with a better idea.

Answer 7

The dedicated UML tools are pretty useless, but some of tne diagrams can be helpful. The best design tool I've come across is one of those whiteboards that allows you to capture the drawing as a paper copy. I then use an ordinary graphics tool like Visio to draw and maintain copies of the diagrams for the project documentation.

Answer 8

We do not need a UML diagram to represent the program for 1+2=3.

But UML and other modelling techniques are standards of SDLC (Software Development Life Cycle) and is a necessary. It is a matter of communication and understanding.

Answer 9

In short, hell yes.

Whenever I'm creating a reasonably complex program de-novo, I always need to start design with a pencil and paper (or better yet, a whiteboard). Trying to just sit down and pound something complex out with no design is a tremendous waste of time.

I also will go to the whiteboard whenever I have some fairly complex code I need to figure out the structure of. For example, my whiteboard currently contains a call graph from a program I just could not get a handle on. Once I had it graphed, it was easy to see why. From main down to the lowest-level subroutine it ended up being 11 different routines from 3 different source files called from within each other, including one in the middle invoked as a callback and one more near the bottom that also calls itself recursively (so the call stack itself isn't 11, but way higher).

Now with the graph I can just look up at the whiteboard whenever I forget where in the chain I am. If you can keep all that in your head as well as me without the whiteboard, I humbly suggest you should be off counting cards in Vegas and not wasting your time coding.

Answer 10

UML? Yes. Very useful. However, I'm not a fan of software tools; I've never had much luck with auto-routing lines, and have to waste a lot of time moving them around. When it comes time to make a change, it's a pain. I'm much more productive and comfortable with a whiteboard or a notebook.

The programs are great if you need to make a clean diagram for a presentation. They aren't too useful for design.

Answer 11

I find them very useful for mapping programs that are already out there - part of my job is modernizing huge amounts of hacked scripts that have emerged over time to be very important.

UML allows me to work out what the current thinking is - simplify it - update it then finally put it back into place.

Answer 12

No, but yes.

I find modelling tools to be far too nitpicky about how I want to express an idea, and I spend more time "tweaking" the diagrams than actually drawing stuff out. However, when I am designing a class heirarchy or a state diagram, I do use the modelling diagrams.

I just do them with pencil and paper instead.

Answer 13

I'd also like to add it is useful for things such as the Common Information Model (see CIM under www.dmtf.org) because without UML, it'd be very difficult to explain.

Answer 14

There's a difference between modelling and models.

Initially in the design process, the value in producing a model is that you have to to get to a concrete enough representation of the system that it can be written down. The actual models can be, and probably should be, temporary artefacts such as whiteboards, paper sketches or post-it notes and string.

In businesses where there is a requirement to record the design process for auditing, these artefacts need to be captured. You can encode these sketchy models in a UML tool, but you rarely get a great deal of value from it over just scanning the sketches. Here we see UML tools used as fussy documentation repositories. They don't have much added value for that use.

I've also seen UML tools used to convert freehand sketches to graphics for presentations. This is rarely a good idea, for two reasons -

1. most model-based UML tools don't produce high quality diagrams. They often don't anti-alias correctly, and have apalling 'autorouting' implementations.
2. understandable presentations don't have complicated diagrams; they show an abstraction. The abstraction mechanism in UML is packages, but every UML tool also has an option to hide the internals of classes. Getting into the habit of presenting UML models with the details missing hides complexity, rather than managing it. It means that a simple diagram of four classes with 400 members get through code review, but one based on a better division of responsibilities will look more complicated.

During the elaboration of large systems (more than a handful of developers), it's common to break the system into sub-systems, and map these sub-systems to packages (functionally) and components (structurally). These mappings are again fairly broad-brush, but they are more formal than the initial sketch. You can put them into a tool, and then you will have a structure in the tool which you can later populate. A good tool will also warn you of circular dependencies, and (if you have recorded mappings from use cases to requirements to the packages to which the requirements are assigned) then you also have useful dependency graphs and can generate Gantt charts as to what you need for a feature and when you can expect that feature to ship. (AFAIK state-of-the art is dependency modelling and adding time attributes, but I haven't seen anything which goes as far as Gantt.)

So if you are in a project which has to record requirements capture and assignment, you can do that in a UML tool, and you may get some extra benefit on top in terms of being able to check the dependencies and extract information plan work breakdown schedules.

Most of that doesn't help in small, agile shops which don't care about CMMI or ISO-9001 compliance.

(There are also some COTS tools which provide executable UML and BPML models. These claim to provide a rapid means to de-risk a design. I haven't used them myself so won't go into details.)

At the design stage, you can model software down to modelling classes, method and the procedural aspects of methods with sequence diagrams, state models and action languages. I've tended not to, and prefer to think in code rather than in the model at that stage. That's partly because the code generators in the tools I've used have either been poor, or too inflexible for creating high quality implementations.

OTOH I have written simulation frameworks which take SysML models of components and systems and simulate their behavior based on such techniques. In that case there is a gain, as such a model of a system doesn't assume an execution model, whereas the code generation tools assume a fixed execution model.

For a model to be useful, I've found it important to be able to decouple the domain model from execution semantics. You can't represent the relation f = m * a in action semantics. You can only represent the evaluation followed by the assignment f := m * a, so to get a general-purpose model that has three bidirectional ports f, m and a you'd have to write three actions, f := m * a, m := f / a, a := f / m. So in a model where a single constraint of a 7-ary relation will suffice, if your tool requires you to express it in action semantics you have to rewrite the relation 7 times. I haven't seen a COTS UML tool which can process constraint network models well enough to give a sevenfold gain over coding it yourself, but that sort of reuse can be made with a bespoke engine processing a standard UML model. If you have a rapidly changing domain model and then build your own interpreter/compiler against the meta-model for that domain, then you can have a big win. I believe some BPML tools work in a similar way to this, but haven't used them, as that isn't a domain I've worked.

Where the model is decoupled from the execution language, this process is called model driven development, and Matlab is the most common example; if you're generating software from a model which matches the execution semantics of the target language it's called model driven architecture. In MDA you have both a domain and an implementation model, in MDD you have a domain model and a specialised transformation to map the domain to multiple executable implementations. I'm a MDD fan, and MDA seems to have little gain - you're restricting yourself to whatever subset of the implementation language your tool supports and your model can represent, you can't tune to your environment, and graphical models are often much harder to understand than linear ones - we've a million years evolution constructing complex relationships between individuals from linear narratives, (who was Pooh's youngest friend's mother?) whereas constructing an execution flow from several disjoint graphs is something we've only had to do in the last century or so.

I've also created domain specific profiles of UML, and used it as a component description language. It's very good for that, and by processing the model you can create custom configuration and installation scripts for a complicated system. That's most useful where you have a system or systems comprising of stock components with some parametrisation.

When working in environments which require UML documentation of the implementation of a software product, I tend to reverse engineer it rather than the other way.

When there's some compression of information to be had by using a machine-processable detailed model, and the cost of setting that up code-generation of sufficient quality is amortized across multiple uses of the model or by reuse across multiple models, then I use UML modelling tools. If I can spend a week setting up a tool which stamps out parameterised components like a cookie-cutter in a day, and it takes 3 days to do it by hand, and I have ten such components in my systems, then I'll spend that week tooling up.

Apply the rules 'Once and Once Only' and 'You Aren't Gonna Need It' to the tools as much as to the rest of your programming.

So the short answer is yes, I've found modelling useful, but models are less so. Unless you're creating families of similar systems, you don't gain sufficient benefit from detailed models to amortize the cost of creating them.

Answer 15

Yes! For me UML class diagrams and alike turned out to be very useful for at least two purposes:

1 To explain design ideas to colleagues and to improve on the initial design together. You really do not want to do this by going through code line by line, and often you don't have any code yet at this stage.

2 To document the design, but always as an illustration to clarify a textual story.

Also note that UML class diagrams can exist in two forms: diagrams of a domain model and diagrams of source code. Domain model diagrams show how you see the customer's problem before you make the translation to code. See the book of Larman: Applying UML and patterns.

Answer 16

Try this: StarUML (it rocks!)

Answer 17

yes, modeling saves time in design , saves time in code generation rather than paper designs and hand written code. All it needs is expertize on the tool we are using!!

Answer 18

Yes.

Having some visual model of key parts of the system is essential for making sure that you're arguing about the same thing.

The specifics vary by project and domain. On several past projects, a few interaction diagrams were key to shared understanding. On another project it was a big E-R diagram. One project had a handful of state transition diagrams. The specifics were less important than the fact that we had a few diagrams on a wall that we could gather around to discuss how to grow the system incrementally, with some assurance that we had a shared understanding of the key bits.

As far as tools, a big whiteboard, a good set of markers, and a digital camera can take you pretty far. Or flip charts and blue tape.

The problem with tools is that they have a learning curve with a high opportunity cost for everyone to learn. And if only a few people can drive the tool, the diagrams get frozen or stale pretty fast. And people up the chain tend to had excess faith in nice looking pictures.

Answer 19

As a technical leader I was always explaining sections of the code-base to team-members. I'm a visual thinker, so as I talked I drew diagrams. And I was always drawing the same pictures.

My solution was to draw them as UML diagrams using Visio and put them on the company Wiki.

When somebody asked me a question I could save time by saying "Lets bring up this diagram". And then the developer would use this as a constant reference.

So yes, the UML diagramming techniques and Visio improved my own productivity.

Answer 20

If you'd like to focus on building you model and not manipulating objects on diagram, you must try Red Koda Community. Check the one minute sequence diagram video, you can see how easy and fast you can use it with the aid of short cut keys.