Haim Kilov
Cutter Consortium, Executive Report, Vol.5, No. 1, 2002
Haim Kilov
Cutter Consortium, Executive Report, Vol.5, No. 1, 2002
It is a measure of the pervasive power of UML that doughty advocates of other notations and methods, such as Ian Graham and Haim Kilov should succumb to its temptations. This report is in one way a traditional plea from Kilov for more precision and formality in business process modelling: something in line with his consultancy and life's work. But it is also a clear recognition that the message, if it is to be heard at all, must now be phrased in the lingua franca of modelling. For it is not only for software or even for system models that the UML is becoming the de facto common language: its reach is visibly extending to the boardroom as well.
There is in fact one example of a traditional Kilov Object Relationship Diagram in this report; but it is at once followed by its equivalent in UML, represented as a class hierarchy. Kilov is careful to argue the semantics of the UML subtype relationship (there is a triangular arrowhead pointing up to the parent class): he requires it to mean exclusive and exhaustive subtyping, which is not necessarily what everyone would assume - experts notoriously disagree about UML's semantics. Similarly, he makes use of the UML composition relationship (the one with the diamond attached to the parent class box) to define his own stereotypes for 'assembly', 'ordered', 'hierarchical' and the like, without noticeable change to the meaning of his models.
The core message of the report is simply that modelling with vague tools like box-and-stick diagrams is pretty risky, even if they result in what Kilov mockingly brands 'beautiful graphics'. Equally, modelling by example (as with concrete scenarios) or by analogy (as with the use of terms borrowed from other fields) is dangerously loose. Kilov objects explicitly to the use of natural language, quoting Dijkstra to this effect, though he accepts that
"If we look at the language of the offers and contracts we deal with, we see that they are formulated in a very stylized English or 'legalese' for the purpose of achieving clarity and precision. Anything 'more natural' or colloquial would be too imprecise and ambiguous".
There is something to be said for this -- use very careful English combined with accurate diagrams with definite meanings. We have all seen waffly reports and useless diagrams. It is certainly a more attractive and practical option than attempting to define everything in models, as the discredited use of Dataflow diagrams to specify processes and systems shows.
There is much in this short report to agree with. Although it is in a way sad that much of the diversity and richness of visual language should be dying out, it is going to be far easier for engineers from different disciplines to share models if they are all expressed in the same language. I think we should welcome the use of UML for business models.
Business modellers new to UML, and/or unused to describing processes precisely, may well find this report both eye-opening and a friendly and helpful introduction to the subject. Kilov's book 'Business Specifications' of course provides much more detail; I do not think anyone who had studied this report would find the book's use of Kilov's now old notation at all difficult, and it would form a useful exercise for readers to translate some of the diagrams into UML using their favourite modelling tool.
© Ian Alexander 2002