One approach we found useful in helping students understand sequence diagrams is the use of a CRC card exercise (Beck and Cunningham 1989; Bellin and Simone 1997). In this exercise, index cards are created -- one for each class in the class diagram. State information is listed. Students are then asked to role play, pretending to be one of the classes and/or a single object. This exercise is particularly useful in helping the students understand which class can/should be responsible for various behaviors based on state information and associations. After role playing the use case in the classroom, we draw from the in-class role play to create the sequence diagram. Figure 4 contains the sequence diagram for the rent movie use case. Figure 5 contains the sequence diagram for the return movie use case. After completing the sequence diagrams, we use the messages from the diagram to update the class diagram to reflect behavior (i.e., add the operations). To add operations to the class diagram, we consider each class represented in the sequence diagram and examine the messages that point to that class (i.e., messages that are received by that class). To receive a message, the class must have an operation that corresponds with the message it receives. For other messages passed to a class in the sequence diagram, the class diagram must be updated to reflect an operation that enables the class to perform the requested behavior. For example, consider the “add rental()” message to the customer class in Figure 4. For the rental clerk agent to send a message to the customer class entitled “add rental()” the customer class must have an operation “add rental().” Thus, we add the “add rental()” operation to the Rental class in the class diagram. To complete this iteration of the class diagram, all non-CRUD messages in each sequence diagram must be added as operations to the appropriate classes in the class diagram. Figure 6 contains the updated class diagram. Should we rethink the processes taught in our database courses to more closely align the way we think about data with the way applications are developed? Our answer to this question is yes. As will always be the case in our discipline, the process and techniques we teach are always shifting to keep up with changes in practice. Where we may disagree Figure 6. Jason's Video -- Class Diagram (with behavior) However, the shift to OO techniques receives a more mixed review. While advocates of OO design proclaim advantages such as conceptual clarity and better alignment with the conceptual space (Pancake 1995; Rosson and Alpert 1990), critics claim it is conceptually complex, difficult to use, and difficult to learn (Sheetz et al. 1997). Further, shifts to OO analysis and design (OOAD) are likely more difficult than shifts to OO programming (OOP) (Sircar, Nerur, and Mahapatra 2001). Empirical studies indicate that ERDs are often more correct and easier to develop than corresponding OO diagrams (Shoval and Shiran 1997).
Connect with 287M+ leading minds in your field
Discover breakthrough research and expand your academic network
