[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] 06.html Wed Jan 25 13:08:19 PST 2012

Contents

    CSci 375/06 Domain Model


    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous5More Requirements89-120Q2(61-120)-
    Today6Domain Model121-157-W2(Use Case Model 1)
    Next7Domain Model II157-171Q3(121-171)-

    (Close Table)

    Arbitrary Rule 1: Everything Evolves

    From now one put the version number, date, and authors on all documents. If possible maintain a Revision History on all documents:
    Table
    Version#DateDescriptionAuthor
    02005-01-03Used boiler plate to make templateRJB
    12005-01-24Added section headingsRJB
    22005-01-27Added notes on each section headingRJB
    32005-01-31Added questions and answersRJB
    42006-01-11Removed Q&A and corrected a definitionRJB
    52006-01-27Added notes on domain model as defining a languageRJB
    62006-01-29Added Q&ARJB
    72006-12-13Removed Q&ARJB
    82007-01-24Adding Q&ARJB
    92007-03-20Removed questions into 06q.htmlRJB
    102008-01-23Corrected some typographical errorsRJB
    112010-01-24Corrected some more typographical errorsRJB
    112011-12-15Extracted classroom exercises to private fileRJB

    (Close Table)

    Iteration 1

  1. *** Tackle difficult/risky things first in a real project.
  2. ** You don't eat an elephant in one bite.
  3. * Some Use cases will spread over a series of iterations.
  4. ** Inception leads to Elaboration.

    Domain Modeling I

  5. ** A Domain/Business Model is a UML class diagram.
  6. *** Not objects inside the software you are designing!
  7. ++++ There are NO actors or use case bubbles in a domain model. And the only class box in a use case must be given stereotype "<<agent>>".
  8. + A Domain model shows categories of real (and imaginary) objects plus the relationships between them.

    UML Class Models

    • Rectangular Boxes indicate sets of similar objects. In the UML we call collections of similar objects a class.
    • Each class(box) must have a name. It should be a singular noun phrase. Examples: Student, Faculty, Course, Section, ...
    • Some classes can have an extra compartment that lists the properties of the objects in the class. These are called attributes. Examples: sid, emailId, courseNumber, sectionNumber, date, age, ...
    • Links between the boxes... lines connecting them indicate relationships between the objects. These are called associations. They should have a name. Example: Teaches, Takes, Has, Describes, ...
    • For each association connecting two classes for each object in a class there is a number of associated objects in the other class. This called a multiplicity. They are written at the other end of the link. Examples: A student can be enrolled in 0 to 6 Sections and a Section can have any number (*) of Students: 
       		Student (*)----(0..6)Section
      (The UML notation puts multiplicities beside the links and omits parentheses).

    In class demo drawing a Domain Model of CSUSB on the board.

  9. + Domain Models answer these questions. What type of things do the stakeholders talk about? How are the things related? What are the important properties of the things. What words appear in the requirements, and how are they related?

  10. *** Take care to note the UML class diagram rules!

  11. ++ Domain Modeling is a useful discipline that plays its part throughout software development. In theory most domain modeling is done in early iterations, but even when delivering a project we may discover some previously unknown part of the world that we must think about. In practice, Domain Modeling is often started during the systems analysis -- but is often called constructing a Conceptual Model of a data base.

    Artifacts: The domain model influences use cases and glossary in Requirements. It inspires many of the classes in Design. In turn, it may evolve to fit changes in Requirements, and as a result of discoveries made in Design and Implementation. See figure 9.1.

  12. ++ A running prototype often uncovers unexpected properties of the domain that changes the Domain Model.

  13. ** Example Figure 9.2: A class diagram with classes, attributes, and associations. ONLY. (for now...)

  14. Definitions:
  15. Domain_Model::="A picture of the Reality that the system is embedded in". Not a picture of a part of the System being constructed. A Domain Model is a Visual Dictionary of the system's environment.

  16. A Domain model is a visual picture of many of the terms in the Glossary.

  17. ++ A Domain Model defines the semantics of the stake-holder's languages by documenting the kinds of objects involved and the roles they play in relationships with other objects.

  18. The domain layer is the part of the software design that directly reflects the systems environment. It is not the same as the Domain Model. It should be closely related to the current Domain Model.

  19. A data model is a picture of the persistent data in the software system or data base. This will overlap the Domain Model. A domain model can include things with no data. A data model may picture data that is not about the domain. Some transient classes should be omitted in a data model.

  20. + In time, a full domain model becomes an ontology defining the key words and phrases that describe the stakeholder's world. Working on a domain model is working on the meaning of the stakeholder's words. A Domain Model is a partial semantics of the "real" world.

    Motivation: Why model a domain? See Exercise below!

  21. * Guideline: How to create a Domain Model
  22. * Guideline: How to find conceptual classes.
  23. *** Three Strategies for uncovering classes and relationships:
    1. Reuse existing models.
      • Read the systems analysis documents and talk to the analysts.
      • Simplify the DBMS's data models/ERD's.
      • Listen to users and stakeholders.
      • ++ Use a known pattern from Model Driven Architecture.
    2. Use the book's list of categories (stick a notelet in this page).
    3. Noun phrases

  24. Example: POS Domain
  25. Example: Monopoly

  26. Guidelines
    • * Sketches not blueprints.
    • ** Leave boxes open on the left and bottom until drafted.
    • * Things will change, but you don't have to change the model. How much will it cost to do it? How much will you regret not doing it?
    • Reports may be part of the system or part of the domain, or both.
    • You are making a map describing the territory. Use the native's language.
    • ++ Look out for aliases: many names for one concept.
    • ++ Look out for ambiguities: one name with more than one meaning.
    • Some things are intangible but important
    • If it is represented by text/string/number/... it's not a class. It may be an attribute ... but only if it is interesting.
    • Use description classes sometimes.

    Associations

  27. Associations: how, when, why so few, not software but ideas, Notation

  28. Guideline: naming associations

  29. How to find associations: Categories, Names, Analysts(DFDs and ERDs).

  30. Examples

    • My Advice
    • ++ Use multiplicities
    • -- Normalize many-many associations into new classes.
    • -- Doubt 1-1 relations! They may be 1-optional, optional-optional, or generalizations!
    Domain models are models of real kickable objects.... what can you see in the classroom. We are working on an inventory program describing stuff at CSUSB. In groups, list names of the kinds of object in the class room. Can you spot any associations? If time -- draw a shared domain model on the board.

    Questions and Answers on Domain Models

    [ 06q.html ]

    Review Questions

    [ 06r.html ] Submit one question+answer at start of next class.

    Exercises on Domain Models

    [ 06x.html ]

    Project Use Case Model 1

    The first requirements (use case model 1) [ w2.html ] are due at the start of class 07.

    Next: attributes etc in domain models

    [ 07.html ] [ 07r.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.
  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 class 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 is not needed, 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 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