Contents

• CSci 375/18 Domain Model III
• Revision History
• Projects: Start iteration 3 at end of class
• Chapter 31 Refining the Domain Model
• Questions and Answers
• Exercises
• Next Review UP and UML
• Next iteration of Project -- Model 3
• Review Questions
• Standard Definitions

CSci 375/18 Domain Model III


Table

Date	#	Topic (Participation 2pt)	Study pages (2 pts)	Quiz(15 pts)	Project Work(10 pts)
Previous	17	GoF	435-476	Q8(1-476)
Today	18	Domain Model III	501-539	-	W8(Model 3: model 2 improved)
Next	19	Revu Interactions and DCDs	221-270	- [ 19.html ]	Q9(1-535)


(Close Table)


Revision History


Table

Version#	Date	Description	Author
0	2005-01-03	Used boiler plate to make template	RJB
1	2006-01-20	Updated reading page numbers	RJB
2	2006-03-08	Added some notes	RJB
3	2007-01-10	Added 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 which you need to master.
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 the semantics of the client's language!
8. ++ A domain can have multiple hierarchies , for example, in a Hospital a Person is either Male or Female. But some people are Patients, as well. And -- also -- You find special People who are Doctors and Nurses... And so Person is simultaneously in these different hierarchies: a Male Nurse, a Female Doctor, a Female Patient who is also a Nurse, and a Male Patient that is neither a Docotr or a Nurse.... It really helps to draw a picture of these possibilities and UML2.0 provides a way to label generalisations to get this effect.

   

9. * 31.7 Abstract classes: must have concrete subclasses, ultimately.
10. ++ By the way, the {complete} constraint has the same effect on a single generalization when there are many hierarchies. See above.
11. * An interface is a special kind of abstract class that has no attributes and no concrete functions/operations.

12. * 31.8 But what if objects need to change class????

    ---

    1. State machines are good for modeling domain dynamics.
    2. UML has a diagram that pictures State Machines.
    3. State machines are often useful for sorting out technical problems (like when to write cached data back to a database -- page 639)
    4. Use State machines to clarify ideas and record requirements.
    5. Separate the changes into a State or Status object (Pure fabrication + Indirection). The state is actually an attribute of the apparently changing object.
    6. The UML does allow objects to change subclasses, if you write {dynamic} on a generalization, but few people use it.
    7. Most programming languages don't allow objects to change their class.
    8. Four classic solutions to coding changing behavior.
       Case
       1. Use the GoF State pattern [ patterns.html#State ] to code it. Here the state points at objects in different classes.
       2. Example [ StatePatternExample.html ] and code: [ State.cpp ] [ test.State.cpp ] (uses a simple Hollywood "don't call us, we will call you" pattern) OR [ State2.cpp ] [ test.State2.cpp ] (A less pure GoF implementation)
       3. (Example in the text is on page 642)
       
       (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. This was the pre-object-oriented way to handle state changes.
       2. See page 640 for classic code example.
       3. Here is the running example using this technique: [ State.not.cpp ] [ test.State.not.cpp ]
       4. In Java 5 enum allows you to attach specific behaviors to the different possible values. This can replace the switch in State.not.cpp.
       
       (End of Case)
       Case
       1. Again -- add a state attribute to the object and tabulate the transitions associated with each operation as data in a file or data base.
       2. Makes it easy to change behavior patterns without reprogramming.
       3. Example in progress: [ State.table.cpp ] [ test.State.table.cpp ] TBA
       
       (End of Case)
       Case
       1. Use Jackson semi-co-routines and Duff's device to simulate a concurrent process (covered in CS320 [ cs320/lab/09.html ] )
       2. Example: TBA
       
       (Close Case )
       The first three solutions are well known techniques.
       
       1. When there is a single operation that changes behavior with the state, then use the traditional switch-case... coding.
       2. When there is more than one operation that changes its behavior with the state, use the GoF State pattern code. (Polymorphism).
       3. Use data driven code to handle shifting requirements (Protected Variation)

    ---

13. * 31.9 Inheritance in Programs vs Conceptual hierarchies
14. 31.10 Association Classes: controlling the connections.
15. ++ 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.
16. 31.11 Aggregation and Composition: at last... but why so late?
17. ++ Composition implies Aggregation. Aggregation implies Association.
18. ++++ When in doubt: DON'T use either.
19. + Exception: In a domain model use composition for real wholes and parts.
20. + In designs put an arrow on an association to show pointers

     		class Wodget{ Widget * w1, *w2 ; ... };

21. + In designs (only) use composition to show storing an object inside an object:

     		class Wodget{ Widget w1, w2 ; ... };

22. + In a design composition, officially, means that the parts are destroyed when the whole is destroyed. You can therefore use a diamond to indicate the creator and destructor classes.

23. 31.12 Fixing an error NextGen Iteration 1?
24. *** 31.13 Role Names (important)
25. * 31.14 Roles...
26. ** 31.15 Derived elements(important)
27. 31.16 Qualified Associations
28. * 31.17 Reflexive associations (DON'T PANIC. important but simple)
29. * 31.18 Packages Organize your classes
30. 31.19 Example: Monopoly

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

    Questions and Answers

    [ 18q.html ]

    Exercises

    [ 18x.html ]

    . . . . . . . . . ( end of section Exercises) <<Contents | End>>

    Next Review UP and UML

    
    Table

    -	-	Subject	Prepare	Guide	Quiz
    Next	19	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

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

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

35. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
36. GoF::="Gang of Four", [ patterns.html#GoF ]
37. 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 ]
38. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

39. 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.

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

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

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

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

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

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

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

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

51. 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".

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

( End of document ) <<Contents | Top