Visual CSharp 2005 - How To Program, 2nd Edition (2005)

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 Software Engineering Case Study sections (in Chapters 1, 39, 11 and Appendix J). 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 academic and industry professionals. Our primary goal 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.17(Only Required Section of the Case Study) Software Engineering Case Study: Introduction to Object Technology and the UMLintroduces the objectoriented design case study with the UML. The section presents 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 Documentdiscusses a requirements document that specifies the requirements for a system that we will design and implementthe 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 objectoriented design with the UML. We discuss the interaction between the ATM system and its user. Specifically, we investigate the scenarios that may occur between the user and the system itselfthese 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 Documentsbegins 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 Systemfocuses 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.10(Optional) Software Engineering Case Study: Identifying Objects' States and Activities in the ATM Systemdiscusses how an object, at any given time, occupies a specific condition called a state. A state transition occurs when the 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 activitythe work it performs in its lifetime. The UML provides the activity diagrama 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.

Section 7.15(Optional) Software Engineering Case Study: Identifying Class Operations in the ATM Systemidentifies the operations, or services, of our classes. We extract from the requirements document the verbs and verb phrases that specify the operations for each class. We then modify the class diagram of Section 3.10 to include each operation with its associated class. At this point in the case study, we will have gathered all information possible from the requirements document. As future chapters introduce such topics as inheritance, we will modify our classes and diagrams.

Section 8.14(Optional) Software Engineering Case Study: Collaboration Among Objects in the ATM Systemprovides a "rough sketch" of the model for our ATM system. In this section, we see how it works. We investigate the behavior of the simulation by discussing collaborationsmessages that objects send to each other to communicate. The class operations that we discovered in Section 6.10 turn out to be the collaborations among the objects in our system. We determine the collaborations, then collect them into a communication diagramthe UML diagram for modeling collaborations. This diagram reveals which objects collaborate and when. We present a communication diagram of the collaborations among objects to perform an ATM balance inquiry. We then present the UML sequence diagram for modeling interactions in a system. This diagram emphasizes the chronological ordering of messages. A sequence diagram models how objects in the system interact to carry out withdrawal and deposit transactions.

Section 9.17(Optional) Software Engineering Case Study: Starting to Program the Classes of the ATM Systemtakes a break from designing the behavior of our system. We begin the implementation process to emphasize the material discussed in Chapter 8. Using the UML class diagram of Section 3.10 and the attributes and operations discussed in Section 4.11 and Section 6.10, we show how to implement a class in C# from a design. We do not implement all classesbecause we have not completed the design process. Working from our UML diagrams, we create code for the Withdrawal class.
Section 11.9(Optional) Software Engineering Case Study: Incorporating Inheritance and Polymorphism into the ATM Systemcontinues our discussion of objectoriented programming. We consider inheritanceclasses sharing common characteristics may inherit attributes and operations from a "base" class. In this section, we investigate how our ATM system can benefit from using inheritance. We document our discoveries in a class diagram that models inheritance relationshipsthe UML refers to these relationships as generalizations. We modify the class diagram of Section 3.10 by using inheritance to group classes with similar characteristics. This section concludes the design of the model portion of our simulation. We implement this model in C# in Appendix J.

Appendix JATM Case Study CodeThe majority of the case study involves designing the model (i.e., the data and logic) of the ATM system. In this appendix, we fully implement that model in C#, using all the UML diagrams we created. We apply the concepts of object-oriented design with the UML and object-oriented programming in C# that you learned in the chapters. By the end of this appendix, you will have completed the design and implementation of a real-world system, and should feel confident tackling larger systems, such as those that professional software engineers build.

Appendix KUML 2: Additional Diagrams TypesOverviews the UML 2 diagram types not discussed the OOD/UML Case Study.
Read Comments To Download