UML Distilled

Martin Fowler

Mentioned 27

A guide to using UML describes major UML diagrams, their creation, and how to decipher them.

More on

Mentioned in questions and answers.

One thing I struggle with is planning an application's architecture before writing any code.

I don't mean gathering requirements to narrow in on what the application needs to do, but rather effectively thinking about a good way to lay out the overall class, data and flow structures, and iterating those thoughts so that I have a credible plan of action in mind before even opening the IDE. At the moment it is all to easy to just open the IDE, create a blank project, start writing bits and bobs and let the design 'grow out' from there.

I gather UML is one way to do this but I have no experience with it so it seems kind of nebulous.

How do you plan an application's architecture before writing any code? If UML is the way to go, can you recommend a concise and practical introduction for a developer of smallish applications?

I appreciate your input.

I consider the following:

  1. what the system is supposed to do, that is, what is the problem that the system is trying to solve
  2. who is the customer and what are their wishes
  3. what the system has to integrate with
  4. are there any legacy aspects that need to be considered
  5. what are the user interractions
  6. etc...

Then I start looking at the system as a black box and:

  1. what are the interactions that need to happen with that black box
  2. what are the behaviours that need to happen inside the black box, i.e. what needs to happen to those interactions for the black box to exhibit the desired behaviour at a higher level, e.g. receive and process incoming messages from a reservation system, update a database etc.

Then this will start to give you a view of the system that consists of various internal black boxes, each of which can be broken down further in the same manner.

UML is very good to represent such behaviour. You can describe most systems just using two of the many components of UML, namely:

  • class diagrams, and
  • sequence diagrams.

You may need activity diagrams as well if there is any parallelism in the behaviour that needs to be described.

A good resource for learning UML is Martin Fowler's excellent book "UML Distilled" (Amazon link - sanitised for the script kiddie link nazis out there (-: ). This book gives you a quick look at the essential parts of each of the components of UML.

Oh. What I've described is pretty much Ivar Jacobson's approach. Jacobson is one of the Three Amigos of OO. In fact UML was initially developed by the other two persons that form the Three Amigos, Grady Booch and Jim Rumbaugh

What is a great way to learn good UML design? How often do you draw diagrams (other than static diagram of classes)? What is the best source for learning it?

I think Martin Fowler's "UML Distilled" is the best book for learning UML syntax. It's succinct and dense with information.

Unfortunately, knowing UML syntax well is not the same thing as knowing how to design.

I'm going to start learning and using UML.

I need to know what considerations do you suggest for me? What is the best way to learn effectively it do you think?

Thank you

I read Martin Fowler's UML Distilled. That's all you need. It's thin, dense book that's unmatched on that topic.

UML Distilled by Martin Fowler together with Applying UML And Patterns by Craig Larman, makes you understand the concept of UML and how to use it - as well the whole process with UP and so forth.

I have just downloaded Sparx Enterprise Architect 7.5 but unfortunately I am not able to find a getting started guide or something like that.

I have gone through official site of Sparx but there is not step by step guide to learning Sparx EA.

I want a guide that will implement a small project and give instructions step by step so that I can understand and try out Sparx EA.

I did find a few sites selling step by step guides but at this point of time I do not want to spend money on them.

See also Enterprise Architect Product Demonstrations and the UML Tutorials.

Keep in mind, this is a UML tool. It's possible that part of what you need is a step by step guide to understanding UML. If these tutorials don't help you, I suggest UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) by Martin Fowler. Before reading this book, I felt that UML was this huge, tangled ball of twine. This book showed me the starting point, from which I was able to unravel the ball of twine.

I’ve almost 6 years of experience in application development using .net technologies. Over the years I have improved as a better OO programmer but when I see code written by other guys (especially the likes of Jeffrey Richter, Peter Golde, Ayende Rahien, Jeremy Miller etc), I feel there is a generation gap between mine and their designs. I usually design my classes on the fly with some help from tools like ReSharper for refactoring and code organization.

So, my question is “what does it takes to be a better OO programmer”. Is it

a) Experience

b) Books (reference please)

c) Process (tdd or uml)

d) patterns

e) anything else?

And how should one validate that the design is good, easy to understand and maintainable. As there are so many buzzwords in industry like dependency injection, IoC, MVC, MVP, etc where should one concentrate more in design. I feel abstraction is the key. What else?

