Customer Reviews

Business Engineering with Object Technology

5 star:		(7)
4 star:		(0)
3 star:		(1)
2 star:		(0)
1 star:		(1)

 

 

Dr. Taylor builds a clear case for business process oriented systems development and he can explain what that is, which is unique for IT books. I use this book to help inform key executives about how business objects really work.

Thank you, David A. Taylor! Your work was extremely readable, written in "lay" terms though not overly simplistic. I am not a programmer, but have been doing software design for 7 years. Your presentation of the object concept was logical, well supported with examples, and actually pleasant to read. I started another book, and put it down after 6 pages due to the pretentious and pompous tone it took. Your book was extremely helpful as an introduction into the world of Object Oriented Design... Thank you!

Pulls you through quite a thought process. Great step-by-step manual. The diagrams and margin summaries would make several classic PowerPoint presentations.

This is the book that, for me, "made it click". I had been trying to wrap my head around object-oriented analysis for years, when a colleague recommended this book. I read it, and suddenly -- -- I GOT IT! Since then, I have always been one of the few in any workplace that actually "gets" OO design.

The thing is, 90% of people look at OO as "data plus functions". But that's only the minimal truth. To really gain the full power of OO you have to go beyond that, and that's what Taylor does. He takes you right up to the edge and even lets you peek over into the vast possibilities: "the customer should know how to bill himself"!! I still get excited about this!! Most people just use accessor methods to make their objects into dumb bags o' bits that are tossed around like big fat dead blobs. Well, after this book, you'll never be that pedestrian again. Screw accessor methods! - give your object an intelligence within its environment.

To me, David Taylor is a genius. As a consultant, I purchased this book for every client I had to work for, so we could work at a higher level -- together. As another colleague said, programming is all about communication; objects ARE the way humans think about the world ("What is that thing?" "That object? That's a Truck.") and the most efficient way to discuss something is to use the same language, don't you think?

If you haven't read this book, read it. If you read it and didn't think it was incredible, then maybe you didn't get it. Don't worry, though, you can. Just keep trying. It's worth it.

This was an odd read for me. I got a lot out of the book, but did not enjoy reading it nor agree with the final approach devised by the author. The author's view of a business application got a bit too framework-y for me and too restrictive. I agreed with many of the book's statements about a business-driven design and using business objects as the core of the code base. If you are looking for more fresh ways to think about how objects behave and/or fit in to your business object development then I think this book can be worth the read.

It's interesting that one of the more recent reviews criticizes this book for not following UML; in fact this book illustrates many of the failings of UML when it is applied too generally. I don't think UML was ever intended as an integrative technology for business/software. Rather, it was intended as an adjunct to the RUP, which was (as its developers clearly state in a number of places) intended for the development of very large software deployments, such as aircraft control systems. The techniques Dr. Taylor advocates are integrative, and designed to scale easily from very small to medium big -- which is the domain of 90+% of business software, I would suggest. I'm often struck by how many times programmers (usually C++, occasionally Java) will tell me that "object-orientation is broken" or "never worked". Yet few, if any, of these people have ever attempted a CRC session along the lines Dr. Taylor suggests. That doesn't surprise me. The main thrust of this book follows the main ideas that the "inventor" of O-O, Alan Kay, put forward, which is essentially that in developing business software, the programmers should not be especially privileged. The use of objects, then, is not driven by "code optimisation" or "code re-use", but by a desire to make some of the architecture of the software understandable to a wider, non-technical range of contributors. This opening of the system can lead to a co-operative development, instead of the code/review/re-code cycle that wastes so much time in most devlopments. I'm still astonished by how many so-called O-O programmers still don't "get" that.

Pulls you through quite a thought process. Great step-by-step manual. The diagrams and margin summaries would make several classic PowerPoint presentations.

A fantastic EASY book (for: programmers, managers and users) to understand the great potential of the object paradigm to fill the gap between technical and business people. I think this is the future of computer development.

The author presents an enthusiastic view of applying some ideas from object-oriented programming to business modeling. In doing so, he makes a number of unsubstantiated, if not false, claims such as "... object technology reflects fundamental cognitive processes" or "... directly supports the way managers think about their business". Compare this to the sobering statement of Jacobsen, one of the founders of the standard model of object orientation (the "UML"), who said that "it is bizarre to apply the way of thinking that governs computer systems to business processes". Clearly, the software engineering concepts brought up by object technology do neither reflect the way the business world is like nor do they reflect the way we think about it. Another weakness of the book is its age. In a world of rapid changes through scientific and technological progress, it is not suprising that the book is not up-to-date. Today, the Unified Modeling Language (UML) defines the standard model of object orientation. Unfortunately, the book is both incomplete and inconsistent with the UML. For instance, it does not discuss the important concept of associations, it calls attributes "variables", and it uses the terms "collections" and "composition" in a way that is incompatible with the UML.