UML real world example??

[petrel]

As a newbie to UML and EA, this is one fine thread since, like Peter, this is my first foray into applying the UML 'notation'. I've laid down my readies for Fowler's UML Distilled, Arlow & Neustadt's RUP, Roth's UML A Beginners Guide and Booch et al. The Unified Modelling Language User Guide and am excited by the prospect of learning a new, and by all accounts, very valuable skill.

Having used a 'student' version of Rational Rose and then trialled Visual Paradigm and EA, I've settled on and purchased EA Pro--the journey begins.

One thing I'm finding is that it's very difficult to know when to stop embellishing elements in diagrams.  For a newbie it's very difficult to know when the model is sufficient.

So I too would like to see some worked examples--not for their content so much but more because I 'need' to appreciate when the author(s) reached a point they felt 'enough's enough' -- when there was no need to add any more --  the point where they had a working example that said all that was required to understand the problem domain.

Such examples could then become my tesing ground, the place where I can check artefacts with my understanding of what each means and how each diagram and its components relate.

The 'Informatik' paper by Bergner et al looks like it may fit the bill. It would be reassuring to see such an effort in an Enterprise Architect project format so I can explore it.

Thanks to all who've contributed to this thread and made using EA more satisfying.

petrel

[CJ]

G'day petrel,

Welcome to UML and EA !

One thing I'm finding is that it's very difficult to know when to stop embellishing elements in diagrams.  For a newbie it's very difficult to know when the model is sufficient

Tough question.  I don't know if it just applies to newbies ...

You should probably check out http://www.agilemodeling.com/.  Scott Ambler's book (http://www.amazon.com/exec/obidos/ASIN/0471202827/qid%3D1095953763/sr%3D11-1/ref%3Dsr%5F11%5F1/002-9215225-6056014) is a great read.

[sargasso]

When to stop?

Try this -
1. when your design adequately communicates what you are trying to say to your audience.
2. when you have no more questions to ask the stakeholders about the elements in the diagram.
3. when you are no longer expressing design decision matters and are starting to implement the design in the design itself.


or this -
1. before there is more ink than whitespace on the printout of the diagram
2. before the point where you need to express the goals of the particular diagram in more than two dot points
3. before the point where you cannot show the diagram on an overhead projector screen unless the audience is 6 inches away from the screen.

or this -  
sometime before the system is deprecated...

Bruce


[on reflection]

The point is, at the end of the day, the design is not the system.  Why do we model?  Always consier this when embarking on a design exercise - what are we trying to  decide, communicate or solve?

Do not design for the sake of it (unless you're an artist).  Each and every model you produce has a specific meaning to you and your intended audience and (if I get my way) to you and them only.

I've said this before and I'll say it again and again..

[glb]The purpose of a UML model is to comunicate something.[/glb]

The comunication may be between youself and the end user community, yourself and your corporate knowledgemeisters or even yourself and yourself (as in "if I dont write this down in three weeks I'll have no idea what the heck I intended")

Use UML, UML diagrams and UML documents for communcation, not religion, and it will all start to make sense.

hth
B

[even more...]

As some readers know, I am currently working on a large integration project - 60 subsystems, ... blah blah blah

We have no distilled the essence of the problem we are trying to manage down to 11 diagrams.  These diagrams contain component, provided interface and boundary elements and connector and assembly links only. Each diagram fits on an A4 page tidily at 100%.

Our area of the project uses these diagrams to manage all the integration issues and we have, on request, provided the diagrams to other areas of the project.  One group wanted us to modify the diagrams to include stuff for their needs - we declined but gave them a copy to use as the starting point for their work.  the point being to keep the integrity of our models by making sure they are simple and focussed to our purposes.  It is a big mistake in UML usage to try and get "everything" into a diagram.
B

[mbc]

In response to Sargasso:

Another purpose of modelling, apart from communication, is visualizing in order to improve understanding. You might know all the details of a system (existing or future) but not really understand the system until you see a drawing of it.

Yet another purpose for the model is to aid during the designing itself. E.g. drawing a sequence diagram to realize a use case will help you discover what classes you need and what associations are needed between them (try it, it's great!). This kind of diagram may only be useful during the design process itself, and can be thrown away afterwards.

Mikkel

[beaf]

If you're wondering what to say (rather than how to say it...using UML of course), then look at some of the architecture frameworks kicking around. They help to lay out what needs to be said when describing a system. RUP is one, along with RM-ODP, DoDAF, FEAF, TOGAF...the list is ever growing. The latter ones are enterprise architecture frameworks and describe the business as well as technical architectures. At the end of the day, they recommend what needs to be said to meet a particular perspective or stakeholder concerns. A good meta-architecture framework is the IEEE-1471 standard. It takes you away from UML a little bit, but it gives a good insight into what a good architecture specification is compared to a bad one.

Good luck!