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

Contents

    19 OO Design


      Table
      Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
      Previous18Domain Model III501-539-W8(Model 3: model 2 improved) [ w8.html ]
      Today19 Revu Interactions and DCDs 221-270 [ 19.html ] Q9(1-535)
      Next20Reviewall [ 20.html ] - W9(Model 4) [ w9.html ]

      (Close Table)

      Revision History


      Table
      Version# DateDescriptionAuthor
      02005-01-03Used boiler plate to make templateRJB
      12005-03-14Added section headings and some notes and linksRJB
      22005-03-16Added more notesRJB
      32006-01-20Updated notes pagesRJB
      42007-03-09Removed chapters 33,34,36,37,39RJB
      52008-02-05Moved MVC details to patternsRJB
      62008-03-05Added emphasis on packages and deploymentsRJB
      72008-12-23Removed architecture and deploymentRJB
      82010-03-10Updated reading and review qnsRJB

      (Close Table)

      Reading -- Pages 221-270 -- Again

      Review Questions 19

      Do as many of these as you can [ 19r.html ] and hand in one for grading.

      Project W8 -- Model 3 due in

      Review the Unified Process

      Name the phases and disciplines.

      How do they relate?

      Describe a typical iteration in each of the phases.

      Review Domain Modelling and Use Case Models

      You have been asked by "Facilities Services" to develop an inventory program for CSUSB. It will allow the facilities management keep track of where thing are on campus. Things can be furniture or equipment. There are many special kinds of furniture and or equipment. Each thing is in one place (a classroom, laboratory, storage, etc.). But a place can have many things in it. Using the classroom as a source of concepts draw a domain model for this system.

      Draw a UML diagram of half-a-dozen likely use cases for the inventory system. Write a brief description of one of them.

      Review Interaction Diagrams and Design Class Diagrams

        Two types of interactions

        Sequence

        Objects, lifelines, found message, activations, messages. Metaclasses, create, delete.

        Communication

        Objects, associations, messages, found message,... Metaclasses, create, delete.

        Design Class Diagrams

        One DCD for a set of interaction diagrams -- indeed for the whole project (if small enough).

        Classes, attributes, associations, generalization, interfaces, dependencies, ...

        Fitting them into the Process

      . . . . . . . . . ( end of section Review Interaction Diagrams and Design Class Diagrams) <<Contents | End>>

      Questions and Answers

      [ 19q.html ]

      Exercises on understanding OO Design

      [ 19x.html ]

      Next Assigned Project: The fourth iteration

      [ w9.html ]

      Quiz 9 -- UML Notations

    . . . . . . . . . ( end of section 19 OO Design) <<Contents | End>>

    Next -- Final Course Review and Project work

    [ 20.html ]

    Previous to 2009 we also did this

      -- Chapter 33 Architectural Analysis

    1. YAGNI
    2. Architecture is about making Technical decisions based on the Purposes and Qualities that are required. -- Chapters 33 and 34. [ architecture.html ] (Not on final)

      -- Chapter 34 Logical Architectural Refinement

    3. * 34.1 Example NextGen
    4. **** Pay attention to these examples. The three layers (figures 34.1,2,3) are usable in just about every project. Just the details change.
    5. **** Pay attention to the coupling between layers -- figures 34.2 and 34.3.
    6. * 34.2 Collaboration vs Layers
    7. ** notice the use of GoF Facade to hide the complexities of a subsystem from its clients.
    8. ** Notice how you may have so many Controller facades that they should go in their own package/layer (figure 34.7)
    9. * 34.3 Issues with Layers
    10. ** Classic Three-Tier Architecture: Client+Web server+DataBase Notice how this may or may not be deployed accross several physical servers.
    11. ** Classic Three Layer Architecture: Model-View-Control [ patterns.html#MVC ]
    12. *** 34.4 MVC and Upward Communication

      -- Chapter 35 Package Design

    13. ** 35.1 Guidelines
    14. ++ Packages show how you organize your classes.
    15. ** Organize your classes into classic packages.

      -- Chapter 36 More Patterns

      YAGNI in this class... You may need them in practice. I have put some of them into the [ patterns.html ] page for this class. It is almost certain that in practice you will need to handle exceptions and errors and this chapter has some excellent advice, including the Proxy pattern developed by the GoF. Notice that you can understand figure 36.12 in terms of GRASP paterns.... In 36.7 Larman introduces the Abstract Factory by the GoF which you will need when creating complex objects. Then there is the Do It Myself pattern in section 36.8 -- you might say this is the original OO design paradigm "A properly designed OO light bulb will screw itself into the socket"

      -- Chapter 37 Persistance Framework

      Nice Examples. You'll need to do things like this is a real project but not in CS375 quizzes and finals -- YAGNI.

      -- Chapter 38 Artifacts, Nodes, and Deployment Diagrams

    16. **** 38.1 A Deployment Diagram Simple and useful.
    17. ++++ In this course, no need to shade edges of nodes.
    18. ++ A deployment shows parts of the Physical system: hardware, , operating systems, virtual machines, run-time environments, data bases, etc

    19. These are called nodes.

    20. node::="any hardware or software that is needed to execute other software".

    21. Nodes are connected by links labelled with protocols to indicate communication.

    22. ++ It can also show things the you produce that are deployed on the nodes. These are called artifacts.

    23. artifact::="anything you produce while developing software", including code, diagrams, tests, executables, DLLs, tarballs, JARs, scripts, ...

    24. ++ These artifacts can realize (contain, implement) components and classes in your design, but they can include documentation as well.
    25. 38.2 Components.
    26. YAGNI
    27. -- We will skip Component diagrams until their usage moves from theory and hype into practice.

      Exercises on Deployment and Packages


      1. What can you recall from this weeks readings?
      2. Can you distinguish subtle UML differences?

    . . . . . . . . . ( end of section Previous to 2009) <<Contents | End>>

    Review Questions

    [ 19r.html ]

    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.

End