[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] 07.html Mon Sep 28 15:44:22 PDT 2009

Contents

    CSci 375/07 Domain Model II
    Table
    Date #Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous 6Domain Model121-157-W2(Use Case Model 1)
    Today 7Domain Model II157-171Q3(121-171)-
    Next 8SSDs173-196-W3(Domain Model 1)

    (Close Table)

    Revision History
    Table
    Version# DateDescriptionAuthor
    0 2005-01-03Used boiler plate to make templateRJB
    1 2005-01-25Entered section headings from bookRJB
    2 2005-01-31Moved domain model ex to this classRJB
    3 2005-02-01Added colored UML imageRJB
    5 2005-02-02Added questions to be answeredRJB
    6 2006-12-06Removed Questions and adjusted date
    7 2007-01-26Add new exercise
    8 2000-01-29Expanded note on derived attributes
    9 2009-01-30Added links to some some domain patterns

    (Close Table)

    Project work 2 due

    9.16 Attributes in Domain Models
  1. * When to do attributes
  2. ** UML Notation: 
      		visibility name: type multiplicity = default {properties}
  3. ++ KISS: In a Domain Model Omit: visibility, type, default, properties.
  4. +++ Don't get hung up on whether an attribute should be put in a diagram. Missing one has few costly consequences. Adding one that is unneeded only costs a little time. As a rule -- it is better to omit one.
  5. + When you omit something from a diagram and you are worried about it -- put it in another artifact: glossary, data dictionary, business rules, ...

  6. *** Attributes should normally be data types: strings, numbers, characters.
  7. ++ else use associations, perhaps with role names.

  8. * A domain model can show requirements -- also document them elsewhere -- JIC.

  9. ++ Replace attributes with multiplicities by associations. This is a first step to a normalized model.
  10. Derived Attributes -- interesting values can be computed from other data. 
      		/ name....
    If there are complicated rules for deriving the attribute put it in another artifact as a business rule or a definition. Note. The UML does have a language for expressing complex rules. It is the Object Constraint Language. We will not be covering it.

  11. * Modeling data types: when, where, how.
  12. **** Make connections (functional dependencies, foreign keys) highly visible
  13. * Quantities and Units

  14. * 9.17 Examples -- POS and Monopoly Doamin Models
  15. * 9.18 Conclusion -- Correct or useful?
  16. * 9.19 Process: Iterative.
  17. Start in Elaboration (or before inception) and revise throughout elaboration.

    9.20 Resources -> using color for common types of classes:
  18. *** Here is how the "PostIt" colors can be used to help draw domain models:

    Colored UML

    [CoadLefebvre99]

    Example of a Domain Model

    First FIS domain model

    [ FIS1.html ]

    Example of Domain modeling

    Domain modeled in last class [ 06x.html ] without attributes can have attributes added like this [ 06xans.gif ]

    Domain Model Patterns

    Aggregation + Intersection + Aspects + Subtype + Reflexive + Directed Graph [Wagner05] and the following

    Bolloju04

    1. Narasimha Bolloju
    2. Improving the quality of business object models using Collaboration patterns
    3. Commun ACM V47n7(Jul 2004)pp81-86 [ 1005817.1005827 ]
    4. =EXPERIMENT MODEL REALITIES PATTERN UML COMPOSITION
    5. Based on Coad and Fowler lists 12 simple patters that helped students improve their conceptual models in 13 different business application domains: spotting classes and connections, plus correcting errors.

      (Figure 1 is in ASCII below)

    6. Collaboration_patterns::#Pattern=following,
      • E1: Role (1)-(0..*) Transaction
      • E6: Transaction (1)-(0..*) FollowupTransaction
      • E5: Specification (1)-(0..*) Transaction
      • E3: CompositeTransaction (1)<*>-(0..*) LineItem
      • E2: Place (1)-(0..*) Transaction
      • R: Actor (1)-(0..*) Role
      • T1: Item (1)-(0..*) SpecificItem
      • T4: Group (1)<>-(0..*) Member
      • E4: SpecificItem (1)-(0..*) Transaction
      • T2: Assembly(1)<*>-(0..*) Part
      • P: OuterPlace (1)-(0..*) Place
      • T3: Container (1)<*>-(0..*) Content
    7. Next [BollojuLeung06]

    Exercise on Domain Modeling with Attributes.

    You will be given or shown [ 07x.html ] some documentation copy the domain model with added attributes.

    I'll handout/post my preferred answer. [ 07xans.gif ]

    Exercise -- Domain models are pictures of reality

    Domain models are models of real kickable objects.... We are working on an inventory program describing stuff at CSUSB. Can you recall ior reconstruct the domain model from last time? Can we add any attributes to it. If time -- draw a shared domain model on the board.

    Questions and Answers on Domain Models II

      [ 07q.html ]

    . . . . . . . . . ( end of section Questions and Answers on Domain Models II) <<Contents | End>>

    Next Step in Project: A First Domain Model

    See [ w3.html ] for details is due this time next week.

    Quiz on Domain Modeling

     Given a description of a domain (text, rules, scenarios,...) draw a suitable domain model. TBA

    Next class

     [ 08.html ] "System Sequence Diagrams", a way of using the UML to model the sequences of events in one use case or scenario flowing between the actors and the system under development.

    Review Questions

    [ 07r.html ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

End