To have your design reviewed by someone is quite important. To review and maintain legacy code helps you to realize what makes the software rotten. Thinking is also very important; One one hand don't rush into implementing the first idea. On the other hand, don't think everything at once. Do it iteratively.

Regular reading of books/articles, like Eric Evan's Model Driven Design, or learning new languages (Smalltalk, Self, Scala) that take different approach to OO, helps you to really understand.

Software, and OO, is all about abstractions, responsibilities, dependencies and duplication (or lack of it). Keep them on your mind on your journey, and your learning will be steady.

It takes being a better programmer to be a better OO programmer.

OO has been evolving over the years, and it has a lot to do with changing paradigms and technologies like n-tier architecture, garbage collection, Web Services, etc.. the kind of things you've already seen. There are fundamental principles such as maintainability, reusability, low coupling, KISS, DRY, Amdahl's law, etc. you have to learn, read, experience, and apply it yourself.

OO is not an end on its own, but rather a means to achieve programming solutions. Like games, sports, and arts, practices cannot be understood without principles; and principles cannot be understood without practices.

To be more specific, here are some of the skills that may make one a better programmer. Listen to the domain experts. Know how to write tests. Know how to design a GUI desktop software. Know how to persist data into database. Separate UI layer and logic layer. Know how to write a class that acts like a built-in class. Know how to write a graphical component that acts like a built-in component. Know how to design a client/server software. Know networking, security, concurrency, and reliability.

Design patterns, MVC, UML, Refactoring, TDD, etc. address many of the issues, often extending OO in creative ways. For example, to decouple UI layer dependencies from logic layer, an interface may be introduced to wrap the UI class. From pure object-oriented point of view, it may not make much sense, but it makes sense from the point of view of separation of UI layer and logic layer.

Finally, realizing the limitations of OO is important too. In modern application architecture, the purist data + logic view of OO doesn't always mesh very well. Data transfer object (Java, MS, Fowler) for example intentionally strips away logic part of the object to make it carry only the data. This way the object can turn itself into a binary data stream or XML/JSON. The logic part may be handled both at client and server side in some way.

Something that's worked for me is Reading. I just had a Bulb moment with this book... David West's Object Thinking which elaborates Alan Kay's comment of 'The object revolution has yet to happen'. OO is different things to different people.. couple that with with the fact that your tools influence how you go about solving a problem. So learn multiple languages.

Object Thinking David West

Personally I think understanding philosophy, principles and values behind a practice rather than mimic-ing a practice helps a lot.

What is the difference between a domain model and a data model?

A datamodel is a design model that only describes data and it's relations. The model contains entities, but they are described in terms of what data they own not how they act on this data or what their responsibilities are.

An domain model on the other hand, is a conceptual model used in analysis of a problem domain. It describes the domain in terms of entities that have relations, data and behaviour. It describes the responsibilities of those entities as relevant for understanding the problem domain.

BTW an excelent and very short introduction to UML is:

UML Distilled: A Brief Guide to the Standard Object Modeling Language

How do i show the use of static methods in a UML class diagram?

