Chapter 1 - Modelling

Architects and software architects

Journals of software architecture haven’t caught on in the same way as architecture journals, for the simple reason that you cannot see the end product. The architect, on completion of his work, can show someone around, pointing at his cleverly designed features and enthusing at his use of materials. The architect and the viewer share the same carpet, walk on similar legs, and look with similar eyes. They can sit, at the end of the day, on a far hillock, and watch the sun sink behind the magnificently realised edifice of their creation.

Far away, or close up, the viewer with no knowledge of architecture can appreciate the architect’s work. In a software system, there is nothing to see except a few dusty servers and some rather quirky looking screens.

We will never have those moments that architects share with their clients on completion of their work, because there is very little to appreciate. If it works, then that’s what was expected. The internal architecture, regardless of its skilful insight and execution, means little.

This lack of joint understanding has created a gaping rift in the fabric of relationship between software developers and their sponsors. Each are apprehensive of communicating with the other, because both are blind in each other’s world. There is no common ground on which we can meet and discuss what we are doing. We do not yet have the wealth of historical communication, nor the similar views, that the architect and his client enjoy.

Consider this: When a bridge disaster occurs, the architectural experts (technical) explain why. When a plane falls out of the sky, expert engineers and designers (technical) explain why. When the spacecraft fails, the NASA scientists (technical) explain what went wrong. When an IT system fails, management (non-technical) explains why. Why?

It is because they are scared to ask us. They won’t understand what we’re talking about. We live in a different world. We are defined by our nerdy stereotype, unable to step beyond it. The unwritten rule is don’t go asking a techie to communicate, at least not in IT.

We need to change. We need to change the way we approach our work. We need to change how we communicate with others. We need to change our personalities, and most of all we need the change to be appreciated.

To begin, we learn how to model. Our models communicate, just as an architect’s models communicate. Perhaps ours are a little more energetic, but at least we will have representations that others might begin to comprehend.

When the architects began modelling, there were lots of different methods available to them. There was sketching, building wooden models, drawing plan and elevation views, carving models from clay, building them from matchsticks, drawing perspectives. I’m sure you could add a few more. Nowadays, a plan, elevation and perspective might look commonplace. They probably didn’t then. Similarly our modelling method may appear a little strange, but it works, and it will improve and gain wider acceptance over time.

Architects’ models let people appreciate their intentions. Software architects, by modelling, will begin to change the landscape upon which we walk.

It is time to begin.

Modelling

As a software architect, you will be required to work at one or more levels of abstraction above code. Your work will be used in communication with others in your development teams, customers or external partners in your project. Blobs and lines are OK for many diagrams, but they do have their limitations. The greatest objection to blob and line drawings is that they are not defined by a standard. A blob and line to you may mean ‘install this here’, but your sponsor will see only a blob, a line and bit of text.

Fortunately, the software industry has compiled its best modelling ideas into the Unified Modelling Language (UML), now standardised by the Object Modelling Group (OMG – www.omg.org). It is a collection of nine standardised modelling techniques and is used throughout this book.

This chapter is a primer for the UML, and introduces the core aspects of its diagrams. UML is a rich modelling environment, and there are features beyond what is mentioned here.

UML 1. Use Case Diagram

If you have not yet come across the term use case, think of it as something a system does. For example, a drinks dispensing machine probably has a single use case: dispense drink. A machine to supply train timetables and provide tickets probably has two use cases:

Use Case 1: Provide timetable information

Use Case 2: Sell train ticket

A software system will typically have somewhere between one and ten use cases.

Ivar Jacobsen, who first coined the term use case defines it as:

A behaviourally related sequence of interactions performed by an actor in a dialogue with the system to provide some measurable value to the actor.[1]

The UML use case diagram presents the use cases of a system and shows the actors with whom they interact. It also displays the boundary of the system within which the use cases operate. No further detail is required.

Figure 1.1 The format of a Use Case Diagram

An actor is an external system. It could be a person who is using an application, or a timer set to regularly perform a task. It could also be a thermometer from which the application is reading the temperature, or a thermostat used to control the temperature. It may seem a little odd representing a thermometer as what is obviously a stick man. Feel free to draw a thermometer if you can. I don’t think it will hurt.

The environment is usually a software application or a software and hardware system such as an ATM or mobile phone. All use cases are contained within the environment, and all actors are external.

Figure 1.2 A Use Case Diagram

Figure 1.2 displays a library member accessing a library’s internet portal. The use cases show that the library member logs in, and is able to view and order books.

Figure 1.3 Use case diagram for a residential heating system

