[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] 09.html Mon Feb 4 11:30:10 PST 2013
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

Opening Microsoft files (winzip, word, excel, powerpoint) on this page may require you to download a special viewer. Or you can download and save the files and use your preferred office applications to view and edit them.

Contents

    CSci 375/09 Packages


    Table
    Date #Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous 8SSDs173-196-W3(Domain Model 1)
    Today 9Packages197-219Q4(173-219)-
    Next 10Interactions221-247-W4(transition to design)

    (Close Table)

    Revision History


    Table
    Version# DateDescriptionAuthor
    0 2005-01-03Used boiler plate to make templateRJB
    1 2005-01-31Input section headingsRJB
    2 2006-02-02Update to 2006RJB
    3 2006-02-08Added link to questionsRJB
    4 2006-02-13Added link to Exercise answerRJB
    5 2007-02-05Added link to simple packages diagramRJB
    6 2011-01-31Added links to PPTs and PDFsRJB
    7 2011-02-05Added Dice Game exerciseRJB

    (Close Table)

    Project -- First Domain Model Due

    13 Packages: How to organize a complex project

    1. This is just a rapid introduction to Logical Architecture which defines how a complex project is divided into understandable groupings.

    2. *** A good set of packages is stable.

    3. *** There are standard ways to do this. For example in a simple project we keep the User Interface, Domain, and Technical Services separate: [ 09Packages.png ] and so I expect you to know this diagram (at least) as an example Package Diagram.

    4. A package should contain a collection of related artifacts. Artifacts in different packages should be less related.
    5. Arrows show dependencies. [ Dependency in uml1 ]
    6. If A - - - - > B then a change in the design of B may force you to change A as well.
    7. No connection between packages mean: You can change one without the other breaking.

    8. * When there are dozens of classes you have to group them to stay sane!
    9. * The idea is to get related classes into a package and separated from the independent ones.
    10. If you are wise and your tools support it each package maps into a folder/directory in your source code directory.

    11. Notes and lectures slide shows -- [ session09.pdf ] (PDF on packages and OOAD), [ LarmanChap13.ppt ] (NJIT's slides for Larman's chapter), [ 04-package-diagrams.pdf ] (academic approach), [ wiki?FourLayerArchitecture ] (View+Application+Domain+Infrastructure), etc.

    12. Fig 13.1 Artifact influences
    13. * 13.1 Example packaging: UI + Domain + Technical Services
    14. * Another useful one: UI + Application + Domain + Technical Services (including Persistance and Networking)

      [Described above]

    15. * 13.2 Definitions
    16. 13.3 Case studies focus on Domain/Core application layer
    17. * 13.4 Definition of Software Architecture

    18. ** 13.5 UML - Package diagrams: folders and dependencies.
    19. +++ learn the notation. Sample packages and a dependency

    20. *** 13.6 Guideline: Use the classic layers
    21. *** Domain layer reflects the domain model.
    22. *** 13.7 Separate Model (data + logic + etc.) from View(what the user sees...) from Control (what the user can do...). [ patterns.html#MVC ]
    23. 13.8 SSD -> System Operations->Layers
    24. 13.9 Example: Nextgen
    25. 13.10 Example: Monopoly

    . . . . . . . . . ( end of section Packages: How to organize a complex project) <<Contents | End>>

    14 Object Design

    1. * Three ways of designing objects: code, draw+code, draw(magic code)
    2. ++ Cynthia Farquhar's research uncovered a 4th strategy: code and then document.
    3. * 14.1 Agile modeling & Lightweight UML
    4. - 14.2 UML CASE
    5. * 14.3 How much time drawing? NOT MUCH.
    6. *** 14.4 Static vs dynamic models.
    7. * 14.5 Object design skill vs UML Notation Skill
    8. 14.6 Another technique
    9. CRC::= Class Responsibility Collaboration Cards. I don't really believe in these! I don't require you to study these. You can experiment with them if you like. No points will be gained or lost on projects for just using or not using CRC. I'll be interested in gathering your experiences.

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

    Exercises

    [ 09x.html ]

    Next Assigned Work: SSD+Packages

    [ w4.html ] Due next week.

    Questions and Answers on Logical Architecture

    [ 09q.html ]

    Review Questions

    [ 09r.html ]

    Quiz on SSDs

    Goal: prove that you can draw a good System Sequence Diagram for a given scenario.

    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 has no value now, 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