Service- And Component-Based Development: Using the Select Perspective and UML

Code reuse has been a part of the software development culture since two programmers first met at the coffee dispenser. There is an enormous amount of hard and anecdotal evidence that programmer productivity dramatically rises when developers share their ideas and where each does what they do best. Component development starts with this idea and extends it to a formal process. A component is a unit of software that can be linked to other components, where the sum total is a working application. The internal workings of the components are generally unknown to the user, a formal specification of what it accepts as input and returns as output is generally the only available information. The purpose of this book is to describe a working process where components are developed for reuse and later modification as necessary. The component development process described begins at the beginning, in the lifecycle models used to construct the components. Since a component is in many ways a stand-alone piece of software, the lifecycle of a component is almost identical to that of a stand-alone application. The only real difference is that the construction of components is often considered to be similar to factory operations. While they are difficult to execute in practice, applying the quality control tactics and structured design processes used in factories to software development has several advantages. Starting with a reasonably firm understanding of what the product should be, constructing blueprints incorporating previous successes and then testing the product before release are sound development processes. As is the case with the parts built in a factory, a way usually must be found to test the component before it is "plugged in" to the rest of the application. Select Perspective is a set of best practices for the development and use of object-oriented software components and is described in this book. I found the various steps of the select perspectives approach to be sensible. The chapter and section headers use a lot of terminology from factories and this is a reasonable thing to do. As the number of available components grows, one of the most important skills will be the ability to comparison shop for components. This important skill is the primary topic of chapter four, where the subtitles are: acquire component, classify and certify component or service, maintain components, locate and retrieve candidate component and monitoring component and service reuse. Since not all components will do exactly the same thing, the comparison will be evaluating a combination of functionality, speed of execution, ease of maintenance and the price. This will be a very difficult thing to do well. A detailed case study of a select cruises business is given in an appendix. Use cases, UML class and sequence diagrams are used to describe the application in detail. While the diagrams are well done and the case study is easy to follow, some detailed understanding of

If you where wondering how to do Component Based Development, stop now and read this book. The book gives some real good insights, based on the real live experiences of the authors. When compared to other development processes like the Unified Process, this methodology is fully Service and Component Based. From the early start in the Select Perspective process, all activities are aimed at Reusing services and components before Buying them, and only as a last choice build them yourselves.The book has some great modeling examples. This was the first time I have seen a straight foreward way of using UML for modeling against a Service based Architecture. A must for people that are serious in adopting a Service and Component Based development process.