In this rather complex use case diagram, we see a note in the top left corner. Notes are represented by a dog-eared rectangle and can be used on any type of UML diagram to add pertinent information. In the actors we see a janitor actor and a resident actor who inherits all of the janitor’s rights to the heating system. Both the resident and the janitor can use the thermostat, but only the resident can control the automatic timer. The heating system in this diagram is shown as an actor, yet it could also be represented by a collection of use cases in another system. For this project, the heating system is external and we are not concerned with how it works, only that we must provide an interface to it. The relationship between the automatic timer and the heat controller is that the automatic timer uses the heat controller. Had the arrow been on the other end, then the heat controller would use the automatic timer. These are largely academic points at present. A use case diagram is not used for creating code. It is used to communicate a high level view of the nuggets of work a system will do, and the actors it will do it for, or rely on.

From this view, the automatic timer is portrayed as a piece of software which may be controlled. If it was a hardware timer, then it would be presented as an actor rather than a use case. Timers often present this problem as they can be internal use cases or external actors. It is usually fairly obvious how to model other system objects.

The text contained within double chevrons or guillemots, e.g. «uses» is known as a stereotype of generalisation. They are used to define relationships between use cases. The use case diagram allows for «uses», «includes» and «extends». As you can see from the actors in figure 1.3, actors can also «inherit» the behaviour of others, though some claim this is taking the use case diagram too far.

It is unlikely that you will create such complicated use case diagrams, yet the mechanisms are available to fully model complex systems should you wish to do so.

UML 2. Activity diagrams

Activity diagrams are similar to flowcharts. They are often used to model the paths though a use case.

The activity diagram has few features, unlike a flowchart, and is all the better for it. The beauty of activity and use case diagrams is that anyone can understand them almost at first sight. The rounded rectangle is the unit of work for this diagram. The black dot and black/white dot identify the start and end points of the activity.

Figure 1.4 Activity Diagram

Another feature of the activity diagram is a diamond, used as a conditional branch. Alternate paths through the activity should split at a branching diamond, and merge at another diamond, as shown in figure 1.5.

Figure 1.5 Activity diagram showing alternate paths using branch and merge

Figure 1.6 shows the use of synchronisation bars, and also displays a conditional path, travelled only if the video shop customer is a member of their bonus scheme. In this type of diagram, the conditional paths of a branch, or a conditional activity, are enclosed in square brackets, e.g. [member], [non-member] or a conditional path for [Bonus scheme member]s only.

Figure 1.6 Activity diagram showing synchronisation and a conditional path.

A feature of this diagram is the self referencing activity check out video. In this case, check out video returns to itself, so another video can be checked out before accepting payment. Here is a similar example, this time for keystrokes.

Figure 1.7 Activity diagram section showing a self referencing activity

The activity key stroke contains the processing of the key. Only a selected group of keys cause activity to move on to the next unit of work. Self references are often used in UML as a shorthand notation.

The following diagram shows the activity of dinner. It uses a modelling technique called swim lanes to describe how dinner takes place in both the kitchen and the dining room. Two swim lanes are shown, one for the kitchen and one for the dining room.

Dinner begins in the kitchen with hand washing, then ends up in the dining room with dinner served. One activity - wait for kids to arrive - shows how the self referencing unit of work implies the wait for the kids to arrive.

Figure 1.8 UML Activity diagram with swim lanes

Swim lanes are used often in business applications where certain activities belong to a specific business entity. For example, creating invoices belongs in accounts; taking an order belongs to sales, and filling the order belongs in the warehouse. They are all part of the sales order process, but accounts, sales and the warehouse could each have their own swim lane.

Figure 1.9 Noise sampler

A real time system for sampling noise may have swim lanes for the analogue to digital conversion, the frequency analysis (using a fast fourier transform or FFT), logging of the result, and its display. Sample noise would be a use case, the path through the use case would be sample noise, perform FFT, record results, display results. Each of these would be broken down into substeps, and assigned to a swim lane. In such a system, each swim lane would be a separate electronic device or set of components.

Notice the use of synchronisation bars to show how the sampler continues to sample data, while passing on the latest complete sample to another system for processing.

Part of the activity may include sending or receiving messages from another system, or another part of the system. It is not necessary to show this other system if it is not relevant to the model, as the UML activity toolbox includes symbols for messaging beyond the current model.

Figure 1.10 Activity diagram showing messages

Figure 1.9 shows an alternative to the use of swim lanes when a separate part of the system is not interesting enough to be included in the model. Instead, messages are sent out from the model, and messages are received.

Your models are not meant to be complete renditions of systems. They are meant to detail a specific aspect of the system for a specific viewer. Including external, uninteresting or obvious parts of the system will only confuse the viewer. You decide what to put in, and what to leave out. You are doing the modelling.

