[Skip Navigation] [ CSUSB ] / [CNS] / [Comp Sci & Engineering] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Question] [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] 18.html Mon Sep 28 15:44:40 PDT 2009

Contents

    CSci 375/18 Domain Model III
    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous17GoF435-476Q8(1-476)
    Today18Domain Model III501-539-W8(Model 3: model 2 improved)
    Next19 Revu Interactions and DCDs 221-270 - [ 19.html ] Q9(1-535)

    (Close Table)

    Revision History
    Table
    Version#DateDescriptionAuthor
    02005-01-03Used boiler plate to make templateRJB
    12006-01-20Updated reading page numbersRJB
    22006-03-08Added some notesRJB
    32007-01-10Added link to project RJB

    (Close Table)

    Projects: Start iteration 3 at end of class

     [ w8.html ]

    Chapter 31 Refining the Domain Model

     A long chapter with lots of notation.
  1. 31.1 New concepts for NextGen
  2. 31.2 example of Generalization in a domain Model(important)
  3. *** 31.2 Super and sub classes(important). Aristotle was here!
    1. The is-a rule
    2. The 100% Rule
  4. * 31.4 When is it worth adding a subclass
  5. * 31.5 When is it worth adding a superclass
  6. 31.6 NextGen Example
  7. ++ These hierarchies define what are called ontologies that define a way of thought and speaking!
  8. * 31.7 Abstract classes: must have concrete subclasses.
  9. * 31.8 But what if objects need to change class????
    1. Most languages don't allow objects to change their class.
    2. The UML does allow them if you write {dynamic} on a generalization, but few people use it.
    3. Use State machines to clarify ideas and record requirements.
    4. Separate the changes into a State or Status object (Pure fabrication + Indirection).
    5. The state is an attribute of the changing object.
      Case
      1. Use the GoF State pattern [ patterns.html#State ] to code it. Here the state points at objects in different classes. Handout: [ StatePatternExample.html ] and code: [ State.cpp ] OR [ State2.cpp ] (A less pure GoF implementation)

      (End of Case)
      Case
      1. Add a state attribute that is an int or enumeration and write a switch statement in each method that encodes changeable behavior. (TBA).

      (End of Case)
      Case
      1. Use Jackson semi-co-routines and Duff's device to simulate a concurrent process (TBA) These first two are well known techniques.
      2. See page 640 for an example.

      (Close Case )
    6. * 31.9 Inheritance in Programs vs Conceptual hierarchies
    7. 31.10 Association Classes: controlling the connections.
      ++ I prefer to reify complicated associations into a new class with it's own attributes and methods. This is part of normalization for the data. It is useful when your programming language doesn't have association classes. Also this gives you a place to store the attributes of the relationship. Like when it started and stopped, as an example.
    8. 31.11 Aggregation and Composition: at last... but why so late?
    9. ++ Composition implies Aggregation. Aggregation implies Association.
    10. ++++ When in doubt: DON'T use either.
    11. + Exception: In a domain model use composition for real wholes and parts.
    12. + In designs put an arrow on an association to show pointers 
       		class Wodget{ Widget * w1, *w2 ; ... };
    13. + In designs (only) use composition to show storing an object inside an object: 
       		class Wodget{ Widget w1, w2 ; ... };
    14. Exception: In a Comp Sci course use composition for records/structs and aggregation for pointers (with an arrowhead at the other end).

    15. 31.12 Fixing an error NextGen Iteration 1?
    16. *** 31.13 Role Names (important)
    17. * 31.14 Roles...
    18. ** 31.15 Derived elements(important)
    19. 31.16 Qualified Associations
    20. * 31.17 Reflexive associations (important but simple)
    21. * 31.18 Packages Organize your classes
    22. 31.19 Example: Monopoly


      (important): like, I might set an exam question or use in an example...

      Questions and Answers

      [ 18q.html ]

      Exercises

       Review UML Notation. (Handout).

      Next Review UP and UML
      Table
      SubjectPrepareQuiz
      Next19 Revu Interactions and DCDs 221-270 - [ 19.html ] Q9(1-535)

      (Close Table)

      Next iteration of Project -- Model 3

       [ w8.html ] due at start of the next class.

      Review Questions

       [ 18r.html ]

      Standard Definitions
    23. CS202::= See http://cse.csusb.edu/dick/cs202/.
    24. CS372::= See http://cse.csusb.edu/dick/cs372/.

    25. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
    26. DRY::XP="Don't Repeat Yourself".

    27. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

    28. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
    29. GoF::="Gang of Four", [ patterns.html#GoF ]
    30. 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 class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
    31. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

    32. 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 is not needed, see YAGNI.

    33. OO::shorthand="Object-Oriented".

    34. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
    35. patterns::="Documented families of problems and matching solutions", see Patterns.
    36. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

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

    38. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
    39. RUP::Process="Rational UP", a proprietary version of UP.

    40. SSD::="System Sequence Diagrams", see chapter 10.

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

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

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

    44. 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 means "It won't be on the final or in quizzes".

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

    End