The Object Primer [NOOK Book]


Scott Ambler, award-winning author of Building Object Applications that Work, Process Patterns, and More Process Patterns, has revised his acclaimed first book, The Object Primer. Long prized in its original edition by both students and professionals as the best introduction to object-oriented technology, this book is now completely up-to-date, with all modeling notation rewritten in the just-released UML 2.0. All chapters have been revised to take advantage of Agile Modeling (AM), which is presented in the new ...
See more details below
The Object Primer

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$33.49 price
(Save 42%)$58.00 List Price


Scott Ambler, award-winning author of Building Object Applications that Work, Process Patterns, and More Process Patterns, has revised his acclaimed first book, The Object Primer. Long prized in its original edition by both students and professionals as the best introduction to object-oriented technology, this book is now completely up-to-date, with all modeling notation rewritten in the just-released UML 2.0. All chapters have been revised to take advantage of Agile Modeling (AM), which is presented in the new chapter 2 along with other important new modeling techniques. Review questions at the end of each chapter allow readers to test their newly acquired knowledge. In addition, the author takes time to reflect on the lessons learned over the past few years by discussing the proven benefits and drawbacks of the technology. This is the perfect book for any software development professional or student seeking an introduction to the concepts and terminology of object technology.

Starting with a description of why developers and their organizations want to take advantage of the object-oriented (OO) paradigm. This book quickly gets into leading edge development techniques such as CRC (Class-Responsibility-Collaborator) modelling and use-cases. The reader is introduced to OO concepts in a straight-forward and easy manner.

Read More Show Less

Editorial Reviews

The proceedings of FOCS'95, held in October 1995, comprise three invited talks and 70 (unrefereed) contributed papers, many of which report on continuing research. The invited talks: Cognitive Computation, by Leslie G. Valiant; Perspectives on Database Theory, by Mihalis Yannakakis; and Controllability, Recognizability, and Complexity Issues in Robot Motion Planning, by Jean-Claude Latombe. No index. Annotation c. Book News, Inc., Portland, OR (
Read More Show Less

Product Details

  • ISBN-13: 9781139813860
  • Publisher: Cambridge University Press
  • Publication date: 12/5/2012
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 3
  • File size: 30 MB
  • Note: This product may take a few minutes to download.

Meet the Author

