Uml and C: A Practical Guide to Objectoriented Development - Softcover

Lee, Richard C.; Tepfenhart, William M.

Softcover

ISBN 10: 0130290408 ISBN 13: 9780130290403

Publisher: Prentice Hall, 2000

Synopsis

(Pearson Education) A practical tutorial in doing object-oriented modeling using UML notation and implementing the model using C++. An introduction to the fundamental skills that make this possible. Gives readers a recipe to do all of the steps of object oriented technology. Previous edition: c1997. Softcover. DLC: Object-oriented programming (Computer science).

About this title

About the Author

RICHARD LEE has more than 35 years of experience developing and managing software projects. He has worked and/or managed leading-edge development in electronic publishing, embedded systems, large IMS projects, multi-media, operating support systems, process control, transaction processing, and switching. Being one of the earlier adopters of object-oriented technology, his current interest is making more object-oriented projects successful.

WILLIAM TEPFENHART is currently an Associate Professor in the Software Engineering Department at Monmouth University. He has eighteen years of experience developing manufacturing, military, and telecommunications applications as a programmer, developer, and technologist. He has developed object-oriented systems over the past 17 years. He is one of the developers of a compiler for R++ (a programming language that adds rules to C++).

From the Back Cover

This practical book by two industry leaders continues to be a self-teaching guide for software analysts and developers. This revised edition teaches readers how to actually do object-oriented modeling using UML notation as well as how to implement the model using C++. The authors introduce all of the basic object-oriented fundamentals necessary so readers can understand and apply the object-oriented paradigm.

FEATURES

• Teaches readers to build an object-oriented application using C++ and make the right trade-off decisions to meet business needs.
• Exposes a number of the myths surround object-oriented technology while focusing on its practicality as a software engineering tool.
• Gives readers a "recipe or step-by-step guide to do all of the steps of object-oriented technology.
• Provides a practical approach to analysis, design, and programming in the object-oriented technology.

NEW TO THE SECOND EDITION

• Gives a practical approach for the development of use cases as part of object-oriented analysis.
• Provides greater coverage of UML diagramming.
• Introduces key C++ libraries that provide important functionality, supporting implementation of an object-oriented model in C++.
• Improved coverage of dynamic behavior modeling, implementation of the state model, and class projects.

From the Inside Flap

Preface

UML and C++: A Practical Guide to Object-Oriented Development continues to be aimed at busy professional software analysts and developers who work on large systems, especially those who need to integrate their new systems with legacy systems. If you do not have time to take a class yet and get up-to-speed on object-oriented (OO) technology using Unified Modeling Language and C++, this book is a self-teaching guide for you. It will help you understand the differences between OO analysis, OO design, and OO programming. Our goals in the first edition were to:

Teach you to build an object-oriented application using C++ and make the right trade-off decisions to meet your business needs; Clarify the basic concepts associated with object-oriented technology; Supply sufficient depth in coverage for students and practitioners entering the field to get them up to speed; Expose some of the myths surrounding OO technology while focusing on its practicality as a software engineering tool; Give you a "recipe" or step-by-step guide to do all of the steps of object-oriented technology; Advocate the view that OO, rule-based concepts, fuzzy logic, multimedia, and data modeling integrated into a single model can address the current and future business challenges for information technology organizations; Provide a practical approach to analysis, design, and programming in the OO technology. Show how to implement OO technology using C++ (though not an object-oriented language it is an extremely powerful multi-paradigm language); and Balance theory with application practices in the existing literature.

This, the second edition, has extended those goals to include:

Give a practical approach for the development of use cases as part of OO analysis; Provide greater coverage of UML diagramming; and Introduce key C++ libraries that provide important functionality supporting implementation of an OO model in C++.

In addition, the second edition made improvements on the following topics:

Dynamic behavior modeling Implementation of the state model Class projects

As always, you do not have know computer science or advanced mathematics to understand the important object-oriented concepts and issues in depth. Even the programming chapters do not require a background in C++; they illustrate how working rode in C++ is produced. Object-Oriented Technology

We are software developers of large systems. We believe that OO technology is the most important software evolution (revolution) of the 1990s. It is changing the way we build software and the way applications intercommunicate over worldwide networks and across mufti-vendor computers. Moreover, the OO model is changing the way we design business processes and the way we think about an enterprise. Most enterprises need redesigning today in order to meet future business challenges.

Business process redesign is one of the most important functions of an information technology organization. A model that captures the business processes, procedures, policies, and rules facilitates design. Tools that translate the model into an operational system speed the implementation of the redesign. When the market or business condition changes, these systems should be regenerated to reflect these changes by updating the model and using these tools. Information science (engineering) has taken us further and faster than any other approach in previous decades. However, it needs constant updating through even better, more refined methods to meet our business needs and challenges through OO modeling and OO programming. More and more people believe that OO technology will put a dent into the software crisis, meaning that the mechanisms of OO will become for software what the bolts and beams are for the construction design and what the chip is for computer hardware design. This belief stems from the following:

