Fog Creek Software
Discussion Board




Visual Modelling Tools - UML, OPEN and others

It's been about two years now that I'm constantly bombarded with advice that I should use visual modelling tools for developing software, or I would stand no chance in being able to develop or understand the complex relationships in today's software. Being a practitioner of the "if it ain't broke, don't fix it" school, and not having anything broken with my ability to develop software, I was in no rush - but after a while, I decided to play a little with some modelling tools.

I haven't spent enough time to be an "expert witness" on this subject, but to me it seems like pure overhead. I reverse-engineered a project I was not familiar with, and tried to gain elightenment through the generated diagrams. Granted, I'm not very proficient at reading them, but they seem to give very little of the "REAL" semantic info - I got much more insight much faster by reading the source; And eventually, the source is all there is - the semantic mapping between any of the UML concepts and what actually happens is so shaky if at all existent that I find the additional value hardly worth the trouble. I have yet to start a project "from scratch" and try to apply this methodology - I hope to do that sometime soon, but I haven't seen anything to hint my experience will be different.

I'm not saying the concepts are wrong - far from it. Use cases and such are absolutely essential. But I really don't see how a sequence diagram helps you any more than the code that implements it, ESPECIALLY since the semantic correspondence is virtually non-existent so the diagram and the code aren't guaranteed to represent each other. If it's complex enough to require nontrivial documentation, UML isn't much help (A free form text file will probably be required), and if it's simple enough than the code is enough.

Back in 83 when I first studied how to program, most beginner books insisted that if you don't draw a flow-chart before writing code, you're doomed to a miserable future of being unable to understand your own code. People actually believed it at some poing in time, but eventually sense (IMHO) won, and most of us DON'T flowchart. Most of the UML propaganda I hear is along the same lines, which gives me that feeling of deja vu -- except this time, there's lots of money involved.

Either I am just 'not getting it' (like I'm sure at least some of the responses will say), or I AM getting it, but there's too much money in it for the industry to admit. I'd like to hear others' experience and thoughts on the subject (Especially you Joel, if you can find the time). I was able to trace all success stories I could find regarding visual modelling tools back to the press releases of the company whose tool was used - are there any independent success stories or case studies we can discuss?

Ori Berger
Sunday, March 03, 2002

Are you the only developer? UML is useful when you have to get everyone "on the same page."

Recently we designed a product that would allow people to enter project info into a database, run various reports on it, get feedback, etc. and it would keep the information inperpetuity.

We broke it down into 3 major components, the admin screen (you log in and see your projects) the edit screen (you edit your project info, and other people view it and pass back comments), and third for reporting.

We drew a box for each, bullet pointed functions for each box, and drew arrows (with accompanying text on what was being done) between the boxes. I know a little UML, and I doubt this is 'well formed' UML, but it was great for getting us all to understand what needed to be done, and the lead programmer copiously referred back to the document (eventually taken off the white board and done in Visio).

As for Use Cases I find drawing, describing, and sequencing everything the system does very tedious.  There must be a way to do it that's final, so once you transcribe it, you don't need to redescribe it.

Mark W
Sunday, March 03, 2002

I don’t think that every single algorithm we write needs to be flowcharted. In fact, most of the flow for a small routine can be done mentally. When the routine being written gets a bit larger, then scribble notes on a piece of paper do the trick. The problem is as a project progresses, these scribbles notes are thrown in the garbage bin. In other words, that “need” for understanding the routine being written is in general only needed during development. Of course, this then means that the next developer will have to figure out the routine via looking at the code, and that is hard work.

Thus, if one can find a nice way to “keep”, or create nice flow drawings of each part of the system being written, then one should do so. The problem is that we don’t employ a good means to transfer these scribble notes into the finished project. To me, those scribble notes are most technically advanced way to design and develop software.

Most of my software is very data centric. This means a information system, and thus where I do use drawing tools is for Entity Relationship diagrams. Ask any developer what they prefer:

1) Really good code, and bad data design

2) Really good data design, and bad code.

You will find that virtually every developer will choose the 2nd option. With a good data (table) design, a application practically writes it self. Since good data design is the key to good software, this is where I put the most effort in my projects.

When I have to maintain, or go back to a old system, I need most the table structures, and the data relationships that exist. In other words,the algorithms are usually written quite well. The real question becomes can I add, or delete some data without messing up another part of the system. What data tables exists, and how are they related each other. Change I change this one thing and not damage the other parts of the application? Hence, the data structure is the key here. Hence there is where I *do* suggest that using drawing tools pays off big time.

They are not fancy, but I do put some effort in them. When done, these ER diagrams do become part of the application. For me, they become the most valuable tool. Even during the development process, they are of most use.

Here is a link to one of my ER diagrams.

http://www.attcanada.net/~kallal.msn/Articles/PickSql/Appendex1.html

and also:

http://www.attcanada.net/~kallal.msn/Articles/PickSql/Appendex2.html

I use Visio for my initial data diagrams. Once the project gets started, then the built-in database ER tools are used. I also do make some general “flow” diagrams for the client during the information gathering process. This “flow” diagrams are *most* useful to the client during discussions, and as to what/how things are going to be done.

Albert D. Kallal
Sunday, March 03, 2002

You need "working paper" not paper work.  Where I am working they use RR/UML extensively, and 99% of the documents they produce add no value at all.

I am a contractor so I learnt RUP and UML, I had too, but I would not use it on any project that I paid for. 

Its the latest in-carnation of case tools, and a new way to make money (tools, traning & management brain-washing).

Give me a simple box, a simple line and a good label and im happy. Oh, and most people can understand the resulting diagram.

James Ladd
Monday, March 04, 2002

I'm agree with previous post. The result of our activity is a software, not flowcharts. So you always should keep a balance, because documenting your design can easily eat your time.

Of course it is nice to have up-to-date UML or ER diagram of your design, but keeping it up-to-date is a waste of time.

So in our team we do UML, ER and other diagrams, but we throw them away as soon as they did their job - put everyone on the same page.

There is a good article about what design is -
http://www.xprogramming.com/xpmag/AchillesTortoise.htm

Roman Eremin
Monday, March 04, 2002

Ori Berger wrote:
"Back in 83 when I first studied how to program, most beginner books insisted that if you don't draw a flow-chart before writing code, you're doomed to a miserable future of being unable to understand your own code."

That brings back memories of the time when I was at the university and had to program my first lines of code.

My university was a strong believer in the UML approach. So, we were forced to have our UML flow charts approved before we were allowed to show our final code. Most students quickly learned that this was a real time waster. So this is what 95% of all students did: Program the application and afterwards create the flow-charts, which, like a miracle, always turned out to be correct.

