[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] 07.html Wed Jan 11 07:25:36 PST 2012

Opening Microsoft files (winzip, word, excel, powerpoint) on this page may require you to download a special viewer. Or you can download and save the files and use your preferred office applications to view and edit them.

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
    10 2011-01-26Added a powerpoint PPTRJB

    (Close Table)

    Project work 2 due

    Introduction PowerPoint

    [ LarmanChap9.ppt ] (Dr. Benjamin Kho0 [ http://iris.nyit.edu/~kkhoo/ ] of NYIT)

    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 does not cost much. 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 -- but also document them elsewhere -- JIC (Just In Case).

  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 Domain 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 ]

    Exercise on Domain modeling with added attributes

    Domain modeled in last class [ 06x.html#Exercise 2 ] [ 07x1.png ] without attributes can have attributes added like this [ 07x1ans.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]

    Questions and Answers on Domain Models II

      [ 07q.html ]

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

    Exercises on Domain Modeling with Attributes.

    [ 07x.html ]

    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. Artifact::="Anything that is created in the course of a project".
  20. artifact::=see above.
  21. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  22. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  23. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  24. GoF::="Gang of Four", [ patterns.html#GoF ]
  25. 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 ]
  26. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

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

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

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

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

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

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

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

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

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

  39. 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 now. In this class it also means "It won't be on the final or in quizzes".

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

End