class A{
    public static void test(){

class B{
    public void b(){

How would a class diagram look like, which shows the relationship? UML 2.0 would be prepared, if there is a difference.

To show static methods and attributes you underline them in a UML class diagram: see UML Distilled p.66 or section 7.3.19 (Feature) of the UML Superstructure specification:

Static features are underlined.

To show the relationship between classes B and A (where B only uses static methods in A), you use a dependency, not an association. Associations are always between instances of the classes at each end, as in section 7.3.3 (Association) of the UML Superstructure spec:

An association specifies a semantic relationship that can occur between typed instances.

But class B is dependent on class A, as in section 7.3.12 of the spec:

A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation.

It is probably worth clarifying the nature of the dependency with a stereotype. You could use a use stereotype, but that's very general and actually encompasses standard associations between instances (though you obviously normally use associations to explicitly show them). As Fowler says in UML Distilled,

Many UML relationships imply a dependency. The navigable association from Order to Customer [in one of his examples...] means that Order is dependent on Customer.

There seems to be no standard on what stereotype to use. I've used usesStatically to be clear on the nature of the dependency; that is

B --usesStatically--> A

(If, alternatively, class B had an instance of A as a static field, I'd use something like B--containsStatically--> A if I'm representing B explicitly in the class diagram; otherwise just have an underlined static attribute of type A in B.)

Possible Duplicate:
Is UML practical?

I heard many opinions about UML. Some people says that it is useless. Some people says that it is very helpful.

What was your experience on using UML? How does it effect on development process?


I find that I tend to use a subset of the complete UML standard.

Class diagrams: to show how components of a class are built and the members and functions they contain. Especially useful to show "isa" and "has a" relationships and even aggregation versus composition for the "has a" relationships which reflect on component lifetimes.

Sequence diagrams: to show how the classes interact with one another and show the flow of messages between the classes in the sequence of the message's use.

and occasionally:

Activity diagrams: to show parallel processing.

If you want to use UML then I can't recommend Martin Fowler's book "UML Distilled" (sanitised Amazon link) highly enough. Seriously, forget all the other UML books! IMHO naturally



I'm drawing some UML in which a concrete class inherits from an abstract class which defines a pure virtual method. Is it required to show this method in the concrete class as well? It's implied by inheriting from the abstract class.

Nope, you don't need to. in fact, in general, don't put any more in the UML than you must have to clarify what you're saying, unless you're (god forbid) trying to generate code from it.

The best guide I know of for UML is UML Distilled by Martin Fowler.

As part of an assignment, I have to create a component diagram for existing code. I understand what a component diagram is and the information it presents, but I'm not sure of a process to follow when looking at code to diagram it out to produce a component diagram. I'm also not sold on how a component diagram, if I am presented with one, would help me with implementation of a system.

Martin Fowler's "UML Distilled" is still the best book on UML you can get. Its chief virtue is that it's thin - densely packed with info.

Does anyone know of a decent UML standards guide?

My company currently relies on UML 2.0 (rightly or wrongly) to do the majority (read all) of their design work. I have been asked to come up with a draft 'best practice' guide to help other developers develop better models. The main problem I face is that Im slightly biased against UML... I feel that: if a diagram takes more than 5 mins to draw then its too complicated! Im looking for advice predominantly on what sort of standards I should be looking at. Also Im looking for an external source of information that can be used to balence out my irrational loathing of UML-heavy design and act as a 'sanitizer' for my suggestions.

Most of all Im looking to write a useful document rather than one that will sit moulding away in some obscure network directory.

Any ideas?

Like Paul C, I recommend UML Distilled. It is primarily about UML, but it contains a lot of insight about design in general (although it insists a bit too much on index cards IMO), it is short, pleasant to read, and to the point.

I strongly recommend against UML in a Nutshell. It is the worst O'Reilly book I have: insanely dense, hard to read and meandering. Not worth the paper it is printed on.

UML Distilled by Martin Fowler

I know you probably want an easy to read book for this but from what you are describing I would suggest going with the specs found on OMG itself. They are a bit much to read but would be as complete as you could hope for. They also have lonks to articles and tutorials that may be helpful.

As far as books go I have found that Using UML is quite good since it tackles the software development process as well as the UML tools and methods.

I am new to writing use cases.I heard that Use cases are non-technical expressions .

I have the following task for which i have to write Use case.
(I reduced the requirement for your understanding)

Registered Customer of ABC company logged in to the system with credentials to retrieve the complete Address of particular service provider.He searches the service provider on TextBox.The System communcates with database and displays the result on monitor.

I am technical guy,
I have to write use case to explain the behavior of the system to the client.

I have written Use case as follows :

Use case Name: Address Locating System
Primary Actor: Customer
Stakeholder: ABC Company
Precondition: Customer Successfully Logged in to the system

Success Scenarios:

  1. Customer Enter the search term in the box provided.
    • System searches the search terms for matches.
    • System Supplies the address to the Customer.

Extension Point: Client is informed when no successful match
Post condition: None


  1. Is the Use Case described above, correct?
    • Do really tech people need to write Use cases?

Whenever I need to write a Use Case, I pick up my copy of UML Distilled and use its suggested format. There are variations in the formats, so this isn't the only way. In any case it's a good reference to have on your desk. You might also check out Writing Effective Use Cases; I haven't read that one, though.

If you'd like a free example, see:

I might avoid the "in the box provided" bit - that's an implementation detail that might change. I might also change 2 to just "System searches for matches."

And yes, technical people do need to write Use Cases readable by non-technical domain experts.

I need a punch of samples of UML diagrams to get an start point to develop my own diagrams.

Does anyone know about a good website where I could find it?


The best resource for learning UML is Martin Fowler's "UML Distilled". Now in its third edition, this thin gem has stood the test of time.

Does anyone have any good resources for refining my skills in developing class diagrams? Would like any strong tutorials in UML 2.0 ideally, but searches seem to be returning poor results.

Also currently revising for a final year exam and really want to try and get my teeth into a practice paper with a model answer, I've searched high and low without any luck, does anyone happen to have any suggestions on where i might find some?

Basically any resources to help push my revision along. Would relish the chance to look at more advance stuff and push the boundaries.

Any help appreciated.

Thanks, Ricky

Martin Fowler Wrote a book. The latest edition was published for UML2...

I have about four years of experience as a Java developer. I'm planning to get myself involved in the world of UML. Can anyone suggest some good books and reference material for UML?

I would recommend The Unified Modeling Language User Guide, written by the creators of UML, the "Three Amigos" of software engineering (Grady Booch, Ivar Jacobson and James Rumbaugh).

Check out the UML Resource Page of the OMG. Among other resources, this page has links to the latest UML specifications.

There are plenty of good books available as well:

I use UML Sequence Diagrams all the time, and am familiar with the UML2 notation.

But I only ever use them to capture the essence of what I intend to do. In other words the diagram always exists at a level of abstraction above the actual code. Every time I use them to try and describe exactly what I intend to do I end up using so much horizontal space and so many alt/loop frames that its not worth the effort.

So it may be possible in theory but has anyone every really used the diagram in this level of detail? If so can you provide an example please?

I have the same problem but when I realize that I am going low-level I re-read this:

You should use sequence diagrams when you want to look at the behavior of several objects within a single use case. Sequence diagrams are good at showing collaborations among the objects; they are not so good at precise definition of the behavior.

If you want to look at the behavior of a single object across many use cases, use a state diagram. If you want to look at behavior across many use cases or many threads, consider an activity diagram.

If you want to explore multiple alternative interactions quickly, you may be better off with CRC cards, as that avoids a lot of drawing and erasing. It’s often handy to have a CRC card session to explore design alternatives and then use sequence diagrams to capture any interactions that you want to refer to later.

[excerpt from Martin Fowler's UML Distilled book]

I am trying to document a software project up to the current stage. The readership would involve myself (in a future time), other developers (currently and in the short-term future), as well as end users. Therefore, the documentation has descriptions of design requirements, architecture/design (data structures, architecture, user interface, procedural design), technical documentation, and end user instructions. The documentation is mainly produced in order to provide some historical record. Currently, it's a team of 2 people working on the project, although it could involve more people in the short-term future as more features from other people's projects are added to this project.

What I'm having trouble is with the architectural design documentation ( While I have tried using doxygen to create some type of data flow diagram, it hasn't been easy. Are there any tools that would make it any easier to generate data flow diagrams from C++ code, or would this be a case of drawing manually on Microsoft Visio? Thanks in advance.

Any low level diagrams automatically generated from source code are going to be useless. They'll be more obscure than your code, have a messy visual layout, and soon be out of date. Future developers will distrust them and look at the code instead, so you're better off investing the extra effort into refactoring your source code (ie, to use self-explanatory names, have a class structure that represents your problem domain cleanly, and so on).

It is worthwhile to create good javadoc or doxygen comments and keep them up to date: many people find these quite useful.

High-level diagrams also are valuable. Read Martin Fowler's UML Distilled and learn the UML notation. Then use Viso or another graphical editor to document just the parts of your software that would be helpful for future developers. Don't waste time making the diagrams "complete" and perfect, just focus on what will help other developers the most.

We have a very large app which has been designed exclusively by a single developer who is a bit reluctant to give too much information out on how it has been put together.

We were thinking about using a UML tool for educational purposes so others can start to learn and take ownership of the code but with the the large code base it may be difficult to work out how it all works.

My questions are:

  1. How would you go about educating others on a complex piece of framework?
  2. Will UML benefit?
  3. What UML tools are there for .net apps?
  4. Can UML tools auto-generate sequence diagrams and at least this will give more information on how the objects interact?

Any information provided will be greatly appreciated.


1) How would you go about educating others on a complex piece of framework?

Answer: I wouldn't focus too much on UML specifics as your audience might get lost. I would suggests taking a look at UML Distilled, Third Edition as it will touch on the most important diagrams you can use, as well as how to use them. As others have said, unit tests (or integration tests if the code doesn't support it), and inline documentation could be very helpful too.

2) Will UML benefit?

Answer: This depends on the audience. Do they already know UML? If so it will likely help. Otherwise, anything but class diagrams and use cases may require you to do double duty (teach the program and UML).

3) What UML tools are there for .net apps?

Answer: I can't speak for anything other than UMLet. Yes, it's a java tool, but it has a standalone version. It makes it fairly easy to create diagrams. I use it instead of a white board for experimenting with designs. However, this tool would require you to manually create everything, which isn't what I think you are wanting. I did a bit of searching and came across StartUML, which is open source. It appears to be able to generate UML from c# code.

4) Can UML tools auto-generate sequence diagrams and at least this will give more information on how the objects interact?

