UML Components: A Simple Process for Specifying Component-Based Software (Paperback)

~ John Cheesman (Author), John Daniels (Author)

Editorial Reviews

Product Description

(Pearson Education) Applies Unified Modeling Language to the world of component architecture, demonstrating how it can be used to specify components, their interactions and their integration into cohesive systems. May be of interest to system architects, designers, programmers, and testers. Softcover.

From the Inside Flap

This book describes how to architect and specify enterprise-scale component-based systems.

It is a practical and technical book. The business benefits of a component-based approach to building systems have been well documented in many theoretical books and we don't repeat these. Our focus is on helping people move from the theory to the detailed reality.

It seems to us that people who want to take a model-based approach to the design and construction of enterprise-scale component-based software face two big problems. First, what tasks and techniques can they use that will both produce a good system and be compatible with whatever project management process is in use? Little has been written to date about processes that can support the construction of large component systems. Second, how should they use the wide range of notations and techniques found in the Unified Modeling Language (UML)? The UML has become the de facto standard for pretty much all application development modeling, but its application to component-based approaches isn't obvious.

If you flick through the pages it might seem to you that we've concentrated mainly on the second of these problems--there are lots of UML diagrams--but a deeper examination will show, we hope, that the primary emphasis is on explaining a simple process by which components can be identified and specified, and robust but flexible application architectures can be produced.

Of course, the full development process covers more than just specification; it covers all activities from requirement gathering to system deployment. But this book focuses on specification. It explains how to represent requirements in a way that will facilitate the construction of specifications, it shows how to create specifications, and it gives guidance on implementing the specifications in software. We make no apology for focusing on specification. The main challenge that a component approach can meet is dealing with change, but the substitutability of parts this requires can be achieved only if components are properly specified.

Underpinning the process are a set of principles and definitions that organize and structure our thinking about software components. We have found these ideas to be a great help, and we urge you to take the time to understand and appreciate them. You'll find them set out in Chapter 1.

Who Should Read This Book? We have written this book for practitioners--people who need to architect systems and specify components in UML today, using today's tools. We describe a clear process for moving from business requirements to system specifications and architectures. This will be helpful for those struggling with business-IT alignment in today's e-business world. The architecture pieces will assist those focusing on system architectures and assemblies, from city planning through detailed application architectures. The emphasis on unambiguous interface specification will be useful for those trying to establish software factories, those defining clear buy-and-build software policies, and those involved in application integration and legacy migration. It should also appeal to testing and validation teams.

We also think this book contains sufficient conceptual clarity and succinct explanations of techniques to make it of interest to both academics and educators. We certainly hope they will buy it.

How Best to Read This Book Start at page 1 and keep going. When you reach a page that's thicker than the rest and shiny on one side, you're done. Seriously though, this isn't a big book, and we think you'll get most from it if you read it all. We think it's all important, so we can't suggest sections to skip on first reading, although you might find it useful the first time through only to skim some of the detailed specification examples, especially in Chapter 7. In fact, we tried to write the kind of book we like to read ourselves--lean and mean, with no unnecessary asides to distract from the main message.

Having read it all once, however sketchily, you will probably want to dip in and out of particular chapters as you're dealing with specific issues on your projects.

If you want to dig deeper into the examples we have provided, you can find the full case study at umlcomponents.

Where Did These Ideas Come From? We'd like to think that the ideas in this book are all our own, but they're not. The component concepts and the process ideas we've used have been formed over a number of years and derive from a great many sources. We've relied heavily on the expertise of others who have struggled with--and solved, at least partially--related problems.

On John Cheesman's side the ideas come from his early work on the Microsoft Repository Open Information Model (OIM), in the mid-1990s; his work with Desmond D'Souza and Alan Cameron Wills on the Catalysis meta-model D'Souza99; UML, of course, to which he was a direct contributor; and Sterling Software's Advisor method for component-based development Advisor, developed mainly by John Dodd and itself influenced by Catalysis.

