Last night I went to a talk by Peter Coad, author of a new book "Java Modelling in Colour with UML". Peter Coad definitely comes across as a Nerd. The way he dressers, combs his hair and holds his hands. Like most of the successful gurus however he is a bit of a rebel when it comes to going against normal development practices and is always trying wacky new ideas - something his customers have to put up with. He is on a promotional tour for this new book and his publisher pays for his time so the talk was free and hosted by BCS (British Computer Society).
He started his talk saying that several years ago he was experimenting with colour in his models. He tried making all classes related to a time period/interval one colour and was amazed to see stripes of colour through the model. He then coloured some other grouping of classes and saw stripes of that. Customers would ask him questions like "How can you model without using colour?". What was originally just an experiment became increasingly useful and interesting.
He has a massive amount of experience modeling problems from lots of different problem domains.
One of the things he enjoys about modelling is being "on the other side of the counter". A business always looks different when you running the business. For example working in the pharmaceuticals industry, your system must be able to work out which countries you can still sell this batch of drugs in since the manufacturing process was faulty for that batch. So you need to store the intended ingredients, times, temperatures and then actual ingredients, times and temperatures (This gives 2 sets of pink which will be explained below). Another example is in the insurance industry. When calculating a quote, you look at the market rate and the value for this specific customer and choose the highest.
Ok so what’s the book all about? The basic idea is to have archetypes. An archetype is used where something is sort of like something else. There are 4 archetypes and therefore 4 colours (All books on colour theory say humans can really only handle 3 may be 4 colours so he stuck to 4).
These are: -
| Colour |
Type |
Example |
| Yellow |
Roles |
Customer, Sales Person, Clerk and Administrator |
| Pink |
Moment/Interval |
A moment in time such as purchase, order, rugby game, transaction |
| Blue |
Description |
Catalogue type attributes: width, wing span, height, weight are made available on one of these |
| Green |
Party/Place/Thing |
Client, Store room, Client site, Bank, Account, Petrol Tank |
Pink (Moments) and Yellow (Role) tend to have the most interest from a business rules point of view.
Always remember the standard modeling concept of one person may have more than one ‘hat’ or role. I may use the system as an "administrator", "a user" and "a service technician". That’s one green, 3 yellows. [This concept and the concept of a Party being either a person or a company comes from Martin Fowlers analysis patterns book.]
With the colours you get a level of understanding above the details. Most business systems have lots of pinks (time intervals) and yellows (roles), telecomms/engineering systems have lots of greens (things).
Pinks normally have a quantity associated with then, like how much cola was bought, how much money was bet, how much of a particular share was bought. If you want to have a grouping/drill down for example reporting by country, region, sales person you tend to have lots of greens next to each other. If you don’t need a particular level of detail the normal pattern of
pink - yellow - green - blue
is broken, say yellow (role) gives no advantage, your get :
pink - green - blue
When choosing the colour (archetype) he uses a VERY IMPORTANT process of elimination. Start with a pink, that is "a moment in time" and add the classes around it. To identify a class’s type ask:
- Is it a moment in time - Its Pink
- Is it a role played - Its Yellow
- Is it a catalogue-entry-like description - Its blue
- Otherwise its a party, place or thing and therefore green.
This avoids the problem many have of ending up with lots of greens.
Industry Tip:
If you have difficulty choosing the name for a class, you should ask whether you have domain experts in the room - Its pointless trying to do the modelling (analysis) without the domain experts.
He showed us this one diagram of with 3 green classes - a Party, aPlace and aThing, linked together by yellow "role" classes, and pink "moment/intervals" and said that this diagram was an accumulation of 10 years of work. Later during the modelling workshop we noticed how similar our design was to this summary diagram.
The above mentioned diagram showed an interface called "a plug in point" attached to description and moment. When asked about the "plug in point" he said it was just a specific use of the strategy pattern (see GOF Patterns book). Its basically an interface so that your other classes interact with the interface rather that the class allowing your code to handle changes more easily - Basically decoupling. His point was that you do not what to have "plug in point"’s everywhere - There is an overhead in creating them and so you only put them in places where things are going to change.
He is an Electronic engineer and I liked his analogy, "When you are designing a circuit board you don’t have IC(chip) socket for every single IC, it costs too much. You just have them where you think changes will occur". Its the same thing with a software design, you need to look at where most of the changes are going to occur and cater for it. This is rather like Bruce Eckel's vector of change statement from "Thinking in Java".
During the workshop I found that Peters suggested methodology of starting with the pink (a moment/interval) for example: order, purchase or delivery and then moving on to roles and things encourages composition over inheritance. This is really great because one of the traps inexperienced modellers fall into is using too much inheritance. Composition is very powerful.
The question I asked him was "People often get confused and don’t draw a clear distinction between analysis, design and implementation views of the model. Did he agree with this separation of the views and how do you deal with the level of detail required in the implementation model?"
He said that he lives in a world where the model is used to generate the code and then is reverse engineered after development work to update the model - (That is what TogetherJ does and why I asked him the question). His point was that yes you do have different views of the model and the new version of TogetherJ allows you to create custom filters with regular expressions to control what appears in a particular view. So a view for the domain experts could just have the class names and public methods with everything else filtered out. The regular expressions can even be used to change the colours of the attributes/methods on a class where for example the first character is a ‘p’.
In the book and available for download are examples from lots of different problem domains - (Its so much easier to understand an example if its from your domain).
Chapter 1 of the book is also available on the site, which explains the whole "plug in point" issue.
Chapter 6 of the book is all about process and delivering frequent tangible results (every 2 weeks). It contains some wacky ideas on how to do project management using a "parking lot" instead of a gantt chart and lots of colour.
"Java Modeling in Colour with UML".
I must say the name of the book doesn’t make me want to buy it - Sounds sort of like "Basic modelling for dummies with crayons" - but at the end of the talk I enthusiastically shelled out 36 pounds.
The reviews on amazon are very mixed. The ratings are either being a 1 or 5 star. After paging through the book I can understand how some of the reviews are a one star. The entire essence of the book is in chapter 1, chapters 2-5, contain examples and chapter 6 is about FDD (See below).
However the most accurate comment I found was:
david@uidesign.net from Dublin, Ireland , June 24, 1999
"5 star: A revolutionary book which will change how you think!"
"This book claims to teach you how to produce better models, faster - and it does!"
"I went for a job interview. The interviewer asked me to model a payroll system and gave me an hour to work it out while he observed. So I built a model using pink moment-intervals, yellow roles, green things, and blue descriptions—classes, attributes, links, methods, interactions. After 25 minutes the interviewer stopped me, saying I had already gone well beyond what others struggle to do in a full hour! So my recommendation is: read this book! It’s made me, a better modeler and I’m sure it will do the same for you".
"Another great innovation in this book, is Feature Driven Development. Its been used on a huge Java project. I am currently trying it on a medium sized eCommerce project which is Object-Relational and uses Java and PL/SQL and it works equally well".
"The key to FDD is that it is a low overhead method which was designed by developers for development. It scales easily from large to small projects, in a remarkably linear fashion, whilst providing the finest grained and most accurate project tracking and reporting that I have ever seen in almost 18 years in the business".
My suggestion is that you read these reviews and download the electronic version of chapter 1 and a set of 61 example models from before buying this book. Don’t underestimate the power of this technique even if it does feel a little like being back at nursery school.
When companies are small they are successful because of heroes. These are the handful of people that keep the company going and as the organisation grows, the ratio of heroes to other reduces and the company must start to document processes - So that any person can do the heroes work.
To me having "director" in your title used to mean powerful person but I have come to realize that you don't get to be a director without screwing some people over. In fact I have realized that if you want to be a director you need to pass though a passage of fire - the passage involves you firing someone. Travel though this passage properly it helps to fire someone who it is very painful to fire - maximum pain - this will guarantee your future success.