UML 3. State diagram

State diagrams, also known as state charts or state machines, show states and transitions between states for objects in response to internal or external stimuli. They were originally developed for modelling integrated circuits or other electronic devices. They are used to model objects with complex states, such as business objects, user interfaces, or objects used as controllers for other objects within an application.

Imagine placing an order for stationery over the telephone. The initial state of your order while you are creating it is incomplete. Its next state may be complete and awaiting payment. When payment arrives, it is in the ready to be picked state. The warehouse person takes your order, and it is in the picking state while they wander around the warehouse filling your bag, then the picked state. It sits in the picked state a while, then the person responsible for dispatch goes around the warehouse collecting the picked orders. It is now in the state of waiting for dispatch. When collected by the courier, it is with courier, then finally delivered. If this state is recorded and made public, you can track your order.

States may also exist within superstates. For example, the states to awaiting payment may be contained in Order with salesperson. Up to waiting for dispatch, may exist within order with warehouse. The final superstate would be order released.

Figure 1.11 Statechart for sales order showing superstates

Occasionally, the order doesn’t get to the delivered state. In that case, it remains with the courier until it is returned to the warehouse. The process for a returned order may itself have multiple states, such as returned, being reshelved and order cancelled.

The state diagram is visually similar to an activity diagram, except the activity diagram displays units of work, and the statechart models the states of a dynamically changing system. The dynamics of a user interface can be modelled using a state diagram, before the states are coded in a controller class.

The example in figure 1.12 is a simple modal dialog box with a text box and an OK button. Even this simple dialog has many different transitions between its states. For example, a user may click the text box with a pointing device, then press the tab key to get to the OK button and press the space bar to operate the OK button. This is just one of the many routes through the dialog. To model it effectively, all states and transitions between those states should be included.

Figure 1.12 Statechart for a dialog

If this statechart is a complete model of the dialog, you can see that once the button is reached, there is no going back. There is no route, i.e. state transition, away from the button other than activating it. You may decide that your dialog will be kinder to its user, and allow a click or Alt-T to take them back to the text box.

Declaring states and their transitions in a diagram this way can help the programmer to implement your model using a set of switch statements. All events on the dialog are routed through the switch statements, which act as filters for blocking illegal transitions. This makes it quite straightforward to manage complicated user interface rules, such as ‘you must fill in the text box before the button is enabled, or if this is user X on account Y, they must provide a reason of: Product out of stock, or Product unavailable.

Statecharts are often a necessity in our loosely coupled, object oriented world. They can save some severe headaches debugging user interfaces if the states and transitions are controlled by switch statements in a class separate to the user interface.

UML 4. Class diagrams

The class diagram is the most directly applied when it comes to coding. Most UML tools will generate a set of classes in many programming languages straight from the class diagram. They are not always complete, especially where collections or templates are concerned, but they can save a lot of repetitive typing.

Class diagrams are also the most complex, and certainly the most discussed when modelling object oriented concepts such as composition and aggregation. Hopefully, we can avoid such arguments for now and accept that class diagrams are able to model many object oriented, and even entity relationship particulars.

Class diagrams come in two basic flavours. The simplest uses class stereotypes, and the more complex details the member properties and functions of the classes. We shall begin with the class stereotypes.

Class acts

The class stereotypes are boundary, control and entity classes.

Figure 1.13 Boundary, Control and Entity classes

You may see these stereotypes used in other types of UML diagrams. They are useful for doing initial high level modelling, mapping out what objects a component might contain, and what relationships exist between them before specifying the class details.

Boundary classes are used to specify interfaces between systems, control classes are used as objects to control other class actions, and entity classes are typically data stores.

Figure 1.14 An example using boundary, control and entity classes

As I have been showing basic objects, I have allowed myself a booklist object, which will hold a collection of book objects. This is not strictly required as in a more detailed diagram, I might have defined the relationship between the objects book selector and book as in figure 1.14.

Figure 1.15 Class relationships

The relationship here is 1 to 0..n. It means one book selector is related to zero or more books. In reality, I know my database will only hold a certain number of books, such as 232, but 1 to 0..4294967296 is not usually required. The numbers defining the relationship are known as cardinality.

Cardinality can contain more than one item. For example, 1..4,6..n means any positive number except 0 and 5. Negative numbers are not used.

Figure 1.15 implies a collection is used, but the UML tools do not take the cardinality and create a collection holding zero or more books. Despite this, the cardinality notation is used as class diagrams begin to get cluttered when they contain collections.

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 correctly associations 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.

