Object-Oriented Methods: A Foundation, UML Edition / Edition 2

Object-Oriented Methods: A Foundation, UML Edition / Edition 2

ISBN-10:
0139055975
ISBN-13:
9780139055973
Pub. Date:
11/26/1997
Publisher:
Pearson Education

Hardcover

Current price is , Original price is $86.65. You
Select a Purchase Option (2ND)
  • purchase options

Overview

Object-Oriented Methods: A Foundation, UML Edition / Edition 2

This is an essential guide to understanding object orientation using the new Unified Modeling Language (UML). James Odell and James Martin build a foundation that can be used to communicate with others using the new UML standard. Furthermore, they explain precisely how to build UML models based on ideas that are fundamental to human thinking-not just program-language specification. Finally, they show how their object-oriented foundation can be used to generate fully executable programs as well as to model and reengineer business processes and to integrate virtually any new technology.

Object-Oriented Methods: A Foundation, UML Edition brings together all the basic ideas needed to specify any system, presenting a formally based foundation that can be understood by both "real-world" developers and formalists. It includes extensive examples and review questions and reflects recent work by the OMG's Object Analysis and Design Task Force. Based on the UML meta-model and notation, Odell and Martin:

  • Present the fundamental concepts of object orientation using the UML model and notation.
  • Provide a sound approach to modeling systems that is completely independent of programming considerations.
  • Clarify how to conceptualize system requirements using an OO approach that leads to sound design and programming efforts.
  • Show how an OO approach encourages serial, concurrent, and synchronized processing specification and incorporates event-driven and component-based technology.
  • Demonstrate how to develop systems that evolve with future changes in technology.
  • Identify powerful ways to reflect-and extend-OO concepts in the enterprise repository and data warehouse.

Shows how OO can organize and interconnect many other systems approaches, including business rules, logic, functions, neural nets, SQL, and client-server.

With exceptional insight and clarity, Object-Oriented Methods: A Foundation, UML Edition presents the best available approach to developing systems today-and planning for tomorrow.

JAMES MARTIN SEMINARS are presented directly by James Martin + Co., 3050 Chain Bridge Road, Suite 600, Fairfax, VA 22030, U.S.A. Tel: 800-248-4562.

http://www.phptr.com @ISBN: 0-13-905597-5

Product Details

ISBN-13: 9780139055973
Publisher: Pearson Education
Publication date: 11/26/1997
Edition description: 2ND
Pages: 432
Product dimensions: 7.24(w) x 9.56(h) x 0.77(d)

Read an Excerpt

PREFACE: PREFACE

What if there were a standard set of core concepts for object-oriented analysis and design (OO A&D)? What if there were a prescribed set of diagrams for communicating these concepts? Imagine how much simpler our OO A&D world would be—not to mention the world of OO-CASE vendors. We could all speak a common OO A&D language, rather than some dialect based on a particular methodologist or OO-CASE vendor. I'm not sure such an event would ever meet everyone's satisfaction. Furthermore, I'm not sure that one fixed set of diagrams can (or should) express everything we need to say. But, a way to express most of our A&D knowledge is now available. With the OMG's Object Analysis and Design Taskforce (OA&DTF) a standard now exists for:

  • a common meta-model for maintaining our OO A&D knowledge,
  • a technique for exchanging this knowledge, and
  • a notation for expressing our OO A&D knowledge.



A Little History

Grady Booch was the first to organize an OO A&D standardization effort. In the spring of 1993, he asked a handful of major methodologists if they wished to create an OO A&D standard. (Jim Rumbaugh, Ivar Jacobson, Stephen Mellor, Peter Coad, and I were included.) However, assembling these people for even one day proved too daunting as we could only agree on a short breakfast meeting at OOPSLA Ô93 in Washington, DC. Since the idea of standardization was considered undesirable by the majority at the meeting, the standards movement floundered—but not for long.

In October 1994, Rational Software Corporation succeeded in hiring Jim Rumbaugh. With the combined force of Booch andRumbaugh, Rational decided to produce its own standard approach, then called the Unified Method. Its rollout occurred at OOPSLA '95 in Austin accompanied by singing (Jim) and merriment (Grady). When Ivar Jacobson joined Rational about a year later, the resulting unified approach became stronger and broader. Soon, Rational's approach—now called the UML (Unified Modeling Language)—became a unification of more than Booch, Rumbaugh, and Jacobson. Literally dozens of other methodologists and organizations became part of an effort known as the UML Partners.



