Structure and behavior in UML

Yes:
- A sequence diagram is readable at a high level, showing how a transaction involves a few components; but it's not good (not readable) at the detailed level, showing how a transaction involves dozens of methods (method A calls method B, which gets data from methods D and E, and then invokes method F, etc.).
- Looking at a class diagram, you might see a based class with several subclasses; this tells you nearly nothing about the behaviour of the classes (it only tells you that they may have some behaviour in common, or at least a common API, plus some individual behaior that's unique to each subclass).
That's a big question. A quick answer is, "Attach text notes to the objects: diagrams aren't sufficient without descriptive text."
No, I don't really; a UML tool help you create UML diagrams (and generate code from the diagrams), but it's up to you how you use it. There was a neat product described in the book titled Real-Time Object-Oriented Modeling (1994) which was an executable model, i.e. the model itself had behaviour, but I know of no UML tool quite like that. The closest I know of is being able to "round trip" between the model and code (i.e. generate code from the model, and the model from code).

UML allows you to specify the signature of a method, and group methods into classes, but it says nothing at all about what code you use as implementation. If that's what you mean by "behavior", I don't think UML addresses it at all at the class level.

It's even worse at the UI level. My impression of UML is that it's woefully inadequate for specifying UIs.

I think the effort required to embed everything into UML is greater than or equal to coding the application, with the added burdens of UML tools being poor IDEs and inability to prove correctness of UML the way you can with unit testing.

UML is way oversold, IMO. I consider it a convenient notation for informal communication between developers, nothing more. It has never been and never will be the object oriented equivalent of engineering drawings.

In some environments (e.g. medical devices) you may need to document how the required functionality has been implemented. In this case maybe UML is a useful documentation tool (between requirements and code), and round-tripping the UML is a good way to ensure that the model is in synch with the actual code.

ChrisW 2009-07-08 21:42:50

Yes, but that still doesn't put the meat of the method into the UML. You just get to update classes and method signatures. Round-tripping after the fact is just a documentation aid. The real work is writing and debugging the software. I still never see what UML is accomplishing for you once you're scoped out the problem.

duffymo 2009-07-08 22:04:49

Yes I haven't found UML useful for writing method implementations: writing method implementations as source code is quicker, and more compact. Still UML is good for visualizing levels of detail above that: in source code for example I'm usually seeing, at best, one class at a time (so UML might be better than source code at showing the architecture and the various interrelations between classes).

ChrisW 2009-07-08 23:08:41

I agree, but I think it's small scale stuff, with maybe a dozen classes, that you can easily fit on an 8.5x11 sheet of paper. A piece of paper or whiteboard, without the tool and all the fancy stuff, would do just as well. Who REALLY uses sequence diagrams? State diagrams? Yes. Activity diagrams? Yes, with swim lanes. But beyond that you'll have a hard time selling me.

duffymo 2009-07-08 23:14:51

Instead of only a dozen classes, you can have a dozen assemblies or components, each with a dozen classes: so, multi-layered, with the ability to "drill down" into any one thing on the diagram (to see more detail in a sub-diagram of that one thing). I think it's useful, close to the way that people think and communicate (there are so many types of diagram that at least one of them might be capable of expressing what you want to express), and although people have such design ideas it's just that people don't usually bother to capture them (as maintainable UML) into the permanent documentation.

ChrisW 2009-07-08 23:26:46

You said it yourself: do enough to get going, write the code, then reverse engineer it into UML if you wish. To be honest, there are networked disks and SharePoints filled with "permanent documentation" that's never read and out-of-date. Nobody will look at the UML. They'll read enough to get the gist of it and dive into the code.

duffymo 2009-07-08 23:43:43

Yeah. But dumbly machine-generated diagrams aren't that good: without no human authorship, they add little value over simply skimming the source code. A human author should have something to say ("I want to document the topmost levels of this assembly"), select relevent UML objects, select an appropriate level of detail for the diagram (methods? data? signatures?), and *add text to explain what's being illustrated*. I think it's the synergy (grin, duck, and run) between the text and graphics which makes a UML diagram more readable than either (descriptive text, or UML objects) would be alone.

ChrisW 2009-07-08 23:52:50

I guess we'll just disagree then. I don't see much use for UML. I think it's oversold, and its best days are in the past. The people that I see promoting it are architects who prefer writing documentation to producing code.

duffymo 2009-07-08 23:55:39

I'm saying that: 1) there are some times and some products where it's appropriate to have written architectural documentation; 2) in those cases, diagrams can help to make that documentation more readable; 3) those diagrams can be UML diagrams. Do you disagree with any of those three statements? I'm not so sure though about the value of using UML to illustrate behaviour (as opposed to architecture), even though UML does define some behavioural-type diagram types.

ChrisW 2009-07-09 00:06:16

1. Can't disagree with "some", but I can't think of many where copious UML made a difference, 2. pictures + text have proven to be quite effective, 3. yes, then can be UML. I just see the push to make UML mandatory and as detailed as an engineering spec to be wrong-headed and wasteful.

duffymo 2009-07-09 00:15:32

Thanks, I am familiar to UML and I use it in my projects. I actually wanted to see some practical limitations that come out from the others' experience, not just theory (which is just what wiki offers)

melculetz 2009-07-08 21:43:28

ansaurus

tags:

views:

answers:

Structure and behavior in UML

related questions