Answer: Others have mentioned tools in VS2010 Ultimate and other programs regarding sequence diagrams. But if you don't have that version of the IDE (or want the other programs mentioned), VS2008 PRO can at least generate class diagrams for you, showing how they are related. If you do have VS2010 ultimate, here is an article on it.

When designing both the domain-model and class-diagrams I am having some trouble understanding what to put in them.

I'll give an example of what I mean:

I am doing a vacations scheduler program, that has an Administrator and End-Users. The Administrator does a couple of things like registering End-Users in the program, changing their previleges, etc. The End-User can choose his vacations days, etc.

I initially defined an Administrator and End-User as concepts in the domain-model, and later as classes in the class-diagram. In the class-diagram, both classes ended up having a couple of methods like

Administrator.UnregisterUser(int id);


Only after some time I realised that actually both Administrator and End-User are actors, and maybe I got this design totally wrong. Instead of filling Administrator and End-User classes with methods to do what my Use-Cases request, I could define other classes from the domain to do them, and have controllers handle the Use-Cases(actually, I decided to do one for each Use-Case). I could have a UserDatabase.RegisterNewUser() and UserDatabase.UnregisterUser(int id);, for example, instead of having those methods on the Administrator class.

The idea would be to try to think of the whole vacation-scheduler as a "closed-program" that has a set of features and doesn't bother with things such as authentication, that should be internal/protected, being that the only public things I'd let the outside world see would be its controllers.

