Chances are you've heard of the term or read some tutorials on how to use these diagrams to help with documenting your thought process when building a slick Flash project. I basically only wanted to share a little gem I've recently discovered but ended up writing propaganda. I digress.
UML definition
"UML includes a set of graphical notation techniques to create visual models of software-intensive systems." - WikipediaThis description is quite heavy as it stereo types UML diagrams to hardcore software engineering. The truth is I've found UML useful in various scenarios. In some cases I'm sure software engineers will shudder when they hear when or how UML became useful. For this post we will focus on Class Diagrams as this is one of the most popular diagrams but by far not the only one.
What is UML useful for?
These days UML is defintely not just for software engineers. Although, having said that I recently noticed some Actionscripters calling themselves engineers (*sigh*). Here are some scenarios where I've found UML greatly improve my workflow, reduced overheads during building, debugging and general courtesy when dealing with legacy code.Maintenance or Reverse Engineering
Some UML tools allow for reverse engineering through auto generation. The only Actionscript supported tool that does this (that I know of) is Sparx Systems Enterprise Architect (EA). This baby in my opinion is the daddy of all UML but it comes at a cost. There are a variety of tools available and if you use one you particularly like please share. With EA you can create a new diagram and drag and drop classes which will autogenerate all the models with their operations and properties. This will then create a link between your classes and the diagram. Should your class change then all you would have to do is hit refresh within EA and all your changes will reflect in the diagram. The only problem with EA is the support for Actionscript needs a bit of upgrading, no MXML support and its a tricky interface to get use to in my opinion. Apart from these two points is the price. These days I'm a bit cheap and tend to support the Open Source community alternatives more often. In most cases these alternatives works better in my humble opinion.
Planning and Technical design
Some of us do this on paper, others do it in the extreme way (i.e. your head), the point is every Actionscripter does this in one way or another. We plan how we build stuff. That is how we work. The more experienced we get the more we plan as experience have taught us that planning is vital to not only produce quality code but also to produce readable, robust and maintanable code. So often do I work with Actionscripters that are used to working solo - and it's difficult for her/him comprehend why we need to do this, very much the same way it is to convince an account team member the extra time required to make a component reusable is worth it. Obviously not all Actionscripters work this way, most of you understand that leaving your code behind requires handover and also reflects on your professional skills.
It's all about relationships
The relationship between classes is what a UML Class diagram is all about. So what kind of relationship is it? Break it down.Instance-level and Class-level
UML relationships are broken down into these two levels. Instance level relationship refer to the instance of an object and the relation it has to other instances. Class level refer to the relationship one class has with another.
Multiplicity
Multiplicity refers to the reference counts one class makes to another. So for example a class that inherits from another class (Generalization) will have a multiplicity of 0..1. This means either no instances or one instance. Below is a list of multiplciities used in UML:
- 0..1 » No instances, or one instance (optional, may)
- 1 » Exactly one instance
- 0..* or * » Zero or more instances
- 1..* » One or more instances (at least one)
Example relationships
To show how classes relate to each other below we focus on the relationship of Composition and Aggregation.
- A car and its engine » Composition
Without an engine the car is pretty much useless, unless you have a drive-in in your backyard. Just like the car has only one engine, this relationship between classes refers to a multiplicity of zero to one. Also important, in most cases, if the car gets blown up, the engine doesn't exist anymore. - Family member » Aggregration
Just like having family, Aggregation refers to a class that has a multiplicity of one to many with other classes, i.e. you can have more than one family member in relation to you and chances are that should any member fade away, you will still be here.
The Basics
UML can be a lot to digest for a newbie, but there are a few simple concepts you need to grasp in order to get started. The idea with these are to get you going and thinking about how you write your code. There are loads of tutorials available and good books if you want to dive deeper.Class Diagrams
Class diagrams are mostly what we will cover but for a description of other useful diagrams please see below.Composition
Composition is represented by a filled diamond. Composition is what you are probably most accustomed to and a familiar term if you've read about design patterns. Usually composition is referred to with inheritance but in UML you'll find composition and aggregation is commonly mentioned in the same sentence. We'll get to aggregation later. Composition indicates one object containing another. For example:
package
{
public class UMLComposition
{
private var child:Object;
public function UMLComposition()
{
child = new Object();
}
}
}
The child instance relationship with the class UMLComposition is of type composition. Should the UMLComposition instance be deleted, usually the child object will be too. The multiplicity of Composition is zero to one.
Aggregation
Aggregation is represented by an empty diamond. Aggregation unlike Composition has a multiplicity of one to many
An example of aggregation:
A tree object contains branches, leafs and a squirrel. Yes a squirrel. The relationship between the leafs and branches are strong as without branches, the leafs won't exist. The same is true of the relationship between the branches and the tree. However the squirrel, will only need to find another tree should the one he is in suddenly be deleted (or die).
Generalization
More commonly known as inheritance, generalization is a class-level relationship. Up till now we've been dealing with instance-level relationships. Generalization means that one of the two classes specified is actually a more complete implementation of the other (super). Generalization is represented by an empty arrow rectangle join.
Realization
If you've guessed Interface well done. If not don't sweat it, maybe next time. Realization is the relationship where one model realizes the behaviour specified by another.
package
{
public class Tree implements ISway
{
private var child:Object;
public function Tree()
{
branch = new Branch();
}
public function sway():void
{
...
}
}
}
It is worth pointing out that Composition and Aggregation are very much confused as either the same or only known as one or the other. For the sake of explanation I've decided to keep these two relationships seperate even though some may disagree and argue that only Aggregation exists with different types, i.e. strong and weak. I'm writing this as I understand it and hopefully give some clarity as this can become really confusing with different interpretations.
Useful UML Diagrams
We've mainly touched on class diagrams but actually there are quite a few diagrams that can be beneficial to know. I'm only covering the ones I've had exposure to but feel free to browse the resources list at the end of this post to get more than you bargained for.Structure Diagrams
The purpose is in the name really. These are diagrams to help identify the structure of the system you are trying to model. And by system I obviously mean Flash application.Class Diagram
A structured diagram based on the classes that will be required to make up your system. The hierarchy and relationship between classes are defined here.
Component Diagram
Modelling a system's component and the relation of these components depicts a component diagram. Components can be recursive and thus understanding this relationship with the system can highlight many flaws, improvements or just generel knowledge of the component architecture (think of Flex).
Behaviour Diagrams
Behaviour diagrams models the system's behaviour in response to startup, idel, input etc.Use case
Use cases are specific behaviours by Actors. An Actor can be a user or the application or a system like a server. A use case is very useful for outlining how a specific behaviour should work. A use case can take an abstract form at the beginning of a project and become more granular as the project progress. A use case coupled with a Sequence diagram is great way to establish how a specific task that occurs from a behaviour should happen. Often use case diagrams are referred to during QA to help understand the application's behaviour.
State machine
In a more complex system it is useful to model the system's state through the triggering events as well as actions involved. State machines are often used in Flash in conjunction with Browser Integration and breadcrumb implementations. But most of the time the applications aren't large enough to validate using a state machine.
Interaction Diagrams
Interaction diagrams is a type of behaviour diagram but shows the flow of control and data within an application.Sequence Diagrams
Sequence diagrams show the sequence of execution within an application. This could be a load sequence or just a general method call sequence. A very useful diagram to have when coupled with a use case.
Benefits
UML can greatly improve the planning process, regardless of which tools you use. Some benefits I personally had from doing UML diagrams:- Reverse Engineering
Working out how another developer thinks by mapping out their code through UML makes for interesting reading. It helps you find things and connect the dots way quicker than any other process. I do this very often done on paper depending on size of the project. There is no harm in taking a photo of your drawings and keeping them within a doc for developers per usal. - Planning
UML is a good place to start before coding. Quite often seeing things from a bird-eye perspective will enhance your understanding of what is required. Also, by doing UML up front you have a good base to start your tech docs from. - Documentation
Your code. Your legacy. Remember this as more often than not it will haunt you if you haven't done enough to create an understanding of your throught process during development. Some of the worst code I've seen have been rectified in my opinion through good documentation. UML is one step closer to this. It's always difficult to work under pressure and against a deadline and docs are the last thing on your mind, but this doesn't mean it should be forgotten. Even at the worst where there is no time for docs and you have done UML diagrams, it gives your code some respect and context to which I can assure you the next developer working on your code within a few months will value and appreciate.
The gem
The tool that inspired this post is an Eclipse plugin called UML2. I prefer to keep all my development within one IDE and this suits my needs perfectly. It's very easy to use and doesn't require any change of perspective. It's a view which means I can have an Actionscript class open and a UML diagram. There is no auto reverse engineer feature as with EA, but I think that the support EA gives to Actionscript is not sufficient. Also, I've found that removing the language from UML diagrams allows a developer to focus more on the Object Orientated Approach.
Install (Eclipse Galileo)
- Help » Install new software...
- In the Work with drop-down select Galileo - http://download.eclipse.org/releases/galileo
- Expand the Modelling tree
- Check UML Tools SDK » Finish
I really heart EA. Code engineering & reverse engineering is a blessing and the eclipse link that auto updates code and allows jumping through it, has done wonders for me.
That said - I am going to try the UML2, maybe it works better with my FDT installation.
Give it a go although I suspect if you are happy with EA then stick with it. I can't afford it so was quite happy with UML2 as an alternative.
I think you have some insightful observations about UML. I’ll give some observations of my own, but unfortunately, I think your containment representation may be backwards. Or at least I’d do it a different way. I’d represent the Tree/Branch/Leaf relationship as 1 tree contains many branches, and 1 branch contains many trees. Your Tree/Branch diagram suggests to me that one or more branches aggregately contains a tree.
That out of the way, I agree with you that UML is very useful for software development, and beyond as well.
The containment as composition versus aggregation confuses many people. However, it’s not worth arguing about, because in most cases the implementation (at least in C++ and/or Java) will almost be identical regardless of the containment chosen. The container class will have an Array, Vector or some other container object that will hold the components being contained.
I think of composition as an integral part of something. It cannot exist separate from the container. So, in most cases the human heart would be composition.
I think of aggregation as a group of things being loosely grouped in containment. They can exist outside of containment. They can even be aggregated with more than one container at a time. So, a person’s car keys or jogging clothes would be aggregation. They’re attached to the person, but they aren’t a part of the person. The could also be in the dresser drawers.
In composition, actions of the container have an impact upon the component. So the act of jogging causes my heart to pump faster. It doesn’t affect my car keys or my jogging suit. This is called propagation.
In aggregation, actions of the container may or may not be passed to the component. It’s more optional.
In composition, the component has the ability to know its container. This doesn’t happen by default, but it can be set up that way. Therefore, the component can pass a request up to its parent. I don’t know of an official name for this, but I call it escalation, as in, “Please connect me with your supervisor.”
In aggregation, the component almost never has any knowledge of its component. In fact, it probably doesn’t even know that it’s part of an aggregate. Since it can also be part of several aggregates, it can’t pass requests to its container, since there could be more than one.
In implementation, composition is often a Vector of objects. The aggregate is often a Vector of object pointers. Of course, these aren’t rules set in stone.
I was first exposed to *UML* when there was only OMT. I was taking a C++ course at work when the “Three Amigos” decided to get together, unify their methodologies into UML, and sell a bunch more books.
I’ve used class diagrams, use case diagrams, sequence diagrams and state diagrams.
I first saw the real power of class diagrams when I was a system tester. I was supposed to test a set of requirements that were all over the place talking about entities, mandatory entities, optional entities, switching entities, etc. I couldn’t keep all of the requirements in my head at the same time to comprehend the bigger picture.
Then one day, I realized that one of the requirements was describing a relationship between two concepts. I got out a piece of paper, and drew the two concepts as classes with the relationship between. I continued with all of the requirements, and after several iterations, I had a UML (technically OMT, since UML wasn’t out yet) representation of the entities that I was to test, and their relationships.
This class representation gave me just enough of a roadmap to place all of the requirements in context and see how they interacted with each other.
So, I see UML not only as a means of designing software, but I also see it as a means of documenting the relationship of the concepts documented in the requirements. Will a class diagram based upon the requirements be the design? No it won’t. But it may be a good starting point from which to understand the desired behavior and create the design.
Thanks for the insightful response.