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


    Exercises 08

    1. Explain the differences in the purposes of domain models vs system sequence diagrams.
    2. How do SSDs fit in the Unified Process?
    3. I have a simple use case where a Customer uses the system to order Pizza. What objects do you put in your SSD?
    4. What is the syntax for a message in a sequence diagram? Give three or four example messages.
    5. How do you document responses to messages? When should you do this and when should you omit responses?
    6. How do you show repetition in a sequence diagram?
    7. What message might you write to express this step in a scenario:
       	User selects a thumbnail of a photograph and the system displays the photo.
    8. Draw an SSD for some thing you do when registering for a class in this university.
    9. What is an operation contract: how do you write one, and what does it mean? When do you need one?
    10. In which phase of the UP do you write most of the Operation contracts for a system?
    11. Why do we move rapidly from an incomplete set of requirements to a working but incomplete program?
    12. Explain the following diagrams. What do they show and what do their parts mean?

      [3 diagrams: A,B Boxes, C line + Stickman X, oval X + Stickman...]

    The Depot Domain SSD

    Draw an SSD for this Use Case:

    Depot Stock Control System UC1 Display unfulfilled orders at my depot

    1. Each morning the depot manager asks the system to display all the unfulfilled orders at his/her depot. The system responds with a list of unfulfilled orders.

    My answer: [ 08getUnfilled.gif ]

    The CSUSB Inventory System

    Draw an SSD for this Use Case:

    System: CSUSB Inventory UC1 Find Equipment

    1. The user logs in with a name and a passwd.
    2. The user inputs the inventory number of a piece of equipment.
    3. The system returns the place the equipment is.
    4. Repeat the above two steps until the user logs out.

    More to come in the next class.

    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.