Class Diagrams

Before jumping into the techniques for coding custom objects, you must understand how custom objects fit into the Systems Development Life Cycle and how to identify and document what custom objects you should create. You learned in Chapter 1 that during the design phase of your application you generate a written specification for how your application should be coded. Activity Diagrams, Use Case Diagrams, and Screen Prototypes are examples of some techniques that can be used to document your design. Class diagrams are another documentation technique.

You are already well aware that an object can have properties, methods, and events. Your application should certainly make use of existing Access objects where possible, so that you do not have to re-write code that the Microsoft programmers have already written for you. However, as appropriate, you should also take advantage of custom objects to maximize the unique features of your application. During the design phase, you should identify the custom objects for your application and document the custom objects using class diagrams.

Class diagrams are critical in object-oriented system designs. They show the classes, relationships within the classes, and the way the code should be structured. In a class diagram, the properties and methods that make up an object are portrayed graphically. For example, in the case of the hypothetical Wrox Auto Sales Application described in Chapter 1, you deal with cars. Figure 4.1 shows the sample prototype screen for managing cars, as discussed in Chapter 1.

An object that you might want to create is a Car object. You could use a Car class to represent the Car object. The user interface is often a good starting point for determining properties and methods of an object. The Car object can have certain properties: Make, Model, Year, and so on, as the fields on the user interface indicate. In addition to these properties, the Car object needs methods that allow for retrieving, adding, updating, and deleting a specific record. These methods correlate to the Lookup, Add New, Save, and Delete buttons on the user interface.

Figure 4.2 shows an example class diagram for the Car object:

Notice that the properties for the Car class are listed first, followed by a divider line, and then by the methods it contains. The class diagram in Figure 4.2 contains the tracked properties and the methods for which you must write code. When you create a new system, create a class diagram that depicts all objects in the entire system. This is not an easy task and requires effort and time to learn. For the sake of simplicity, I focus on writing custom properties, methods, and events for the Car class of the hypothetical Wrox Auto Sales application.

A complete solution would contain other class modules as well, such as one for a Customer object or a Searchlnventory object. The comprehensive case studies in Chapters 12 and 13 will include complete class diagrams for the respective system and are excellent resources for refining your understanding of documenting and creating custom objects.

Figure 4.1

In Chapter 1, I mentioned that your code can be separated into three different logical tiers, even though Access is not used for physical three-tier applications. In most cases, it is a good idea to separate your code into different logical tiers. This makes it easier to update a particular portion of the system and migrate it to other platforms.

Returning to the Car class example, I will walk you through adding additional class diagrams based on the separation of tiers concept. You can actually create the class diagrams in any order you choose, but my personal preference is to start with the business logic layer first. The business logic layer is where you put your main classes like Car, and everything else revolves around it.

The class diagram in Figure 4.2 fits into the business logic layer. Now that you have created the business logic layer of the application, the other two remaining layers are really easy to create. Any call to the database will be included in a class in the data access layer. For each business logic layer class module that has a method requiring data from the database, you create a corresponding class module in the data access layer. Thus, the business logic layer (the Car class) will not make any calls directly to the database

-VehicleIdNumber

-Makeld

-Modelld

-Year

-Mileage

-Colorld

-InteriorTypeld

-InteriorColorld

-TransmissionTypeld

-Statusld

-ReceivedDate

-SoldDate

-SoldToCustomerld

-Photo

-Special Features

+Retrieve()

Figure 4.2

to get data. Instead, the Car class calls a method in a CarDb class in the data access layer, which, in turn, gets the data from the database, as you can see in Figure 4.3.

Presentation Layer

Open Car (UC 2.1)

Add New Car (UC 2.3)

Update Car (UC 2.2)

Delete Car (UC 2.4)

--

Business Logic Layer

-VehicleldNumber

-Makeld

-Modelld

-Year

-Mileage

-Colorld

-lnteriorTypeld

-lnteriorColorld

-TransmissionTypeld

-Statusld

-ReceivedDate

-SoldDate

-SoldToCustomerld

-Photo

-Special Features

Data Access Layer

CarDb

+RetrieveCarDb() +AddCarDb() +UpdateCarDb() +DeleteCarDb()

Figure 4.3

After creating the business logic layer and data access layer class diagrams, you create the diagrams for the presentation (user interface) layer. This is probably the easiest of the three to create, because you simply put each of your use cases on the diagram. Remember the use cases you created in Chapter 1 that defined each of the independent actions the user can take in the Wrox Auto Sales Application from the user interface? As Figure 4.3 illustrates, you can just list the use cases for the presentation layer class modules because the use cases define the user interface services to be performed.

Notice how each of the layers is connected appropriately to the others in the instances where they communicate with each other. For example, the Open Car action on the presentation layer calls the Retrieve method on the Car class, which in turn calls the RetrieveCarDb method on the CarDb class. The code to implement the presentation layer usually goes in class modules associated with the related form or report. The code to implement the business logic layer and data access layer ideally goes in custom class modules, although other variations are also possible and acceptable. I hope you are starting to see how this isolation of application logic into tiers works.

At this point, don't worry about understanding the complex details of designing class modules for an entire application. You should just understand that class diagrams can be used to model the custom objects that you want to create. I now return to the discussion of creating custom objects, and show you how to write the code to implement the properties and methods listed on the Car object in Figures 4.2 and 4.3.

0 0

Responses

  • catena
    Can we show class module in class diagram?
    8 years ago

Post a comment