"One MessageQueue can have any number of Message object"

Figure 1.16 Spaceman’s food dispenser

In this example, our spaceman has access to a food dispenser. Actors always connect to a boundary class. A dietician creates his main course from meat and vegetable substitutes, and the spaceman, lucky fellow, is allowed to choose which fruit he wants from his fruit bowl. It’s not real fruit, which would deteriorate over the five years he is in space, but there are three fruit definitions, all derived (inheriting) from a base class of fruit. UML uses quite a few line and arrow types, all with specific definitions. We shall look at other line and arrow types shortly.

These simple class diagrams are fairly easy to produce, and not too difficult to understand. Getting it right at this stage makes finalising object oriented designs far easier, as the high level view without properties and functions means you do not get lost in the detail. Displaying them in this format means you have a good foundation upon which to build the detail, and a good picture to use in early discussions with designers and developers.

I believe all diagrams should be able to fit on one page of printed paper. Any fitting together of pages or searching for a larger printer is a fruitless activity. An A3 diagram (like a Business Analyst’s magnificent flowchart) is usually impossible to understand without some serious study. It is far better to create one skeleton diagram and a series of more detailed diagrams each representing a bone. Unfortunately, many become lost in their works of art, and spend so much time on them that they begin to understand them. What is worse, this creates a false belief that others will have their immediate insight into the odd shaped boxes and decision flows. We should be eternally grateful to the UML creators for their foresight not to use the flowchart symbols.

Class diagrams are very useful design diagrams, representing specific implementations. They can also become works of art. Beware.

Figure 1.17 A class diagram for the Apple class

Figure 1.17 shows a more detailed representation of a class. It is quite straightforward, having three public properties and one private property. The class name is Apple. SkinColour is an RGB value, Juiciness is measured in the Standard Juiciness Number, the Variety is a string, and the Worms collection is private. You won’t know about them until you take a bite. You could say the same about some software.

It’s not a very good class, as classes go. Let’s try a little harder.

Figure 1.18 A better model of an apple

The apple now derives quite a lot from its base class of fruit. Not only does it have properties, but it is able to rot too. Calling the apple.rot() function could decrease its Freshness. It may also decrease the size slightly. The apple class itself has only two properties and one object. The object Worms does not have to exist, as an apple can contain either 0 or 1 Worms collections. The Worms collection has no properties of its own, but contains 0 or more worm objects. Worms can be added to the apple, or removed, or counted. Every property in this set of classes is public, and shown with a +. You will know about the worms before you take a bite.

Figure 1.19 A fruitier fruit model

Figure 1.19 shows a fruit with a private freshness property. However, you can derive its freshness by using its smell and look functions. Anyone can look at the fruit as it is a public function, but you may only smell it if you are a friend.

Here are two examples showing the relationship between a teacher and her students, and a pentagon and its sides.

Figure 1.20 Teacher and student

The teacher teaches between 2 and 25 students. The name of the association is teaches, and direction shows that it is the teacher doing the teaching. An opposite arrow could show the students learning from the teacher, but that is not always the case.

Figure 1.21 A pentagon and its sides

The cardinality shows one pentagon has exactly five sides. Also we see that the sides are ordered, and that the pentagon is composed of its sides. The black diamond is a composition sign, declaring that the pentagon is made of sides, and that the sides are contained within the pentagon.

Figure 1.22 A class qualifier

This shows the relationship between train journeys and ticket sales. The train journey class has a qualifier of seat number and departure time, for which either no ticket or one ticket can be sold. The classifiers can be used as keys in data structures or databases.

You may also define associations between classes when they are not specifically defined in the class relationships. To do so, the normal class relationship is stated, then the associated class is shown connected to the connector which states the relationship between the associated classes.

Figure 1.23 A reservation class shown as an association to the sales relationship of train journey and ticket.

Let’s take a look at the relationships we can show in a class diagram. Most of these connectors or more correctlyassociations are not confined to the class diagram and are used in most of the diagram types. The last two are not used in class diagrams, but are included here as a reference of all the UML association types.

Figure 1.24 Connector types in UML

These connectors represent object oriented concepts. I expect anyone developing software today uses at least a few object oriented methods, so at least a few of the connections will be familiar. Some of these concepts are discussed further below.

Dependency and interfaces

Figure 1.25 - Interface dependency

Figure 1.25 shows class B is dependent upon the DataOut interface of class A. This means class B uses the DataOut interface of Class A to provide it with some information, and is unlikely to operate properly without it.

Realisation

If a class is a realisation of another class, then it fully implements its behaviour, but does not inherit (unless specifically stated) its structure or interface. The behaviour must be coded in the realised class.

Composition and aggregation

These two terms mean different things to different people. Both terms allow a class to be made up from a number of other classes.

Figure 1.26 A dog class made up of other classes

In both aggregation (shown in figure 1.26) and composition (solid black diamonds rather than the outlined diamonds), the dog class is made up of a head, a body, the legs and a tail. If you kill a dog made by aggregation, the head, body, legs and tail live on and can be attached to another dog. Killing a dog made by composition would be killing the parts too. Frankenstein believed we were made by aggregation and could be reassembled and kick-started with a few good shots of electricity. And so have we proved, that as long as we work on the interface with anti-rejection drugs, we can supplant organs from dead (or live) donors into others.

