[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] w4.html Wed Jan 11 07:26:28 PST 2012

Contents


    Assigned Work 4: SSDs and Logical Architecture


    Table
    Version#DateDescriptionAuthor
    02005-02-04Copied from w3 and edittedRJB
    12011-01-26Added some notesRJB

    (Close Table)

    Given

    Requirements
    1. Vision
    2. Business Case
    3. Use Cases including interesting scenarios of significant use cases
    4. Supplementary Specifications(if any)
    5. Business Rules(if any)
    6. Glossary
    7. Domain model with classes, associations, and some attributes.

    Deliverables

    The deliverables form a packet and every element in the packet should be there in the listed order.
    1. SSD of at least one interesting scenario of a significant use case.
    2. A first logical architecture.

    Note: these two types of documentation are independent of each other. The SSD does not change if you re-package the design!

    Process


    1. Review previous documentation.
    2. Think...
    3. Draw rough diagrams.
    4. Edit rough diagrams
    5. Prepare a less rough one to hand in
    6. Bring to class on paper and present(5 minutes). Submit copy of deliverables.

    Grading

    Points are for following the notation (messages and packages) and the hints in pages 173-219. In early iterations most documents will need revision as the project proceeds.

    Hint: KISS

    Keep It Simple!

    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 Dept, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

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

  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.

End