Fog Creek Software
Discussion Board




UML where to start?

I keep feeling I should be using UML with something like rational rose to keep it all in synch. However I've never been taught it and neither have the other developers (it's a large database app) and we're starting the move to .NET.
So I have some questions:
a) Best book to start with?
b) Tools - Should I perhaps start with the VISIO stuff that comes with VS.NET (while reading a UML for dummies type book) and move over to rational once I've sorted out some simplistic models?
c) Is it even worthwhile?
d) What are the pitfalls e.g. does it force relationships into the database which then can't be broken? How painful is changing schemas? Version control of the schemas might turn into an issue.
e) Should I give up and go on a course or get someone in to do a week long training session.

Having browsed the Rational site, it all looks like a good idea but I feel I should do some paper based reading first then pick a tool.

Peter Ibbotson
Monday, May 13, 2002

Oh BTW this is part of a move from a traditional thick client-server app to a three tier model, so we're throwing most of the existing code base away although keeping most of the schemas and code functionality. This means my starting point is trying to model much of the existing database.

Peter Ibbotson
Monday, May 13, 2002

<< I keep feeling I should be using UML with something like rational rose to keep it all in synch. >>

UML is great. ROSE is good, as are other tools, but UML has to come first. I will NEVER tell you NOT to use a tool; but if tool issues (costs, complexity) get in the way, learn UML first, THEN learn the tool.


<< a) Best book to start with? >>

Two answers:

* Fowler and Scott, "UML Distilled".

* Schneider and Winters, "Applying Use Cases".

Fowler recommends Schneider, Schneider recommends Fowler, I recommend them both. Probably start with Fowler, but you can't go wrong either way.

After those, look for Ambler's "Elements of UML Style". It's not released yet; but I've read a review copy, so it has to be coming soon. This is a must-have book to help you communicate with your diagrams, which is the point of UML.

To think about how much modeling you need, I recommend Ambler's "Agile Modeling". I'm about half-way through with it. I don't agree with everything he says in there; but I agree with a lot of it, and I think he makes a good case for pragmatic modeling over formal modeling.

Given your particular needs, I might suggest "UML for Database Design" by Naiburg and Maksimchuk. I can't actually recommend this one, because I haven't read it yet (it's number two or three on my reading stack); but Ambler mentions it favorably in "Agile Modeling". I skimmed it in the book store, and it looked good enough to be worth a read.


<< b) Tools - Should I perhaps start with the VISIO stuff that comes with VS.NET (while reading a UML for dummies type book) and move over to rational once I've sorted out some simplistic models? >>

Start with paper, pencil, and Post-It notes... AND one or more coworkers to help you argue about a problem, using the diagrams as a way to communicate your arguments. I have tried teaching UML and a tool simultaneously, and it's just too much. Now I teach UML by hand first, and THEN teach ROSE or XDE or Visio.

Visio has some problems, by the way, if you're going to do code generation. (Many people won't, but I think there's a great case to be made for code generation.) It's not quite a full-featured modeling tool, but it ain't bad, especially if you've paid for it already.

If you're in the .NET environment, my tool of choice right now is Rational XDE.


<< c) Is it even worthwhile? >>

First, full disclosure time: I teach UML a couple of weeks (or more) per month. I speak on UML at conferences. I'm writing a book on UML and .NET. So when someone tells you UML is all about selling consulting and books, they're talking about people like me. Decide for yourself how much faith to put in my words.

Given that... Heck, yeah! I can't imagine writing code any other way, now. I sit down (either alone or with a team) and model requirements. Then I turn those into an architecture. Then I turn that into components. Then I turn those into code. But at every step of the way, I build a model before I build the real thing. And I make all sorts of mistakes in the model; but it's cheap and easy to change. I can throw the whole thing out and start over again, if need be, and it's STILL cheaper than getting the code wrong and having to throw THAT out. If we were talking about any other field of engineering, no one would even ask the question: modeling is just an accepted design technique, period. Use it where it helps, skip it where it doesn't.

Will modeling be that effective for you? Not right away. I tell my students to expect UML to be a net productivity LOSS the first six months. Modeling is a new skill set, and new skill sets take time to master. If you have a crisis right now and have to solve it tomorrow, use they tools you know now. But if you have ongoing problems you want to solve for the long term, then modeling is a useful skill set to add to your toolbox.


<< d) What are the pitfalls e.g. does it force relationships into the database which then can't be broken? >>

That depends a lot on the process you apply. For instance, if you just use UML to get your thoughts right, then never generate code or a schema from it, then nothing is forced on you.