Is this the right approach? Or am I getting this totally wrong? Is it generally bad idea to put Actors in the domain-model/class-diagrams? What are good rules of thumb for this?

My lecturer is following Applying UML and Patterns, which I find awful, so I'd like to know where I could look up more info on this described actor-models situation.

I'm still a bit confused about all of this, as this new approach is radically different from anything I've done before.

I would not say that your design, as you speculate, is totally wrong, in fact Administrator and End-User are valid domain objects that should be represented somehow in the Class Diagrams. Just because you identify those two entities as actors doesn't mean they should be excluded from the Domain, remember, your domain is your scope, or "relevant context", that is, the set of useful objects that play a relevant role in your solution.

You may start with basic objects that comprise your model, just write them down, without further analysis, like brain storming...

  • Vacation
  • Location
  • Travel Agent
  • Schedule
  • User
  • Reservation
  • Reservation Service (This can be an interface for accessing the vacation reservation stuff)

Then try to establish the relationships between those objects, if you can not find any relationship that means you are not choosing the right objects, if they are part of the same problem domain then they must be related somehow.

After some time, you will discover that there are objects missing, try to encapsulate as much as possible, and represent the correct abstractions, Design Patterns might help you out with that.

When every possible object is represented with all its properties and methods, then you should have a fully, although not yet finished, functional design.

I know you should have a lot of theory in your mind, so get going, without fear, I myself have used this approach successfully many times at work.

Finally get a copy of UML Distilled


I am finding it difficult to model polymorphism and instances in UML.

For example if i have an abstract, parent or base class called "Bird", i would imagine that you could say that "duck" is one form of polymorphism but it could also be an instance.

Maybe, i'm confusing where one starts and ends. Are there visual examples of these?

The question of inheritance vs instance depends on functionality. If there are any differences in your data model between ducks and other types of birds then you would want a Duck class that inherits from Bird. Otherwise you're looking at your duck simply as an instance of Bird.

