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


    375 Objectives Tested in Final

      Vision and Business Case

    1. What is a vision and what is it for?
    2. What is a business case and what is it for?

      Domain Models

    3. Describe a glossary and explain its purpose in a project.
    4. Define a data dictionary and explain its purpose in a project.
    5. Draw domain models using UML class diagrams with classes, associations, roles, and multiplicities. Some classes may have attributes.
    6. May incude generalization.
    7. Use multiplicities and role names correctly.
    8. Give the purpose of a domain model in a project.
    9. Avoid using aggregation and composition in a domain model.
    10. No operations in domain models!
    11. Use the UML derived attribute notation only when needed.
    12. Explain the purpose and use of a domain model.
    13. Give examples of the use of the Glossary.


    14. Describe what a stakeholder is and why they must be identified.
    15. List half-a-dozen types of stakeholders in a project.
    16. Distinguish functional from non-functional requirements.
    17. Give examples that typify functional and non-functional requirements.
    18. Give a list of half-a-dozen types of requirements. (you can use the books FURPS+ or my PQRST or any other mnemonic).
    19. Explain why we separate functional from non-functional requirements.
    20. Give examples of nonfunctional requirements/ilities/Qualities.
    21. What is a "Supplementary Specification" used for?
    22. Give an example of a businesss rule.
    23. Give an example of a non-functional requirement and its impact on your team's project.

      Use Case Model

      [ usecases.html ]
    24. Define a use case and give examples using the brief format.
    25. Use either the brief or casual format to describe a use case.
    26. List half-a-dozen of the headings in Larman's Fully Dressed Use case.
    27. Define a scenario and write simple examples of scenarios.
    28. Distinguish actors from use cases and give examples of actors.

    29. Use simple UML use case diagrams + scenarios to state requirements. Note: use case diagrams do not have to show the system boundary.
    30. Correctly use extensions in a written use case.
    31. Keep use case diagrams simple by avoiding details and complicated relations.
    32. Reproduce parts of your team's project's use cases.

      Interaction Diagrams

    33. Describe the relations between and purposes of: interaction, sequence, and communication diagrams.
    34. In interaction diagrams: distinguish class for instance, and from named instance.
    35. In interaction diagrams: draw creation and destruction correctly.
    36. Use UML a Systems Sequence Diagram(SSD) to describe a scenario as a series of messages passed between actors and the system.
    37. Use UML message sequence diagrams to describe interactions between objects.
    38. Use UML communication diagrams to describe interactions between objects.
    39. Use UML communication diagram sequence numbers correctly.
    40. Use iteration and conditions correctly in communication and sequence diagrams.
    41. Translate between given sequence and communication diagrams.
    42. Note: .set
    43. Sequence diagrams will normally omit return arrows unless data is being returned.
    44. Normally they will show synchronous arrows not asynchronous ones.
    45. In designs, you may have ONE(1) "found message": an arrow coming from nowhere.
    46. Reproduce parts of your team's project's interaction diagrams.

      Design Class Diagrams

    47. Draw, read, and critique a UML class diagram with attributes and operations.
    48. Use arrows etc correctly in class diagrams. [ arrows.gif ]
    49. Use multiplicities and role names correctly in a design class diagram
    50. Allocate responsibilities to classes and test result vs scenarios.
    51. Use the General Responsibility Assignment Patterns to place operations in a design model.
    52. Use visibility(-#+) and derivation (/) symbols correctly in a class diagram.
    53. Make sure a set of communication/message sequence diagrams is supported by a class diagram.
    54. Extend simple class diagrams to include generalization, aggregation, and composition.
    55. Use dependency, association, generalization, composition, etc correctly.
    56. Avoid using aggregation in a design class diagram.
    57. Explain why aggregation is avoided in a design class diagram.
    58. Use the two notations for interface correctly.
    59. Use the idea of interface to make a design more flexible.
    60. Use the following stereotypes correctly: <<enumeration>>, <<interface>>, <<singleton>> (1), <<constructor>>, ...
    61. Use the following constraints correctly: {abstract}, {create}, {active}, {complete}, {disjoint}, {ordered}, ...
    62. Reproduce parts of your team's project's class diagrams.

      Patterns and Principles

      [ patterns.html ]
    63. List the GRASP patterns.
    64. Illustrate the use of the GRASP patterns in moving from a domain modeland use case to a design.
    65. Given a GRASP pattern show how it might be applied in an example.
    66. Explain and apply MVC.
    67. Use some simple "GoF" design patterns correctly: Singleton, Decorator, Factory, Adapter, Facade, State, Command, ...
    68. Explain: DRY and YAGNI.
    69. Explain what a pattern is and how they are used.
    70. Describe how your team used some patterns in your project.

      Architecture and Packages

    71. Draw, explain and critique package diagrams with packages, classes, and dependencies.
    72. List a the typical set of layered packes in the book and describe one of them in more detail.
    73. Describe your team's project's logical architecture.

      Planning and Process

    74. Describe the sequence of phases in a Unified Process (UP).
    75. How does Inception differ from Elaboration and Elaboration from Construction and Transition.
    76. Give three simple rules for whether an artifact (diagram, memo, text,... program) should be prepared.
    77. Compare iterative development planning differ with traditional Systems Development Life Cycle?
    78. Write down a list of five(5) Unified Process Best Practices. Describe what one of these means in detail.
    79. What does agility and adaptiveness mean in software development?
    80. Compare how models are used in a traditional life cycle and in the Unified Process.
    81. How do the UP disciplines relate to UP iterations?
    82. List upto half-a-dozen of the 9 UP disciplines.


    83. All students should be able to recall the work done in their project well enough to describe a given part of it from memory.

    . . . . . . . . . ( end of section 375 Objectives Tested in Final) <<Contents | End>>


  1. PQRST::RJB=Purposes, Qualities, Realities, Systems, Techs, a mnemonic for various types of requirement. Purposes include funtions and use cases and define why someone wants the software. Qualities are the needed properties of the software like security and performance. Realities are domain models
  2. including static classes and dynamic start charts. Systems are the existing systems that we are designing, replacing, using, modifying, and competing with. Techs include technologies, techniqes, etc. and describe what and how we might construct the software -- the decisions we make: eg-- use VB and MySQL.
  3. DRY::="Don't Repeat Yourself".

    Standard Definitions

  4. Artifact::="Anything that is created in the course of a project".
  5. artifact::=see above.
  6. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  7. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  8. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  9. GoF::="Gang of Four", [ patterns.html#GoF ]
  10. 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 ]
  11. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

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

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

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

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

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

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

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

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

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

  24. 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".

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