[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] w9.html Tue Mar 12 20:21:55 PDT 2013


    Assigned Work 9: The Fourth Iteration

    02005-03-15Copied from w8 and editedRJB
    22007-03-09Revized to remove architectureRJB
    32008-12-23Revized to remove deploymentRJB

    (Close Table)

    Given: Model 3

    1. Vision + Business case
    2. Use cases: some fully dressed ones... Some casual. Some brief.
    3. Supplementary specifications: desirable qualities.
    4. Architecture -- package diagram
    5. Use case model
    6. Domain model.
    7. Glossary
    8. Business Rules
    9. System Sequence Diagrams for interesting scenarios.
    10. Interactions: sequence or communication diagrams for some interesting messages in your SSD. With many comments explaining why (GRASP) you choose that assignment of messages to classes.
    11. A DCD

    Plus reviewers comments.


    Paper Deliverable Due Before Start Time of Final -- Model 4

    The deliverables form a packet and every element in the packet should be there in the listed order.
    1. Vision + Business case
    2. Use cases: more fully dressed ones... more scenarios
    3. Use case model
    4. Supplementary specifications: desirable qualities.
    5. Architecture -- package diagram
    6. Domain model + that has at least one example of a generalization.
    7. Glossary
    8. Business Rules
    9. System Sequence Diagrams for nearly all interesting scenarios.
    10. Interactions: sequence or communication diagrams for all interesting messages in your SSD. With some comments explaining why (GRASP and GoF) you choose that assignment of messages to classes.
    11. Design classes (DCD) that support all your interactions. These should include some generalizations/interfaces/polymorphism.


    Everything should fit together.

    Includes and uses some generalizations.

    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. [ 02DiceGameClasses.gif ] (example).
  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 set of objects and/or classes 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 has no value now, 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 it 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.

( End of document ) <<Contents | Top