UML 7. Sequence Diagram

The collaboration diagram and sequence diagram are so highly interrelated that software tools can create one from the other. The information presented in each is exactly the same.

In a sequence diagram, the sequence begins at the top and ends at the bottom. It was a sequence diagram I used when presenting the software architect’s interactions in the introduction.

Figure 1.34 The format of a sequence diagram

In this sequence diagram, we see two objects and a message passed from object 1 to object 2.

Figure 1.35 Sequence diagram showing Doogay chasing Dogbee

Here, the class names are also shown, and Doggay is chasing Dogbee. Displaying the class names is optional, as in the object or collaboration diagrams, where they are included only if they are of interest to the viewer. In the next example, we see what did happen when Doggay caught up to Dogbee after his master's chiding.

Figure 1.36 What Doggay and Dogbee did later

Wasn’t that nice of them. You also know where the bone came from in the first place. I skipped a few interactions, but I’m sure you get the point. As: time proceeds from top to bottom in the sequence, there is no need to number the events as you have to in a collaboration diagram.

The large X at the base of the Bill :Buffalo column indicates the object is destroyed at that point. Bill :Buffalo creates (by decomposing) the bone object as it is destroyed.

The classes in your software system need to communicate with each other to fulfil their tasks. Both sequence diagrams and collaboration diagrams are known as interaction diagrams, as they display the interaction between objects. Sequence diagrams are clearer, but it is difficult to get many objects and interactions on the same page, whereas a collaboration diagram is far more densely packed. With them you can model messages between objects in an application, and also model messages between disparate systems, both synchronously and asynchronously.

In the next example, we use the class stereotypes. We see the creation of an apple object from the fruit class, and an asynchronous response where the requester may take his apple when he pleases.

Figure 1.37 Class stereotypes and asynchronous messages in a sequence diagram

Figure 1.38 shows the class stereotypes again, in sequence of events leading up to the death of a mosquito.

Figure 1.38 Sequence diagram with class stereotypes

UML 8. Component Diagram

Now we have all of the difficult methods out of the way, we are left with two rather simple ones. Both the component and deployment diagrams use similar constructs. The component diagram shows dependencies between components in a software system, and the deployment diagram shows the deployment and configuration of the components on physical nodes of the networked computer system.

Figure 1.39 Component diagram of a sales order processing and accounting system

Each component is drawn as a rectangle with two rectangles in the upper left corner. The various arrows used to define class relationships can also be used in component diagrams. In the diagram above, the database is shown as a component, as are the main applications of the system, i.e. Sales application and Accounting application. Both these and the data access component, are composed of sub components, whereas the database is considered a black box.

UML 9. Deployment Diagram

The deployment diagram is used to show the distribution of components, typically across a multi-tier system or the deployment of components around a heterogeneous environment.

Figure 1.40 Multi-tier deployment

In this diagram, we can see a multitier system comprising of a client with a web browser and a widget. The widget connects to the KoolTool application on the web server. This, in turn, accesses information directly from the document server, and from the Kool database via a tier of components on a component server. Kooltool has been written as a set of business objects which communicate with the database through a common data access component.

There is nothing startling in this deployment diagram, which is how it should be. If there are complex interactions within the layers, they are best presented in another diagram, or more correctly in a component diagram. Deployment diagrams are intended for deployment and should be quite clear.

Figure 1.41 Heterogeneous environment for the survival suite

This deployment across a heterogenous environment simply shows which chunk of information sits on which server, and what the servers’ hardware configurations are.

Other UML Concepts

UML supports the concept of packages. They are loosely defined structures and look like a folder with a tab. Groups of objects can be shown in the folders, or they can appear on their own to show packages of applications. Most of the UML modelling relationships apply to them, so you can show dependencies etc. You can also use them in collaboration, object and class diagrams to display a higher level view than at the class level.

Figure 1.42 UML Packages showing dependencies

Layer diagrams and UML

Layer diagrams still haunt networking publications. They live on in approaches to business systems, yet there is no layer diagram in UML. Why not?

The weakness of layered diagrams is they are often ideals rather than reality. Some components always sneak across more than one layer, and drawing parts of the system straddling layers, or working across more than one layer soon becomes awkward.

Here is a typical layered design for a business system.

figure 1.43 layered design

Lets take a look at those layers drawn as a UML equivalent.

Figure 1.44 Layered development shown in a class diagram

This approach is far easer to draw and understand, especially where complex layered structures are being displayed. If you need layers and objects, it is simple enough to draw layers as packages or classes grouped together visually.

Figure 1.45 shows the Internet protocols mapped across the seven layer OSI networking model.