I use schema generation. I am an OO developer, NOT a DB guru; and I have learned to trust ROSE to translate my object model to a schema. Then I take my schema to the local DB guru and ask him or her to explain it to me. For the most part, they tell me that it's roughly what they would do, only they might name things differently (though I can fix that with ROSE). That makes it better than I could do myself.


<< How painful is changing schemas? Version control of the schemas might turn into an issue. >>

Depending on the tool, you can reverse engineer new or existing schemas directly into your model.


<< Having browsed the Rational site, it all looks like a good idea but I feel I should do some paper based reading first then pick a tool. >>

AND some paper based practice, if you ask me.


<< Oh BTW this is part of a move from a traditional thick client-server app to a three tier model, so we're throwing most of the existing code base away although keeping most of the schemas and code functionality. This means my starting point is trying to model much of the existing database. >>

UML works well for databases; but ER has a longer history, and is more entrenched in the DB world. So though I applaud you investigating UML, you might want to compare the benefits of ER.

Now if you want to do more than the database, then UML is definitely the way to go. For instance... You say "we're throwing most of the existing code base away although keeping most of the schemas and code functionality". That sounds like a golden opportunity to "harvest" most of the requirements straight from the existing application, as well as from end user docs. Maybe even from a reverse engineering effort, if the app and docs are difficult to comprehend, or if there are complex algorithms to be captures. Then those harvested requirements (expressed as Use Case and Activity Diagrams) would complement your DB model, providing a place to hook in the functionality you need to implement and to tie it to the DB.

Martin L. Shoemaker
Monday, May 13, 2002

Martin:

My exposure to UML was one poorly taught semester-long class in college.  I came away with the impression that UML was nothing more than a glorified whiteboard; and didn't enable me to do anything more than a decent set of coloured markers could, with the possible exceptions of automatic stub generation and the ability to email my whiteboard to coworkers.  I am mystified asto why it would take me a row of books in order to learn how to draw diagrams on a whiteboard.

As a form of documentation, UML seems decent, but like all documentation separated from the code, it's only a matter of time before the two become out of sync.

Since you are clearly more experienced in UML than I am, can you tell me what it is about UML that I am ignorant about that makes it so great -- because I still don't get it.

