Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

The Object Primer: The Application Developer's Guide to Object-Orientation and the UML

The Object Primer: The Application Developer's Guide to Object-Orientation and the UML

by Scott W. Ambler
Scott Ambler, 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, now this book is completely up-to-date with new material in every chapter.


Scott Ambler, 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, now this book is completely up-to-date with new material in every chapter. There are also new chapters on good OO programming techniques and OO software testing. All modeling notation has been rewritten in UML notation. 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.

Editorial Reviews

From the Publisher
'Overall an introduction to OO software in structured steps written in a teachign style, easy to read for a novice.' CVu
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 (booknews.com)

Product Details

Cambridge University Press
Publication date:
Managing Object Technology Series , #20
Edition description:
Product dimensions:
6.97(w) x 9.21(h) x 1.18(d)

Related Subjects

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,

Meet the Author

Scott Ambler is an instance of an OOConsultant for roninIntemational (www ronin-ind.com) based in denverColorado. roninInternational implements objectArchitectureConsulting(), cornponentArchltectureConsultingU, and softwareProcessConsulting() operations. Instances of HumanoidLifeForm can send email messages to him at:scott.ambler@ronin-intl.com

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. sdmagazine.com) 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. ambysoft.com, where he has posted a collection of WhitePaper objects and other software development resources.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews