[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] FIS1.html Mon Sep 28 15:49:34 PDT 2009

Contents

    Free Interface to College

      Free Interface to College Use Cases

        Note that some use cases were named but not described! I've also had to pick, choose, simplify (abbreviate?), and combine use case descriptions.

        Order Books

        A student goes online and orders the books for the classes in which they have enrolled.

        Retrieve Course's Book list

        A student provides one or more course numbers for the current period. The system retrieves the book list from the bookstore. The system provides the list of books to the student, grouped by course.

        Review Class Schedule

        Also known as:

        Review Schedule

         Student uses FIS to access TRACS and logs in using student Id and a PIN. The student requests a class schedule and is shown it by the system.

        Get Syllabus

        This use case lets a student to get a syllabus for a registered class. After accessing FIS the student is listed the courses in which they are registered. The student chooses to retrieve the syllabus for a course and the system displays the syllabus.

        View Grades

        Also known as

        Review Grades

         The student must authenticate themselves and is then given a list of classes they have taken. The student selects a class and sees the grade for that class. The student can then log of or see other classes.

        Update Class Schedule

        Get Assignments

        Review To-Do list

        View map of location

      . . . . . . . . . ( end of section Free Interface to College Use Cases) <<Contents | End>>

      Domain Model

      First FIS domain model

    . . . . . . . . . ( end of section Free Interface to College) <<Contents | End>>

    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