Polymorphism only comes into play when you are calling the same method across different Bird implementations.

For UML modeling here are a couple points to help you out.

This book is required reading for many Software Engineeing courses and has served me well for many years.

This blog does a pretty good job of showing the different use cases and the corresponding OOP models.

I have found quite a few material (books and other stuff online) on how to make UML diagrams. So now I understand UML and the diagramming (with a tool).

However, where I am stuck is the approach / methodology. My hunt for approach / methodology always leads to how to use UML and which diagram fits where. Frankly my intent is to know how to start the journey from putting down the domain understanding (and how) to drafting the blueprint of the system that is ready for the use of developers.

I really don't care if it is UML (good if it is so) or not. I should be able to communicate the target application's domain understanding, it's analysis and eventually it's intended design in as clear terms as possible.

I think there is no Cast in Stone way of doing this, however, I am looking for potential approaches / methodologies. Please share pointers to any books / training material that is available for the purpose.

Here are a few resources that may help:

  1. Domain Driven Design Quickly (Free summary of Domain Driven Design)
  2. Domain Driven Design

These resources deal with gathering the knowledge of the Domain from domain experts, coming up with terms that are ubiquitous for all parties involved, and then designing the programming model to suit.

Additionally, since you mention UML, and if you haven't come across the following book yet, I highly recommend it:

Lastly, in more general terms, I would look further into Agile Development Methodologies.

What type of design diagram is recommended for capturing the high level/concept design of an application that has multiple threads? Any examples?

In my specific case (C# WPF app) I have a application that has:

  • a UI project & some class libraries (util classes broken out for reuse)
  • classes within (both UI and class library)
  • but also about 5 different threads (including UI thread) handling various things

The UML Distilled book, which is a summary of the Booch/Rumbaugh/Jacobson book, says to use UML Activity Diagrams to model parallel tasks. At the end of Chapter 9: Activity Diagrams, the summary says:

The great strength of activity diagrams lies in the fact that they support and encourage parallel behavior. This makes them a great tool for workflow modeling and, in principle, for multithreaded programming.

Can you give me an UML example of a website or REST server.

Definitely agree with John on this one...if you're just going to use somebody else's diagram, it's going to be meaningless and useless to you. addition to the book he suggests, you might also try The Elements of UML 2.0 Style. It definitely makes a good pocket reference for just about any diagram you'll need to create.

I read your other post on this, and have to tell you that you should not use UML for this. Even if you had an example to work from, UML is too complicated to just copy.

When you get around to actually learning UML, I recommend "UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)", by Martin Fowler.

I'm interested to know about the relationships (Aggregation, Composition) between the different roles of adapter design pattern. I still have few confusions over association and aggregation. I have posted the class diagram of Adapter below. I need to know whether adaptee is in an aggregation relationship with adapter.

Adapter Design Pattern UML

Aggregation relationship is defined as shown in the below code snippet.I know that aggregation is not implied in the UML but I see that there is a similar implementation in the adapter and adaptee as shown in the below code.

final class Car {

  private Engine engine;

  void setEngine(Engine engine) {
    this.engine = engine;

  void move() {
    if (engine != null);

Can someone please explain me, why the relationship between adapter and adapteee doesn't fall into the category of Aggregation.

Thank you in advance.

Aggregation is a part-of relationship.

In the pre-UML days, people were usually rather vague on what was aggregation and what was association. Whether vague or not, they were always inconsistent with everyone else. As a result, many modelers think that aggregation is important, although for different reasons. So the UML included aggregation but with hardly any semantics. As Jim Rumbaugh says, "Think of it as a modeling placebo"

Quoted from UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition.

So according to the definition, the adapter may not aggregate the adaptee. In other words the adaptee may not be in a part-of relationship with the adapter.

Another thing is the fact that aggregation has no semantics what so ever so using it has become more or less of a personal choice.

One last thing. I always felt kind of vagueness about the difference between association, aggregation and composition but after reading DDD by Eric Evans i had another prespective about it so i wrote an article about the subject. If you care to take a look at Relationships in Context.

where can i find information about UML?

Check out the UML Resource Page of the OMG. Among other resources, this page has links to the latest UML specifications.

There are plenty of good books available as well:

Martin Fowler's UML Distilled is a very good introduction. It's pragmatic, well-written, and very concise.