Mappings of other networking protocol stacks can be found in [2].

Figure 1.45 Internet prototcols compared to the OSI seven layer model

It is clear the internet does not sit happily across the seven layered OSI model. In fact, no networks do. Not even IBM’s SNA Server, upon which the OSI model was based. Figure 1.46 shows an implied layered design for the internet protocols without using a layered diagram.

Figure 1.46 Internet protocol layers displayed as packages in UML

UML Summary

The UML is made up of nine interrelated diagramming methods. Ideas can be traced between the diagram types, and all are directly applicable to (and have been designed for) modelling software. This does not mean you cannot model other systems with it. In the examples, I have used everyday objects and modelled them, so that the message I am portraying is clearer than if I had modelled a software system of which you had no experience.

The nine diagram types can be subdivided into static and dynamic diagrams where static diagrams model structure, and dynamic diagrams model behaviour.

Static UML diagrams


Use case diagram

Identify the units of work in a system, and the external actors it communicates with.

Class diagram

Displays classes showing their interfaces, static collaborations and relationships.

Object diagram

Shows data structures or snapshots of system data at times of interest.

Component diagram

Shows the components of a system and their relationships at a level of abstraction above the class diagram.

Deployment diagram

Shows physical nodes (computers), their relationships and the components installed on them.



Dynamic UML diagrams


Activity diagram

The flow of control of activities in a system or part of a system.

State diagram

Shows a dynamic view of the state of the system or part of a system.

Collaboration diagram

Shows the structural organisation of components and the interaction between them.

Sequence diagram

Shows messages between classes or components in time order.

The UML tour guide’s Parthian shot

UML is a rich language and this has been a whistle stop tour. There are other mechanisms and notations available in UML, but this is enough to be able to model. For more information on UML, see the references below. [3] and [4] were written by the architects of the UML, Grady Booch, James Rumbaugh and Ivar Jacobsen.

The ghost of modelling past

Many modelling notations have been superseded by UML. This includes the Booch method, OOSE and OMT, which were combined into the beginnings of UML. Other ghosts such as Data Flow Diagrams (DFDs) are still floating around, but sequence diagrams are far more useful, and have largely replaced them. It is up to us, as a community, to lay them to rest and unite with UML as our method of choice, and the method of our profession.

The future of UML

UML is a live modelling language and although it is no longer in its infancy, there are still modelling problems to address. Future versions may support business modelling and data modelling. At present, data modelling can be achieved using the class diagram, where each class represents a table in a database. Some UML tools will generate database generation scripts from the class diagrams, complete with primary and foreign keys, indexes, unique and null qualifications. This does not mean you should generate your table scripts from your class diagrams, as a 1:1 mapping between classes and tables will produce a lousy database.

Some believe the goal of UML is to specify software with sufficient detail that it can be compiled into applications. I do not know how that might be achieved, but it has already begun with class diagrams directly generating code. Whether it will ever become fully compilable is a matter for debate and will be for a long while. Modelling, and specifically UML, is a large part of the software architect’s arsenal; you will be better armed with it than without it.

The reality of UML and sponsors

Technically astute buyers are demanding software models in UML. This is likely to become more and more prevalent, and more the norm.

There are also, and will continue to be, buyers who are interested only in the resulting software and not in its internal mechanisms. These buyers when confronted with UML diagrams will switch off. They want, and should be presented with, colourful, high level blob and line pictures. Give them what they want.

A common term in software development is IKIWISI - I’ll know it when I see it. If they expect to see colourful blobs and lines and get UML, you will lose them.

Modelling folklore

In the meantime, you may bear in mind this light hearted comment which has almost grown into modelling folklore, and certainly quoted in every piece of modelling discussion:

All models are wrong
Some models are useful [5]

Wrong, they may be, but as Leonardo wrote:

Do not interfere with matters for the eye 
trying to get them in through the ears[6]

References

  1. The Unified Software Development Process, Ivar Jacobsen, Grady Booch, James Rumbaugh. Addison Wesley Object Technology Series. amazon.uk
  2. Network Essentials Study Guide, James Chellis, Charles Perkins and Matthew Strabe. Sybex.
  3. The Unified Modelling Language User Guide, Grady Booch, James Rumbaugh and Ivar Jacobsen. Addison Wesley Object Technology Series. amazon.uk
  4. The Unified Modelling Language Reference Manual, James Rumbaugh Ivar Jacobsen and Grady Booch. Addison Wesley Object Technology Series. amazon.uk
  5. George Box
  6. Trattato della Pittura, or Treatise on Painting. Leonardo da Vinci. amazon.uk