The proficiency of a higher-level OO model should provide the software designer with real-world, programmable components, thereby reducing software development costs. Its capability to share and reuse code with OO techniques will reduce time to develop an application. Its capability to localize and minimize the effects of modifications through programming abstraction mechanisms will allow for faster enhancement development and will provide more reliable and more robust software. Its capability to manage complexity allows developers to address more difficult applications.

The collection of OO concepts is a tool set for modeling reality. This OO tool set gives developers the best means of managing the complexity. Certain OO concepts help developers produce flexible and maintainable software. Why Unified Modeling Language?

As practitioners of OO technology, we know that all of the methods, if practiced properly, result in the same or a similar model. For many years, the number of different modeling language notations were impediments to progress and we adopted UML before it was widely accepted or supported by modeling tools. The wide acceptance of UML has eliminated these problems—different modeling language notations and scarcity of modeling tools—for the most part.

Underlying the reason for the success of the Unified Modeling Language is that it gives us all the drawing icons necessary to capture most of the concepts or mechanisms that we find valuable in solving real business problems. Also, it provides all of the necessary diagrams that are vital for documenting our models. In addition, it is a living language that gives us the ability to extend the notation for mechanisms not yet defined by the distinguished group of Grady Booch, James Rumbaugh, and Ivor Jacobson at Rational Software Corporation. Why C++?

It is a misconception that C++ is exclusively an OO programming language. It is a multi-paradigm language that supports a number of programing paradigms, including procedural, abstract data type, and OO. We show you how to map your OO model into the C++ constructs using the OO paradigm in C++. We also show you how to use other non-OO concepts of the language in the context of OO design to help you meet your business needs.

C++ is our language of choice for two practical reasons. First and foremost, most developers have to address real constraints: interfacing to legacy systems and technical limitations on databases, storage, and performance. C++ gives developers multiple paradigms that they can tune as needed. Second, vendors supplying tools and compilers have put their money on C++. Our Approach to Object-Oriented Technology

We are not OO purists, nor are we theorists. We are developers who are willing to use any good idea that will help us achieve two very critical business goals: lower development costs and reduce time-to-market for enhancements. We believe that these technical objectives—reliability, maintainability, and flexibility—are critical to meeting these business goals.

Our approach to using OO technology is to manage the complexity of developing software so that it is reliable, maintainable, and flexible. Managing complexity is the key to achieving these objectives and, thus, our business goals. To manage complexity in complex problem domains, we find that the developers are required to know how objects, classes, relationships, and rules fit into the object paradigm. When we model most complex problem domains, we find objects, classes, and many relationships among objects. In addition, we need to capture the rules (policies) within that domain. Thus, we have to use very rich static modeling techniques to capture the data (object) relationships.

Many OO experts consider relationships as "bad" because they violate the encapsulation principle. From our perspective, it helps us manage the complexity of the problem domain and helps us to achieve our business goals. We gladly use it and we look for more mechanisms and language support in this area. In Chapter 9 on declarative semantics, we write that rules and policies should be captured as an integral part of our model and not in special subsystem extensions.

Using mechanisms to help us model complex problem domains is consistent with our choice of UML as our modeling language and C++ as our programming language. Both UML and C++ allow us to define any needed mechanism that helps us to build more manageable software.

We discuss behaviors (dynamic and static) and polymorphism for capturing the procedural aspects of the model. The use of a finite state machine or some other state model helps us manage procedural complexity while addressing timing, synchronization, and interrupts. These areas are generally ignored or overlooked by most OO books. We do not address these issues in depth, but we lay the foundation so the reader can make use of the semantics added to UML.

We believe the key to success in building large OO systems requires that developers/ programmers know more than what is taught in most OO books. Building large systems requires using mechanisms promoted by some OO experts but not accepted by all. Professional developers need to at least understand how these aspects of the problem domain can be handled before they can be a productive team member. This book will not make you an expert. You still need experts /consultants to develop the system. By applying the 80/20 rule, this book provides the 80% that can make you productive and understand how the experts solve the difficult 20%.

In this book we do not cover the latest trends or fads in OO technology, including object design patterns and distributed object computing. Although they are interesting, we are not convinced that they contribute significantly to our goal of providing a practical framework for enabling developers new to OO programming to get up to speed as soon as possible. Design patterns are proven techniques that enhance good OO practices and were not intended to be a paradigm by themselves. We still believe that learning the basic fundamentals of OO is essential to the correct application of design patterns. Distributed computing is being made as transparent to application developers as possible via well-written middleware. We expect that the infrastructure vendors will eventually make this technology issue transparent to the application domain.