Enter the OA&D Task Force

By 1995, OO A&D unification and standardization were certainly in the wind and on June 29, 1995, an old special interest group was revived within the OMG (thanks to Richard Soley and Ivar Jacobson). This renewed special interest group became known as the Object Analysis and Design Task Force (OA&DTF) and was co-chaired by Mary Loomis and me. Its bimonthly meetings are usually attended by 30 to 90 individuals representing dozens of companies. After an initial period of data gathering and discussion in 1995, the OA&DTF submitted its first Request for Proposal (RFP) in June 1996. All submissions to this RFP were required to:
  • define a meta-model that represented the semantics of object analysis and design models.
  • define the OMG's IDL (Interface Definition Language) interfaces that enable models or model elements created by one tool to be accessed from another tool. The model access facility had to be either an import facility or a connection facility or both.
  • provide a set of notations for representing models.
  • include a "proof of concept" statement, explaining how the submitted specifications have been demonstrated to be technically viable.
  • accommodate evolution of models and incorporation of additional semantics over time.



Who responded to the RFP?

Those organizations that responded include: Hewlett-Packard, I-Logix, ICON Computing, IntelliCorp, IBM, MCI Systemhouse, Microsoft, ObjecTime Limited, Oracle, Platinum Technology, PTech, Rational Software Corporation, Reich Technologies, Softeam SA, Taskon A/S, Sterling Software (formerly Texas Instruments Software), and Unisys. On January 17, 1997, these companies coordinated their responses, resulting in six submissions. In the months that followed, the effort was unified into a single proposal. On September 1, 1997, all 18 organizations presented the UML proposal to the OMG.



Conclusion

In summary, the OA&D facility is expected to implement the interfaces that would enable tool builders to provide facilities for tool users to:
  • extend and augment a model produced by another conforming tool.
  • use a model produced by another conforming tool in the course of producing a different but related model.
  • Additionally, this RFP resulted in a standard notation for users to express their models.



A few years ago, such a facility was hoped for and dreamed about—but hardly considered feasible. Now, there is a standard defining the core concepts for OO analysis and design and a prescribed set of diagrams for communicating these concepts.

While this standard will not solve all our problems, it will reduce the Babel-ization surrounding OO A&D communications. Furthermore, it will provide a kind of Rosetta Stone for communicating various kinds of OO A&D specifications. We can then put more effort into what we're communicating—and not so much into how we communicate it. Imagine a world where an OO developer can spend less time in religious battles about notation and more time on the quality of communication.



This book was revised in this spirit.

James J. Odell

Table of Contents

1. Introduction.

I. The Basic OO Foundation: Object Structure.

2. Concepts.
Concepts and Reality. Documenting Concepts. Domains. Summary. Review Questions. References.

3. Objects.
Objects. Object Lifecycles. Summary. Review Questions. References.

4. Concept Versus Type.
Why Change Terms Now? The Intension and Extension of Concept/Type. Summary. Review Questions.

5. Connecting Objects.
Connections. Relationships. Mappings. Mappings and Relationships: Two Sides of the Same Coin. Summary. Review Questions. References.

6. Mappings.
Mappings and Their Reverse. Cardinality Constraints. Object Properties. Base and Derived Mappings. Type-Level Mappings. Summary. Review Questions.

7. Associations.
Associations as Relationships. Associations as Types. Three Common Representations of Associations. Expressing History. Summary. Review Questions. References.

8. Handling Object Complexity.
Classification. Generalization. Aggregation. Other Mechanisms for Handling Object Complexity. Summary. Review Questions. References.

9. Subtypes and Supertypes: Part I.
Generalization. Type Partitions. Complete Versus Incomplete Partitions. Multiple Supertypes. Generalization and Inheritance. Summary. Review Questions. References.

10. Subtypes and Supertypes: Part II.
Levels of Generalization. Association Subtypes. Derived Types and Partitions. Summary. Review Questions. References.

11. States.
What is State? State and Time. State and Mappings: A Closer Look. Naming States. Summary. Review Questions.

II. THE BASIC OO FOUNDATION: OBJECT BEHAVIOR.


12. State Changes.
Object State Changes. Summary. Review Questions.

13. Events.
Events Versus State Changes. Basic Events. Compound Events. Event Prestates and Poststates. Internal, External, and Temporal Events. Event Occurrences and Events. Events Are Object History. Summary. Review Questions.

