[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] 15.html Tue Feb 26 15:04:24 PST 2013

Contents


    CSci 375/15 More Analysis


    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous14Design..Code363-394-W6(GRASP)
    Today15More Analysis401-413Q7(1-413)-
    Next16GRASP II413-435-W7(Model 2: use cases, domain, interactions, classes)

    (Close Table)

    Revision History


    Table
    Version#DateDescriptionAuthor
    02005-01-03Used boiler plate to make templateRJB
    12005-02-17Added outlineRJB
    22005-02-28Added sample from Q7RJB
    32005-03-02Added Questions and some answersRJB
    42006-02-16UpdatedRJB
    52006-02-27Corrected chapter numbersRJB
    62013-02-26Add new example of PolymorphismRJB

    (Close Table)

    Project W6 (GRASP) due in

    Iteration 2

      Skip chapter 22 unless you really want to read it. It has some good practical advice on selecting tools. It also quotes three ways to use diagrams:

      1. Informal sketch to clarify ideas
      2. Formal Blueprint defining the code
      3. A programming language

      No questions on the final or in quizzes.

      23 Iteration 2

    1. Introduction.
    2. 23.1 moving from iteration 1 to iteration 2
    3. 23.2 Focus: Object design and Patterns

      24 Analysis (again)

    4. 24.1 NextGen (note)
    5. **** Figure 24.1 has an SSD with many external actors.
    6. 24.2 Monopoly (note)
    7. **** Focus on Generalization on pages 410 and 411.
      1. Any sub is a special kind of super

        [Smile and Frown as special kinds of face]

        Lots of examples

      2. +++ Notice [---|>] the form of the arrow head.

      3. Notice:-
        1. Special classes have all the properties of the general classes.
        2. Special classes are more complex than the general ones.
        3. Special classes add attributes and operations to the general class.
        4. Special versions of operations override the general versions.

      4. *** When sub--|>super is useful.
      5. * Make super classes abstract (normally)
      6. ** Include super class name in subclass name
      7. ++ refactoring: create a superclass to reduce repeated code.


      (note): Look at these changes to requirements to help understand the future design decisions in the book. I will not test you on your knowledge of NextPoS or Monopoly. You may, if you wish, ask questions on this chapter.

      Explanation of Polymorphism

      To get polymorphism (easily) you need a language that has pointers and inheritance.

      For example, to make a Wodget a special kind of Widget we might write

       	class Wodget extends Widget { stuff } // Java
      or
       	class Wodget : public Widget { stuff }; // C++
      or
       	class Wodget(Widget)... // Python
      or
       	class Wodget < Widget... // Ruby

      Assume that somewhere in Widget and in Wodget there is a function

       		public void zark( ... ) { ... } //Java
       		public: void virtual zark( ... ) { ... }; //C++

      Secondly you declare a variable or parameter that refers or points to an object of type Widget

       		Widget myWidget; //Java objects are pointers!
       		Widget *myWidget; //C++

      Then you attach the variable or parameter to an object of type Wodget:

       		myWidget = new Wodget ( ... );
      (for example).

      Then in an OO language like Java will make the behavior of myWidget match that of a Wodget, not a Widget.

       		myWidget.zark( ... ); //Java
       		myWidget->zark( ... ); //C++

      If you get Widget behaviors then you don't have polymorphism. In C++ this means you forgot to declare the functions as virtual or to use a pointer.

      Notice that some assembler language systems in the 1970s did this -- Sketchpad for example.

      Notice that we take polymorphism for granted in every day life. We don't expect real objects to work differently when you rename them.

      Notice that we can now place behaviors inside objects and when we pass these objects around our software they take their the behavior with them. One function can tell another object how to do something!

      Example of Polymorphism -- Loaded Dice [ LoadedDie.cpp ] [ testLoadedDie.cpp ]

      [ DiceGame2.cpp ] [ testDiceGame2.cpp ]

      Exercises

      [ 15x.html ]

      Quiz 7

      [ Q15sample.gif ]

      Project Work 7: Second complete set of models due next Tuesday.

      [ w7.html ] (This is a big piece of work start working now)

      Questions and Answers Generalization etc

      [ 15q.html ]

      Next -- More GRASP using Generalization and polymorphism

      [ 16.html ]

      Review Questions

      [ 15r.html ]

      Standard Definitions

    8. Artifact::="Anything that is created in the course of a project".
    9. artifact::=see above.

    10. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code. [ 02DiceGameClasses.gif ] (example).
    11. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".

    12. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
    13. GoF::="Gang of Four", [ patterns.html#GoF ]
    14. 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 ]
    15. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

    16. 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 has no value now, see YAGNI.

    17. OO::shorthand="Object-Oriented".
    18. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.

    19. patterns::="Documented families of problems and matching solutions", see Patterns.
    20. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

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

    22. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci and Engineering School, CSUSB".
    23. RUP::Process="Rational UP", a proprietary version of UP.

    24. SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

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

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

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

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

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

    ( End of document ) <<Contents | Top