CSci 375/09 Packages
Table| Date # | Topic (Participation 2pt) | Study pages (2 pts) | Quiz(15 pts) | Project Work(10 pts)
|
|---|
| Previous 8 | SSDs | 173-196 | - | W3(Domain Model 1)
|
| Today 9 | Packages | 197-219 | Q4(173-219) | -
|
| Next 10 | Interactions | 221-247 | - | W4(transition to design)
|
(Close Table)
Revision History
Table| Version# Date | Description | Author
|
|---|
| 0 2005-01-03 | Used boiler plate to make template | RJB
|
| 1 2005-01-31 | Input section headings | RJB
|
| 2 2006-02-02 | Update to 2006 | RJB
|
| 3 2006-02-08 | Added link to questions | RJB
|
| 4 2006-02-13 | Added link to Exercise answer | RJB
|
| 4 2007-02-05 | Added link to simple packages diagram | RJB
|
(Close Table)
Project -- First Domain Model Due
13 Packages: How to organize a complex project
- This is just a rapid introduction to
Logical Architecture
which defines how a complex project is divided into understandable
groupings.
- *** A good set of packages is stable.
- *** 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 ]
- A package should contain a collection of related artifacts.
- Arrows show dependencies.
[ Dependency in uml1 ]
- If A - - - - > B then a change in the design of B may force
you to change A as well.
- No connection between packages mean: You can change one without
the other breaking.
- * When there are dozens of classes you have to group them
to stay sane!
- * The idea is to get related classes into a package and separated from
the independent ones.
- If you are wise and your tools support it
each package maps into a folder/directory in your source code directory.
- Notes and lectures
[ search?q=Layers+packages+architectures ]
- Fig 13.1 Artifact influences
- * 13.1 Example packaging: UI + Domain + Technical Services
- * 13.2 Definitions
- 13.3 Case studies focus on Domain/Core application layer
- * 13.4 Definition of
Software Architecture
- ** 13.5 UML - Package diagrams: folders and dependencies.
- +++ learn the notation.
- *** 13.6 Guideline: Use the classic layers
- *** Domain layer reflects the domain model.
- *** 13.7 Separate Model (data + logic + etc.) from View(what the user sees...)
from Control (what the user can do...).
[ patterns.html#MVC ]
- 13.8 SSD -> System Operations->Layers
- 13.9 Example: Nextgen
- 13.10 Example: Monopoly
. . . . . . . . . ( end of section Packages: How to organize a complex project) <<Contents | End>>
14 Object Design
- * Three ways of designing objects: code, draw+code, draw(magic code)
- ++ Cynthia Farquhar's research uncovered a 4th strategy: code and then
document.
- * 14.1 Agile modeling & Lightweight UML
- - 14.2 UML CASE
- * 14.3 How much time drawing? NOT MUCH.
- *** 14.4 Static vs dynamic models.
- * 14.5 Object design skill vs UML Notation Skill
- 14.6 Another technique
- 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
expriences.
. . . . . . . . . ( end of section Object Design) <<Contents | End>>
Exercises on SSDs and Packages
Draw SSDs based on given scenario
[ 09x.html ]
from a use case.
Answer:
[ 09SSD060208.jpg ]
Exercise: Write a letter to your grandmother explaining what she should
do with those little drawings of folders on her computers screen.
Exercise: What are the parts (A,B,C,x,y,z) of this diagram:
and what do they mean?
Exercise: Name three typical layers in a logical architecture and
draw a diagram of them with packages and dependencies.
Answer:
[ 09Packages.png ]
Next Assigned Work: SSD+Packages
[ w4.html ]
Due next week.
Questions and Answers on Logical Architecture
[ 09q.html ]
Quiz on SSDs
TBA
Review Questions
[ 09r.html ]
Standard Definitions
- CS202::= See http://cse.csusb.edu/dick/cs202/.
- CS372::= See http://cse.csusb.edu/dick/cs372/.
- DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
- DRY::XP="Don't Repeat Yourself".
- ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm,
Ivar Jacobsen simplified "Essential" UP.
- Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
- GoF::="Gang of Four",
[ patterns.html#GoF ]
- 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 ]
- Grades::= See http://cse.csusb.edu/dick/cs375/grading/.
- 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.
- OO::shorthand="Object-Oriented".
- OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
- patterns::="Documented families of problems and matching solutions", see
Patterns.
- Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.
- Process::="How to develop software".
- RJB::=The author of this document,
RJB="Richard J Botting, Comp Sci Dept, CSUSB".
- RUP::Process="Rational UP", a proprietary version of UP.
- SSD::="System Sequence Diagrams", see chapter 10.
- TBA::="To Be Announced".
- UML::="Unified Modeling Language".
[ Unified_Modeling_Language ]
- UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.
- 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".
- XP::="Extreme Programming", the ultimate iterative code-centric, user-involved
process.