14. Operations.
Operation Basics. Operation Input Variables. Operation Output Variables. Operations and Their Events. Preconditions and Postconditions. Operations as Clocks. Summary. Review Questions. References.

15. Methods.
The Basics of Methods. Operations Can Consist of Other Operations. Methods Are Isolated from Cause-and-Effect Considerations. Methods as Structured Specifications. Cohesion and Coupling. Local and Input/Output Variables. Multiple Methods for an Operation. Summary. Review Questions. References.

16. Triggers.
Trigger Basics. Triggers and Their Mappings. Multiple Invocations. Triggers that Use Local Variables. Data Flows Versus Triggers. Summary. Review Questions.

17. Control Conditions.
Control Condition Basics. Control Conditions Provide Synchronization. Control Conditions Provide Branching. Multiple Synchronizations. Expressing Conditional Statements. Notation Summary. Summary. Review Questions.

III. The Extended Level OO Foundation.


18. Aggregation.
Kinds of Aggregation. Nonaggregational Relationships. Summary. Review Questions. References.

19. Constraints.
Beyond Zero, One, and Many Cardinalities. Constraints on Mapping to Collections. Constraints on Mapping to Duplicate Objects (Bags). Constraints on Mappings where Duplicates Are Not Allowed (Sets). Constraining the Order of Objects (Tree, Lattice, etc.). Common Association Constraints. Immutable Mapping Constraints. Uniqueness Constraints. Using Constraints with Generalization and Aggregation. Other Mapping Constraints. Behavioral Constraints. Summary. Review Questions. References.

20. Rules.
Introduction to Rules. Rules Expressed in Natural Language. Categories of Rules. Global, Local, and Temporal Application of Rules. Summary. Review Questions. References.

21. Using Rules with Diagrams.
Using Rules and/or Diagrams. Rules and OO. Attaching Rules to Diagrams. Rule Syntax: Executability Versus Readability. Summary. Review Questions.

22. Meta-Modeling.
Meta-Modeling Basics. Representation of Meta-Model Constructs. Extending the Meta-Model. Summary. Review Questions. Reference.

23. Power Types.
Introduction to the Need for Power Types. Power Types and Their Representation. Implementing Power Types. Summary. Review Questions.

IV. Representing OOA Constructs.


24. Representing Object Structure.
Interpreted Predicate Logic Models. Binary-Relationship Models. Entity-Relationship-Attribute Models. The Ramifications of Types for OO Design. Ensuring ERA Models Support OO Design. Should Mappings Be Labeled with Nouns or Verbs? Summary. Review Questions. References.

25. Approaches to Object Structure Modeling.
Introduction. Booch Class Diagrams. Coad/Yourdon OOA Model. OMT Object Model. Shlaer/Mellor Information Structure Diagram. Jacobson Analysis Model Diagram. Summary. Review Questions. Reference.

26. Representing Object Behavior.
Introduction. Finite-State Machines. Scenario-based Specification. Decision-based Specification. Language-based Specification. Summary. Review Questions. References.

27. Approaches to Finite-State Machine Modeling.
Varieties of FSMs. Behavior between Types. When to Use or Avoid FSM-based Representation. Summary. Review Questions. References.

28. Approaches to Scenario-Based Modeling.
Scenarios. Specific Scenarios. General Scenarios. Validation with Scenarios. Discovery with Scenarios. Caveats about Scenarios. Review Questions. References.

29. Other Modeling Approaches.
Context Specification. Functional Specification. Decomposition in Terms of Types. Other Representations. Summary. Review Questions. References.

V. DESIGN AND IMPLEMENTATION.


30. Considerations for Design and Implementation.
Design and OO. Design and Relational Databases. OO Analysis and Non-OO Design. Representing Design Constructs. Conclusion. Review Questions. Reference.

VI. APPENDIX.


A. Glossary of Terms.
B. Summary of Diagram Symbols.
Basic Class Diagram Notation. Basic Activity Diagram Notation. Basic Object-Flow Diagram Notation. Diagram Layering.

C. Order Processing Modeling Example.
About the Model. Glossary Notation. Order Processing System Description. Class Diagram and Glossary. Activity Diagram and Glossary.

D. Toward a Formalization of OO Analysis.
Introduction. Concepts. Classification Relations. Generalization/Specialization Relations. Relations in General. Functions. Attributes, Roles, and Invariants. Conclusion.

References.
Index.

Preface

PREFACE: PREFACE