Alyosha`
Monday, May 13, 2002

Alyosha:

Thanks for the great questions. I'll answer as best I can. And because of posting problems, I'll answer in pieces...

<< My exposure to UML was one poorly taught semester-long class in college. >>

Don't even get me started on learning design in college...

Well, too late, you got me started. But I'll keep this rant as brief as I can, because you couldn't know you were hitting a hot-button issue for me. And this is NOT a criticism of you nor of your question; it's just what happens when the hot button is pressed.

You had a one-semester class. That might have been, what, fourteen weeks? Let's call it sixteen for trimesters. Now a week gets lost on finals, a week on mid-terms, and a week ramping up the class at the start. So that's thirteen weeks. Let's assume this is a tough class, with six hours per week in class. Let's further assume this is a REALLY tough class, with, say, three hours of homework for every hour of class. That's 24 hours per week on this one class. (I NEVER had a class that tough. Hope I never do!) But of those 24, six are classroom lecture and discussion; and I figure at least that many have to be reading and study. That leaves 12 hours per week for project work. That's about 156 hours for all projects over the class. Even if that's devoted to various aspects of ONE project, that project is 156 hours. That's a small enough project that code-and-fix can be very effective, ESPECIALLY when compared to a new tool, new notation, and new process that you're trying to master. (Realistically, I'll bet that total project time is closer to 50 hours.) So it's very hard to make students appreciate the benefits of UML in a class like that. They can go through the motions to get the grade; but they are justifiably convinced that they could have gotten the same results with a lot less effort if they'd skipped UML and went straight to code. I tell my students they might need six months to gain productivity with UML. As a rough measure, that means about 1,000 hours of work. No college class comes close to that.

This is no slam on you, nor on the class (even if it was poorly taught, as you say). It's just hard reality: it is very hard for a college class to teach you to appreciate process and tools and standards. The scope of such a class is usually so small that they cannot demonstrate the benefits of UML, only lecture you on them. Well, you learn it better when you experience it than when you're lectured.

Martin L. Shoemaker
Monday, May 13, 2002

(continued...)

<< I came away with the impression that UML was nothing more than a glorified whiteboard; and didn't enable me to do anything more than a decent set of coloured markers could, with the possible exceptions of automatic stub generation and the ability to email my whiteboard to coworkers. >>

Well, here's where we again have to distinguish between UML the notation and the wide range of (often expensive) UML tools.

UML the notation can be practiced very successfully with your whiteboard and markers. See Ambler's "Agile Modeling" for a lot of discussion on this. A whiteboard and a copy of "UML Distilled" may be all the UML tool AND all the UML training you need. The fact is, I have a vested interest in convincing you that you need UML training -- from me, of course -- but there are enough people wanting UML training that I don't need to rope you in to keep myself busy for the foreseeable future. So I can be straightforward when I say that you could learn UML all on your own. After all, I did; and if I can do it, anybody can. (My living comes from people who want to learn far more quickly than they could on their own and who want some guidance around common pitfalls.)

But that copy of "UML Distilled" is important, because it will show you a common language which will cover many diagrams you need to draw. Imagine if you sat in a requirements meeting, and the participants were speaking different languages: Russian, Urdu, English, Sankskrit (is that a language, or just an alphabet?), and Pig Latin. Even if everyone understood every language, the meeting would be a madhouse if you didn't settle on a common language. AND the choice of language matters: if you're discussing quantum mechanics, Sanskrit would be a lousy choice, because it was never designed to handle many of the quantum mechanical concepts. Russian or English would be a much better choice. The common language matters a lot, and needs to be both common and rich in the problem domain. Well, UML is a pretty common standard; and it's rich in the domain of modeling.

And remember: modeling is the important skill here; UML is just a notation for expressing the models. A model lets us explore alternatives early, in a light-weight fashion, before we commit to code. Modeling is a lot easier with a good modeling tool (though Ambler raises some counter-arguments in "Agile Modeling").

But UML tools are a whole different ball game. There you have to figure out which features you need and what you can afford. I have my favorite, for reasons I'm happy to explain when people ask. But the merits of the tools are a separate issue from the merits of the notation.

And we have a third factor to separate out: your development process. UML is no process, only a notation. This is where I think many tools fall short: they let people draw pictures and create models, but don't help them to know which pictures to draw or which models to create. That's really not a UML issue. Your process should dictate what needs to be drawn in which models.

Martin L. Shoemaker
Monday, May 13, 2002

(continued...)

<< I am mystified asto why it would take me a row of books in order to learn how to draw diagrams on a whiteboard. >>

One book gets you started: again, "UML Distilled". That's a tiny little book that will teach you how to communicate better using that whiteboard.

The other books may discuss particular modeling issues (databases, Web apps, etc.) or strategies (agile modeling, use case modeling, etc.) or processes (unified process, etc.). Others are authoritative guides to the notation (the Three Amigo books). Still others may be trying to get the point across in a different way: as much as I like "UML Distilled", I find some people don't get it, and may benefit from a different explanation.

And no doubt, some books are just out there to sell books. But beyond the surface (how to draw) are a lot of complex issues that deserve more specialized books.

Martin L. Shoemaker
Monday, May 13, 2002

(continued...)

<< As a form of documentation, UML seems decent, but like all documentation separated from the code, it's only a matter of time before the two become out of sync. >>

That's an issue you have to settle when selecting a tool. I rely heavily on code generation, and my code and design are never out of sync by more than maybe a half hour. Others have reasons to hate code generation, so they have to decide how much time to spend manually keeping the design and code in sync.

Then there's the Agile Modeling approach: throw away temporary models. Some XP folks take that farther, throwing away ALL models once they have served their immediate purpose. The theory here is that the code is the sole source of authority, not the model. If that's how you think (I STRONGLY disagree, but your mileage may vary), then a whiteboard is probably the best UML tool for you: model it, solve it, code it, test it, and erase it.

Martin L. Shoemaker
Monday, May 13, 2002

(concluded)

<< Since you are clearly more experienced in UML than I am, can you tell me what it is about UML that I am ignorant about that makes it so great -- because I still don't get it. >>

I don't think you're ignorant; you're pragmatic. You want to solve problems, not chase bandwagons. That's laudable.

But it sounds like you're looking for the forest when there are plenty of useful trees in front of you. UML just isn't as complicated as the plethora of books and tools might lead you to believe. (In my UML classes, the students spend the first day just analyzing requirements and designing a system on paper, with me teaching them absolutely the minimum UML they need to actually solve problems. THEN I can teach them why UML is great, and teach them details of the notation and a particular tool. Once they've actually solved a problem with UML, they're much more eager to learn.)

Here's an experiment, if you have some time, some helpful coworkers, and around $30 for "UML Distilled". Describe to me a current or recent development problem, something that's chewing up some hours. (If no one else wants to see the experiment, maybe we should take it offline.) It shouldn't be a process problem such as clueless managers, corncob developers, or such. It might be something as fundamental as obscure requirements, or as detailed as a really ugly implementation bug. I'll describe a strategy for how I might use UML to help resolve the problem; and I'll even give some reference pages in "UML Distilled" to show you how to draw the relevant UML diagrams. Then you draw the diagrams and try to iron out the issues. When you're done, report back on whether the UML diagrams helped to think about the problem, or even to solve it. I can't guarantee I'll prove the benefit this way, but I find it works most of the time. (Notice also that I did NOT offer to solve the problem for you, for two reasons: I'm too busy; and the goal is for YOU to learn to solve the problem, not for me to solve it for you.)

I hope this helps!

Martin L. Shoemaker
Monday, May 13, 2002

Martin:

Wow.  I appreciate the copious and informative feedback.  Just when I thought this board was going to the trolls ... =-)

I agree completely with your comments regarding learning design in college.  In my personal experience (having recieved a degree in Computer Engineering), I learned ten times as much in a one-year internship than I did the whole four years of college.  Certainly the class would have been much better taught if we weren't forced to use UML to model toy problems; it would have been far better to introduce us to a large project already using UML.

I will take your advice and take a look at UML Distilled.  I think my problem is simply a lack of exposure to any seriously large enough projects that would benefit from models -- the largest problems I've faced at my previous work were entirely process-related.  [The projects there were all 'toy problems' motivated by a sort of get-rich-quick mentality so common in the recent years; I would imagine a significant number of people in my field can relate].  Fortunately now I am blissfully unemployed, so I have far more time for reading Joel!  =-)

Alyosha`
Monday, May 13, 2002