Class diagrams may contain many other constructs. Some of them are very useful shortcuts for defining relationships. Too often, information discovered about the system being modelled is written up in paragraphs, where a little extra work on the class diagram can state relationships exactly.

In the following class diagram we see a business entity called a group which is made up of practices. The practices themselves are an aggregation of practices, i.e. a practice can contain other practices. As it is an aggregation, the practices do not rely on the parent practice for their existence, and can be moved to another parent practice if desired. Such a practice hierarchy is usually implemented as a linked list where each practice is linked to a parent. Those with no parent will be the top level practices in the group.

Figure 1.27 Class diagram example

The cardinality attached to this aggregation means a practice may or may not contain child practices, and also may or may not have a parent practice.

The relationships between practice and employee shows that a practice has one or more members. It shows how a practice can have no manager (if the last one left and has not been replaced), one manager (as is normal), or two managers, in the rare case of joint heads of practice. Manager is identified as a subset of member, implying that a manager is also a member, and defined as a {subset} of member.

This model states relationships quite succinctly. It states a manager must be a member of the practice, and a member may or may not be a manager. It also shows the relationship between practices and their children are specified, or keyed, by the property PracticeID

That’s quite enough on class diagrams for now. The only way to get the hang of them is to model with them.

Class diagrams, as you have no doubt realised, are extremely rich in the methods available to define their properties and relationships.

UML 5. Object Diagram

An object is the instantiation of a class, i.e. it is the object created from the class at runtime. Object diagrams are similar to class diagrams, except the object name and class they are instantiated from are underlined.

Each object is given a name, and this name will be used as the object’s definition when writing code. As a simple example, consider this:

Figure 1.28 Deefer Dog

Here is an object instantiated from the class Dog. The name of the Dog object is Deefer. Its properties and functions are defined by the Dog class.

The differences between modelling a class and modelling an object are shown in figure 1.29

figure 1.29 Examples of classes and objects

A class contains a class name, properties and functions. An object shows the class name it is instantiated from preceded by a colon (:), then optionally preceded by the object name. The class in a class diagram displays properties and functions, whereas the object in an object diagram shows only properties, along with their values at the moment of interest to the modeller or viewer.

Figure x.xx shows a snapshot of the data in a system used in vehicle collision detection. There are two objects of the class car, named according to their registration numbers. A road object, named as Route 66, is included in the calculation. The CollisionDetector class is not named, as that piece of information is superfluous to the model.

Figure 1.30 Object diagram for traffic warning system

The CollisionDetector object has knowledge of the two cars. The condition of the road can be ascertained by passing in the coordinates of the likely passing point to the two functions in the road object. The cars are approaching each other with a relative speed of around 200 kph. They are not quite in a head on collision, but are not far off.. The collision detector calculation may ascertain that the two cars have only a 0.01% chance of colliding based on past data, and that only a slow down warning might be given. In the past, the slow down warning has prevented all collisions on this particular stretch of Route 66.

You may be presenting a normal operational examples, or critical information for use in testing the system. Perhaps this is the limit for an amber warning, and any vehicles travelling faster, or travelling on a more dangerous stretch of road or in worse conditions, will require a red warning.

Similarly, object diagrams can be used to demonstrate data which leads to state transitions, and in complex systems a series of examples may be required, specifying the conditions for a state change in the required warning.

Object diagrams can also be used as organisational charts.

Figure 1.31 Organisational chart with data

UML 6. Collaboration Diagram

In the first object diagram, the Dog class was instantiated as an object named Deefer. In the CollisionDetection class, it was not shown instantiated. It is not always necessary to define the name of the object, if only one object of that type will exist, or the context is such that it requires no declared object to fully explain the model. Similarly, collaboration diagrams may contain declared or implied objects.

Figure 1.32 Messages in a collaboration diagram

In collaboration diagrams, messages are shown as a sequence defined by a number and colon. Our singer Guy Greenfield first sings to the audience, then the audience applauds. Another arrow could be added in the vicinity of 1: to show Guy’s response to the audience’s applause - 3: Bow. The Audience class is undefined. Whenever Guy sings, they applaud. When they applaud, he bows. It’s a monotonous life. He’s thinking of opening a café somewhere where there are yachts, where clouds are always sparse and fluffy and the sun shines all day long…

Here is a story about two dogs called Doggay and Dogbee.

Figure 1.33 Dog and bone man

Wow, that was quite a story. I wonder what happened when Doggay caught up to Dogbee after his master telling him off?

Such a brief collaboration diagram containing four objects probably takes up around the same page space as a narrative. More complex diagrams are likely to take up less space than an equivalent narrative, and also be more quickly understood as they are specific. Narratives can be ambiguous. Objects in the story can also be positioned on the diagram to imply some kind of group or relationship, and that is the main reason for using collaboration diagrams. You can reflect the messages passing around an organisation or system by the proximity of those objects on the diagram. Collaboration diagrams are highly related to our next diagram type.

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
Facade	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 Resp.	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

source - http://www.dofactory.com/Patterns/Patterns.aspx

JavaScript Design 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
Facade	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 Resp.	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