Scott Ambler is an instance of an OOConsultant for roninIntemational (www based in denverColorado. roninInternational implements objectArchitectureConsulting(), cornponentArchltectureConsultingU, and softwareProcessConsulting() operations. Instances of HumanoidLifeForm can send email messages to him

Scott Ambler is a very versatile object that will polymorphically change type in order to meet the needs of roninInternational clients. For example, he often becomes an OOMentor, OOArchitect, OODeveloper, or SoftwareProcessMentor object. Scott has been an instance of an OOConsultant since 1991. He used to be a MastersStudent object, having received an instance of an InformationScienceDegree from the university0froronto. As a MastersStudent, Scott Ambler did a lot of work in 00 CASE and instantiated a ThesisPaper object in computersupported co-operative work (an academic alias used to describe groupware). The only message his instance of ThesisPaper responds to is sitOnShelfAndGatherDust, which Scott Ambler finds disappointing but predictable. Scott Ambler has worked at a variety of organizations, including instances of Bank, InsuranceCompany, TelecommunicationsCompany, InternetStartup, ServicesOutsourcer, MilitaryContractor, and Product Distributor.

Objects that have been declared as friends of Scott Ambler often send him the message youTakeThisObjectStuffooFar, to which he responds with the text string "It's nothing compared to how far I take Star Trek." In his spare time he likes to write, having instantiated several books about object technology. He also writes regular object columns for softwareDevelopment (www. and computingCanada (wwwplesmanxom). Scott Ambler is an avid watcher of instances of StarTrek, and intends to one day do his doctorateDegree at starFleetAcademy. His personal web site is http-//www., where he has posted a collection of WhitePaper objects and other software development resources.

Read More Show Less

Read an Excerpt

Excerpt from Chapter 2

...change in a single business rule could affect many programs. For example, say you have four structured programs that access the student data table in a university database. Consequently, you add the attribute "Guardian name" to the table. To support this change, all four structured programs need to be modified to work with the new data. Now say you've developed exactly the same systems using object technology. Instead of coding four different applications to work with the student data, you instead code one single class called "Student," which works with this data that encapsulates (contains) both the functionality and the data appropriate to students. To add "Guardian name" you merely have to modify the definition and source code of the class "Student" in one place, not in four. Clearly, this is easier.

As a second example, you may need to modify your existing system to keep track of university administrators. A university administrator is just like a professor, except that in addition to teaching courses, he or she also schedules them. In a structured application, you would potentially need to add a new data table for administrators and a new program module to handle administrative functions. That is a lot of work. In an 00 system, you would define the class "Administrator," which would inherit from "Professor." Granted, you would still need to write code to schedule courses; however, you would not have to worry about all the data and functionality already defined for professors.

The preceding examples illustrate how easy it is to extend existing 00 applications. First, existing classes are easily changed because both the functionality and data reside in one place. Second; through the use of inheritance, new classes are created that take advantage of the behavior implemented by existing classes. No more reinventing the wheel.

2.1.3 Improved Quality

Quality systems are on time, on budget, and meet or exceed the expectations of their users. Improved quality comes from increased participation of users in systems development. As you will see in this book, 00 systems development techniques provide greater opportunity for users to participate in the development process (for example, Chapter 3 presents CRC modeling and use case modeling, techniques where users perform the bulk of requirements definition).

Inheritance The representation of an is a, is like, or is kind of relationship between two classes. Inheritance promotes reuse by enabling a subclass to benefit automatically from all the behavior it inherits from its superclass(es).

2.1.4 Financial Benefits

Reusability, extensibility, and improved quality are all technical benefits. While they all sound like good things (and they are), the reason they are important is because they lead to the business benefits of 00. From the point of view of our users (remember them, they are the people who pay the bills), the real benefits are we can build systems better, faster, and cheaper (BFC).

While most 00 books like to concentrate on the technical benefits, the only ones that count are the business benefits, such as BFC. Not only are the BFC benefits applicable to project development, they also apply to production. Systems with high rates of reusability have less code to maintain than systems with low rates of reusability (that's because instead of reusing common code, the same code appears over and over again). The more code, the more effort it takes to maintain it. Furthermore, by definition, a system that is easily extensible is easy to maintain. Finally, a system that meets the needs of its users will receive fewer change requests and fewer support calls than a system that doesn't meet their needs.

It's important to note that the benefits of object orientation are achieved throughout the entire lifecycle. We use inheritance throughout analysis, design, and programming. This means we can reuse our analysis and design efforts, as well as our code. To add new features or to modify existing features in a system, we must first update our analysis and design models, and then modify our code. Therefore, both our models and our code must be extensible a (and they are). An indispensable way to improve the quality of systems effectively is to increase the involvement of users throughout the entire development process. That is exactly what 00 does. Therefore, because the technical benefits are realized throughout the entire development lifecycle, the BFC ones are also realized (remember, the BFC benefits are the direct result of the technical benefits).

2.1.5 Increased Chance of Project Success

Traditionally, developers have not done a good job at delivering affordable systems in a timely manner that meets the needs of their users. As software professionals, we need to find a way to develop high-quality systems quickly and inexpensively: object orientation is one potential solution. I consider a project successful if it is on time, on budget, and meets the needs of its users. Unfortunately, by this definition, almost every single systems development project has failed. Although, at first glance, my definition may appear harsh, it is actually quite fair. To convince yourself of this, consider the following scenario:
Scenario You and your spouse have decided to take the plunge and have a house custom-built for your family. You go to a house developer, describe your needs and your budget, and tell him to draw up a plan. At your next meeting, the developer shows you something he calls a prototype, which is a scale model of your house that is made out of cardboard. Because it is not what you want, you tell him about a few changes that need to be made. After a few meetings where you evaluate the prototype and suggest changes, you finally have a house design you like. The developer has architectural plans drawn up and, at the next meeting, gets you to sign off on them. You are not an architect, so you really don't understand the drawings. They seem complicated, though, so you think they must be right. You and the developer finally settle on a price of $200,000 and a moving date of June 14th (it's now March 2).

Time goes by, and every second week you receive a progress report from the developer. Although he keeps telling you everything is going well, you begin to suspect something is wrong. Then, during the last week of May, your worst fears are confirmed-you get a call from the developer: "Gee, it seems we're a little behind schedule. Because of unforeseen complications, we've had to tear down and rebuild a few sections of the house, so it won't be ready until July 30th." You stand there in disbelief-your house is going to be seven weeks late, a time slippage of 50 percent! Where are you going to live? To make things worse, the developer tells you "Oh, by the way, we're also a little over budget. Now that we've actually started building +e house, we have a better idea of what it will really cost: $400,000." As you try not to faint, you realize that $400,000 is double the original estimate. You are not happy about the situation, but you have already invested a lot of money, so you tell the developer to continue.

August 14th rolls around and you are finally able to move into your house (the schedule slipped an additional two weeks). You don't mind as much, because the final bill came in at only $385,000. You walk through the front door, and as you try to turn on the lights, you realize there's no light switch. You turn to the developer and ask him how to turn on the lights. "You wanted lights in your house? You never told me that!" he exclaims. Angrily, you reply "Of course I wanted lights! Hey, where are the wall plugs? Isn't there any electricity in this house?"

"There wasn't any electrical wiring in the architectural plans or in the prototype, didn't you notice?" says the developer. "You signed off on them. This is the house you've paid for, so you better get used to it."

Unbelievably, you shout, "This isn't right! You're incompetent! You'll never work in this town again! Get out of my house!" The developer exits quickly, and begins walking to his truck, saying under his breath "That's the problem with people, they don't know what they want. And then when I can't read their minds, they blame me. Boy are people ever stupid."

Sound familiar? How happy would you be if this really had happened to you? How do you think your users feel when the systems you develop are late, over budget, and/or don't meet their needs? In our scenario, the house developer did not get the right specifications from his clients. While prototyping was an effective technique for understanding the basic needs of his clients, it didn't provide him with the full details he needed to produce a complete design for the house. Sure, forgetting to put electricity in a house seems like a fairly obvious problem. However, systems developers often miss features that seem basic and obvious to our users. The reasons developers miss "obvious" features is not that we are incompetent, it's because we don't know the business well enough to ask the right questions.

The house developer showed his clients drawings (models) that they didn't really understand, but still had to accept anyway. The fundamental problem is the developer didn't have a medium he could use to communicate the design effectively to his clients. What he needed was a model that was simple to understand, but still showed the details necessary to make an educated decision about the design of the house. His prototype was simple, yet lacked the required details, while his architectural plans were too complicated. Just like the house developer, as a system developer, you must have a way to communicate your design to your users in a way they can understand.

The developer then went away and built a house that did not meet the needs of its eventual owners. Had the buyer been more involved with the development of the house, he might have realized the house needed to be wired for electricity. This is a fundamental flaw in the way systems are currently developed using structured techniques. Although we know the chance of project success increases as users become more involved in development, users are typically only involved during analysis and user acceptance testing, but not during design and development. You need to find a way to increase the involvement of your users in the development process (in Chapters 3 and 4, you learn techniques to do just that). ...

Project success. A project is considered a success when it is on time, on budget; and meets the needs of its,

Read More Show Less

Table of Contents

Ch. 1 Introduction 1
Ch. 2 Object Orientation: A New Software Paradigm 9
Ch. 3 Gathering User Requirements 31
Ch. 4 Ensuring Your Requirements Are Correct: Requirements Validation Techniques 109
Ch. 5 Understanding The Basics: Object-Oriented Concepts 133
Ch. 6 Determining What to Build: Object-Oriented Analysis 181
Ch. 7 Determining How to Build Your System: Object-Oriented Design 249
Ch. 8 Object-Oriented Testing 347
Ch. 9 Object-Oriented Testing 403
Ch. 10 Putting It All Together: Software Process 427
Ch. 11 Where to Go From Here 455
Glossary 475
References and Recommended Reading 499
Index 505
Read More Show Less



The Object Pprimer is a straightforward, easy-to-understand introduction to object-oriented concepts, requirements, analysis, and design methods applying the techniques of the Unified Modeling Language (UML). Object orientation (00) is the most important change to system development since the advent of structured methods; during the 1990s, it superceded the structured paradigm as the primary approach for software development. While 00 is often used to develop complex systems, learning how to work with object-oriented techniques does not need to be complicated. This book differs from many other introductory books about 00-it is written from- the point of view of a real-world developer, somebody who has lived through the difficulty of learning this exciting software paradigm.

Who Should Read The Object Primer?
If you are a mainframe COBOL or PL/1 programmer who is working on his or her first 00 project, The Object Primer is for you. If you are a business analyst or user representative involved in the documentation of requirements for an 00 application, The Object Primer is for you. If you're a project manager who needs to get up to speed on 00, The Object Primer is for you. If you are a systems designer whose organization is migrating to object technology, The Object Primer is for you. If you are a student taking your first course in Java or C++, The Object Primer is for you. If you're a researcher or an academic interested in arcane software engineering theory, sorry, I can't please everybody. Throughout this book, I use the term "developer" very broadly: a developer is anyone involved in the development of a software application. This includes programmers, analysts, designers, user representatives, database administrators, support engineers, and so on. While many people would not include user representatives in this list, my experience is that active user involvement is often the key determinant to the success of a software project. Users can actively participate in requirements engineering, analysis, and sometimes design-it is clear to me that users should be considered developers. Call me a radical.

Why Read The Object Primer?
By reading The Object Primer you will gain a solid understanding of objectoriented concepts and basic objected-oriented modeling techniques. These are the fundamental skills needed to develop object-oriented applications, particularly C++ and Java-based software. Furthermore, these skills are put into the context of a running example-you see how these skills can be applied in the real world.

Why Read This Book Series?
The Object Primer is the first in a five-volume series describing 00 development techniques and the 00 software process. These books are as follows: The Object Primer - Introduction to 00 concepts and techniques

Building Object Applications - Intermediate 00 modeling, That Work programming, testing, patterns, metrics, user interface design, and persistence

The Elements of Java Style - Tips and techniques for writing high- quality Java source code

Process Patterns - Initiate and construct large-scale, mission-critical software using object technology

Deliver, maintain, and support large- scale, mission-critical software using object technology Why a Second Edition?

When I originally wrote the first edition of The Object Primer, in the autumn of 1994, the object industry was in relative chaos. The notation wars were raging, and although there were seven or eight well-known modeling notations and more than thirty less-popular ones, there wasn't a clear winner yet. Now when I rewrite this book, in the winter of 1999/2000, the Unified Modeling Language is the industry standard. In 1994, user-centered design was a niche concept in the software development environment at best; now usage-centered design techniques such as essential use case modeling are becoming industry norms. In 1994, organizations were not sure whether object technology was something they should adopt, in 2000 object and component technologies are the standards for new development in most organizations. In 1994 Smalltalk, Eiffel, and C++ were vying for language supremacy and in 2000 Java is the clear market winner with a strong following using C++ for performance-critical applications. Times have changed.

What's New in the Second Edition?

The second edition builds on the strengths of the first, and it is simple and easy to understand. However, it goes beyond the first edition by including usage-centered design techniques such as essential use case modeling and essential user interface modeling. It still includes classresponsibility collaborator (CRC) modeling, a key (technique of Extreme Programming (XP). Analysis and design modeling has been expanded to include the primary UML techniques as well as persistence (data) modeling. Chapters showing how to move from design to programming and then into testing have been added to round out the book. Finally, leadingedge development techniques and processes, including patterns and the Unified Process, are included to provide you with a true introduction to the state of the art. Most important, the second edition reflects my additional experiences over the past five years helping individuals learn how to apply object technology effectively across a variety of problem domains.


  • it is short, straightforward, and to the point-it is not wasting your time.
  • it presents a full development lifecycle-there is more to c>0 than just programming)
  • It takes complicated concepts and makes them simple--it will shorten your (earning curve.
  • it is written in the language of developers, not academics-you can understand it.
  • It uses real-world examples and case studies-4t describes realistic applications.
  • It relates new techniques to your current practices you can see where OQ fits in.
  • It provides a smooth transition to object technology your first project can succeed.
Read More Show Less



I was recently surfing the web, and I ran into some very interesting figures. According to the analysts, on the order of 30%-40% of software projects are cancelled. The average software project costs more than double original cost estimates, and a mere 15-20% of all software projects are completed on-time and on-budget. On top of this, there's opportunity cost, which measures the lost business opportunity that could have been seized upon if the project was done correctly from the onset. This opportunity cost is the real problem, and can grow to staggering proportions.

I was befuddled when confronted with this data. Is this really the state of our profession? Apparently so-the numbers do not lie. So what could be the cause of these catastrophic failures?

One obvious answer is lack of sufficient developer resources on projects. We are living in an era where the developer reigns king, and is a highly prized possession, scarce to be found. The result of this is an outstanding supply/demand imbalance in IT.

However, this is only the tip of the iceberg. There are a host of other factors that contribute to failure as well. Examples are poor software developing processes, not engaging users during the development process, and improper use of object-oriented analysis and design.

The good news is that we can change these factors through education. By properly learning correct software development best practices, you can avoid the stumbling blocks that have plagued the rest of the industry. Sidestepping those landmines is critical, especially when time-to-market is measured in the order of weeks, not months or years.

This book is the best starting point for learning object-oriented best practices. When you read this book, Scott Ambler will explain a wide array concepts and paradigms to you which you can apply immediately in your software development. The concepts are conveyed in an easy-to-understand, jovial manner, so that any developer, regardless of background, can harness these concepts.

I firmly believe that reading this book will increase your chances of project success. It will also force you to raise the bar for what you deem acceptable when performing software development, which increases your marketability as an individual developer.

I wish you the best of luck in your projects. Let's work together to better ourselves.

Ed Roman
CEO, The Middleware Company

Read More Show Less

Customer Reviews

Average Rating 5
( 1 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted July 26, 2005

    Timeless Principles

    I've been looking at the online text of Scott's Object Primer 3/e and just ordered my own copy, because he's the first person I've seen other than Ivar Jacobsen to get Use Cases completely right. I have been using Use Cases since before UML 1.0 and I have always been disappointed by the general inability of practitioners to understand and apply the extend and include dependencies (and their predecessors.) Many practitioners advise against the use of these dependencies (which is better than using them incorrectly or inconsistently.) I have found no tool that implements them completely and correctly. I was pleasantly surprised to find that Scott Ambler's treatment of these dependencies in the Object Primer 3/e matched my own experience applying them in many environments. First, he states they should be used sparingly. (Overly complex collections of use cases and diagrams are not helpful to anyone.) Second, he has a consistent notation for the point at which each extend or include dependency is invoked. (Some practitioners state that the base use case should not have a reference to the extension, others leave off references to included use cases - neither of these practices is consistent with UML 2.0.) These are simple principles, but not following them has caused many people to get far less out of their use cases than they could have.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)