Many thanks for that Martin, sounds to me like get some books at the weekend, read and digest then get stuck in.
As you correctly say since I'm currently planning on keeping most of the schema I'm tempted to go with the Rational XDE system and use that to extract and model the current system, I do however of course have already have full licenses for VS.NET which comes with the bundled Visio bits so I think I may start out there with a small model then flip over to Rational and try out the two way code to diagram synching (also the auto test generation sounds good).

Rational is however expensive (Circa $3.5K per seat) and I'm looking for some details of what it doesn't do well or where folks have had problems. At least they have a test version for download but it's often been 12 months in that it dawns on you what the tools aren't doing for you or do badly. I remember a bad experience with Pharlap 386 extenders were by the end of the project it was only really being used as a loader, the rest of the features could have been ditched.
Of course it's difficult to know at the start what the problems are and it's possibly impossible for you to explain them until I've had more experience.

In particular I'm worried about the two way code stuff and how fragile it is along with the test suite code. Related to this is how to test multiuser concurrency and deadlock issues with a database does rational give any help with this? In particular we'll be swapping our database locking model from being "pessimistic" to "optimistic" i.e. moving from the lock record, update record, unlock record model to a update record, get exception, repeat/deal with exception.
Also does rational deal with stored SQL procedures as part of the two way process?

(BTW I assume ER stands for entity relationships?)

Anyway Martin thankyou very much for your feedback and suggestions, what level is the book aimed at and do you need any reviewers?

Another thread was discussing when to bring in consultants, this is one of those areas where I can see the point in getting in trainers / consultants to help get you started, but the aim is more of a mentoring process rather than a get in, solve the problem, take the money, walk away kinda thing.

Peter Ibbotson
Tuesday, May 14, 2002

<< As you correctly say since I'm currently planning on keeping most of the schema I'm tempted to go with the Rational XDE system and use that to extract and model the current system, I do however of course have already have full licenses for VS.NET which comes with the bundled Visio bits so I think I may start out there with a small model then flip over to Rational and try out the two way code to diagram synching (also the auto test generation sounds good). >>

Visio will do the reverse engineering just fine, IF you're in Visual C++, VB, or C#. I'm not sure how they do in other environments.

In fact, Visio does a BETTER job than XDE in at least two particulars:

* Right now, XDE will ONLY work with C#.

* XDE does not understand C# indexers. Visio does.

I expect both of these to be fixed with XDE 1.1.

Where Visio falls short is in code generation, again in two particulars:

* When Visio reverse engineers your code, it builds a hierarchical model structure. That structure actually makes a nice way to organize your model. BUT when you generate code from that model, by default, the code is generated in a hierarchical directory structure that matches the model, NOT in the directory structure you started with. This can be overridden one class at a time, but it's the default behavior.

