[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] 07x.html Tue Jan 31 14:29:29 PST 2012


    Exercises in class 07

    1. What is the syntax for writing an attribute in an UML class? Show how you would say that a Person (class) has a public attribute age which is a number and starts at zero. Which parts do you omit in a typical rough domain model?
    2. Explain the following Domain Model:

      [Boxes C and B connected by A ...]

    3. Draw a diagram that shows that a class Person has a unique associated Address. Redraw this to show that a Person has an attribute address that has type string.
    4. What is a derived attribute? How do you show a derived attribute? Give an example.
    5. Give a guideline for choosing between an attribute and an association in a domain model.
    6. In which UP phase do you start a domain model, and how often do you expect to update it?

    7. Here are two types of diagram, use case and domain model. What is A, B, C, X, Y? What is the relation between X and Y?

      [Box A connected to box B by line C plus Stickman X connected to oval Y]

      Adding Attributes to a Domain Model

        Scope -- SuperMartStockControl


        To be able to keep track of the stocks of products held on different shelves in the SuperMart Store.

        Use Cases

        1. Stock control clerk gets stock levels for a given product.
        2. Stock man moves stock from one shelf to another.
        3. Manager prints an inventory.
        4. Purchasing manager orders new stocks.
        5. ...

        . . . . . . . . . ( end of section Use Cases) <<Contents | End>>

        Initial Domain Model

        Each Stock is on one shelf and for one Product

        Missing Facts

      1. Each product has a text description and a restockLevel.
      2. Each shelf has a code position in the store -- the coding is a 6 character string.
      3. Each stock has a price and a number of items of the product.
      4. We also need to keep track of how much a product costs.

        Copy and Add Attributes -- KISS

        Include all attributes -- even value objects and possible foreign keys.

      . . . . . . . . . ( end of section Adding Attributes to a Domain Model) <<Contents | End>>

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

      Exercise -- Inventory for CSU

      Exercise -- Grading

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

    Standard Definitions

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

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

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

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

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

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

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

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

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

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

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

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