UML design

If it's not that forum i was thinking about, just don't reply Can anybody recommend a good book aboutUML.. but i ain't looking for another tutorial about the basis of object oriented software development... i know what class'es are, what state and activity diagrams are... i'm rather looking for a book that will guide me in advanced and datailed software development, that shows how to organise classes in packages and.. the issues concerning software engenieering.

http://www.amazon.com/exec/obidos/tg/detail/-/0130925691/qid=1103332148/sr=8-7/ref=pd_ka_7/002-8184044-0423268?v=glance&s=books&n=507846

UML is a graphical notation, no more, no less, so learning UML will not necessarily teach you any of those things. UML is useful for illustrating design concepts & patterns, documenting existing designs, and for group design discussions round a whiteboard. The idea that you can design a complete system up front in UML is widely discredited, especially within the agile development movement. Agile development emphasises iterative, evolutionary development emphasising working code as the embodiment of the design, rather than UML documents.

For learning UML I recommend

* UML Distilled by Martin Fowler

For learning sofware design techniques I recommend:

* Design Patterns by Gamma et al

* Refactoring by Martin Fowler

For general programming skills:

* The Pragmatic Programmer by Hunt and Thomas

* Code Complete (2nd edition) by Steve McConnell

* Programming Pearls (2nd edition) by Jon Bentley

For agile development:

* Agile Software Development by Alastair Cockburn

* Extreme Programming Explained by Kent Beck

An excellent book that covers good design principles, design patterns, and agile development techniques is:

* Agile Software Development - Principles, Patterns, and Practices by Robert Martin


Dave - The Developers' Coach

Yep, I have that and it's a nice look at most of what you will need in uml and how to use it explained in an easy to read way. UML is more a way of communication of your system to others, so be aware of that if you purchase a book on UML.

I found that quite difficult reading. They define alot of the patterns in terms of other patterns, so for a newbie to patterns I found it to be no help. Especially since the concepts are quite deep to get through in each pattern when learning them for the first time.

I've gotta get around to these as well. Thanks for the list Dave.

I'd like to recommend:

Patterns of Enterprise Application Architecture (PoEAA) by Martin Fowler and Domain Driven Design by Eric Evans. The first one (PoEEA) I think is something you are looking for. It helps orgainse how to break up systems logically and is very pragmatic about it. The second one is also excellent - and explains how and why to keep your software design representatitive of the business domain model that you are modelling it against.

Cheers,
Eli

The Methods & Tools newsletter has an archive section with some article on applying UML to the real world like:

* Precise Use Cases
This article describes a precise form of use case that promotes the specification of inter-actor options and alternative course conditions.
http://www.methodsandtools.com/archive/archive.php?id=8


* Database Modelling in UML
This article offers a step by step approach to transform a UML object-oriented class model in a purely relational database.
http://www.methodsandtools.com/archive/archive.php?id=9

Never heard of methods & tools before; thanks for the linkage.

UML and The Unified Process, Arlow/Neustadt

Building Web Applications With UML – 2nd Edition, Jim Conallen, Addison-Wesley

I used these in two courses in CIS the past two semesters. Both by the same publisher. Both really good. The first is the basics of UML, the second (obviously) is geared more toward web applications of UML.

okay this is prolly a total understatement- but UML seems like just a big flow diagram.
I.E.
Boxes for classes - circles for properties - triangles for methods - maybe some diamonds for conceptual linkage - rectangles for comments.
Arrows w/ a straight line indicate a "has a" relationship - arrows w/ dotted line indicates an "is a" relationship. Double lined arrows indicate IO streams.
Baddow.
UML in a nutshell Cliff notes for ya.

I have tried reading a couple "definitive sources" on the subject - but good lord talk about overcomplicating for the sake of complication.
You know who write a darn good book?
The "head first" guys (derivate of O'Reilly).
They got a book called design patterns which is pretty choice.

Honestly, I have to agree with hzane to some degree. I used UML in two courses for a year. The professors required that a full specification, use cases, sequence diagrams, class diagrams, and vision statements for the project be given. All classes that could potentially be used had to be in the class diagrams. All flows of events (use cases) had to be in a sequence diagram. The sequence diagrams had to use methods and properties of the classes to interact with one another.

WHEW!

Unfortunately, scope creep, simply missing or not thinking about some classes that you might need, and other factors made the diagrams and documenation that I had created all but obsolete.

We created diagrams in the first few weeks of the course, then implemented what we had diagrammed and written up. By the end of the course we had changed everything so much that we more or less had to redo all diagrams to fit what the system actually did!

It does seem overcomplicated sometimes, but for GIANT projects it can be a great way to see the big picture. It does take much practice to get better and you will never perfect it.

I have heard of few companies that actually use UML in designing software and systems. I work for YUM! Brands in Louisville, KY (parent company of over 30,000 restaurants) and we do not use it. We draw out diagrams and such sometimes when the project is large enough that it's hard to keep focus. UPS here in Louisville DOES use UML for its software design. As you can imagine, the task of organizing 15,000,000 records of packages at one time could be ugly so UML does make sense. They have to worry about which ones go where, which planes will get the packages to destinations fastest, records of business accounts, ETC ETC ETC... again, WHEW!

So... moral of the story: use UML to get a 30,000 ft. view of your system, but unless you are a true UML master, it is likely that your 30,000 ft. view will change 10+ times before you are done with the project.

The Unified Process works to alleviate the issues of changing architecture as the project evolves. You don't have to be a UML master to use it, when you're using true UP.

Perhaps not, but in my case (a medium sized project) I found it to be more trouble than it was worth.

I don't know about changing architecture. That would be a REAL problem. Perhaps you mean changing feature/scope?

I just started reading

UML for Mere Mortals®
By Robert A. Maksimchuk, Eric J. Naiburg

I'm just a little out of chapter 1 but I'm liking it so far.
it's a available at safari.oreilly.com

The best use for fancy UML tools like Rational Rose is is to reverse engineer your code into smart looking diagrams that you can paste into reports to keep managers happy. Use UML to document your design after it has been created if you need to, but don't try to use it to create the complete design.

The best UML *design* tool is a whiteboard. The best way to use UML as part of the design process is to have a group of developers round the whiteboard discussing the design and thrashing out alternative ideas. UML is useful as a language for communicating design ideas between people. However it is not the design itself - ultimately the source code is the design.

Dave - The Developers' Coach