- Paperback: 400 pages
- Publisher: Prentice Hall; PAP/CDR edition (October 1, 2001)
- Language: English
- ISBN-10: 0130668397
- ISBN-13: 978-0130668394
- Product Dimensions: 7 x 1 x 9.1 inches
- Shipping Weight: 1.5 pounds (View shipping rates and policies)
- Average Customer Review: 13 customer reviews
- Amazon Best Sellers Rank: #1,691,774 in Books (See Top 100 in Books)
To get the free app, enter your mobile phone number.
Streamlined Object Modeling: Patterns, Rules, and Implementation PAP/CDR Edition
Use the Amazon App to scan ISBNs and compare prices.
Fulfillment by Amazon (FBA) is a service we offer sellers that lets them store their products in Amazon's fulfillment centers, and we directly pack, ship, and provide customer service for these products. Something we hope you'll especially enjoy: FBA items qualify for FREE Shipping and Amazon Prime.
If you're a seller, Fulfillment by Amazon can help you increase your sales. We invite you to learn more about Fulfillment by Amazon .
"Warlight" by Michael Ondaatje
A dramatic coming-of-age story set in the decade after World War II, "Warlight" is the mesmerizing new novel from the best-selling author of "The English Patient." Pre-order today
Frequently bought together
Customers who bought this item also bought
Customers who viewed this item also viewed
From the Back Cover
- A rigorous and practical framework for modeling business systems
- Pares object modeling down to its core concepts, making it easier than ever.
- Twelve object collaboration patterns that address virtually any business scenario
- Powerful techniquesnot fancy notation!
The first rigorous and practical approach for modeling complex business domains, rules, and systems.
Streamlined Object Modeling presents the first rigorous, practical framework for object modeling complex business domains, rules, and systems. Three world-renowned leaders in object development have pared object modeling down to the core concepts for all business domains, business rules, and business services. Starting from the first principles of "object think," the authors offer a fully integrated approach to building, validating, and critiquing object models. Coverage includes:
- Proven principles and techniques for successfully modeling the structure and operations of any business domain.
- Guidelines for finding and associating objects, assembling object models, and distributing system behavior among objects.
- Rigorous methods for discovering, organizing, and implementing business rules around objects.
- Twelve all-encompassing "collaboration patterns"what they represent, how they relate, and how to apply them.
- Five kinds of business rules, three types of services, and six categories of properties completely specify object-oriented business requirements
From start to finish, the book makes extensive use of examples drawn from real commercial applications. To illustrate how streamlined object modeling flows from analysis to code, it also presents a complete case study derived from a real-world application, and implemented in two leading object-oriented languages-Java, and the Squeak implementation of Smalltalk.
About the Author
JILL NICOLA is an independent software consultant in Houston, TX who has worked in object-oriented software for over 15 years as a programmer, mentor, modeler, and architect. She specializes in helping organizations apply object techniques to develop strategies and model business processes, and co-authored Object-Oriented Programming with Peter Coad.
MARK MAYFIELD is the Object Guru at Chelsea Market Systems in Houston, TX. A leading authority on object modeling patterns, he has created hundreds of object models in a wide range of commercial environments, and co-authored Object Models: Strategies, Patterns, & Applications and Java Design with Peter Coad.
MIKE ABNEY is a Senior Java Developer at Chelsea Market Systems in Houston, TX who has performed many roles in software development, including analysis, user interface and software architecture design, coding, and project management.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
Anyway, I'll keep slogging through it. Read a sample chapter before you buy this one.
I'm very surprised at the low Amazon.com sales rank of such a unique, insightful, and practical book. With agile and "extreme" methods and practices all the rage you would think a streamlined, dare I say 'agile', approach to modeling would have recieved more attention. I suppose the publisher missed a great opportunity by not putting "Agile" somewhere in the title. Having been the XP 'evangelist' and coach on an XP project I think it even has a place in XP (though purists will argue that point). This is my biggest problem with XP - XP recommends coming up with a "metaphor" for an application which gives the project "conceptual integrity" and will allow the customer and programmers to communicate clearly about the application. In the famous C3 payroll system project the sytem was likened to a manufacturing line in which paychecks were 'assembled' from hour 'parts' and various other 'parts'. Sorry, it may have worked but it is overly contrived and not "the simplest thing that could possibly work and no simpler". The other problem is that Beck himself says that coming up with a useful metaphor cannot be taught and that he can only come up with one on half his projects. So what if, instead of racking your brain to come up with a useful metaphor, which you will only come up with 50% of the time at best, you used a simple-as-possible-but-no-simpler modeling approach to model the *actual* business domain? Wouldn't that model provide the necessary "conceptual integrity" for the system under development and allow the customer and programmers to communicate clearly about the system, and do so *directly*? In the C3 case, paychecks would be paychecks and hours would be hours. No translating back and forth between different domains. I understand the purpose of having a good metaphor - to capture and allow communication of the essential entities and of the essential relationships between those entities. But I think that creating a basic domain model, quickly and iteratively, by applying the patterns, rules and techniques in Streamlined Object Modeling, is a cleaner and more direct practice than metaphors and fits in fine with XP. And creating such a domain model is possible not just 50% of the time, but 100% of the time. (The authors do make certain suggestions and recommendations here and there reflecting their own methodology and implementation preferences which do not always jive with agile and, especially, XP practices. But those are easily identified and agile/XP practitioners should not allowed them to distract from the core of this work.)
In the interest of full disclosure I should state I know and have had the privilege of working with all three of the authors. They gave me an early draft and I did not read it. The book was published and they gave me a copy and I did not read it. Sorry, guys and gal! But finally, this past week, I got around to reading it. Fantastic piece of work. I just wish I would have read it sooner!
When I discovered Peter Coad's Object Modeling in Color book (ISBN 013011510X), where I was introduced to his "domain neutral component" (DNC), I had an epiphany. Then, after experiencing the fractal application of the DNC, I started to notice the patterns that Nicola, Mayfield, and Abney lay down quite nicely. It is a natural maturation of thought from Coad's DNC; Coad himself even acknowledges the importance of the book.
If you want to become a good object oriented analyst, read this book, then read it again. If you think you're a good object oriented analyst, read this book, then read it again. In either case, after applying the principles described, I think you'll wonder how you ever got along without them.
Kudos to Nicola, Mayfield, and Abney for an intellectual milestone in object oriented technology. I wish someone had handed this book to me when I first started working with object oriented languages.
I had been practising object modeling for some time before I read that book and was, at times, wondering :
-what could be the right objects in that situation ?
-where should I put this behavior ?
-do I need "services/processes" objects to operate on my "domain" objects ?
This book gave me really precious answers :
-use the patterns to identify objects
-Let the objects do the work
-Let the object that has the knowledge do the work that requires this knowledge.
I have been practising on new projects since and found the lessons invaluable.
That's why I am not surprised at all about other reviews and I have been recommending the book around me ever since.
The fundamental complexity of business systems is business, not transactions, persistence, gui or any other technical aspect. We have many years of experience with technical matters but we often strive to preserve/improve business value in the systems we build.
Most recent customer reviews
No, Not the human kind, but the stuff that 'controls' your "Objects".Read more