[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] 09x.html Tue Feb 7 15:37:58 PST 2012

Contents


    Exercises for 09

    1. What UML diagram do you use to plan the organization of a complex piece of software? Give a simple example.
    2. What is a dependency in the UML? How do you show it and what does it mean?
    3. What is the relationship between the Domain Model and the Domain Layer?
    4. Explain the model-view separation principle.
    5. Explain the relationships between a dynamic model and a static model of an interaction.
    6. I have a dynamic model that shows a message m being passed from class A to class B. Where do I put m in the static model?
    7. Draw an interaction diagram that shows that an object a in class A sends a message m(d) to an object b of class B.
    8. Draw a plausible static Design class diagram that supports the interaction in the previous question.

    draw an SSD for a given Use Case

      This is a use case taken from the Depot Stock Control System [ 06x.html ] exercises.

      Depot UC2 Refill Low Stock Levels

      Main Scenario
      1. The stock control clerk asks the system for a list of stocks with low stock levels.
      2. The system displays a list of stocks.
      3. The stock clerk selects a stock and prepares a purchase order for it.
      4. The stock clerk tells the system to record the order and the system prints a confirmation.
      5. Repeat the above two steps.

      Draw an SSD for this scenario.

    . . . . . . . . . ( end of section draw an SSD for a given Use Case) <<Contents | End>>

    Exercises on SSDs and Packages

    1. Discussion -- The Dice Game (in [ DiceGame.html ] & start of course/book) could be implemented in many ways... I want a list of 3 possibilities to add to the test example using a Command Line Interface and C++. Where would we document these?
    2. What logical Architecture should we use to handle all 4 implementations of the DiceGame?
    3. Draw SSDs based on given scenario [ 09x.html ] from a use case.

      Answer: [ 09SSD060208.jpg ]

    4. Exercise: Write a letter to your grandmother explaining what she should do with those little drawings of folders on her computers screen.

    5. Exercise: What are the parts (A,B,C,x,y,z) of this diagram:

      Three icons and 3 links

      and what do they mean?

    6. Exercise: Name three typical layers in a logical architecture and draw a diagram of them with packages and dependencies.

      Answer: [ 09x.png ]

. . . . . . . . . ( end of section Exercises for 09) <<Contents | End>>

Standard Definitions

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

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

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

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

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

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

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

  • TBA::="To Be Announced".

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

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

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

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

    End