John Daniels is one of the pioneers of object-oriented concepts and practices. In the early 1990s he developed, together with Steve Cook, the Syntropy method Cook94. This work has been a forerunner and common ancestor of many of the later developments mentioned above, especially Catalysis. The UML's Object Constraint Language (OCL) is directly descended from Syntropy, and several ideas first seen in Syntropy have found their way into the UML.

Figure P.1, although inevitably a simplification, gives some insight into how the ideas have influenced each other. Of course each of these areas has its own set of influences, which we haven't shown, although OMT Rumbaugh91 and Bertrand Meyer's notions of design by contract Meyer00 deserve special mention.

We joined forces in 1999 to refine the concept models, tighten the process ideas, and align them with the workflows and terminology of the Rational Unified Process (RUP) Jacobson99. This book is the result.

Practical Experience We have greatly benefited from studying the experiences of the Sterling Software component-based development (CBD) Customer Advisory Board (CAB). This is a set of companies who have been developing enterprise-scale component-based applications since 1996 in a variety of vertical domains, from telecoms to transportation, and finance to manufacturing. At the time of writing, the CBD CAB has around one hundred member companies.

These companies have helped to separate what works in practice and has genuine, practical added value from what sounds good but is impractical on a real project. They've kept our feet firmly on the ground.

What works in practice is often a function of how well a particular process or technique is supported by application development tools. And it has to be said, most UML tools don't do a great job of supporting component-based development. We avoid references to specific tools in this book since we want it to have a broad appeal, and we try to keep as close to standard UML as we can, defining a relatively small set of extensions. But clearly, the better your tool of choice supports these concepts and processes, the more practical you will find them.

John Cheesman Surrey, England johnc@componentsource

John Daniels London, England [e-mail]

0201708515P04062001

See all Editorial Reviews

Product Details

