Introduction

1. *** Class diagrams are used for many purposes: domain models, object oriented designs, models of code, defining component interfaces, ...

2. DCD::acronym="Design Class Diagram", a class diagram that models the classes that will appear inside the code for the software. [ watch?v=Vy_gLkxuCnw&feature=related ] (YouTube with robotic voice and one error (no void in UML!)).

3. Static model: what is possible. Also need models of dynamics: what happens. Need to relate them.
4. Make sure that what should happen in the machine is possible!

5. Develop interactions and classes in parallel: Each object is in a class so put the class in the class diagram. Each message points at an object in a class.... add the message as an operation in the class. Each message links two objects and if they are in different classes then there will be a path in the class diagram. Data (in messages or returned) may become attributes in the class diagram. See session [ 13.html ] onward.

6. Your first attempts will be hesitant and messy. Later in this class the attempts will be just messy.

7. In a real project, let the problem drive the diagrams.

8. We will cover a set of Patterns for placing operations into classes. These are called the GRASP patterns. The first is simple enough that you can use it in your projects, right now:
   (Information_Expert): An operation should be done by the class that has the information that is needed by the operation.

9. Process: Each use case becomes many scenarios. Each scenario becomes one SSD. Each SSD makes many Interaction diagrams. One interaction per message (max) in the SSD. One DCD for all the interactions. See [ UC2Code.png ] for an informal sketch of the flow.

   16.1 - 16.6 Important notations and definitions for class Diagrams

10. *** 16.1 Notations (Q5) Put a sticky note on this section
11. * 16.2 Definitions: Design vs domain
12. 16.3 Definition: Classifier (UML Jargon)
13. ** 16.4 Attributes and associations (Q5)
14. **** The idea is to make the connections between classes OBVIOUS.
15. *** use role names in designs and association names in domain models.
16. * 16.5 Notes and comments (Q)
17. ** explain, constrain, and code!
18. *** 16.6 Operations and methods (Q5)

    16.7 - 16.9 Notations used later

19. * 16.7..9 Properties: keywords, stereotypes, profiles, and tags, ... (Used later in this class)

    16.10 Generalization, Dependency, and Abstraction

20. *** 16.10 Generalization and Abstraction (Q)

    (some sample generalizations)

21. * 16.11 Dependency (Q) One class depends on another if changing one can effect the correct operation of the other.
22. * 16.12 Interfaces (Q) An interface is a set of operations that gives access to objects that realize that interface. It is a socket into which other objects can plug-in.
23. ++ Think sockets and plugs --

    

    16.13-16.16 Associations etc

24. * 16.13 Composition (Q)
25. "is a part of" -- like data in an object.
26. + Use in designs not domain models.
27. *** avoid <>-- aggregation. Use ----> instead!
28. ** 16.14 Constraints (Q)
29. 16.15 Qualified Associations
30. ** 16.16 Association classes
31. +++ or make into a class that links the associated classes.

    

32. ++ For example: SalesOrder and Stock are linked by a many-many relationship by SalesOrderItem:

    

    16.17 - 16.20 Advanced stuff: singletons, templates, ...

33. 16.17 Singleton Classes (Future)
34. 16.18 Template classes and Interfaces (Future)
35. ** 16.19 User-Defined compartments
36. * 16.20 Active Classes (Future)

    16.21 Relating interaction and class diagrams

37. ***** A vital skill(Q5). Each part of an interaction diagram tells you something about the design class diagram (DCD).
    Table

    Interaction Diagram	Class Diagram
    Object life line	Class
    Message to object	Operation in target class
    Data	May be an attribute of sending class
    Returned Data	May be an attribute of class that returned it

    
    (Close Table)
    
38. Example [ 11getStatusses.gif ] (Interaction -- finding the statusses of a customer's orders) [ 11StatussesDCD.gif ] (Changed DCD).
39. +++ One DCD for many interaction diagrams.
40. ++ Each interaction adds to the DCD.

. . . . . . . . . ( end of section 16 Class Diagrams) <<Contents | End>>

My notes on Class Diagram Notation

Use interaction diagrams to develop a class diagram that supports the interactions.

Use a pair of a communication and a sequence diagram of the same collaboration to fill in blanks.

See [ 11Exs.png ]

Here is a domain model and a communication diagram from the last class [ 10ExGetUnfilledInteract.html ] (thank you Visio). Redraw the Domain class diagram as a Design Class Diagram that supports the communications shown.

Time to recall or reconstruct the domain model of the objects in a classroom for an inventory of the CSUSB campus. Add some generalizations and more general classes.

Project Step 5 Interactions and Classes -- Next Week

Note:
(Q): Some topics will be tested later...

Questions and Answers