This review is included courtesy the CBDi Forum. If you are interested in components, take a look at www.cbdiforum.com for many related book reviews, plus a continuous news service, concept reports and analytical reports and more.


Book Review - UML Components

A Simple Process for Specifying Component-Based Software by John Cheesman and John Daniels

The Unified Modeling Language (UML) is a standard, universally accepted Object Oriented Modeling Language; there are no pretenders to the throne. Yet, whilst widely accepted, the UML is not universally adopted. There are some important reasons for this dichotomy. First the majority of application development projects still do not use formal modeling techniques. Perhaps because they are insufficiently complex or large enough to warrant the perceived overhead; perhaps because OO "analysis" remains for many a black art which is synonymous with project risk. The second reason might be because, as we have been saying for years, the UML is incomplete in its support for components.

"Now wait a minute," I can hear you saying, "no support for components!" "Surely in today's Java, COM and CORBA centric world, that must be incorrect". I'm afraid not. The truth is that the world embraced UML as an OO modeling standard just at the time that components were starting to move into the mainstream, but before there was widespread acceptance that components and objects were not competing concepts. The UML language supports components as implementation concepts, but provides no explicit support for the all important aspects of specification.

Cheesman and Daniels assert as indeed we have, that it is essential to consider components at an architectural and business analysis level. It is only in this way that the natural structures of the business can be reflected in the supporting information systems. In contrast the UML sidelines any consideration of components until considering the detail design and packaging.

In this book Cheesman and Daniels have addressed this issue head on. They describe how to architect and specify enterprise-scale, component-based systems using the UML. The book commences with a detailed explanation of the basic principles of software components and component based development, in a manner that establishes a precise set of foundational definitions that are essential before approaching the remainder of the book. They explain that components adopt the principles of object orientation but extend these (unification of data and function, encapsulation, identity) by strengthening the role of the interface and separating the component specification.

The scope of the book is sensibly mapped to the RUP (Rational Unified Process), as it is, perhaps perversely in light of its lack of support for components, becoming a de facto standard. The entire RUP management process and the requirements, test and deployment workflows with the exception of some minor workflows correspond directly to the book. However the book's specification, provisioning and assembly workflows effectively replace the RUP analysis, design and implementation workflows. This huge gap of course speaks volumes about the RUP!

The core of the book is the chapter Applying UML in which the authors provide precise and detailed guidance on how to extend and customize the UML. This guidance commences with techniques for using stereotyping and then introduces a new set of diagrams listed in Table 1.

 

Diagram Brief Description
Business Concept Model Diagram The conceptual model of the information that exists in the problem domain
Interface Specification Diagram Precise definition for provider and consumer components actions: includes the interface type; its information model; operation specifications; invariants
Business Type Model Diagram A class diagram modeling precisely the information that is relevant to scope
Component Specification Diagram A stereotype of class providing the building block of component architecture defining interfaces and dependencies.
Component Architecture Diagram The contextual diagram of the component architecture
Interface Responsibility Diagram Class diagram depicting the business type model augmented with business interfaces and rules
Component Interaction Diagram Collaboration diagram applied to the interaction between component objects

Table 1 - New UML Based Diagrams

In addition to the new diagrams the same chapter discusses how core UML diagrams such as the Use Case are used in the context of components. The body of the book then describes the use of the approach using a case study throughout requirements definition, component identification, component interaction, component specification plus provisioning and assembly. The process descriptions are strongly example based and provide practical guidance.

Cheesman and Daniels are authoritative in this field and this book is the result of many years at the heart of component based development thinking and practice. John Daniels is one of the pioneers of object oriented concepts and practices. He developed the Syntropy method together with Steve Cook, which might be regarded as a progenitor of later methods such as Catalysis. John Cheesman worked on the Microsoft Repository Open Information Model (OIM) in the mid 1990's; he worked with Desmond D'Souza and Alan Cameron Wills on the Catalysis meta model and has been a direct contributor to a comprehensive method for component based development while he was with Sterling Software nee Texas Instruments Software.

This book could easily have been an academic treatise. The task of "merely" creating a coherent component based language predicated on compromise with the pre-existing UML must have been sufficient challenge. However to Cheesman and Daniels considerable credit they have delivered a practical handbook that is eminently approachable. This is a practitioner's handbook that provides answers to difficult questions that we have been searching for some considerable time. It is certainly not over optimistic to anticipate that many of the concepts articulated in this book will in time be integrated into the UML standard and of course properly supported by development and repository tools. See my report on higher order standards dated January 2001 for more insight on this matter1.

We have commented before that it is deeply regrettable that in the rush to adopt Java (and now C#), analysis and component specification has commonly become a programming task. This is in no small measure due to the widespread misunderstanding that a component is an implementation artifact, which has been the message propagated by object specialists everywhere and confirmed as a standard by the UML. This book is a breath of fresh air, providing both convincing arguments together with the necessary detail to persuade practitioners that components are different to objects and that without specification and architecture Java is just another programming language.

This is a seminal work that we expect to exert considerable influence in the industry over the next few years. The book is essential reading for project managers, architects, business analysts, application analysts, designers, Java, C++ and C# programmers, who will find it invaluable as practical guidance in support of higher quality and more adaptable business software applications.

David Sprott david.sprott@cbdiforum.com

UML Components - A Simple Process for Specifying Component-Based Software
by John Cheesman and John Daniels
Foreword by Clemens Szyperski

Copyright (c) 2001 Addison Wesley
ISBN 0-201-70851-5

  1. Higher Order Component Standards Starting to Emerge?
    A report on important initiatives that at long last should deliver standardization of key component concepts. INTERACT 2001 http://www.cbdiforum.com/secure/interact/2001-01/highorder.php3