Customer Reviews

Object-Oriented Software Engineering: Using UML, Patterns and Java (2nd Edition)

5 star:		(8)
4 star:		(6)
3 star:		(1)
2 star:		(2)
1 star:		(2)

 

 

Many SE books tell you about SE (eg., Sommerville). Those kinds of books equip you to win in a software engineering version of the trivia game Jeopardy! but will hardly impart any skill and will not make you a better software engineer, only more informed.

In contrast, this book tells you how to do software engineering. They tell you what, Bruegge shows you how. Rather than cover all the concepts in SE, Bruegge picks the most essential ones, gives you a brief but thorough explication of those and then proceeds to teach how they are used.

Professor Bruegge's approach to teaching his SE students is by having his entire class work *together* as one team on *one* real-life project during the term (that's one project for the whole class).

Typically, this project is an upgrade of the previous class's project. Stop and imagine how realistic this approach is -- modifying a system created by engineers who are no longer available for interview, working with as many as 50 different people, working with designs that do not match the code anymore, working with code of varying quality, etc.

Bruegge distills the lessons learned from these practical projects and illustrates practical (not idealistic) approaches to solutions.

Expect German thoroughness and a lucid, unpretentious prose that heeds Strunk and White's dictum: "Omit needless words".

Highly recommended.

-vja

It is a highly readable book. The authors are good at explaining concepts with clarity.

But the book is sloppy in any area that requires precision. They make no distinction of the four kinds of message sending in sequence diagrams. It is important for a UML user to differentiate synchronous, asynchronous, return and flat arrows. Otherwise a diagram will have different meaning. The authors use indiscriminately the notation of synchronous message when most of messages in their diagrams should be asynchronous.

The coverage on OCL is even worse. More than half of the OCL constraints are wrong!!!

You cannot rely on the corrections found on the authors' website because it only contains minor typos but misses the serious mistakes.

Though it is more prescriptive than the standard software engineering books such as the ones by Pressman and Sommerville, I would NOT recommend its use as a textbook due to the many errors. I found "Object-oriented Systems Analysis and Design" by Bennett, McRobb and Farmer a better how-to book in software engineering.

Although this book comes from an academic background, I used it in a real client project in industry for the first time. The book offers a rather complete overview of software engineering in general: requirements engineering, analysis, system design, object design, implementation, testing. It also includes specialities, for instance rationale management, project management and others. I agree with a previous annotator who wrote that not all of the samples are 'perfectly helpful'. However, some are and some are quite amusing, e.g., in the Design Rationale chapter.

Overall, the best collection of Software Engineering best practices I found in a single book. Really helpful for academic use as well as in industry.

This is NOT a book on Unified Modeling Language (UML). It's not a book on Object Constraint Language (OCL). It's also not a book on Capability Maturity Models (CMM), Class-Responsibilities-Collaborators (CRC) cards, Decision Representation Language (DRL), Extreme Programming (XP), Gantt charts, Issue-Based Information Systems (IBIS), Joint Appication Design (JAD), Key Process Areas (KPA), the Liskov Substitution Principle, Model-View-Controller (MVC) architectural styles, Nonfunctional Requirements (NFR) Frameworks, Object Design Documents (ODD), PERT charts, the Questions-Options-Criteria (QOC) model, Requirements Analysis Documents (RAD), Royce's methodology, Software Configuration Management Plans (SCMP), System Design Documents (SDD), Software Project Management Plans (SPMP), the Unified Software Development Process, User Manuals, V-Models, Work Breakdown Structures (WBS), or any of the myriad other tools introduced in the book.

This IS a book to introduce newly-minted programmers to the kind of things, tools, and processes they can look forward to (with either anticipation or dread) in the real world of software development. As the authors state on page viii of the Preface:

"We have observed that students are taught programming and software engineering techniques in isolation, often using small problems as examples. As a result, they are able to solve well-defined problems efficiently, but are overwhelmed by the complexity of their first real development experience, when many different techniques and tools need to be used and different people need to collaborate."

It's been many years since I was involved in major software development projects (and those were all in the military). But, this book seems to have covered everything that all new programmers need to know so that they aren't simply lost when they enter their first software project. The readers certainly won't be experts in the things covered, but they'll at least have a good grounding and be able to bootstrap themselves from there (especially since the authors provide "Further Readings" and a Bibliography at the end of each chapter). For instance, on page 71, under Further Readings, they list three works on UML: one of which is the 566 page official specification, "OMG Unified Modeling Language Specification."

Overall, this is an excellent book for anyone who is just entering the software development world. I rate it at 5 stars out of 5.

As a side note, Florida State University (FSU) uses this book in its COP 3331: "Object-Oriented Analysis and Design" course.

I'm currently following a Msc in Software Development in England. This book is very good. Finally an excellent source to go through in all its aspects. Examples as well as explanations are clear, sound, and solid. The book provides short, though detailed definitions that avoid verbose and useless comments. The book is guiding the reader through the explanation of how to carry out and accomplish a real project. What I mostly like is the heuristics given for identifing and setting forth all the artifacts needed during Requirements Elicitation and Analysis. Hat off to the authors of this great reference.

This book was used in my software engineering class at college. Overall, the material in this book was presented in a very boring and complex manner, focusing on jargon definitions and a few isolated examples.

Although the book does explain software engineering, it tends to do so in a painful way. Do yourself a favor and pick another book on the subject.

This book provides a general overview of the issues involved in the practice of software engineering. Covers requirements elicitation/analysis, design (both high level/architectural and lower level/object-oriented), testing, and a process and project management issues. The book is up do date with current practice covering topics such as UML, design patterns, and software lifecycles and development methodologies.

The examples used tend to become very stale after a while, and the text doesn't always read as well as it could.

Overall, this book is a good introduction to software engineering and a good starting point, but should not be considered a final reference.

I'm a Software Engineer and Software Engineering/OOAD teacher with a modest bibliography on Object Technology and Software Engineering: This book is pretty good for both worlds. Maybe it could be confusing for someone with little exposure to UML, because authors creatively used UML for any illustration required (design, software engineering concepts and artifacts, and even reading map).

This book is now within my favorites in OOAD/Software Engineering, and I just waiting for my 2nd edition unit.

The only useful chapter in this entire book is the last one, where the book finally asks the question "How much process/modeling/management/etc. is enough?" for a given project. A number of methodologies are presented, that combine just a few of the techniques covered in the other 15 chapters, and discussed in the context of different types and sizes of project.

The rest of the book, comprising 15 chapters, is structured as a catalog of modeling and analysis techniques but they're presented as *the* way to develop software, according to the authors. It's only until the end that those techniques are placed in a context where they make any sort of sense.

The book also uses UML to model the activities and techniques in each chapter. This is cute, but not especially helpful and occasionally confusing. In fact, this usage serves as a helpful counter-example to the idea, espoused in the book, of UML as a catch-all modeling tool.

In lieu of this book, computer science students would be well served to study a range of methodologies and projects to which they were applied, and then to dig deeper into the techniques that make up those methodologies, according to the interest and needs of each student, in other dedicated references.

The book is definitely a guide telling you how to do right thing in a right way. Good introduction to UML and show you how to prepare document for your customer.
Highly recommend !!!