What if there were a standard set of core concepts for object-oriented analysis and design (OO A&D)? What if there were a prescribed set of diagrams for communicating these concepts? Imagine how much simpler our OO A&D world would be—not to mention the world of OO-CASE vendors. We could all speak a common OO A&D language, rather than some dialect based on a particular methodologist or OO-CASE vendor. I'm not sure such an event would ever meet everyone's satisfaction. Furthermore, I'm not sure that one fixed set of diagrams can (or should) express everything we need to say. But, a way to express most of our A&D knowledge is now available. With the OMG's Object Analysis and Design Taskforce (OA&DTF) a standard now exists for:
  • a common meta-model for maintaining our OO A&D knowledge,
  • a technique for exchanging this knowledge, and
  • a notation for expressing our OO A&D knowledge.



A Little History

Grady Booch was the first to organize an OO A&D standardization effort. In the spring of 1993, he asked a handful of major methodologists if they wished to create an OO A&D standard. (Jim Rumbaugh, Ivar Jacobson, Stephen Mellor, Peter Coad, and I were included.) However, assembling these people for even one day proved too daunting as we could only agree on a short breakfast meeting at OOPSLA Ô93 in Washington, DC. Since the idea of standardization was considered undesirable by the majority at the meeting, the standards movement floundered—but not for long.

In October 1994, Rational Software Corporation succeeded in hiring Jim Rumbaugh. With the combined force of BoochandRumbaugh, Rational decided to produce its own standard approach, then called the Unified Method. Its rollout occurred at OOPSLA '95 in Austin accompanied by singing (Jim) and merriment (Grady). When Ivar Jacobson joined Rational about a year later, the resulting unified approach became stronger and broader. Soon, Rational's approach—now called the UML (Unified Modeling Language)—became a unification of more than Booch, Rumbaugh, and Jacobson. Literally dozens of other methodologists and organizations became part of an effort known as the UML Partners.



Enter the OA&D Task Force

By 1995, OO A&D unification and standardization were certainly in the wind and on June 29, 1995, an old special interest group was revived within the OMG (thanks to Richard Soley and Ivar Jacobson). This renewed special interest group became known as the Object Analysis and Design Task Force (OA&DTF) and was co-chaired by Mary Loomis and me. Its bimonthly meetings are usually attended by 30 to 90 individuals representing dozens of companies. After an initial period of data gathering and discussion in 1995, the OA&DTF submitted its first Request for Proposal (RFP) in June 1996. All submissions to this RFP were required to:
  • define a meta-model that represented the semantics of object analysis and design models.
  • define the OMG's IDL (Interface Definition Language) interfaces that enable models or model elements created by one tool to be accessed from another tool. The model access facility had to be either an import facility or a connection facility or both.
  • provide a set of notations for representing models.
  • include a "proof of concept" statement, explaining how the submitted specifications have been demonstrated to be technically viable.
  • accommodate evolution of models and incorporation of additional semantics over time.



Who responded to the RFP?

Those organizations that responded include: Hewlett-Packard, I-Logix, ICON Computing, IntelliCorp, IBM, MCI Systemhouse, Microsoft, ObjecTime Limited, Oracle, Platinum Technology, PTech, Rational Software Corporation, Reich Technologies, Softeam SA, Taskon A/S, Sterling Software (formerly Texas Instruments Software), and Unisys. On January 17, 1997, these companies coordinated their responses, resulting in six submissions. In the months that followed, the effort was unified into a single proposal. On September 1, 1997, all 18 organizations presented the UML proposal to the OMG.



Conclusion

In summary, the OA&D facility is expected to implement the interfaces that would enable tool builders to provide facilities for tool users to:
  • extend and augment a model produced by another conforming tool.
  • use a model produced by another conforming tool in the course of producing a different but related model.
  • Additionally, this RFP resulted in a standard notation for users to express their models.



A few years ago, such a facility was hoped for and dreamed about—but hardly considered feasible. Now, there is a standard defining the core concepts for OO analysis and design and a prescribed set of diagrams for communicating these concepts.

While this standard will not solve all our problems, it will reduce the Babel-ization surrounding OO A&D communications. Furthermore, it will provide a kind of Rosetta Stone for communicating various kinds of OO A&D specifications. We can then put more effort into what we're communicating—and not so much into how we communicate it. Imagine a world where an OO developer can spend less time in religious battles about notation and more time on the quality of communication.



This book was revised in this spirit.

James J. Odell

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews