UML Components: A Simple Process for Specifying Component-based Software (Component Based Development Series) Paperback – 18 Oct 2000
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Would you like to tell us about a lower price?
If you are a seller for this product, would you like to suggest updates through seller support?
From the Author
The book that tells you how to combine EJB and COM+ with UML
We wrote this book to help those of you who want to use UML to describe components built using technologies such as EJB and COM+. A technology-independent specification of a component is very useful in providing a more abstract view. UML, together with OCL, provides a mechanism for putting precision into the abstract specifications.
Other books provide an overview of UML, but this book explains specifically how to use UML to specify components. Most importantly, it also provides a simple step-by-step process for moving from requirements to component specifications.
From the Back Cover
Developers using component technologies such as COM+ and Enterprise JavaBeans need to be able to define and express specifications for their components. They can do so using the Unified Modeling Language (UML), whether or not the components are being implemented internally using object technology. However, they also need a simple process that ensures specifications relate correctly to requirements.
Although originally conceived as a notation for object-oriented modeling, UML has great potential for component-based systems. UML Components applies UML to the world of component architecture, demonstrating how it can be used to specify components, their interactions, and their integration into cohesive systems. This book shows readers which elements of UML apply to server-side component-based development and how to use them most effectively. Following a simple step-by-step process, the authors walk through requirements definition, component identification, component interaction, component specification, and provisioning and assembly. Throughout, the focus is on the specification of the external characteristics of components and their inter-dependencies, rather than on internal implementation. Numerous UML diagrams illustrate component specifications, and a detailed case study demonstrates important concepts and techniques.
System architects, designers, programmers, and testers interested in leveraging the advantages of UML will find this a concise, practical, and insightful guide. The authors address the two great challenges of designing and constructing enterprise-scale component-based software: finding a process that can support the construction of large component systems, and making the best use of the wide range of notations and techniques found in the UML.
0201708515B04062001 See all Product description
Top customer reviews
The only shortcomings are a lack of discussion on packages, patterns, component dependancy matrix, version release managment in global organisations and FINALLY an example CCM (Corba component Model)/ Catalogue for the Designer and how this should be interpreted by the programmer. Why has it not gained more prominence or is it ahead of the 'Curve' sic hype ?
Overall a job well done but needs updating and I think that it will be welcomed by the whole industry.
Kevin O'Hanain - Business Systems Analyst -London & Dublin
If you found the Catalysis book oververtly complex (go on admit it) then this book should be next on your purchase list.
The only debate would be whether the use of Mgr suffix on interface types and how this applies to EJBs was discussed adequately.
Initially I was tempted to give this book four stars. However, as this book is pitched as being a "simple process" I think it lives up to its title and is an excellent introduction to CBD.
I hope people buy it and read it.
I've read the Catalysis book, which is overly complex for most people. And Paul Allen's book, which takes a higher level view, never getting down to the nitty-gritty detail required.
This book gives a step by step breakdown of how to do analysis and design for CBD targeting EJB and COM+. And does so, for the most part, realistically - given the nature of EJB and COM+.
Recommended above other books on the subject, although a reading of the Catalysis book, which is cited often in this book, would also be useful.
Most helpful customer reviews on Amazon.com
Here is the book by the experts. This starts with the basics. First, they say what they mean by a component - valuable, because authors all differ. Then they cover a few of the development basics, including project management and requirements. This really isn't a process book, though, so those topics get just enough discussion for the rest to make sense.
The real meat of the book starts in Ch.3, "Applying UML." That opens the topic that this book is really about, and gives a quick review of the kinds of UML diagrams used. Ch.5-6 look a lot like traditional OO analysis, not surprising because OO is the implementation mechanism for any modern component mechanism. Also, like OO, component systems emphasize bundling of data with operations. In fact, the experienced OO developer should pay more attention to the differences between OO and component analysis than the similarities. Whether your development involves components or not, you'll still find a detailed case study of the UML applied to a realistic sample design. In particular, the many different roles of interfaces apply as well to OO software as to components.
Ch. 7 goes into the real detail, esp. use of the Object Constraint Language (OCL) for interface specification. This is Meyer's "design by contract" specification technique, cast into UML/OCL terms. Although the material is good, I came away with mixed feelings about it.
On one hand, the material involves a very high level of detail, possibly enough to put some readers off. "Design by contract" is a descendant of mathematical proof of program correctness. It's a whole new aspect of programming, with a whole new set of thought processes involved and a whole new set of problems to get lost in. My experience of typical production programmers is that the contracts will probably end up a) vacuously general, or b) a never-ending mesh of inconsistencies, or c) ignored. I like contracts, and I like formal specification of behavior, I just don't see that the average practitioner is ready for it.
On the other hand, I found some maddening omissions. The authors repeatedly warn that aggregation has subtle semantic implications, that collections need special attention, and so on. They don't say what the problems are, though, or give pointers to readings that can be accessed readily.
The authors note that CASE tools of the day are not ready for such broad, intensive use of detailed UML features. Worse, some UML features are mis-supported, and the user may have to fight the tools to get the results desired. That's fair; if anything, I appreciate the honesty. UML as a whole is too big, and its usage is evolving too rapidly for the tools to catch up. The best UML-related writings today, this included, describe usages that ought to work but, in commercial reality, don't.
There is one peculiarity here that I never figured out. The UML is a standard from the Object Management Group (omg.org). So is CORBA, with its component model. Why, then, did the authors address COM+ and EJB components but not CORBA? Maybe the CORBA model isn't mature enough, but I really don't know.
This the best, maybe the only book that pays serious attention to component software in UML terms.
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.
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.
Look for similar items by category