[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 11.html Mon Feb 4 11:37:26 PST 2013

Contents


    CSci 375/11 Class Diagrams


    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous10Interactions221-247-W4(Transition to Design)
    Today11Class Diagrams248-270Q5(221-270)-
    Next12GRASP271-319-W5(Interaction & Class Diagrams)

    (Close Table)

    Revision History


    Table
    Version#DateDescriptionAuthor
    02005-01-03Used boiler plate to make templateRJB
    12005-02-07Added section HeadingsRJB
    22005-02-16Adding questionsRJB
    32006-02-13UpdatedRJB
    42011-01-26Added SlideFinder PPTRJB

    (Close Table)

    Project W4 -- SSD and Packages due

    [ w4.html ]

    How do all these diagrams and documents work together?

    First look inside the front cover of the book: [ artifactrelationships.gif ]

    16 Class Diagrams

      PowerPoint Presentation

      [ 25779248 ]

      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)

      Examples of Generalization (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 --

      UML2.0 Standard Example interfaces and components

      16.13-16.16 Associations etc

    24. ++ Navigating Associations. If class A has an association with class B and x is an object in class A then
       		x.b
      is the assoicated elements in B to x (Note the shift to lower case). If the association is many-to-one ( A *---1 B) then "x.b" is a single object in B and you can do what you like with it. If it is not many to one the "x.b" means a collection of elements. Further operations work on all the elements and generates another collection. It may be a vector, set, multiset, list, ... depending on the DCD. Finally, you can write loop conditions to access each element if "x.b" in turn
       		[for each y in x.b]
      Of course, the actual data may be private, but we can always code a "getter" function to navigate the association. So if A (*)-(1) B then
       		x.getB()
      is in the design or if A (*)-(*) B then
       		[for each y in x.getB()]
      might be what you want. In either case your DCD ends up with
       		+ getB():B[*]
      as an operation.

      The coding will depend on the language and the precise type of collection you choose. For example in C++ you need to explicitly code objects as pointers. If we have chosen to implement the "*" as a vector you might even (for example) code "*[for each b in x.b]b.zark()" like this:

       		vector<B*> myBs = x->getB();
       		for(int i=0; i< myBs.size(); i++)
       			mBs[i]->zark();

    25. +++ A many to many association is often best handled as an "association class" (below).

    26. * 16.13 Composition (Q)
    27. "is a part of" -- like data in an object.
    28. + Use in designs not domain models.
    29. ++ Unless the real world container has life and death control over its parts.
    30. *** avoid <>-- aggregation. Use ----> instead!
    31. ** 16.14 Constraints (Q)
    32. 16.15 Qualified Associations
    33. ** 16.16 Association classes
    34. +++ or make into a class that links the associated classes.

      Figure16.16 with linking class

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

      SalesOrder(1)-(*)SalesOrderItem(*)-(1)Stock

       		* [for so in customer.getSalesOrder()] list.add(so.getStatus())

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

    36. 16.17 Singleton Classes (Future)
    37. 16.18 Template classes and Interfaces (Future)
    38. ** 16.19 User-Defined compartments
    39. * 16.20 Active Classes (Future)

      16.21 Relating interaction and class diagrams

    40. ***** A vital skill(Q5). Each part of an interaction diagram tells you something about the design class diagram (DCD).
      Table
      Interaction DiagramClass Diagram
      Object life lineClass
      Message to objectOperation in target class
      DataMay be an attribute of sending class
      Returned DataMay be an attribute of class that returned it

      (Close Table)
    41. Example [ 11getStatusses.gif ] (Interaction -- finding the statusses of a customer's orders) [ 11StatussesDCD.gif ] (Changed DCD).
    42. +++ One DCD for many interaction diagrams.
    43. ++ Each interaction adds to the DCD.
    44. + Associations and attributes may add "getter" operations to access private information.

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

    My notes on Class Diagram Notation

    [ ../samples/uml1.html ] (generic) [ ../samples/uml1b.html ] (C++ oriented) [ ../papers/20050502Body.html#Class and Object Diagrams ] (UML2.0 changes)

    Be careful to use arrows correctly in the UML

    [Meanings of arrows in the UML]

    Demo if time

    Developing a communication diagram, a sequence diagram and a class diagram in parallel.

    Exercises

    [ 11x.html ]

    Project Step 5 Interactions and Classes -- Next Week

    [ w5.html ] is due next week.

    Quiz on Interaction Diagrams and Classes

    Foot Notes


    (Q5): May be tested in Quiz 5 (will be tested sooner or later). Make a set of diagrams fit together. OPEN BOOK.


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

    Questions and Answers

    [ 11q.html ]

    Next: How to make a good design

    [ 12.html ]

    Review Questions

    [ 11r.html ]

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code. [ 02DiceGameClasses.gif ] (example).
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".

  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good set of objects and/or classes to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what has no value now, see YAGNI.

  10. OO::shorthand="Object-Oriented".
  11. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.

  12. patterns::="Documented families of problems and matching solutions", see Patterns.
  13. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  14. Process::="How to develop software".

  15. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci and Engineering School, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

  18. TBA::="To Be Announced".

  19. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  20. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  21. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it also means "It won't be on the final or in quizzes".

  22. XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.

( End of document ) <<Contents | Top