Visual Basic 2005 Design and Development - Chapter 4 pdf

Object-Oriented Design This chapter discusses how to design the classes that make up the application. It explains the major goals of object-oriented programming, and how they relate to the application’s classes. This chapter also explains how you can use different views of the system to get a better under- standing of the application as a whole. It introduces the Universal Modeling Language (UML), which you can use to help specify and understand the application before you start building it, and describes some UML design tools that you can use to model the application. The Bug Hunter Example The sections in this chapter explain different ways to characterize an application. They discuss the program from the point of view of the users, architects, developers, and others. To make the discussion easier, each section works with the same example: a hypothetical bug tracking application named Bug Hunter. This application allows users to enter bug reports. A bug manager reviews each report and assigns it to an appropriate developer. The developer reviews the bug, tries to reproduce it, fixes the bug (hopefully), and clears the bug. A release coordinator then performs regression testing, revises the application and user documentation, and then releases a new version of the code. In some cases, the bug can follow a different path, looping back to a previous state. For example, if the assigned developer cannot reproduce the bug, it is sent back to the user for clarification. If regression testing shows that the bug fix broke something, the bug is sent back to the developer for reevaluation. Throughout this process, users can view the status of a particular bug to see if it is new, under review, assigned, under study, fixed, or released. The user can generate reports showing informa- tion about bugs, selected and ordered in various ways, such as a particular bug, all bugs, bugs 08_053416 ch04.qxd 1/2/07 6:29 PM Page 69 with certain severity levels, bugs submitted during a particular time range, or bugs in various states (new, assigned, fixed, and so forth). The bug manager and release coordinator can also select reports that are not available to the users (such as the code modules containing the bugs, the developers who wrote code containing bugs, and so forth). Building an Object Model Before you can start building an application, you must identify the classes that you will use. Once these classes are defined, they will quickly become intertwined with the developers’ code. Changing, remov- ing, or replacing them later becomes very difficult. You may be able to add new properties and methods to a class. However, making large changes is time-consuming and likely to affect the existing code. To avoid needless drudgery and frustration, you should spend extra time at the beginning of the project identifying the major classes that you will use, spelling out their roles and responsibilities, and defining (at least in general terms) their properties, methods, and events. The following sections describe some methods you can use to pick classes for developers to use. Picking Candidate Classes One way of picking candidate classes is to take a close look at the project’s written specification or description, and highlight all of the nouns in the text. For now, focus on nouns that are objects, such as document, user, and report. Skip concepts and activities, such as testing and evaluation. The nouns you have highlighted are the candidate classes. The following text is the description of the Bug Hunter application with the candidate nouns in bold: This application allows users to enter bug reports. A bug manager reviews each report and assigns it to an appropriate developer. The developer reviews the bug, tries to reproduce it, fixes the bug (hopefully), and clears the bug. A release coordinator then performs regression testing, revises the application and user documentation, and then releases a new version of the code. In some cases, the bug can follow a different path, looping back to a previous state. For example, if the assigned developer cannot reproduce the bug, it is sent back to the user for clarification. If regression testing shows that the bug fix broke something, the bug is sent back to the developer for reevaluation. Throughout this process, users can view the status of a particular bug to see if it is new, under review, assigned, under study, fixed, or released. The user can generate reports showing information about bugs, selected and ordered in various ways, such as a particular bug, all bugs, bugs with certain severity levels, bugs submitted during a particular time range, or bugs in various states (new, assigned, fixed, and so forth). The bug manager and release coordinator can also select reports that are not available to the users (such as the code modules containing the bugs, the developers who wrote code containing bugs, and so forth). Next, combine any duplicates and make a list. Add comments, if necessary, to clarify a word’s meaning. For example, the word “something” is too vague to be useful by itself. The following list shows the bold nouns from the previous text: 70 Part I: Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 70 ❑ all bugs (report) ❑ application ❑ bug ❑ bug manager ❑ bug report ❑ bugs in various states (report) ❑ bugs submitted during a particular time range (report) ❑ bugs with selected severity levels (report) ❑ code modules containing the bugs (report) ❑ developer ❑ new version of the code ❑ particular bug (report) ❑ path (a bug report’s path through the states/statuses) ❑ release coordinator ❑ something (a piece of code broken by a bug fix) ❑ state (of a bug report) ❑ status (of a bug report) ❑ the developers who wrote code containing bugs (report) ❑ user ❑ user documentation Note that picking candidate classes in this way requires that you have a good specification. If the specifi- cation is vague, it won’t include all of the nouns that you will need for the classes. The specification is the starting point for building a list of candidate classes, not the final story. If something seems to be missing, take another look at the specification and see if it completely describes what the program needs to do. Converting Candidates into Classes After you compile the initial candidate list, you must look over the items and decide which will make good classes, and what interactions there are among them. This list contains some items that represent the same concepts. The items “state” and “status” are really the same concept, so you can remove one of them. Let’s remove “state.” Similarly, “bug” and “bug report” represent the same idea, the data about a bug, so let’s remove “bug.” Looking at the list, you can see a couple of general categories. There are several different kinds of reports. There are also four kinds of people: user, bug manager, developer, and release coordinator. You should pull these related objects out into groups. Such groups of objects often indicate a close relationship, and may be a sign of inheritance, composition, or other close coupling. 71 Chapter 4: Object-Oriented Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 71 Think about the groups and decide whether these objects are the same type of thing at some level, or whether they are just closely related. In this example, user, bug manager, developer, and release coordi- nator are all the same sort of thing: people. It’s even easier to see that all of the reports are types of reports. Because the objects are the same sort of thing, it probably makes sense to combine them by making them inherit from parent classes. Study these items further and see how much they have in common because they are the same type of thing. The people items all have characteristics of people: name, address, phone number, and so forth. Different people will also have different permissions for using application features. For example, the bug manager and release coordinator can make reports showing bugs by module or developer, whereas the users cannot. The report items are less well-defined at this point, so it’s a bit more difficult to know what they have in common. Drawing on previous experience with other applications, however, you can guess that they will all need methods for building the report, setting report parameters, saving the report into a file, printing, exporting the report for analysis in a spreadsheet and possibly other file formats, and so forth. Armed with this information, you can generalize the groups by pulling their common features into a parent class, and making the items in the previous list child classes. Now, consider the remaining items and think about the types of roles they will play in the application. Decide whether the item represents a single piece of data, a more complex data structure with multiple fields, something that performs an action (or on which important actions are performed), or a combina- tion of these. You can model a single piece of data by using normal variables such as strings, integers, or arrays of similar simple data types. You can implement a complex data structure in Visual Basic by using either a structure or a class. Both structures and classes can provide methods, so you can use either to represent something that performs actions. The difference between a structure and a class in Visual Basic is mainly one of how the item is allocated. A structure is allocated when it is declared, whereas a class is allocated when you use the New keyword. For example, if you declare an array of 1,000 structures, Visual Basic allocates memory for them when it reaches the declaration. If you allocate 1,000 class objects, Visual Basic only allocates memory for refer- ences to the objects, and doesn’t create the objects themselves until you initialize them individually by using the New statement. There are also a few additional differences (such as the fact that structures don’t have constructors). I usually use classes, at least partly because they can have constructors. The “bug report” item contains information about a bug, so it represents a piece of data. It is also a very central concept to the system: a user creates it, the bug manager assigns it, a developer works it, and the release coordinator releases it. It takes part in reports and requires user documentation. The fact that this item plays a role in so many activities indicates that it is something special. Let’s make it a class. In the earlier description of Bug Hunter, “application” refers to Bug Hunter in a fairly general way, and it doesn’t really do anything specific. At most, you could use it to represent application properties such 72 Part I: Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 72 as the version number, release date, and so forth. Because this information changes rarely (only when new versions are created) and because the “application” item doesn’t need to perform any action, let’s tentatively remove it from the list. The program will store application information such as version num- ber in the program’s properties and in the data describing a bug report. I’ve seen many systems where object enthusiasts insist on creating objects for even small items such as this. They would create an ApplicationInformation class whose sole purpose is to load and save these few data values. I prefer to initially keep these items simple and make them more elaborate later only if it proves absolutely necessary. Similarly “new version of the code” refers to a new program build to fix a bug. The new code itself is stored outside of the program in some sort of source code control system. Though this is an important part of the Bug Hunter system as a whole, it’s not properly part of the code. The “user documentation” item also refers to something external to the program. Updating the docu- mentation is an important activity, but it’s not part of Bug Hunter. Even if the program displays the documentation online, it is the release coordinator, not the program, that updates the documentation. You could add a property to the “bug report” object to record the version number of the documentation produced in response to the bug, but even that may not be necessary. It’s more common for the docu- mentation to include a revision history that will indicate that it was revised because of the bug. The “path” item represents the path a bug report takes through the system as it is created, assigned, worked, and released. Whether you need to keep this item depends on whether you really care about the job’s path through the system or whether you just need to know that the job follows some path. In some applications it is important to know an object’s complete history. For example, if you are processing financial information, you may need to establish a chain of custody so you know exactly who did what to the data and when. In that case, you might want to implement an audit trail system where the application saves a record every time the data is modified (and possibly viewed). For Bug Hunter, let’s assume that you just want to know that a bug report flows through the system and you don’t need to remember all of the steps, so let’s remove “path” from the list. The “status” item represents a bug report’s current state in the system. This item takes specific values such as New, Assigned, and Released. The “status” item is a single enumerated value that applies to a bug report, so let’s make it a property of the “bug report” object. In the Visual Basic code, let’s make the list of possible values an enumerated type. Finally, the “something (a piece of code broken by a bug fix)” item represents the code that was fixed. This is another item that lies outside of Bug Hunter’s code. However, the program’s description says that the bug manager should be able to generate reports showing bugs by module and bugs by devel- oper. To provide those reports, the program must know where the bugs occurred and who created the bugs. These are fairly simple data items, and the program won’t do anything with them other than report them, so let’s make these properties of the “bug report” item. After fixing a bug, the developer should enter this information in the “bug report” data. Figure 4-1 shows the initial object model. 73 Chapter 4: Object-Oriented Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 73 Figure 4-1: The initial object model contains objects extracted from the program’s description. Adding Internal Classes Sometimes an application’s object model needs additional classes that don’t correspond to the physical objects mentioned in the project description. These classes provide features that the developers need to build as parts of the system, but they are often hidden from the users. Sometimes you may know that these classes are necessary from previous experience. In a similar appli- cation, you may have used a PriorityQueue class that you think will be useful for keeping bug reports ordered by priority. Other times you will discover that you need new classes as you develop the classes that you have already defined. You may discover that the Report object’s ExportToFile method would best be implemented by a group of classes that can handle different export formats (such as tabbed text, comma-separated value, Excel workbook, and others). You may find additional classes when you apply design patterns to the application’s design. Model- view-controller, facade, adapter, and other design patterns add new classes to the design. It’s often useful to look at the places where the application interacts with the outside world to identify new classes. That includes places that read or write files, such as the ExportToFile method mentioned earlier. It also includes places where the application must read or send email, upload or download files from the Internet, print reports, send faxes, interact with Windows or other applications, and interact with different components of your application. BugReport Status FixedInVersion BugInModule BugWrittenBy Description ReportedBy Etc. Report New() Parameters SaveToFile() ExportToFile() Print() Etc. Person Name Address Phone Privileges Etc. BugManager Developer ReleaseCoordinator User ReportBySeverity ReportByModule ReportByDeveloper ReportSpecificBug ReportAll ReportByStatus ReportByDate 74 Part I: Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 74 Adding Database Classes A particularly common interaction is with a database. Many programs read and write data in a database, and they can use classes to make that easier. Higher-level classes can act as factories for reading and writing certain other kinds of objects. For example, a DbPersonFactory class might have methods that can build and save Person objects in the database. A database-level class might provide methods for inserting, updating, querying, and deleting data. Higher-level classes could use its methods instead of accessing the database directly. Separation between the day-to-day development classes and the database is important so that developers don’t need to remember the details of the database’s structure and the particular database engine’s access methods. For example, Access and Oracle databases delimit dates differently. The database classes should hide this from higher-level classes. However, I’ve worked on several applications where developers got carried away and added too many extra layers of classes trying to increase the separation between the developers and the database. That made tracing a piece of data through the system almost impossible. I’ve seen code that climbed through 30 or 35 layers of call stack involving dozens of objects to retrieve a relatively simple piece of data. This is not only inefficient, but it’s also incredibly hard to debug. Use classes for separation, but strive for broad, shallow object hierarchies, instead of very long inheritance chains or deep stacks of method calls. Often, the tables in a database map naturally to classes within the program. Perform a quick study of the program’s data needs and design a preliminary database. Now see if any of the tables should correspond to classes. Tables that are related in the database often correspond to classes that are related in a similar way. Bug Hunter will probably need a BugReports table to store information about bugs and a People table to store information about people. There are two one-to-many relationships between the BugReports table and the People table because each BugReports record will contain references to the User who created the report and the Developer who is assigned to it. These are one-to-many relationships because each BugReports record refers to a single creating user and assigned developer, while each user or developer can be associated with any number of BugReports records. You will probably want to model this relationship by giving the BugReport class references to the corre- sponding User and Developer objects. Studying Different Design Views It has been repeatedly shown that the longer it takes to find a bug in an application, the more difficult it is to fix. Design decisions are particularly important, because you make them near the beginning of the project and because they have such wide-ranging consequences. A big mistake in the initial design can make the entire project fail. One of the easiest ways to make big design mistakes is to not understand the application thoroughly. If you don’t understand the customers’ needs, you can’t design classes to satisfy them. If you don’t under- stand the application’s internal needs, you can’t design the classes that it needs to get the job done. 75 Chapter 4: Object-Oriented Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 75 To gain the best possible understanding of the system, you should look at the application from as many points of view as possible. Some of the different views you should consider include the following: ❑ Object View —Perform an object-oriented analysis to define likely classes to represent the physi- cal objects in the system. Group and combine objects, build an inheritance hierarchy, refine the objects, and so forth. ❑ GUI View —Sketch out a rough user-interface design. Then think about the types of data the program will need to support that interface. Often, the items displayed on the screen match underlying classes. Chapter 5, “User-Interface Design,” has more to say about designing the application’s user interface. ❑ Data View —Identify the data that the system needs. Decide where the data should reside: in classes, global variables, or someplace else. Design the database if you need one and see if the tables in the database naturally map to classes. ❑ Document View —In many applications, the users work on some sort of document. In Bug Hunter, the central document is a bug report. Often these documents correspond to classes. Mentally follow the documents through the system and identify the entities that interact with them. In Bug Hunter, these are the different kinds of people and reports. Often, these entities should also be implemented as classes. ❑ Case View —Step through the use cases that you and the users have defined for the application. See if the classes you have defined contain all of the necessary ingredients to handle the use cases. Look for new nouns in the use cases that might make good classes. The Universal Modeling Language (UML), described later in this chapter, can help you characterize the details of different aspects of the application’s design and behavior. It gives you a representation that you and the other application designers can use to study the design meaningfully. Later, it can give developers guidance so they share a common vision of how the system should work. UML also gives you several new views from which to examine the system, so even if you are the sole designer and developer on the project, you may get some benefit from using UML. Improving the Classes For years, object-oriented developers have focused on three important characteristics of object-oriented languages: encapsulation, polymorphism, and inheritance. These three principles make classes more powerful and easier to use with fewer chances for errors. Unfortunately, many focus so tightly on those three principles that they forget the purpose behind the dogma. By keeping in mind the reasons why those three concepts are useful, you can generalize them and apply similar principles to higher-level design tasks. Most experienced developers understand that a well-designed class should provide encapsulation, polymorphism, and inheritance. It’s less clear how you can apply the underlying concepts to improve the design of higher-level entities such as application systems and subsystems. The following sections describe encapsulation, polymorphism, and inheritance. They also extract the underlying ideas and explain how you can apply them to the application’s higher-level organization. 76 Part I: Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 76 Encapsulation Encapsulation is the idea that a class should wrap up its implementation details in a tight little package. The class provides an interface (properties, methods, and events) that lets other parts of the program interact with the class’s objects, but it keeps the details about how it does its job a closely held secret. Many programmers justify encapsulation by saying that it makes the rest of the program less dependent on the class’s code. If you later need to change the way the class works, you will not need to modify the rest of the program to work with the new code. For example, suppose an Invoice class looks up a customer’s data and the list of items that customer has purchased, adds up the items’ prices, and prints an invoice. The main program can create an Invoice object and call its MakeInvoice method to make and print an invoice. Now, suppose the company decides to create a new Preferred Customer program that gives any customer a 10 percent across-the-board discount on every order after the customer has purchased $10,000 worth of goods. You need to modify the Invoice class so it checks the value of the customer’s previous orders. If the customer has placed $10,000 worth of orders, the Invoice class applies the 10 percent discount and prints the invoice. Because the Invoice class encapsulates the invoice generation and printing process, you don’t need to change the rest of the application. The main program still creates an Invoice object and calls its MakeInvoice method exactly as before. The details of how the MakeInvoice method works is safely hidden from the main program. You can also think of the ability to change one part of the application without messing up another part as loose coupling. The different systems are related, but loosely enough that changes to one don’t neces- sarily require changes to the others. Although developers think of encapsulation as a class-level concept, loose coupling applies equally to all levels of the project. Keeping the user interface, report generation, invoicing, inventory, and other major systems as loosely coupled as possible means changes to one are less likely to require changes to the others. A second part to encapsulation that is sometimes overlooked is the simple fact that it hides information about the class’s internals. This is such an integral part of encapsulation that encapsulation is sometimes called information hiding. Even if hiding the class’s internals didn’t promote loose coupling, it would still have a large benefit for developers because it allows them to use the class without worrying about what’s going on beneath the surface, thus reducing the developer’s cognitive load. The developer can use the class and assume that it works. This may seem like the smaller of encapsulation’s two effects, but it can have a big impact, particularly if you apply the idea to the higher levels of the application design. If the report generation system hides its internal details from developers, those developers can work on their own pieces of code, calling the report generation system as needed, without worrying about how it works. On a large project where different teams implement the application’s various systems, keeping the sys- tems as independent as possible is absolutely crucial. You must allow the teams to work separately to get their pieces of the application done as quickly as possible. Information hiding allows members of one system’s team do their jobs without needing to consult with the members of the other teams. 77 Chapter 4: Object-Oriented Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 77 One really strong way to promote loose coupling is to build parts of the application as dynamic link libraries (DLLs), components, and controls. Most developers have the sense that classes in these kinds of modules are separate entities. That makes them less likely to try to break the class’s encapsulation than they might be if the class was simply another class in the same code base. Putting the class in a separate code library adds a “barrier to messing around” with the code. Of course, if it’s harder to modify the library’s code, then you’d better spend some extra time up front to ensure that the library can handle all of the requests that the developers will need to make of it. The extra work at the beginning will be more than repaid by the additional isolation you get between the applica- tion’s systems. To summarize, encapsulation really includes two concepts: loose coupling and information hiding. Both of these are beneficial when you build a class, but they are also useful at the higher levels of application design. Hide as many of the details as possible within a class. Provide public access to the bare essentials that other code needs to get the job done. If it later turns out that a piece of vital information that is hidden within the class must be exposed, you can add it later. It’s better to start out too restrictive and loosen access than it is to start too loose and create dependencies that will be hard to implement, debug, and maintain. Polymorphism and Inheritance Encapsulation, polymorphism, and inheritance are the three main characteristics of object-oriented pro- gramming. As the previous section explains, you can maximize encapsulation in your classes and system- level design to make the application easier to build, debug, and maintain. Polymorphism and inheritance, however, are more descriptions of objects, rather than advice on how to use them. Polymorphism means the ability to use one object as if it were another type of object. In particular, it means that the code should be able to treat an object as if it had the type of its ancestor classes. You should be able to treat a User object as if it were a Person because User is a child class of Person. User is a type of Person, so a User is actually also a Person. Note that the reverse is not true: a Person is not necessarily a type of User. In practice, this means that you can pass a User object into a routine that expects a Person. You can also store a User object in a variable that is a reference to a Person. Inheritance means that derived classes inherit the properties, methods, and events of their parent classes. A User object has all of the features of a Person object, possibly with some additional features. The User class may also modify some of the Person features (for example, overriding or shadowing them). It’s hard to see how you would change a class’s definition to gain the most benefit from polymorphism and inheritance, much less how to apply those principles at a higher design level. It helps to ask why these capabilities are useful. Both polymorphism and inheritance provide forms of code reuse. If a routine manipulates derived classes as if they belonged to the parent class, you don’t need to write separate routines to handle each derived class. If you write a routine to send email to a Person object, you don’t need to write separate routines to deal with User, BugManager, Developer, and ReleaseCoordinator objects. 78 Part I: Design 08_053416 ch04.qxd 1/2/07 6:29 PM Page 78 [...]... onto the diagram Double-click an object to display the dialog shown in Figure 4- 1 7 Enter the name you want for the object, and use the Classifier drop-down list to select the object’s class In this example, the class is SequenceDiagramTest (the project’s name) followed by User (the class) 92 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 93 Chapter 4: Object-Oriented Design Figure 4- 1 6: You can use Visio to... enumerated types), inheritance relationships, and other design features When you have a design you like, open the UML menu’s Code submenu and select Generate In the dialog that appears, select the design items that you want to generate, and pick the directory where Visio should put the new code 94 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 95 Chapter 4: Object-Oriented Design Visio is a very complicated application... structure and behavior, both to study the application and to provide users, architects, and developers with the same view of the system Chapter 5 discusses user-interface design While a good object-oriented design makes the system buildable, a good user-interface design makes it usable Without a good user interface, the application may fail, no matter how flexible and robust the code is 95 08_05 341 6 ch 04. qxd... bother to draw it The goal is to specify the system’s behavior and design precisely so that you can study it and develop a common understanding with users, other designers, and developers It’s not to create a bunch of diagrams with little to say 91 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 92 Part I: Design :User :BugReport Initialize() void Figure 4- 1 5: This UML diagram doesn’t say anything that you can’t... variety of platforms (including Windows, Linux, Unix, Java VM, and MacOS), and are intended for use with an assortment of languages and development environments (such as Java, Delphi, Smalltalk, Visual Studio, and Visual Basic) Microsoft’s Visio Enterprise Architect product, which is available as part of Visual Studio 2005 Team System or Visual Studio Professional with MSDN Premium, includes support... objects from each class in the relationship 83 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 84 Part I: Design Person User BugManager Developer ReleaseCoordinator Figure 4- 4 : A class diagram can show an inheritance hierarchy In the relationship diagram shown in Figure 4- 5 , the ReportSingleBug object represents a report about a single bug It is associated in a one-to-one relationship with the BugReport object representing... Figure 4- 8 : An activity diagram shows a sequence of events in an intuitive way 86 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 87 Chapter 4: Object-Oriented Design A dark circle represents the start of the activity that the diagram represents, and a dark circle with an extra ring around it represents the end This type of diagram is usually more intuitive than a sequence diagram like the one in Figure 4- 7 , so... Figure 4- 7 , so it is more meaningful to users More-complicated activity diagrams can include If-Then style branches, loops, and other more elaborate structures When you add all of the bells and whistles, an activity diagram looks a lot like an old-fashioned flow chart Figure 4- 9 shows an expanded and reformatted version of the activity diagram in Figure 4- 8 This version is called the swimlane version,... Bug Hunter GUI Figure 4- 1 4: In this deployment diagram, nodes are connected by a simple network A Database Server computer stores the bug data in a SQL Server database It also contains the Data Store component responsible for managing the data 90 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 91 Chapter 4: Object-Oriented Design The computers used by the users, bug manager, developers, and the release coordinator... diagram Figure 4- 1 7: Use this dialog to set an object’s name and class 93 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 94 Part I: Design Next, drag activations, messages, and other diagram tools from the UML Sequence toolbox tab onto the diagram You can anchor the tools to each other so they move together For example, if you drag an object to a new position, its lifeline and activations, and the endpoints . : 83 Chapter 4: Object-Oriented Design 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 83 Figure 4- 4 : A class diagram can show an inheritance hierarchy. In the relationship diagram shown in Figure 4- 5 ,. information in the “bug report” data. Figure 4- 1 shows the initial object model. 73 Chapter 4: Object-Oriented Design 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 73 Figure 4- 1 : The initial object model contains. either already understand UML or who pick it up quickly, you can use UML 79 Chapter 4: Object-Oriented Design 08_05 341 6 ch 04. qxd 1/2/07 6:29 PM Page 79 to help ensure that the design implemented