Fog Creek Software
Discussion Board




UML and design patterns

Hi,

I feel like I have been under a rock. I know nothing about UML and design patterns.

Are they only necessary in languages like Java?

Is UML mainly used for enterprise apps?

I only work on desktop apps so have I been insulated from this somehow?

Mike Grace
Tuesday, April 15, 2003

You can use UML in any language. It's really about designing your data structures in an OOP kinnda way. I've been using UML since VB6 up to .Net & Java.

What language(s) do you work with?

KenB
Tuesday, April 15, 2003

UML is a basically a way of visualizing stuff.

If you are doing OO code, you create use cases.  You create objects.

UML tools allow you to drag and drop and create pretty pictures that describe the objects from different ways - how the objects inter-relate, how they interact with the world, what the public methods are, etc.

Let me pull out my SE notes ...

That gives us:

Use Cases (Think index cards)
Use Case Diagrams (Think what touches what when you do a search-and-replace)

Sequence Diagrams (Flow Charts)

Collaboration Diagrams/Object Message Diagrams (Design-level stuff - what objects talk to who when.  Design the interface.)

State Charts - Think state transitions.  Like a flowchart, but different.  Do some google searches for a better explanation; it's beyond the scope of this post.

Basically, I too have managed to survive without UML.

The best UML tools allow you to describe a system, and then they dump out C++ or Java Headers for you.

Great so far, right?

The main problem is that once you shift to the maintenance phase, nobody goes back to update those pretty little pictures, and they get out of sync pretty fast.

So, why use UML?

Basically, if you are trying to work on a HUGE project that can only be described by a HUGE bound spec that nobody reads, you need something to communicate how the system will work to 25+ coders ... UML can help.  Your architects can create the high-level UML, and the coders can fill in the rest.

Some of the user-centric views can also help describe what the software actually does - thus mitigating the chance that the customer won't bother to read (or won't understand) the 10-volume spec and then will sue you when the project is over because the software doesn't do what they thought it would do.

For DoD contracts, or working on the space shuttle, it might be really good.

PERSONALLY, I try to keep my functionality and designs clear and simple - I try to avoid the problem that UML attempts to solve.  Since my work teams have been generally small, <7 people, I've also managed to avoid the complexity nightmare that UML solves.

You could go to rational.com for more information, but basically, UML tries to help big organizations that have so much bloat and negative inertia that they need help.  Instead, I would suggest that you try to avoid those problems in the first place.

:-)

regards,

Matt H.
Tuesday, April 15, 2003

I have to disagree with Matt H. when he says that UML is only for large corporations with big projects.

Even for small business contract work I use UML design. I'm not saying you have to go so crazy with tons and tons of paper work - but it really helps to draw a picture to design & understand the architecture of a system.

How many times are you asked to work on a system that someone else wrote? Probably a lot. Instead of reading through lines & lines of code to figure out what's going on, UML is great because you spend 5 - 10 mins looking over a UML diagram first to understand the concept & architcture. Then you proceed to look at the code & implement the functionality.

UML can be a beautiful thing when not over-used....

KenB
Tuesday, April 15, 2003

I have to say, I agree. Class diagrams and sequence diagrams, judiciously applied can't half make understanding a system simpler.

Why write long rambling fuzzy English language definitions when you can have a half page diagram?

Katie Lucas
Tuesday, April 15, 2003

I'm with Katie and Ken on this one.  A simple class diagram can explain more than pages of text!

happy to be working
Tuesday, April 15, 2003

A good book I came across recently is "Visual Basic Developer's guide to UML and design patterns".

The UML side of the book is unapologetically sparse; they tell you enough to understand the stuff in the book, so you'ld probably need something else, too.

Having said that the book includes descriptions of each pattern [from the Gamma book], how and where to use each and has code examples (in VB, obviously).

I'm sure there are other good books out there, also for other languages, but I was quite impressed with this. It would also make an excellent primer for students.

Justin
Tuesday, April 15, 2003

[The main problem is that once you shift to the maintenance phase, nobody goes back to update those pretty little pictures, and they get out of sync pretty fast.]