Our teachers must have thought that the UML approach worked really really well, because most of us showed perfectly fine working code within hours after showing the UML.

Jan Derk
Monday, March 04, 2002

I teach UML and in itself, it has not much value [just a notation]. BUT, when framed in an appropriate logic of thought, it goes much further than ad-hoc notation.

Separating the concerns of all parties into clear points of view help a lot on a complex system. A system is not just 'code'... Any system I have been involved with was 20% technical and 80% peopleware. That's where communication matters. And UML help. UML is a tool, not a religion...

Philippe Back
Monday, March 04, 2002

Best visual modelling tool you can get: Black felt tipped drafting pen: 0.5mm or 0.7mm is really good plus a flip-chart refill pad.

I use a cut down Booch notation for the classes. Different coloured pens for making different annotations...

That's it: it's big enough that four or five people can cluster around it on a table. You can draw diagrams with enough space to add things in as you think. You can't edit or erase stuff, so you won't waste time doing so.

If the diagram gets too scruffy, copy it out onto a fresh sheet and file the old one.

When you're done, pin the diagram on the wall.

If you absolutely have to do "proper" software engineering, stick it into Rose then.

Flipchart refills are easy to carry around the building to whichever meeting room is free. Photocopy the thing if you need copies... far too much of software engineering is about making neat things, not useful things. Specifications that are full of words but not actual information, UML diagrams that are too complicated to decode without a dictionary but look neat when printed out...

That's my opinion - the round-trip of Rose is a red-herring, because it just doesn't work. The code generation MIGHT be useful but it's only for OO languages... not for, say, the nest of Perl scripts and HTML fragments making up a server-side web application.

Development documents must be living documents - able to evolve, able to be sketched and lightweight. The user interface needs to be zero. Far too often people start playing with modelling tools and end up spending more time looking for arrow configuration settings than thinking about their systems.

The only computer based tool I ever used to use in anger was Microsoft Access: it has a neat database schema editor - has the tables laid out with all the links between them and stuff. Nice tool, but then you CAN'T PRINT THE DAMN THING OUT. That's what it needs: an A1 printout of the tables that you can hang on the wall...

Paper and pen has a REALLY low learning curve.

Katie Lucas
Monday, March 04, 2002

Access 2000 finally added File, Print Relationships after generations of developers had spent time capturing and printing screenshots of the relationships window.

I'm just starting to look at Rational XDE, which promises round-trip modeling in Visual Studio .NET. If it works I may finally switch from pencil & paper to a UML tool, at least for some projects.

Mike Gunderloy
Monday, March 04, 2002

Very interesting stuff.

One topic that's been going on around here is how to document the work you do. Not being a programmer myself, I don't think I can really contribute much to the conversation and I generally stay out of it.

Consensus seems to be that you simply keep good comments in your code. Occasionally someone mentions producing a document based on those comments, or that describes the application, or the individual scripts that make up the application from a high level. The rest, they say, should be self evident from the code.

It seems to me that UML is good for keeping documents in-perpetuity so that years later someone can quickly come up to speed on what something does. Examine a nice diagram showing the whole system (or a particular subset) and then dive into the code. First get an understanding of what it's supposed to do and then you dive in, or use the diagram as a roadmap as you're exploring.

"Oh, it's an engine so there will be pistons, fans, cooling systems, ah, and the particular piece we're looking at is the part that mixes the fuel with oxygen for combustion. Okay, now let's get our hands dirty and see how that's handled in this particular engine."

For example, a team we work with did a knowledge transfer from one development team to another. From what I hear it went smoothly, and I'm sure it had to do with the copious documentation they did.

Also, unlike the achilles/tortiose example above (the XP link), in a month or so there will be nobody to ask about the system. Again, documentation helps.

So, my question is, how do you document your work "for future generations"?

Mark W
Monday, March 04, 2002

The proper use of UML or some other visual modelling language can be invaluable to a project.  I started working with Rose in about '93 and have problems conceiving any reason why you would avoid using such a tool in large scale system development.

Granted, a team of one or two could live without it but it is the most efficient way to gain insight into the relationships and dependencies of the system.  The philosophy of 'just read the code' scales poorly.  Even having said that, I would probably use Rose for small scale projects because it is a part of my design philosophy.  I need to type the data in somewhere, it might as well be in a tool from which I can generate both my code and documentation.

The round trip engineering aspects of Rose are workable but I would only use them to establish a baseline.  Once you have your model up and running, it becomes simple to say that any code updates have to be generated from the model.  In this way, the model never falls out of line with the code and you can always view the current design.

I have model files in Rose dating back 10 years and for the most part, the design information stored in them is relevant and usable today.  If someone needs to understand how things work, you can point them to the model to get the total view.  Yes, you might be able to piece this together from the code, but I am pretty sure it will take you considerably longer.

UML is a tool.  Use the portions of it that are most applicable to your job and go from there.  I wouldn't advocate writing down every scenario and use case, but documenting the key ones is pretty important to a good design.  As a minimum, the information that you can derive from a well drawn class diagram can't be beat.

!
Monday, March 04, 2002

It seems the people who actually use UML do not use a fancy tool. We have one pen and marker user, two Visio users and only one Rose user.
Am I hearing, UML can be usefull, but don't waste money on the high $$$ tools?
What is the best tool for designing with UML? Is it worth more than the copy of Visio I already have?

Doug Withau
Monday, March 04, 2002

You might want to have a look at Enterprise Architect from Sparx systems ( www.sparxsystems.com.au ).
It's a nice tool for less than $150.
It beats rose in my view.
I even went so far as registering it... A really good product with added diagrams. Well Visio does them too but this one looks better to me.

Philippe Back
Monday, March 04, 2002

I can't find any evidence on Google (which nearly voids credibility to the next statement), but I heard that in a lecture somewhere, when Kent Beck, one of the fathers of extreme programming, was asked what he thinks about UML he responded with "I prefer my own invention, called 'GML', which stands for 'Galactic Modelling Language'; It consists of arrows, boxes, and arrows pointing to boxes". The responses so far seem to indicate that GML is what people actually use.

"Reading the code" doesn't scale -- granted. But neither does any other programming methodology, or for that matter, any other design methodology. For example, if you insist that diagrams be modified and code generated from them, you'll most probably find that when 40 people are working on the project it becomes infeasible -- unless, of course, the project is well modularized so that only 3-4 people modify any specific part of the project, in which case "reading the code" still scales. No, I haven't tried that with UML or Rose, but I have tried to keep documentation up to date, and it seems that more than 3 people on a specific module guarantees code and non-code will go out of sync.

I think the important issue is that class spaghetti, the all-too-common modern day equivalent of code spaghetti that structured programming was able to efficiently reduce, does not scale. If there's no spaghetti, you can just read the code; If there is spaghetti, well - you can reduce the pain with modelling tools, but they won't help you solve the problem.

