Classes and their relationships

1. Classes and their relationships

2. How to find classes? • Bertrand Meyer’s suggestions • nouns in requirements document or use case descriptions do not provide adequate solutions • each class should contain a distinct set of operations relevant to the system under consideration • think of a class as an ADT • ignore a candidate class • if it does not suggest any operation relevant to the current application • if all operations of this class are already covered by other classes in the system • if this class overlaps with several abstractions • If this class’s name indicates an action C-S 546

3. Selecting the right classes • remove irrelevant classes • those that are not mandatory or not important for the current application • Information about employment details of a customer is NOT RELEVANT while modeling a bank transaction system • may be useful, but NOT NECESSARY • requires thorough knowledge of the application domain and possibly the help of domain experts C-S 546

4. Selecting the right classes (continued) • remove vague classes • classes that do not adequately describe themselves • a class that represents the internet • trade off between vague classes and abstract classes • vague classes are too abstract • most likely, vague classes do not have any concrete methods • define several component classes that together define the vague class • the “internet” class one or more concrete classes such as “web server”, “OS interface”, “user options model” and so on C-S 546

5. Selecting the right classes (continued) • do not include implementation-oriented classes in the analysis model • may be introduced later during design and/or implementation • examples: array, tree, list C-S 546

6. Identifying associations • an association corresponds to a semantic dependency between classes • class A uses a service from class B (client-server) • a TV object requires a signal from a Cable object • class A has a structural component whose type is class B (aggregation) • remember: aggregation is a special case of association • a TV object includes a Screen object • class A sends/receives data to/from class B (communication) • a TV object sends and receives signal to and from a VCR object C-S 546

7. Identifying associations (continued) • include only those associations that are relevant to the current model • constrained by assumptions, simplifications, system boundary (what is expected to be provided by the system) • “Faculty member” teaches “Course” in a course registration system • “Faculty member” creates “Course” in a curriculum development system • “Faculty member” evaluates “Course” in a course evaluation/inspection system C-S 546

8. Identifying associations (contd…) • eliminate redundant associations • some associations can be derived from others • “Faculty member” teaches “Course” • “Course” is taught between “Time” to “Time” • therefore, “Faculty member” teaches between “Time” to “Time” • use transitivity between associations • Give a similar scenario between a TV object, a VCR object and a Cable object • remember that subclasses inherit the associations of a superclass C-S 546

9. Identifying aggregations • aggregations are also associations • identify as association if it is not clear whether it is association or aggregation • “Mail” has “Address” (aggregation) • “Mail” uses “Address” for delivery (association) • “Customer” has “Address” (aggregation) • “Customer” resides at “Address” (association) • “TV” includes “Screen” (aggregation) • “TV” sends information to “Screen” (association) C-S 546

10. Identifying structural components • must be done for each class independently • some identified by aggregation • remember the definition of aggregation • deciding the types of attributes is not a primary concern during analysis • implementation dependent C-S 546

11. Identifying structural components (continued) • include only those attributes that are relevant to the current application • “size” for a TV object is not necessary if the application is concerned only with connections between TV and other objects • do not attempt to include every attribute at the beginning • more attributes can be added when the model is iterated • iteration of the model occurs almost at all times, particularly for large projects C-S 546

12. Identifying structural components (continued) • avoid derivable attributes; instead, create a function to derive each such attribute • “age” can be derived from “birthday” and “current-date” • “total” of all transactions can be dynamically computed when necessary, rather than storing it somewhere C-S 546

13. Identifying specialization • some of them are obvious in the application domain • derivable from requirements document • specialization (top-down approach) • “Student”, “Full-time Student”, “Part-time Student” • “TV”, “Plasma TV”, “Flat Panel TV” • “Customer”, “Bank manager” C-S 546

14. Identifying specialization (continued) • some of them are discovered during analysis • motivated by identifying similarities and common features among classes • generalization (bottom-up approach) • “Part-time Instructor” derived from “Instructor” and “Student” while modeling a department • “User” derived from “Customer”, “Bank Manager” and “Teller” while modeling an ATM system • “Material” derived from “Book”, “Journal” and “Magazine” while modeling a library catalog system C-S 546

15. Identifying specialization (continued) • remember the constraints on superclasses and subclasses • superclass and subclass must be necessarily different • otherwise they are duplicates and hence are redundant • superclass and subclass must not be completely different • must have at least something in common • may become completely different when specialized several times (huge hierarchy) C-S 546

16. Identifying specialization (continued) • avoid large hierarchy of specialization • difficult to see the relationships between the leaf class and the root class • remember the concepts “specialization” and “aggregation” and choose the appropriate relationship • influence of the application domain C-S 546

17. Identifying specialization (continued) • move structural and behavioral components to the appropriate superclasses (or to subclasses) • do not keep features just for code reuse • may require to iterate a few times • superclass’s (or subclass’s) relationship with other classes may influence this move • try to avoid multiple specialization • potential conflicts during implementation C-S 546

18. Deriving components of a class diagram from a usecase diagram • Actors are potential candidates for classes • Sometimes, an actor may not be modeled as a class • Generalization or specialization between actors will end up in generalization or specialization relationship between the corresponding classes C-S 546

19. Deriving components of a class diagram from a usecase diagram • Two actors will be related if they are connected through a series of use cases • The classes corresponding to these actors will thus have an association • See the ATM example – the actor “User” is related to “Account” because of the use cases “deposit” and “update account” • The relationship among use cases will be exploited later in dynamic modeling C-S 546

20. Iteration in developing a class diagram • quite common in large projects • iterate major components • classes, associations, structural components, inheritance hierarchy • separate basic and derivable information C-S 546