[Skip Navigation] [ CSUSB ] / [CNS] / [Comp Sci & Engineering] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Question] [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] w5.html Mon Sep 28 15:48:38 PDT 2009

Contents

    Assigned Work 5: First Interaction and Class diagrams
    Table
    Version#DateDescriptionAuthor
    02005-02-07Copied from W4 and edittedRJB
    12006-02-15Added some more details RJB
    22009-03-04Stated rules for SSD->Interactions RJB

    (Close Table)

    Given
    1. Requirements
      • Vision
      • Business Case
      • Use Cases: a few fully dressed, most named, brief, or casual.
      • Supplementary Specifications(if any)
      • Business Rules(if any)
      • Glossary
    2. Domain model with classes, associations, and some attributes.

    3. SSDs of interesting scenarios

    4. A first logical architecture

    Note

     In early iterations most of the above will need revision as the project proceeds.

    Deliverables
    1. Use case with SSD of an interesting scenario
    2. Interaction diagrams (sequence or communication) for events/messages in SSD with GRASP annotations. Note: Each interaction diagram should have precisely one found event/message taken from the SSD. It should show how a set of objects inside the software can carry out the step.
    3. A class diagram that supports all the interaction diagrams. Notice: many interactions generate a single design class diagram.
    4. Do not do any login/logout messages yet.


    (annotations): These are informal, but vital. The name of the GRASP links one message to an object, as in the book.

    Hint 1

     In real projects you should do the more complex SSDs but here (Grading) you just need to show that you've got the ideas as shown on a simple one to get the credit.

    Hint 2

     Use at least the first two GRASP patterns -- Information Expert and Creator in your designs. Perhaps Controller if necessary. Initially take your classes from the domain model, then from the design class diagram.

    Process
    1. Review previous documentation.
    2. Think...
    3. Draw rough diagrams: interactions+class diagram.
    4. Edit rough diagrams.
    5. Prepare less rough ones(one interaction+class) to hand in with use case and SSD.
    6. Plan a presentation where the team acts out one of the collaborations. Each person should play the part of an object.
    7. Present SSD, interactions, and class diagram showing how the classes support the interaction and the interaction realizes the use case(5 minutes).
    8. Revise paper deliverables.
    9. Submit copy for grading.

    Grading

     Points are for following the notation and hints in pages 221-270.

    Standard Definitions

  1. CS202::= See http://cse.csusb.edu/dick/cs202/.
  2. CS372::= See http://cse.csusb.edu/dick/cs372/.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. DRY::XP="Don't Repeat Yourself".

  5. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

  6. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  7. GoF::="Gang of Four", [ patterns.html#GoF ]
  8. 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 ]
  9. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

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

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

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

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

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

  18. SSD::="System Sequence Diagrams", see chapter 10.

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

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

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

  22. 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 means "It won't be on the final or in quizzes".

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

End