CSCI375: Header
[Text Version] header.html Mon Sep 28 15:44:49 PDT 2009

Contents

    Header

    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
[Text Version] old.19.html Mon Sep 28 15:44:51 PDT 2009

Contents

    19 Architecture


      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)
      Today19Architectures 541-586+651-660 [ 19.html ] Q9(541-586+651-653)
      Next20Reviewall-W9(Model 4 with components and deployment)

      (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

      (Close Table)

      Important points
    1. Architecture is about making Technical decisions based on the Purposes and Qualities that are required. -- Chapters 33 and 34. [ architecture.html ]
    2. Organize your classes into classic packages -- Chapter 36.
    3. Plan your hardware and software using deployment diagrams -- Chapter 37
    4. ++ Don't forget: in an agile method -- never draw a diagram or write a document unless you can see some value (to the client) for doing it.

      Chapter 33 Architectural Analysis
    5. * 33.1 When?
    6. ** 33.2 Variation and Evolution: Where
    7. * 33.3 Architectual Analysis
    8. * 33.4 Steps in Architectual Analysis
    9. *** 33.5 Factors driving architectural decisions
    10. ** 33.7 The Art....
    11. * 33.8 Themes
    12. * 33.9 Iteration
    13. ++ Forms/templates in HTML [ architecture.html ]

      Chapter 34 Logical Architectural Refinement
    14. * 34.1 Example NextGen
    15. * 34.2 Collaboration vs Layers
    16. * 34.3 Issues with Layers
    17. ** Classic Three-Tier Architecture
    18. *** 34.4 MVC and Upward Communication

      Chapter 35 More GoF

       YAGNI in this class... You may need them in practice.

      Chapter 36 Package Design
    19. ** 36.1 Guidelines
    20. ++ Packages show how you organize your classes.

      Chapter 37 Artifacts, Nodes, and Deployment Diagrams
    21. **** 37.1 A Deployment Diagram Simple and useful.
    22. ++ In this course, no need to shade edges of nodes.
    23. ++ A deployment shows parts of the system that your didn't build like the machinary, the operating systems, virtual machines, run-time environments, data bases, etc
    24. ++ It can show these as nodes even if you did develop them.
      ++ It can also show things the you did produce that are deployed on the nodes: artifacts.
    25. artifact::="anything you produce while developing software", including code, diagrams, tests, executables, DLLs, tarballs, JARs, scripts, ...
    26. node::="any hardware or software that is needed to execute other software".
    27. ++ These artifacts can realize (contain, implement) components and classes in your design, but they can includes documentation as well.
    28. 37.2 Components.
    29. -- We will skip Component diagrams until their usage moves from theory and hype into practice.

      Exercises Deployment and Packages

      Quiz 9 on UML Diagrams

      Questions and Answers

       [ 19q.html ]

      Assigned Project: The fourth iteration

       [ w9.html ]

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

    Next -- Final Project Presentations and Course Review

    [ 20.html ]

    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