In this section we tour the book's optional case study on object-oriented design with the UML. This tour previews the contents of the nine Software Engineering Case Study sections (in Chapters 1, 3-9 and 11). After completing this case study, you will be thoroughly familiar with an object-oriented design and implementation for a significant C# application.
The design presented in the ATM case study was developed at Deitel & Associates, Inc. and scrutinized by industry professionals. Our primary goal throughout the design process was to create a simple design that would be clear to OOD and UML novices, while still demonstrating key OOD concepts and the related UML modeling techniques.
Section 1.9-(Only Required Section of the Case Study) Software Engineering Case Study: Introduction to Object Technology and the UML-introduces the object-oriented design case study with the UML. The section presents the basic concepts and terminology of object technology, including classes, objects, encapsulation, inheritance and polymorphism. We discuss the history of the UML. This is the only required section of the case study.
Section 3.10-(Optional) Software Engineering Case Study: Examining the ATM Requirements Document-discusses a requirements document that specifies the requirements for a system that we will design and implement-the software for a simple automated teller machine (ATM). We investigate the structure and behavior of object-oriented systems in general. We discuss how the UML will facilitate the design process in subsequent Software Engineering Case Study sections by providing several additional types of diagrams to model our system. We include a list of URLs and book references on object-oriented design with the UML. We discuss the interaction between the ATM system specified by the requirements document and its user. Specifically, we investigate the scenarios that may occur between the user and the system itself-these are called use cases. We model these interactions, using UML use case diagrams.
Section 4.11-(Optional) Software Engineering Case Study: Identifying the Classes in the ATM Requirements Documents-begins to design the ATM system. We identify its classes by extracting the nouns and noun phrases from the requirements document. We arrange these classes into a UML class diagram that describes the class structure of our simulation. The class diagram also describes relationships, known as associations, among classes.
Section 5.12-(Optional) Software Engineering Case Study: Identifying Class Attributes in the ATM System-focuses on the attributes of the classes discussed in Section 3.10. A class contains both attributes (data) and operations (behaviors). As we see in later sections, changes in an object's attributes often affect the object's behavior. To determine the attributes for the classes in our case study, we extract the adjectives describing the nouns and noun phrases (which defined our classes) from the requirements document, then place the attributes in the class diagram we created in Section 3.10.
Section 6.9-(Optional) Software Engineering Case Study: Identifying Objects' States and Activities in the ATM System-discusses how an object, at any given time, occupies a specific condition called a state. A state transition occurs when that object receives a message to change state. The UML provides the state machine diagram, which identifies the set of possible states that an object may occupy and models that object's state transitions. An object also has an activity-the work it performs in its lifetime. The UML provides the activity diagram-a flowchart that models an object's activity. In this section, we use both types of diagrams to begin modeling specific behavioral aspects of our ATM system, such as how the ATM carries out a withdrawal transaction and how the ATM responds when the user is authenticated.