Finally, we do not agree with most experts that OO technology is a mature technology. We believe it is in its infancy; what impresses us is how much we can accomplish with such an infant technology. Object-oriented technology has the enormous potential to help us manage complexity that did not exist with the earlier technologies (procedural, functional, rule-based, etc.). Organization of the Book

We take the reader through our rationale in applying OO techniques and methods. These are not a set of absolute laws. Our goal is to make you think about good OO concepts and good design principles when developing software and programming in C++. In the case study, we take a project through all of the steps of OO analysis, design, and coding, using specific OO techniques and applying fundamental OO concepts. The design is implemented in C++ with performance enhancements techniques of C++.

This book was originally written to be a self-teaching guide that should be read in sequential order. We have kept this aspect of the book the same. Each chapter discusses a major step of our approach to OO technology. Most chapters conclude with a step-by-step guide or recipe. We hope the reader will use these steps as a guide only; always rely on common sense rather than following prescribed steps blindly.

Chapter 1 provides the reasons why companies are interested in OO and why a software professional should understand OO. Chapter 2 addresses the business of software and the need to manage complexity. Chapter 3 describes how to find the basic terminology and key concepts in OO technology. Chapter 4 describes how to employ use cases to bound the domain to relevant objects. Chapter 5 describes how to find potential objects, the first step employing OO technology. Chapter 6 describes how to differentiate between "real" objects and "false" objects by identifying attributes (data) and services associated with the object. Chapter 7 demonstrates how to capture an object's behavior. Chapter 8 describes how to identify and describe dynamic behavior. Chapter 9 describes the various relationships (generalization/ specialization, link, object aggregation, etc.) that are available for organizing all objects in a system. Chapter 10 describes how to incorporate declarative facts into the OO model about object knowledge and a rule-based mechanism for their implementation. Chapter 11 describes how we can make objects into classes to take advantage of the mechanisms of C++. Chapter 12 addresses some design issues with OO system development. Chapter 13 provides C++ basics necessary to perform OO programming using C++. (Readers who are familiar with C++ can skip this chapter.) Chapter 14 teaches you how to implement a class, which is a template for creating objects. Chapter 15 introduces the C++ libraries for use in the subsequent chapters. Chapter 16 teaches you how to implement the behavior specifications developed in Chapter 6. Chapter 17 teaches you how to implement the dynamic behavior developed in Chapter 8. Chapter 18 addresses how to create and destroy objects using the class mechanism of C++. Chapter 19 addresses how to implement generalization/ specialization (one of the key OO concepts) by using the class derivation mechanism of C++. Chapter 20 addresses how to implement other relationships not supported by C++. Chapter 21 introduces the two case studies. Chapter 22 presents a case study based on the Breakout game. Chapter 23 presents a case study for a microwave oven. Appendix A presents a summary of the Unified Modeling Language. Use of this Book as a Text

This book arose out of industrial courses attended by competent programmers who knew nothing about OO and C++. This material was taught in two courses of 1 week in duration. The first course covered the material of the first 13 chapters and the second course covered the remainder of the material. At the end of the second course, the students had a fully functional program that reflected the design achieved at the end of the first course. The case study at the end of this book was the project implemented by the students in this course. This book continues to support this instructional context.

At present, one of the authors teaches a one-semester course that covers the first 13 chapters of the book to university students who already know C++. He continues to teach this material in conjunction with a project, depending upon the project rather than homework to reinforce the concepts. Use of a significant project allows the student to apply the concepts as they are learned. Following the whole process of performing an OO analysis and design for a project seems to work much better than a large number of discrete, unrelated homework problems. A significant analysis and design model can be completed in one semester. A second semester is necessary to implement the model.

The selection of a project of suitable scale enables a student to master all of the key concepts. Bill Tepfenhart, the instructor, assigns a large adventure game as a project and allows students to develop their own theme for it. Completed projects typically consist of more than 1OO classes and just as many relationships. The games typically incorporate many different kinds of terrain, weapons, monsters, treasures, and characters. Some of the games have a complexity equivalent to many commercially available products.

A reasonable project team consists of three or four students. A larger team tends to spend too much time coming to agreement on the game theme and a smaller team tends to get overwhelmed. This team size has the further advantage that individual team members get a taste of what it is really like to work as part of a development team. They have to work on it weekly in order to complete the project within an allotted time frame.

Edition details

• Publisher: Prentice Hall
• Publication date: 2000
• ISBN 10: 0130290408
• ISBN 13: 9780130290403
• Binding: Paperback
• Language: English
• Number of pages: 57