A lot of the round-trip UML modelers/IDEs actually do go back and update the UML diagrams. TogetherJ is one such IDE that can do this. You can generate your UML diagrams and TogetherJ will stub out the classes for you. Then when you update the code it can update the models for you. I'm not sure about other IDEs that do this but my experience with TogetherJ was pleasant, except for the high memory use associated with some Java GUI applications (What I ended up doing was using TogetherJ only for UML modeling and using JBuilder to code)

Ian Stallings
Tuesday, April 15, 2003

Eclipse has free addons too - which does the same thing...

KenB
Tuesday, April 15, 2003

I am currently using xbase++ ( a clipper style windows compiler) but I am trying to break free of procedural coding into OOP with Java.

Mike Grace
Tuesday, April 15, 2003

Simple is the key, and high level the domain.

It is not, as Rational would like to have us believe, a mechanism of converting diagrams into a functioning system at the  press of a button.

If you go the whole hog then you'll end up hiding tons of detail in places no one will ever see it unless they print it out, and you really, really don't want to print it all out.

Simon Lucy
Tuesday, April 15, 2003

"Design patterns" were first popularized by the "Gang of Four":  Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their book "Design Patterns: Elements of Reusable Object-Oriented Software".

In short, these are the "Gang of Four" patterns:

Creational Patterns
Abstract Factory:    Creates an instance of several families of classes
  Builder:  Separates object construction from its representation
  Factory Method:  Creates an instance of several derived classes
  Prototype:  A fully initialized instance to be copied or cloned
  Singleton:  A class of which only a single instance can exist

  Structural Patterns
  Adapter:  Match interfaces of different classes
  Bridge:  Separates an object’s interface from its implementation
  Composite:  A tree structure of simple and composite objects
  Decorator:  Add responsibilities to objects dynamically
  Façade:  A single class that represents an entire subsystem
  Flyweight:  A fine-grained instance used for efficient sharing
  Proxy:  An object representing another object

  Behavioral Patterns
  Chain of Responsibility:  A way of passing a request between a chain of objects
  Command:  Encapsulate a command request as an object
  Interpreter:  A way to include language elements in a program
  Iterator:  Sequentially access the elements of a collection
  Mediator:  Defines simplified communication between classes
  Memento:  Capture and restore an object's internal state
  Observer:  A way of notifying change to a number of classes
  State:  Alter an object's behavior when its state changes
  Strategy:  Encapsulates an algorithm inside a class
  Template Method:  Defer the exact steps of an algorithm to a subclass
  Visitor:  Defines a new operation to a class without change

T. Norman
Tuesday, April 15, 2003

Design patterns come from The Timeless Way of Building by Christopher Alexander.

UML is a very large umbrella and includes many kinds of diagrams. Like many other things, it's a way of formalizing something that many people had been doing informally before.

There are even some software programs out there that will let your project managers enter in UML and do a "round trip" with your developers who simply build in the code around it... I doubt any of them work well in more than a few applications though.

www.marktaw.com
Tuesday, April 15, 2003

UML in 24 hours looks like a good book to start learning UML with.  You will the book review here http://www.amazon.com/exec/obidos/tg/detail/-/0672322382/qid=1050782925/sr=1-1/ref=sr_1_1/002-7148968-5040005?v=glance&s=books

Looking at the book expert here: http://www.amazon.com/exec/obidos/tg/detail/-/0672322382/ref=lib_dp_TT01/002-7148968-5040005?v=glance&s=books&vi=reader&img=14#reader-link
I found it very easy to understand. Perhaps its not the experts book but it will show if its for you or not. Read the sample chapters (provided in the link above) to see if its your cup of tea.

I'm going to lent it from my public libary and hope soon to be design my killer (bugless) apps.

Smurf

Smurf
Saturday, April 19, 2003

I'm a fan of UML as a concept - it certainly enables somebody to get on board a project team much more quickly than having to wrestle with code directly.

I've had a really bad experience with Rational Bloatware - stay away from that. I mainly use text boxes in word for my class diagrams, which is a bit crude but it serves its purpose. For larger projects, your mileage may vary.

Better than being unemployed...
Wednesday, April 23, 2003

*  Recent Topics

*  Fog Creek Home