- Shopping Bag ( 0 items )
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.
...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.
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).
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).
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."
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,
|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|
|References and Recommended Reading||499|
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.
ADVANTAGES OF THIS BOOK SERIES
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.
CEO, The Middleware Company
Posted July 26, 2005
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 NoThank you for your feedback. Report this reviewThank you, this review has been flagged.