[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] objectives.html Wed Dec 12 07:39:30 PST 2012

Contents


    CS375 Objectives

      This document describes the objectives of CSE375 course. It replaces [ old.objectives.mth ]

      Relevant ABET Accreditation Goals


      1. Analysis and design IV-6
      2. Theoretical foundations IV-7
      3. Communication skills IV-14 (oral + written)
      4. Collaborative skills IV-16
      5. Study in an IS environment IV-2

      375 Mission

      To learn how to express requirements and analyse them to produce a comparatively stable architecture and maintainable object-oriented design to meet user's needs, using currecnt notations and techniques.

      375 Content

      There should be evidence on file that demonstrates that during CSe375 the students:
      1. Worked in small groups/teams to analyze systems and propose solutions.
      2. Presented their work for review by peers, faculty, and IS workers.
      3. Completed a UML model for a computerized solution to a problem in an existing system.
        1. (Note. The solution may expressed on paper, as a presentation, and/or as a web site.
        2. It may or may not include simply prototypes.
        3. It may be a photographic or software record of a presentation.
        4. )

      4. Carried out a group simulation of at least one object-oriented program design.

      375 Learning Objectives

      After completing the CSE375 student will be able to:
      1. Define a use case and give examples.
      2. Define a scenario and write simple examples of scenarios.
      3. Distinguish actors from use cases and give examples of actors.
      4. Use simple UML use case diagrams + scenarios to state requirements.
      5. Correctly utilize use case extension, includes and generalization.
      6. Draw object-oriented domain models using UML class diagrams with classes, associations, roles, and multiplicities.
      7. Extend a domain model to include attributes/data.
      8. Allocate responsibilities to classes and test result vs scenarios.
      9. Use UML Package diagrams to anlyse and design stable software architectures.
      10. Use UML message sequence diagrams to describe interactions between objects.
      11. Use UML communication diagrams to describe interactions between objects.
      12. Use UML communication diagram sequence numbers correctly.
      13. Use iteration and conditions correctly in communication and sequence diagrams.
      14. Translate between message sequence and communication diagrams.
      15. Know how to draw, read, and critique a UML class diagram with attributes and operations.
      16. Cross-validate a use case model plus communication/message sequence diagrams against a class diagram.
      17. Use the General Responsibility Assignment Patterns to place operations in a design model.
      18. (Design model = class diagram + either message sequence or communication diagrams).
      19. Extend simple class diagrams to include generalization, aggregation, and composition.
      20. Recognise and analyse some simple design patterns correctly: State, Composite, Observer, Factory, Adapter, ...

      375 Options

      After completing the 375 a student may:
      1. Use either CASE tools or low-tech techniques (chalk board, posters, cards) for documentation.
      2. Use the UML notation for parameterized, active, and interface classes.
      3. Develop simple prototypes and tests as executable specifications of components.
      4. Develop a first iteration of a set of components.

    . . . . . . . . . ( end of section CSE375 Objectives) <<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. [ 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 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 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