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


    Example Winter 2010 -- How to organize The Frequently Asked Questions on this site


      1. Jan 27th. RJB generated the missing Domain Model graphic. and added UCs.
      2. Jan 22nd. RJB drew first domain model.
      3. Jan 21st. RJB explained the problem to the class and elicited first use case. RJB initiated file with glossary.

      . . . . . . . . . ( end of section Blog) <<Contents | End>>


      A piece of software that will rapidly organize the accumulated questions and answers [ Use Case 1 ] for a topic in this course.

      Use Case 1 -- Organize FAQs

        (UC1Name): organize FAQs
        (UC1Primary actor): me -- faculty, harassed, confused.
        (UC1Main scenario):
        1. user gives file name and system finds it.
        2. system sorts the file by page number (Risk1)
        3. user reviews result
        4. system publishes result

      Use Case 2 -- Add a new FAQ to an organized set of FAQs

      Use Case 3 -- Delete FAQ from set of FAQs

      Use Case 4 -- Edit a FAQ


      Are UC2,3,4 too detailed? All parts of a larger Usecase.


      (rapidly): Some response in a tenth of a second, complete reorganization within 5 seconds in 99.9% of cases.


      (Risk1): Is the format consistent for page numbers? Answer: NO.

      Domain Model

      A set of FAQs contain many FAQ, and each FAQ has a headline and a number (0 or more) other lines.


      Glossary and Data Dictionary

    1. FAQ::glossary="Frequently Asked Question".

    2. FAQ::data=headline #nonheadline.
    3. FAQs::= #FAQ, any number of FAQ.
    4. headline::= ". " line.
    5. nonheadline::= line ~ headline.
    6. line::= #(char~eoln) eoln.

      Details in [ http://cse.csusb.edu/dick/maths/ ]

    . . . . . . . . . ( end of section Example Winter 2010 -- How to organize The Frequently Asked Questions on this site) <<Contents | End>>

    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.