<< 1 >>
Rating: 
Summary: Pragmatic Approach to Distributed System Architecture
Review: All too often, design books (and practictioners for that matter) fall into a trap of treating the design process like the desired outcome is "Art", rather than focusing on solving business problems and working within time and budget constraints. This book attacks this notion and presents a process that extends UML to be an effective tool in building distributed component architectures. The focus is on meaningful deliverables that evolve through analysis and design iterations, and the techniques will effectively break you of waterfall habits.
Rating:
Summary: Pragmatic Approach to Distributed System Architecture
Review: All too often, design books (and practictioners for that matter) fall into a trap of treating the design process like the desired outcome is "Art", rather than focusing on solving business problems and working within time and budget constraints. This book attacks this notion and presents a process that extends UML to be an effective tool in building distributed component architectures. The focus is on meaningful deliverables that evolve through analysis and design iterations, and the techniques will effectively break you of waterfall habits.
Rating: 
Summary: Component Architects enjoy this feast!
Review: 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.
Rating:
Summary: Packs a punch...
Review: Flat out ...I liked this book. Frankly this book could be twice this size and still be good. It compresses a TON of information into a small package. I knew that UML was extensible ...but this book really puts that idea into practice. Only negative would be the organization of it could be a bit better. The book essentially is giving you documentation guidelines but the 'where to document' sometimes gets blurred with the 'how to document'.
Rating:
Summary: Clearest description so far
Review: If you had trouble using the UML to handle component systems, there's a good reason for it. The UML is so broad, has so many parts, and has so exponentially many combinations that fitting it to any one discipline is a job for experts. 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.
Rating:
Summary: Good Starter for Component based Architecture
Review: The book walkthrough a example you can relate with real life. The approach gives a very good overview how a component based architecture can be used in real business applications.
Rating:
Summary: Specification Made Plain
Review: 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.
Rating:
Summary: Practical But pre-requiring UML
Review: This book is practical and explains UML usage based on design process. I think it is useful for someone who has UML knowledge and want to know practical applicatin of UML in real field. But this book doens not explain UML itself.
Rating:
Summary: A very highly recommended, user-friendly reference
Review: UML Components, John Chessman and John Daniels successfully collaborate to show how UML applies to the world of component architecture and demonstrating how it can be utilized to specify components, their interactions, and the integration into cohesive systems. UML Components reveals which elements of UML apply to server-side component-based development and how to use them most effectively. The reader is taking carefully and step-by-step through requirements definition, component identification, component interaction, component specification, as well as provisioning and assembly. Numerous UML diagrams and a detailed case study illustrate component specifications, concepts and techniques. UML Components is a very highly recommended, "user friendly" reference for system architects, designers, programmers, and testers.
Rating:
Summary: Realistic exercise used to explain how components are used
Review: 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.
<< 1 >>
| 