• Paperback: 208 pages
• Publisher: Addison-Wesley Professional (October 28, 2000)
• Language: English
• ISBN-10: 0201708515
• ISBN-13: 978-0201708516
• Product Dimensions: 9.1 x 7.3 x 0.4 inches
• Shipping Weight: 12 ounces (View shipping rates and policies)
• Average Customer Review: 4.5 out of 5 stars  See all reviews (10 customer reviews)
• Amazon.com Sales Rank: #225,801 in Books (See Bestsellers in Books)

  Popular in this category: (What's this?)

  #34 in

  Books > Computers & Internet > Programming > Software Design, Testing & Engineering > UML

Customer Reviews

Most Helpful Customer Reviews

18 of 19 people found the following review helpful:

4.0 out of 5 stars Component Architects enjoy this feast!, January 21, 2001

By	Daniel Moth (Seattle, WA) - See all my reviews (REAL NAME)

Chapter 1 provides an excellent intro to defining what a component is. It also effectively establishes the language and terms that are used in the rest of the book.

The next chapter describes a development process including stages, activities within each stage and the inputs/outputs of each stage. The stages are: Requirements, Specification, Provisioning, Assembly, Test and Deployment. The focus of the book is the details of the Specification stage. We are shown what artefacts are created between substages of the specification stage and how to organise them in our UML tool. UML itself - or rather the subset to be used - is also described, along with a bunch of stereotypes together with the meaning of each (chapter 3).

At this stage, if you are thinking that you are interested in how to capture requirements for developing components OR that you would like to know the details of the `Provisioning' stage with detailed descriptions of how to map a design to both EJB and COM, you will be disappointed. The two areas just mentioned are only touched upon in chapter 4 and part of chapter 8. Also, if your UML tool is not flexible to cater for the various stereotypes and the means of organising them, then the material of the book will only satisfy academic interest. Academics will certainly be satisfied anyway, since the delivery of the various concepts is clean, thorough, complete and based on precise definitions firmly established with the reader (the presence of OCL and design by contract principles are no surprise).

The practitioners (mainly software architects) will only benefit if they do have the flexible UML tool and the development & management environment that they operate in is very component focused and appreciates the importance of specifying component interfaces to the nth degree. This development culture leaves the door open for reuse of the components in alternative environments than the one they were originally conceived for. It also contributes to the ability to evolve the component's implementation without ever disturbing the solid interfaces it exposes. If this is the environment you work in (or aspire to be part of), then you will find chapters 5-7 full of `gold' advice backed by a case study; they prescribe techniques for capturing and organising component identification, interaction and specification.

14 of 15 people found the following review helpful:

4.0 out of 5 stars Realistic exercise used to explain how components are used, January 2, 2002

By	Charles Ashbacher "([e-mail])" (Marion, Iowa United States([e-mail])) - See all my reviews (TOP 50 REVIEWER)    (VINE VOICE)

With few exceptions, and this is not one of them, in computing the word simple should only be applied with some form of relative-to qualification. The dream of creating interchangeable parts out of software has been a goal that first appeared on the horizon some time ago, but up to now, it has yet to make a complete appearance. The authors acknowledge that fact in chapter 8 and argue that with the availability and power of the Unified Modeling Language (UML) to standardize the design coupled with standards such as COM+ and Enterprise Java Beans (EJB) for the run-time side, it is about to happen. While these tools will no doubt accelerate the move to component reuse, the process of the increased adoption of components is more complicated than that.
However, in the arena of the specification of components software using the UML, this book has many positive attributes. There is no preamble or introduction to UML, for that you must use another resource.
This was a good decision on the part of the authors. Many people now know UML and there are several good resources available. Furthermore, the explanations are such that one knowledgeable in computing would quite likely be able to discern what is being described without detailed knowledge of UML.
As the authors stress, the set of steps that will turn a software segment into a component is not difficult to understand. The precise specification of what a component expects and what it is expected to do is the major task that needs to be addressed. A secondary, but necessary task is that the details of the implementation are not part of the component specification, for if they were, then it would violate the concept of interchangeable parts. The basic structures of a design by contract are described using the Object Constraint Language (OCL). It is not necessary to know OCL to understand what is being described, a thorough background in Boolean expressions is all that is needed.
The example used throughout the book is that of a hotel room reservation system. It satisfies the three criteria that any such example must adhere to:

1) It is an operation that is routine to most of us, so there is very little need to explain the basic premises and additional realistic extensions can be added without any substantial explanation.
2) There are enough different features that can be encapsulated into a component so that the complete example is complex enough to be an effective learning tool.
3) The interactions among the components are complex enough so that the real problem of using components, namely specifying how they intercommunicate, can be sufficiently developed.

In sports, projects are divided into two parts, the plan and the execution. If only one is done well, it will not work. The same applies to components as well, whether you are defining them or describing how to define them. In this book, the authors also execute their well-conceived plan. The descriptions are complete, understandable and in the proper order. Granted that this is shorter than the typical technical book, but I had no trouble in reading it in two sessions, a morning and an afternoon in the same day. My attention did not waver and there were only a very few times when I stopped and either reread or looked at a previous page for clarification.
You would have to be the programming equivalent of a cave dweller to believe that components will not become a dominant technology in the very near future. With this book, you can face that future with much of the knowledge that will prevent you from being relegated to the recycle bin of history.

10 of 11 people found the following review helpful:

5.0 out of 5 stars Specification Made Plain, April 28, 2001

By	R. Williams "code slubber" (Los Angeles, CA United States) - See all my reviews (REAL NAME)    (VINE VOICE)

Amazon Verified Purchase

This book has a couple things going for it that make in not only outstanding, but truly unique: 1. It attempts to present an aspect of development in a structured way, without offering it up as some kind of miraculous silver bullet, 2. The literature available on methodology tends to run the gamut from the simplistic (XP) to the baroque (Catalysis). This book makes a compelling argument for a simple process of doing component specification before writing code. We've already introduced many of the concepts into our team and it has made our process much more solid and mature. People are finally waking up to the fact that the future has to be component-based, language or process alone will not deliver us from the throw away world of most modern software.

Also, see the book 'Objects, Components and Frameworks in UML: The Catalysis Approach'. It goes well with this, though @ 1200 pages, it is on the baroque side. The influence of Catalysis on the authors (one of them worked on it) is clear.