* If you DO override the default behavior to force the code to generate back where you started, it overwrites all your changes! I can't speak for XDE for sure, because it's still too new; but with ROSE, once I learned a few simple rules, it NEVER overwrote my code.

It may be that there are workarounds for both of these problems, but I've been too busy to look for them.

So if you want to see the structure of your code using a tool you already have, Visio is a great choice.


<< Rational is however expensive (Circa $3.5K per seat) >>

Yep! I love the tool, but fitting it in the budget is a nightmare. I think XDE is worth every penny. So is a 747, but most of us won't be buying one of those any time soon.


<< Of course it's difficult to know at the start what the problems are and it's possibly impossible for you to explain them until I've had more experience. >>

Worse: there ARE problems, but I have to start using the tool to really remember them. I think the benefits vastly outweigh the problems, so I tend to forget the problems; but that particular cost-benefit equation has to be calculated differently for every individual. Problems I can tolerate may be insurmountable for your projects.


<< In particular I'm worried about the two way code stuff and how fragile it is along with the test suite code. Related to this is how to test multiuser concurrency and deadlock issues with a database does rational give any help with this? In particular we'll be swapping our database locking model from being "pessimistic" to "optimistic" i.e. moving from the lock record, update record, unlock record model to a update record, get exception, repeat/deal with exception. >>

I don't know their testing tools very well. I don't have a license for them. Sorry, but I can't help you on these questions.


<< Also does rational deal with stored SQL procedures as part of the two way process? >>

I don't do enough database stuff to be sure, but I think your stored procedures are ignored both when reverse engineering and when generating code.


<< (BTW I assume ER stands for entity relationships?) >>

Yep. ERDs, or Entity Relationship Diagrams, are the standard way of documenting DBs.


<< Anyway Martin thankyou very much for your feedback and suggestions, what level is the book aimed at and do you need any reviewers? >>

If I EVER finish (I'm way late), the book will introduce UML and a lightwieght process, and then it will show models of the .NET environment and framework. It will finish with a case study of applying UML and the lightweight process to analyze and design a .NET system. I will need reviewers, but I'm not sure how the publisher wants to select them. Drop me a note and I'll keep you informed, if you're interested.


<< Another thread was discussing when to bring in consultants, this is one of those areas where I can see the point in getting in trainers / consultants to help get you started, but the aim is more of a mentoring process rather than a get in, solve the problem, take the money, walk away kinda thing. >>

Agreed. I've had some students take my course, then not do anything with it for almost a year. By that time, they forgot almost everything I taught them. They then brought me in as a consultant, and we worked together for a couple of weeks -- first week, me driving; second week, them driving, me kibbitzing -- and that time, the lessons stuck. Mentoring can jump start a process change, IF the goal is knowledge transfer, not just solving the immediate crisis.

Martin L. Shoemaker
Tuesday, May 14, 2002

Toolset:  Enterprise Architect is a very clean, well-designed tool for UML from Australia, which I've used for the past few months.  It has all the UML models, forward and reverse code engineering in C++/C#/VB.Net/Java, database schema support (configurable to the nth degree), XMI import/export and superb, responsive technical support.  The price is $149.00 US, and there is a 30-day trial edition.

The product is stable, fast and feature rich.  This is one of only two pieces of software I've bought in past three years - CityDesk was the other.  Here's the address:

http://www.sparxsystems.com.au 

Dave Warner
Wednesday, May 15, 2002

Dave,

Thanks! As an instructor, I try to at least know what tools are out there, and to check them out when I have time. This one goes on the tool list for the students.

Martin L. Shoemaker
Wednesday, May 15, 2002

Google is your friend:  http://www.ajug.org/info/tech/uml/uml.html  is a good on-line introduction that gives much credit to "UML Distilled" by Fowler & Scott. I won't repeat them here, but he lists some web references at the bottom of the page.

Rick
Thursday, May 16, 2002

There are dozens of free UML tutorials at http://www.objectmonkey.com as well as articles & resources on project management, Agile Development, usability engineering and UI design, testing and test-driven development, design patterns and architecture, business complexity and IT strategy.

Jason Gorman
Saturday, July 19, 2003

Another free tutorial at http://www.alaide.com/cours.php?c=8 presented by http://www.alaide.com/

Louis GALOIS
Thursday, December 11, 2003

*  Recent Topics

*  Fog Creek Home