Features
- Cover Type: Hard Cover with 864 pages
- Published by: Addison Wesley
- Edition: 8th Edition June 4, 2006
- Written in: English
- ISBN 10 Number: 0321313798
- ISBN 13 Number: 978-0321313799
-
Book Dimensions:
9.1 x 7.6 x 1.7 inches
- Weighs: 3.5 pounds
Reader Reviews
It has been 2 years since Sommerville put out the 7th edition of this book. So what has changed? Three new chapters have been added at the end of the 8th edition. One is entitled "Service-oriented software engineering". All about Web Services, which is a burgeoning field. The 7th edition just had a relatively brief explanation about XML and the sundry services developing atop it. Now the 8th edition goes into those, like the Web Service Description Language, and the Business Process Execution Language. To be sure, the chapter is not an exhaustive explanation of the syntax and usages of these languages. For that, you need to consult books devoted to them (and these do indeed exist). Rather, the chapter furnishes a concise overview that gives you the essence of what they can do. I actually think the chapter should have been simply called "Web Services". The actual title, while accurate, is too indirect. Another new chapter looks at aspect oriented programming. Again, just an overview. But it does convey accurately what AOP offers. Centred around the key idea of cross cutting concerns. And that conventional object oriented code tends inevitably to have closely related code scattered thru many classes; making maintenance harder. It is by no means clear that AOP will ever become common. But it is one of the most intriguing ideas to arise recently, and Sommerville is correct in explaining it. In the existing chapters brought over from the 7th edition, I do still disagree with his remarks on Extreme Programming. While XP does have some laudatory features, I take issue with the constant refactoring and the pair programming, as well as having a customer onsite at the developers' place. The latter is simply not realistic in some projects. While pair programming, and not having programmers responsible for specific parts of the code, totally ignores different levels of expertise. Some programmers are simply better (or more experienced) than others. A real danger is having 2 neophyte programmers unwork complex code made by a senior programmer, that they simply did not understand. If you have done any programming, you will encounter subroutines that are highly intricate and intrinsically hard to understand. Typically, these subroutines are only a small part of the total code. But they might play a crucial part. They should be associated with specific programmers, who are responsible for them. Another reason against pair programming is when the programmers are not just "pure" programmers. They might have backgrounds in various engineering or scientific fields, where this background is needed for the project. So a programmer/engineer versed in mechanical design, and who has to code accordingly, has different responsibilities from another programmer who has to deal with modelling the electrical circuitry, for example. At the design level, it makes eminent sense to sometimes pair these, when the domains overlap. But at the programming level, each can't usually do the other's work.
Comment | |
(Report this)
Search for books at