I can recommend Doxygen [ http://www.doxygen.org ] - it simlpy rocks. It can read Java, C, C++ (and PHP, if you try hard enough), and produces docs in RTF, HTML, CHM, unix man pages and beautiful LaTeX (compilable to PS or PDF). The docs map all classes and relationships (producing clickable class diagrams), optionally creates extensive cross referenced and review-ready code, maps #include and import dependencies, and generally does an excellent job of putting order into the chaos of ANY project.

If you go as far as actually marking up your source with Doxygen specific markup (which is basically enhanced JavaScript), you get high quality user presentable documentation, which can be used from inside Visual Studio and others; e.g., markup such as:

/** Compute the final question.
.    The answer is known to be 42 for some time now,
.    but the question is yet unknown - this function
.    computes it.
.    @return The final question.
.    @todo Project must finish before earth is blasted.
.    @bug In space, no one can here you scream. */
char *FinalAnswer(double x, /**< Improbability Factor */,
.                            double z, /**< Impossibility Factor */) {
...
...
...
}

Gets transformed into quality formatted documentation in any of the formats above.

Ori Berger
Monday, March 04, 2002

Good discussion. I have comments at various points along the way.

[FULL DISCLOSURE: When I'm not consulting as a software developer, I teach UML design for a living, and use Rational ROSE day in and day out for all my development. Consider that as expertise or as bias, as you wish.]

To be concise, I'm only commenting where I either disagree or see something to add. (Albert, Philippe, and the anonynous poster who started with ROSE in 93: I hope we meet at some conference some day, to swap insights and war stories.) Let's start with Ori Berger's original post...

****************************************

<< It's been about two years now that I'm constantly bombarded with advice that I should use visual modelling tools for developing software, or I would stand no chance in being able to develop or understand the complex relationships in today's software. >>

This is overly enthusiastic advice. Clearly, good code DOES get written without these tools. But as a practitioner who uses these tools, I find they make my job easier. Some people get evangelical about what works for them. UML is no different from extreme programming, Java, C++, or any number of other over-hyped tools in that regard.


****************************************

<< I haven't spent enough time to be an "expert witness" on this subject, but to me it seems like pure overhead. I reverse-engineered a project I was not familiar with, and tried to gain elightenment through the generated diagrams. Granted, I'm not very proficient at reading them, but they seem to give very little of the "REAL" semantic info - I got much more insight much faster by reading the source; >>

Forgive me, but your lack of expert witness status may have just demonstrated itself. What you did was good, but it was only the start of a MUCH larger process. In my experience, reverse engineering only provides structure, not semantics; then you have to apply expertise to convert that structure to meaning.

Let me tell a brief story (yeah, like I've ever told a BRIEF story) as a counterexample. I inherited a huge project when its creator got fed up with office politics and quit with zero notice. As the only other Visual C++/MFC developer in the organization, the job fell to me. (There was one other who MIGHT have laid claim to the necessary skills, but he wanted no part of that train wreck.) Part of what made my predecessor quit so undiplomatically was the ridiculous pressure to produce bug patches nearly every hour. Well, I had NEVER seen this code before. I could immediately plead ignorance and thus dictate a more reasonable schedule. The first thing I demanded -- and got -- was two weeks before anyone would even ask me for bug fixes or new features. The second thing I demanded -- and got, again: it's nice to have management over the barrel when you want to do things right -- is that after two weeks, we could discuss schedules and priorities, not immediate bug fixes. I needed to UNDERSTAND this code base -- literally thousands of source files developed over nearly ten years, with essentially no design docs -- before I would touch it.

So I took the code home with me, and disappeared for two weeks. I also took home a license for Rational ROSE. And then I did what it sounds like you did: reverse engineered the structure of the code. BUT! That was only step one. In a typical design, that structure comes at or near the end of the design process (unless designing changes to a new system).

So next I needed to apply experience with UML. Reverse engineering doesn't give you the experience, so reverse engineering would be less useful for you than it was for me. What comes before structure is functionality (depicted in Use Case Diagrams) and detailed interaction underlying  that functionality (depicted in interaction diagrams: Activity, Sequence, Collaboration, and maybe State Diagrams). ROSE doesn't reverse engineer those (maybe another tool does), so I had to do that work manually. But I could do that, because of my lengthy experience with MFC.

Because my predecessor used standard MFC input mechanisms -- message maps, object maps, etc. -- I knew how to recognize all the functions expected from outside the system. These became Use Cases in a Use Case Model. That helped me to organize the functionality in a way that made sense to me; and simultaneously, to create and organize the diagrams, I had to comprehend the code at a deeper level.

Then, once I had the Use Cases defined and the structure reverse engineered, I could manually create the interaction diagrams implied by the code that handled each outside input. In other words, I built meaning out of the structure by reading the code and the structure side-by-side. And again, to create and organize the diagrams, I had to comprehend the code at a deeper level.

At the end of two weeks, I was ready for the questions. I didn't understand the whole code -- how could I understand thousands of files in two weeks? -- but I understood the big picture well enough to handle maintenance on the system. When they reported a bug in a certain function, I could dig into the corresponding Use Case and the underlying interaction diagrams to understand how that code worked in general, as well as how to reproduce the problem. When they requested a new option on an existing feature, I could dig into the corresponding Use Case and interaction diagrams, then find the corresponding structural diagrams and see where and how the structure could be modified to support the feature. By the end of six weeks, they were extremely happy with the progress we had made.

Note that one major use of UML was what I call the Outlining Syndrome. A good study habit (which I never learned until far too late for my GPA) is to simply outline the course material. A similar good requirements gathering technique is simply to restate what you hear, but phrase it in your own words. By striving to express what you perceive in another fashion, you amplify your comprehension: first, because you must pay more attention in order to comprehend it, either aurally or visually; and second, because you have to output the information, you process it through still more parts of your brain. Cognitive science shows that the more ways you have to process the information, the more you comprehend it. (This is why I have to disagree SLIGHTLY with the respondent who said you don't need UML for solo work: I think he's right that you get the most benefit from communication with UML, but I see benefit even on solo projects.) You don't need UML for this, of course -- before I knew UML, I used to do very similar things simply by going through and commenting the intent of the code I inherited -- but it's a very simple tool for this sort of work.

And that leads into an even more important point: UML by itself did nothing for me; it was the process in which I used UML that counted. Much of what I did in this example was simply sound development process, period: getting the right people for the job, demanding realistic schedules, getting team and management commitment to those schedules, design docs (ANY design docs), uninterrupted time to think... But UML certainly helped.

Just remember: UML won't solve your problems; but UML is a tool you can apply as you solve your problems.


****************************************

<< And eventually, the source is all there is - the semantic mapping between any of the UML concepts and what actually happens is so shaky if at all existent that I find the additional value hardly worth the trouble. I have yet to start a project "from scratch" and try to apply this methodology - I hope to do that sometime soon, but I haven't seen anything to hint my experience will be different. >>

Fair warning: the learning curve is steep. In my case, I saw a net improved productivity after about six months. I try to shorten that with my classes, but I doubt anyone will see a net benefit in under three months. So if you give up too soon, you'll miss the benefit.


****************************************

<< I'm not saying the concepts are wrong - far from it. Use cases and such are absolutely essential. But I really don't see how a sequence diagram helps you any more than the code that implements it, ESPECIALLY since the semantic correspondence is virtually non-existent so the diagram and the code aren't guaranteed to represent each other. If it's complex enough to require nontrivial documentation, UML isn't much help (A free form text file will probably be required), and if it's simple enough than the code is enough. >>

Not in my experience. But you must decide for yourself.


****************************************

<< Back in 83 when I first studied how to program, most beginner books insisted that if you don't draw a flow-chart before writing code, you're doomed to a miserable future of being unable to understand your own code. People actually believed it at some poing in time, but eventually sense (IMHO) won, and most of us DON'T flowchart. Most of the UML propaganda I hear is along the same lines, which gives me that feeling of deja vu -- except this time, there's lots of money involved. >>

That was my experience then, as well. Now I'm doing penance by having to teach young whippersnappers like I was that these diagrams -- properly applied, NOT drawn just because somebody says so -- actually help you to solve problems faster. And problem solving is where the fun is.


****************************************

<< Either I am just 'not getting it' (like I'm sure at least some of the responses will say), or I AM getting it, but there's too much money in it for the industry to admit. I'd like to hear others' experience and thoughts on the subject (Especially you Joel, if you can find the time). I was able to trace all success stories I could find regarding visual modelling tools back to the press releases of the company whose tool was used - are there any independent success stories or case studies we can discuss? >>

Plenty, if you're interested. Contact me and I'll discuss further. I'm obsessive on the topic.


Then Mark W said...

****************************************

<< Are you the only developer? UML is useful when you have to get everyone "on the same page." >>

See above. If you say "MOST useful (by a very large degree)", I'll agree.


****************************************

<< We drew a box for each, bullet pointed functions for each box, and drew arrows (with accompanying text on what was being done) between the boxes. I know a little UML, and I doubt this is 'well formed' UML, but it was great for getting us all to understand what needed to be done, and the lead programmer copiously referred back to the document (eventually taken off the white board and done in Visio). >>

I'm a pragmatist: if it works, it's good UML. Yours worked, so it's good enough.


Then James Ladd wrote...

****************************************

<< You need "working paper" not paper work. Where I am working they use RR/UML extensively, and 99% of the documents they produce add no value at all. >>

Then the diagrams shouldn't be drawn. Again, pragmatism.


****************************************

<< Give me a simple box, a simple line and a good label and im happy. Oh, and most people can understand the resulting diagram. >>

If that's not just as true of the UML diagrams, then someone is horribly misusing UML. You've hit on some key concepts, which all add up to: the diagrams must be comprehensible, so as to communicate and solicit feedback. If that's not true, then why draw them?

Like your diagrams, most people can understand my UML diagrams, WITHOUT me having to teach them UML. I think we can all agree that's a good thing. But I'm biased enough to believe that, since my diagrams are in a standard notation, there's an added benefit to them.


Then Roman Eremin wrote...

****************************************

<< Of course it is nice to have up-to-date UML or ER diagram of your design, but keeping it up-to-date is a waste of time.

So in our team we do UML, ER and other diagrams, but we throw them away as soon as they did their job - put everyone on the same page. >>

Here I have to disagree a little more strongly. In this example, the diagrams have done ONE very important job -- putting everyone on the same page -- but they can serve other purposes. One big job is introducing newcomers to what has gone before.

Now you can argue that keeping the diagrams up-to-date is a waste of time; but I have two separate responses there:

1. That's why I use the code generation and reverse engineering capabilities of a powerful tool. I know that I just immediately alienated a good chunk of the development community by saying that, but these work for me. Isn't a tool that works a good thing? I can make structural changes in my model, and I can implementation changes in my code; and the tools today work together so seamlessly that I hardly notice I'm working in two tools. Again, it's easier to appreciate this benefit with experience.

2. So the diagram and the code get out of synch? So what? The map in the glove compartment of my car doesn't show the road construction I will inevitably encounter on my way into Detroit tomorrow. Should I throw it out? Nope, because on balance, the map is far more right than wrong, and can help me to understand MOST of my route. Then I apply my problem-solving skills wherever I find the map to be wrong. And when I create the map (i.e., the model), then much like refactoring, I can go in and correct the model as a way of comprehending what lies behind where it is wrong.


Then Jan Derk wrote...

****************************************

<< My university was a strong believer in the UML approach. So, we were forced to have our UML flow charts approved before we were allowed to show our final code. Most students quickly learned that this was a real time waster. So this is what 95% of all students did: Program the application and afterwards create the flow-charts, which, like a miracle, always turned out to be correct. >>

As the saying goes: been there, done that.

But I would like to suggest another perspective. Consider a project at a university today. Let's imagine that you have ONE project over the duration of a course. A typical course is, say, 4 credit hours. At my school, that meant 4 hours per week spent in class. Now with vacations and what not, the length of a typical course might be 13 weeks; but at least two of those weeks are exams, and the first week is a wash. I think that 10 weeks is a fair measure of effective duration for a course. Now assume this is a HARD course, with the homework taking 5 hours for every hour spent in class (if every course was like this, it would bury the students); but at least some of those hours have to be spent on studying the material itself. Say that you actually spend 3 hours on the project for every hour spent in class. That means that, if 4 people work on the project, then the size of the project is approximately 480 person-hours. I think 500 person-hours is pretty close to maximum for a typical university course project; and if you do multiple projects over the course, than any one project is smaller. If you do only four projects, then 125 person-hours is a reasonable upper limit.

Well, if all of our projects were 125 person-hours in length -- or even 500 -- we might never see a benefit from UML or any formal design process. The learning curve is so steep, it's far easier to just code-and-fix (then retrofit a design if one is required). The first project where I BEGAN to appreciate the benefit in UML involved 5 developers over probably 20 months. Given the long hours we worked, that's about 20,000 person-hours, or probably two orders of magnitude larger than a typical university project. Then after that, I began to apply UML more thoroughly across the board, and the benefits started to manifest more clearly.

Now, with hindsight and practice and acquired expertise, UML is NOT a hindrance for me, but a help. I WILL apply it even on a 125 person-hour project, because it often helps me to discover that that project is REALLY a 500 person-hour project (or worse) before I have invested more than 10-20 hours. While not a welcome discovery, that's a discovery I would rather make early than late. But if I had STARTED by applying it to projects of this size, I would never have understood what UML was doing for me.

It's HARD to teach the application AND appreciation of good design skills in a university setting, because the artificial structure of the academic calendar selects for small-scale projects where heroic efforts can solve most problems. These skills are a little easier to teach at the graduate level, where students tackle larger projects; but it's still difficult. I once heard of an architecture school (physical, not software) where students spend their freshman year designing and building a domicile of some sort. Then they spend the rest of their four years actually living in it AND upgrading it. This teaches them a real appreciation of the impact of their design decisions, when they have to live with the consequences of their earlier decisions. I don't know if the story is true or not, but it gets a lot closer to the "ideal" of a large-scale project.


Then Katie Lucas wrote...

****************************************

<< If the diagram gets too scruffy, copy it out onto a fresh sheet and file the old one. >>

Excellent advice, no matter what your tool.


****************************************

<< Flipchart refills are easy to carry around the building to whichever meeting room is free. Photocopy the thing if you need copies... far too much of software engineering is about making neat things, not useful things. Specifications that are full of words but not actual information, UML diagrams that are too complicated to decode without a dictionary but look neat when printed out... >>

More excellent advice. Too many people confuse "comprehensive" with "comprehensible".


****************************************

<< Paper and pen has a REALLY low learning curve. >>

Yep. Which is why I teach it FIRST, when I'm teaching my students to communicate with UML. After that, if they like, I can teach either ROSE or Visio or more in-depth paper and pen, depending on their needs. But when trying to learn the benefits of UML, learning a tool only gets in the way.

But paper and pen do not scale well.


Then Mike Gunderloy wrote...

****************************************

<< I'm just starting to look at Rational XDE, which promises round-trip modeling in Visual Studio .NET. If it works I may finally switch from pencil & paper to a UML tool, at least for some projects. >>

I've seen a demo, and been impressed. I hope to see it running on my machine next week. If you're interested, write me, and I'll let you know how it goes.


Then Doug Withau wrote...

****************************************

<< What is the best tool for designing with UML? Is it worth more than the copy of Visio I already have? >>

Depends. Visio for free (already paid for, to be precise) may be better than an expensive tool that you can never get management to purchase.

But I have tried HARD to get Visio to do what I want -- I have to, because some students want me to teach it -- and it just fails to live up to the high standard that ROSE sets. It's a far better drawing tool, but a much lesser modeling tool. And modeling is the key, not just drawing. You should never be drawing pretty pictures; you should be editing a model, using the pretty pictures as your user interface to the underlying model. Visio does this much better than it used to, but it still doesn't come close to what ROSE will do.


Then Ori Berger wrapped up with...

****************************************

<< "Reading the code" doesn't scale -- granted. But neither does any other programming methodology, or for that matter, any other design methodology. For example, if you insist that diagrams be modified and code generated from them, you'll most probably find that when 40 people are working on the project it becomes infeasible -- unless, of course, the project is well modularized so that only 3-4 people modify any specific part of the project, in which case "reading the code" still scales. No, I haven't tried that with UML or Rose, but I have tried to keep documentation up to date, and it seems that more than 3 people on a specific module guarantees code and non-code will go out of sync. >>

See above for my thoughts on this problem. And ROSE (like other tools, I am sure) supports that partitioning, so that you may simultaneously have a macro model and micro models. Yes, reading the code scales in the sense you describe; but reading a good design scales better, and is faster and easier.


****************************************

<< I think the important issue is that class spaghetti, the all-too-common modern day equivalent of code spaghetti that structured programming was able to efficiently reduce, does not scale. If there's no spaghetti, you can just read the code; If there is spaghetti, well - you can reduce the pain with modelling tools, but they won't help you solve the problem. >>

Nothing will. And I think reducing the pain is a VERY good thing.


I'd like to finish with a little philosophy. Why do we get trapped in code-and-fix? Are we just stupid? Nope. In essence, some of the same forces that motivate staged delivery and evolutionary delivery and even extreme programming motivate code-and-fix behavior. The key is this: problem definition is such an inexact art, we can often only define by negative definition -- build something, and see what doesn't work or what the users don't like. Staged delivery emphasizes the negative definition by promoting early delivery of functionality, in an effort to reduce a major development risk: building the wrong functionality. Evolutionary delivery emphasizes the negative definition by having no overall plan, but simply discovering new requirements after each delivery, based on users' description of both missing and incorrect functionality. Extreme programming isn't quite so centered on negative definition in the "what the users don't like" sense; but it has negative definition in the "what doesn't work" sense written all over it. And it does have a similar feel to other iterative approaches, in that it emphasizes building small, comprehensible chunks and verifying that they meet requirements.

So if these are all respected, proven methodologies, why do we eschew code-and-fix? After all, code-and-fix can be summed up as, "What's it doing? Nothing. Write some code. Now what's it doing? The wrong thing. All right, fix some code. OK, now what's it doing? Not enough. OK, write more code..." Seems like a similar technique, but it gets us in trouble time after time.

What's wrong, in large part, is the time it takes on the "code" side of code-and-fix. The impulse is right, but the implementation can be wrong, because it takes too long. And that's why I tell people: "Code-and-fix: BAD! Design-and-fix: good..." In many cases -- not all, but many -- you can do some design work, review it with team members and customers, find the biggest problems, and correct them, all in significantly less time than it would take to write the code... the WRONG code, which you must then correct again and again. The emphasis shouldn't be on perfect diagrams -- you'll never get them -- but on useful diagrams that help you to discuss problems. Those useful diagrams take very little time to get a great benefit.

Martin L. Shoemaker
Tuesday, March 05, 2002

After experimenting with UML using Visio and other Visio diagraming tools, I finally turned to Mindmaping. The tool MindManager ( http://www.mindjet.com ) is really good in creating and exporting Mindmaps. I use it to evaluation design options, alternate solutions, document design and even prepare the final spec doc and a project plan.

Extremely useful tool.

Check out the site

http://www.mind-map.com
http://www.mindjet.com

Nitin Bhide
Tuesday, March 05, 2002

Today, as I fumbled through making an E-R diagram in Visio, I thought to myself that this is a perfect example of what software should not do.  Specifically, anytime that it takes 10x longer to create something using software than it does with a pencil and paper, the software has missed the point.

So, here's what I need from any budding entrepreneurs out there: a simple electronic stylus and notepad.

The notepad would be rigid like a clipboard, have a fixed grid, and be wireless.  Most of all, it would not be tiny like a PDA because tiny just plain sucks.  The tipped end of the stylus would be the pen, and the other end would be the eraser. 

As I drew lines on the notebook, the application would snap the lines to the nearest grid points.  As I added text in the drawing objects or scribbled notes, the handwriting recognition feature would convert this to crisp, clean text.  When I add arrows from one object to another, it would allow me to have them snap to any grid point, not just a midpoint of a line.

Lastly, I could buy add-ins that would allow me to create code from the drawing.  If I wanted to create Sequel Server DDL scripts from my E-R diagrams, I could buy the Sequel Server module.  If I wanted to create Java classes from the UML diagrams, I could buy the Java module.  Etc., etc.

I think more developers would be proponents of design software if it allowed them to create the diagrams as fast as they could with a pencil and paper.

I like to use MS Project and Visio as examples of poor UI design.  I use them primarily because they are the tools of choice at my company for communication project timelines and creating diagrams, respectively.

Project is bad because it does behave like you'd expect.  In a basic Gantt chart, the grid along the left looks similar to an Excel grid, but it does behave like one.  If you decide to change a task description, you must double-click the entry, hit F2, or right click and select task properties to edit the description in the dialog box.  I don't know how many times that I've decided to change a task description or some other task detail, selected the "cell" and hit the delete button before retyping the information into the cell.  The problem is, it doesn't have cell behavior, it has group behavior, so the whole task is deleted.  Consequently, when a project doesn't require MS Project, I use Excel.  I put the tasks on the left, the time line across the top, and fill in the grid with gray shading.  Why?.  Because it's faster, and that's what productivity software is supposed to do - make me more efficient.

Visio is an example of the other major UI design problem I see: flip-flopping input devices.  Half the Visio tasks are done with a mouse and half are done with the keyboard.  In a perfect world, I would be comfortable working back and forth with both.  But, personally, I find that switching back and forth between type-click-type-click slows me down not just physically, but mentally as well.  I end up giving equal or greater attention to navigating the UI than I do to the task at hand.

So my point is that software that is designed to organize and simplify our jobs needs to consider input devices as critical extensions of the UI.

P.S.  Regarding the earlier post about printing Access relationship diagrams, there is also a Print Relationships Wizard for Access 97 that is downloadable from Microsoft.

Nick Hebb
Tuesday, March 05, 2002

Interesting diagrams, those Mindmaps. From what I can see of the examples, I can't see anything I can do with them that I can't do with UML. But I certainly can see how they could be used to solve some kinds of problems.

But the Mindmap Web site needs better research, since it starts its whole pitch with a false premise: that we only use 1% of our brains, and this tool can unleash the other 99%. This is a new twist on the old claim (often, OFTEN repeated) that we only use 10% of our brains. Both claims are wrong, no matter how many people make them. See  http://www.snopes2.com/science/stats/10percnt.htm  for a cursory dissection of this urban legend, including a reference to a more detailed refutation.

(That has NOTHING to do with the usefulness of these diagrams; but that urban legend always bugs me...)

Martin L. Shoemaker
Tuesday, March 05, 2002

<< Today, as I fumbled through making an E-R diagram in Visio, I thought to myself that this is a perfect example of what software should not do. Specifically, anytime that it takes 10x longer to create something using software than it does with a pencil and paper, the software has missed the point. >>

An easy enough metric to apply. I like it. Would you care to discuss another metric that covers learning curves? I'm not sure what the parameters or form of such a metric would be; but I clearly believe that if a tool takes long at the start but gets easier over time, there is some break-even point where the tool is worth the trouble.


<< So, here's what I need from any budding entrepreneurs out there: a simple electronic stylus and notepad.

The notepad would be rigid like a clipboard, have a fixed grid, and be wireless. Most of all, it would not be tiny like a PDA because tiny just plain sucks. The tipped end of the stylus would be the pen, and the other end would be the eraser.

As I drew lines on the notebook, the application would snap the lines to the nearest grid points. As I added text in the drawing objects or scribbled notes, the handwriting recognition feature would convert this to crisp, clean text. When I add arrows from one object to another, it would allow me to have them snap to any grid point, not just a midpoint of a line. >>

Cross had the CrossPad, which had a few of the features you want: rigid back like a clipboard, large size, fair text recognition (not great then, but it was the IBM stuff that has since gotten a lot better). It never lasted long enough for it to develop a market for third-party add ons. (When I first drooled over it, they wanted $350-$500. When I bought one, it was $80 on clearance.) The idea was an actual clipboard with an actual pad of paper; but the pen had a radio transmitter, and the clipboard was a receiver. It recorded your strokes, then could upload to your PC for processing. It had some geek-cool to it, but never caught on. It was never quite as interactive/intelligent as what you want. Cross has abandoned the line, but I think some other company is working on the same core technology.

Maybe, when the TabletPC debuts (this year, maybe?), someone will do an app like you describe.


<< I think more developers would be proponents of design software if it allowed them to create the diagrams as fast as they could with a pencil and paper. >>

I can draw faster with pencil and paper. I can redraw and rearrange a LOT faster with a good tool. And it's almost impossible to maintain a large model behind the diagrams without a decent tool.


<< I like to use MS Project and Visio as examples of poor UI design. I use them primarily because they are the tools of choice at my company for communication project timelines and creating diagrams, respectively. >>

Examples snipped. Good examples, in line with stuff from Joel's book.

Martin L. Shoemaker
Tuesday, March 05, 2002

Regardless of the modelling tool its important to realise that its not just documentation, its not just communication, its fundamentally modelling.

With modelling you aren't describing a system (the inherent flaw in flowcharting), you are squidging and manipulating analogs to the real world problem.  My one hangup with UML is the use of the stickman, it anthropomorphises to the point where it distorts the modelling process.  That aside I'm happy to model and play until I have something that can define interfaces.

From that point on the model becomes a reference to code to and measure by.  I don't expect classes to be generated by the model, though its nice when that can happen.

As a lot of what I do is data centric I actually use ORM (Object Role Modelling), more than UML.  With ORM I can model with the domain experts before ever getting to ER diagrams.  From my experience modelling with ER is like modelling with code, entirely the wrong level.

Its one of my dreams to have a tool that can use ORM and generate Use Cases.

Simon Lucy
Tuesday, March 05, 2002

> UML is NOT a hindrance for me, but a help. I WILL apply it even on a 125 person-hour project, because it often helps me to discover that that project is REALLY a 500 person-hour project (or worse) before I have invested more than 10-20 hours.

How do you do size/effort estimates, and how does UML help, and so quickly? An estimate that's accurate to a factor of only 4, within 20 hours or the first 10%..20% of a project, seems good to me.

Christopher Wells
Tuesday, March 05, 2002

Modelling and coding are converging at least a little bit at the high end. Rational XDE offers continuous 2-way synchronization of UML and C# code. Unfortunately I'm finding it to be a bit fragile in initial testing. But it's a promising idea, I think.

For me, the ideal would be to have UML and ORM and use cases and code (or whatever) all synchronized...make a change in one, have it echoed flawlessly to the other levels of abstraction. Seems like a pipe dream until you realize that's essentially what we get with high-level languages already. We don't worry that our C++ and our assembler and our machine code will somehow get out of sync.

Mike Gunderloy
Tuesday, March 05, 2002

http://www.anoto.com/
http://www.business2.com/articles/web/0,1653,38392,FF.html?ref=cnet

Looks pretty impressive. Doodle a diagram, it gets plopped into a computer, and you can e-mail by writing an email address in the right field and checking "e-mail this page" e-mails the page. It doesn't do anything beyond that, but it seems cool. It looks similar to a white-board tool we had. You suction cupped a 3 foot long thing to the white board, and put wrappers on all your markers. You had to press a little extra hard with the market to trigger the tracking function, but it did update to the computer. The only problem with it was the limited size it would recognize. We had wall sized white boards and it only recognizes something like 3 feet by 4 feet. I'm not sure if and how it handled erasures.

Mark W
Tuesday, March 05, 2002

A sidenote here.

I agree on some comments above that most modeling tools miss their point as drawing the diagrams take too much time.

Therefore I would like to recommend a really great tool that I had the opportunity to use a couple of months ago, called Mimio. It is a whiteboard accessory that you attach to any whiteboard, allowing you to transfer your handwritten diagrams to a computer. It works by having a base station attached to the borders of the whiteboard, and special drawing pens which then are used by the base station to read coordinates and colors.  It even has a eraser component that allows in-progress editing of a diagram while you are drawing it.
Please go to the link below for more info:
http://www.mimio.com

The drawbacks are of course that the Mimio diagrams are not machine-understandable at all, they do not compile, they do not generate code, and once saved, you can not edit them without redrawing them again on the whiteboard.
But I really don't care. I love this product, it is easy to use, and ideal for quick UI design, brainstorming and drawing simple diagrams of any kind. Have I already mentioned that I love this product? :-)

Gabriel Lima
Tuesday, March 05, 2002

BTW, I suspect that Mark W was actually talking about Mimio in the comment previous to mine (see two comments/topic replies back).
I should have noticed it earlier, but I got carried away.

Gabriel Lima
Tuesday, March 05, 2002

Mimio. Yep. Forgot the name. Thanks.

It turned out to be a high priced toy for us though, we didn't use it enough to really justify having it.

Also, I like Inspiration, a sort of Visio lite. The nice/different thing about Inspiration is that you can put the mouse somewhere and if you start typing a box appears. There's also a rapid-fire idea that let's you start a box, and hitting enter adds a new box to type in. This way you add the ideas as fast as you can type, and they're already connected to the node you started from. They also have a number of nice box shapes to choose from. I'm not sure how good it is for UML, but it's great for brainstorming and showing how box A is related to box C, G, and M.

http://www.inspiration.com/

Mark W
Tuesday, March 05, 2002

You can't use UML because UML has no substance, no concrete definition, its basically an illusion.  The UML 'gurus' would have you believe it is a rock solid way of doing everything, but then you ask them for a simple definition of aggregation and they get all confused.  Don't even bother talking about object models...

MrReality
Tuesday, March 05, 2002

On tools able to support my thinking, here is the current list of mine:

- MindManager (MindMaps)
- Axon2002 (better than MindManager for multidimensional data sets)
- Visio Modeler (ORM)
- Enterprise Architect (UML+UIs+Requirements+Reverse/Fwd code engineering)
- Plain old word/excel/access/powerpoint
- A decent vector drawing program able to produce windows metafiles

Rose is installed but not used anymore (except for teaching it... which will allow you to see the limitations).

*AND*

use of the meatmachine (without which the tools above are meaningless).

The trick is to get as many perspectives as possible on a given subject and be able to tolerate ambiguity.

Have multiple tools in your toolkit so you do not end up as a victim of the golden hammer syndrome (...everything looks like a nail.)

Philippe Back
Tuesday, March 05, 2002

I also use Action Outline & Treepad as outliners. Action Outline is shareware, Treepad has a plaintext free version and a rich text/encrypted/etc. shareware version.

I use outliners to organize my thoughts from time to time, or to keep structured information. Action Outline has some really great export features (like auto numbering of the outline, auto commenting of the node headlines /* node headline */ in any format you choose, though I tried putting C++ code into it and it refused to save. Ah well. I wrote their tech support but I don't think they did anything to fix it.

Other people have other opinions on outliners. This site has a really good section on outliners and brainstormers:

http://john.redmood.com/

Mark W
Tuesday, March 05, 2002

It looks like the thread is converging towards "Modelling good, Visual modelling potentially good but current tools severely lacking". Does that sound right?

Assuming that this is the case, are there any alternatives you're aware of? e.g., a modelling language that is simple, conveys enough meaning (interaction diagrams, state diagrams, etc.) but is, perhaps, not visual - or at least, can be edited non-visually?

I'd love to have a formal, well defined way of describing test cases textually, because eventually that's what I always find myself doing - a picture may be worth a thousand words in general, but not when semantics are involved, and semantics are very important.

Oh, and I think this is the right place to mention - Having been burnt by Word and other WYSIWYGs multiple times, I've stayed off any of them for quite long; I'm using SDF for text and DOT for graphs, and only convert the final output to the required format (usually Word .doc). People seem to like the produced output - it's usually more consistent and looks more professional than trying to write the same thing inside Word. Perhaps I need to find the SDF/DOT of modelling?

Ori Berger
Tuesday, March 05, 2002

Christopher Wells wrote...

<<<How do you do size/effort estimates, and how does UML help, and so quickly? An estimate that's accurate to a factor of only 4, within 20 hours or the first 10%..20% of a project, seems good to me.  >>

Realize, of course, that the size of the projects makes the estimates a little easier. Let's take an example from my consulting last year.

A customer wanted me to wrap a particular API as an ActiveX control that could then be hosted in a Web page, and also to add some printing functionality. Their developers provided a written spec for the existing API and for the desired new functionality, as well as some simple scenarios of use. Their developers had this pegged as 60-80 hours of work.

What I did was: I took the statements of use and the specs and converted them into Use Case Diagrams. Then for each Use Case, I created a first draft of an interaction diagram that showed the basic logic that lay between the new ActiveX interface and the old API. These diagrams weren't perfect, just a good first pass effort. And from these, I derived some basic Class Diagrams -- again, first pass only. Counting time reading the spec, time drawing diagrams, time formulating questions, time asking and answering questions, and time tracking and reporting my time, this stage probably took about 12 hours. Now that seems long for a 60 hour project; but it wasn't a 60 hour project...

Next I took the elements in the UML model and interpreted them as inputs to a function point spreadsheet I created, based on some research gathered by McConnell and others. The design wasn't complete, so I had to include some uncertainty; but it was again a good start.

The answer came out 260-320 hours; and since they wanted a fixed-bid contract, I bid at 320. Now the client didn't like these numbers at all; but that's not the point. _I_ trusted these numbers not to be perfect, but to get an idea where the client's estimate was way off base. When they screamed, I went over the design with them and showed how the elements I had identified were necessary. I also showed them the estimate allocated to the tasks, and asked how many of these task estimates were unreasoanable. At the level of such small tasks, no one dared argue that the tasks might be still smaller; and no one could argue with the list of tasks. Thus, though they didn't like it, they couldn't knock the estimate. What they COULD do was negotiate fewer features and get closer to their desired schedule. It worked, and my final time was withing about 40% of my revised estimate. I would like to  do better; but I know I've done a lot worse.

Note the most important factor here: THEY didn't need to like my estimate, as long as I felt it was a valid worst case scenario. As an indepent consultant, I had the freedom to walk away. Thus, I also had the freedom to stick to my estimate under pressure; and that forced them to study it and take it seriously.

Martin L. Shoemaker
Wednesday, March 06, 2002

I agree completetly. This kind of method already saved my butt a copule of times !

When the battle heatens, it's good to have some kind of territory map to get your point made. That's what models are for: communicating and scaffholding the software being built.

I happen to like the way A. Cockburn puts it:

"Software development is a cooperative game, in which people use markers and props to inform, remind and inspire themselves and each other in getting to the next move in the game. The endpoint of the game is an operating software system; the residue of the game is a set of markers to inform and assist the players of the next game. The next game is the alteration or replacement of the system, or creation of a neighboring system."

(see http://members.aol.com/acockburn/manifesto.html for more).

So, be the markers UML, whiteboards, napkins or whatevers, the goal is set and I will use whatever notation or tool helps me get there. If it does not, I'll drop it for *this* time (who knows, it may be useful for another project!).

By the way, I forgot to mention this tool: WhiteBoard Photo from pixid. http://www.pixid.com. Very useful !

As a final comment: boxes and arrows work fine in some settings. In others, either put a lot of text in/aside them or move to a richer notation (why not UML), allowing you to spend less saliva explaining the boxes and the arrows so you can concentrate on moving forward and not running in place.

Philippe Back
Wednesday, March 06, 2002

And on the document writing front, DocBook is cool for technical documentation. And it happens to like CVS and file "includes" and DSSL for overall formatting.

*but*

When it comes to documents meant to be reviewed and changed by customers, it's another story. Don't expect them to be able to do that. And think about revision marks in DocBook (yuk!)
The most frustrating aspect I see in Word is its tendency to change styles and import them from copy/paste operations. This is really annoying. To the point that most of the import I do are text-based (Paste as text), even for tables, they get converted to text with separators before import and then moved back to an appropriate format.

I ended up with a pretty well formatted document I am reusing again and again. So, Word is useful, especially the Document Map mode for navigating large pieces.

Philippe Back
Wednesday, March 06, 2002

IANAD (I Am Not a Developer) but I am trying to remember my limited Java.

A possible halfway house that you might find useful: generate diagrams from (possibly partly implemented) code. BlueJ does this: http://www.bluej.org

It lets you take a load of classes, and visualise them as UML-type diagrams with a simple indication of inheritance and which class uses which. You can also edit the code directly.

It's designed for education and it's probably a bit simplistic. As I understand it, something like Visio can't take code and generate a UML diagram which updates while you work (or am I wrong?). Are there any more professional tools or IDEs which let you do this?

BH
Wednesday, March 06, 2002

<< It's designed for education and it's probably a bit simplistic. As I understand it, something like Visio can't take code and generate a UML diagram which updates while you work (or am I wrong?). Are there any more professional tools or IDEs which let you do this? >>

Together's tools do this, or at least its Java version does. Rational claims that their new XDE product does something like this; but I _just_ got XDE running and have a backlog of work to do with it, so I haven't checked into this yet. If Visio does this, it's news to me.

While this seems like a neat feature, I know all sorts of cases where it will be worse than no drawings at all, unless you can go in and tweak the diagrams to show only the details you need for a particular discussion. Never forget: in many cases, comprehensive != comprehensible. Too much detail can sometimes obscure a point.

Martin L. Shoemaker
Tuesday, March 12, 2002

Visio Enterprise Architect (the version included in the high-end Visual Studio .NET package) can do forward and reverse engineering of ORM models to databases, and UML models to applications in VB, C#, or C++, but doesn't automatically synchronize.

Rational XDE does do continuous synchronization and allows you to create multiple diagrams in a single solution, so you can hide information as you like. But the .NET version only supports C# at the moment, and it is a memory hog; they say 512 MB required and they mean it (I tried it on a 256 MB box, and various portions definitely do not work in that environment).

Mike Gunderloy
Tuesday, March 12, 2002

So can the UMLers of the world point to some examples of successful and well known software where UML has been applied successfully ?

Is it used at Microsoft ? What products ?
Is it used at Oracle ?
Is it used in GNU ?
Is it used any Linux development/FreeBSD ?
SUN ? BEA ? Lotus ? Adobe ? Fogcreek ?

Are are these companies going to be overcome once some UML powered skunkworks comes out with a Solution to world hunger and captures Osama Bin Laden ?

Regs

Paul

Paul Reidy
Wednesday, March 13, 2002

<< So can the UMLers of the world point to some examples of successful and well known software where UML has been applied successfully ?

Is it used at Microsoft ? What products ? >>

I can speak to this one. The answer is: Maybe. Depends what you mean by Microsoft. For various reasons, groups within Microsoft are at liberty to use whatever development methodologies and tools they choose. They're judged not on conformance to some corporate standard, but simply on producing results. So some groups use UML a little, some use it a lot, and some won't touch it.

I have taught UML a number of times to the Great Plains group at Microsoft. I actually haven't seen them at work; but since they keep asking me back, I can only assume they're using UML in their development efforts.


<< Are are these companies going to be overcome once some UML powered skunkworks comes out with a Solution to world hunger and captures Osama Bin Laden ? >>

Nope. Good design is important, but it's not enough by itself to displace long-established market leaders. UML adoption is a slow process, and the payoff only happens over time.

Martin L. Shoemaker
Monday, March 18, 2002

*  Recent Topics

*  Fog Creek Home