91.522 Object-Oriented Analysis and Design
http://www.cs.uml.edu/~lechner/03f522/03f522syllabus.htm
(This syllabus
is maintained with MSOffice97® and is subject to change)
|
Office: OS210 |
OfficePhone: 978-934-3632 |
|
Email: lechner@cs.uml.edu |
HomePhone: 781-444-8321 |
|
'03 Fall
Class Schedule:
(91.522.201) Wed. 530-830 at Cadence, Rte 129,Chelmsford |
'03 Fall Office Hours (OS210): TBD (~one afternoon/evening per wk.) (others
by email appointment) |
Course 91.522:OOAD covers the basic
principles and techniques of object-oriented analysis, specification, design
and prototyping. Our ongoing case study is a framework for application
development called Collaborative Object-Oriented Laboratory: _COOL_FAQs . UMass-Lowell's
COOL generates coded for an object-relational database from static
information models, and generates executable prototypes from a database of
state-based, event-driven dynamic behavior models. [Do not confused our COOL product with other adopters
of the COOL acronym: e.g., http://ca.com/products/cool/gen/coolgen_pd_old.htm) (referenced in Heineman et al: CBSE p. 526)].
Required: 91.301 (Languages) and 91.304 (Fundamentals);
Unix/C++ or Java programming experience.
Recommended: 91.502 (Foundations) and 91.531 (Languages) plus knowledge of an application domain (e.g., DBMS, CAD, CASE, GUI development, telecomm, multimedia, E-commerce).
[In fall 2001 and 2002, we used
two other texts:
Meilir Page-Jones: "Fundamentals of OO Design in UML",
A-W 2000,
Shlaer & Mellor: "Object Life Cycles: Modeling the
World in States", P-H 1992,
and recommended Sanders: "Data Modeling", B-F/Thompson 1995
(esp. Chap 3: ERD to RDB Conversion). These were abbreviated
FOOD, OLC and DMOD in syllabus
references.
Handouts (HO) : selected reprints, COOL-related .ppt slides and project legacy reports.
Data Models: ../DataModels2htm/
Object-Relational Databases: ../Obj-RelDBv2/index.htm
COOL Framework: ..\COOL\COOL-FAQs-97f522Ver.htm
JP2htm Demo: ../97f522/jp2htm/DEMO/
BDE User Guide: ..\COOL-BDE\bdeUG_2000\bdeUG_2000.htm
Design by Contract: ..\OOSCCh11r1\index.htm
Using Object Charts:[Coherent Models for OOA, OOPSLA '91] (95f523 .ppt slides) CoherentOOAModels
Scott Ambler's Tutorial: http://www.agiledata.org/essays/dataModeling101.html
UML Tutorial Series: This is copyright material with access permission
to UML/CS students via download from
$CASE/omg/Behavior
Modeling-ad01-03-03.ppt (approx 150
slides, 1MB)
Laptop copy for off-line
in-class use:
Object Modeling with OMG UML:
../Behavior Modeling-ad01-03-03.ppt
Assignment
1: (due next week):
Part 1A. Read Hay's report, then submit (email or print) several FAQ's on Hay's recommendations. You can read thaem online (follow links to Hay's sections) - or download the articles (52page .pdf). You can skip ORM and XML (both out of scope).
If Hay confuses you, read Ambler's tutorial
first: (Scott Ambler's
Tutorial: DataModeling101)
David Hay's Comparison of Data Modeling Techniques
Part 1B. Read and respond (email or print)
with your FAQ's to this description of Assignments 2 and 3:
../03f522/03f522Asgnts2and3.htm
91.522 PART I: INFORMATION MODELING (~4 wks: 9/3 to 9/24; Hour Exam 1, 9/24.) |
|
|
Information Models (Class Diagrams, Chen EERD, and Bachman DSD; multiplicity, relational integrity, alternate owners.) |
(HOs: Syllabus and Update; DataModels.ppt, Cardinality.ppt. |
|
ERD - RDB - ORDB Conversion: Tabular representation, surrogate keys, persistence. |
(HOs: Obj-RelDBv2, genv12 User Manual; URLs: chgen and gencpp Reports) |
|
IDEF- 1X Fully specified Associations, Normal Forms, Optional-MAX method. |
(DMOD Ch. 3; HO: IDEF-1X; Normal Forms.) |
|
Object-Relational Databases, Code Generation, Schema as meta-data |
(HO:
meta-data examples {SV, TT, TA, FK}) |
|
Assignments:
#1 due 9/10, #2 due 9/17; #3 due Oct
8; 03f522Asgnts2and3.htm Hour Exam on 10/1; NO CLASS 10/15 |
|
91.522 PART II STATE-EVENT MODELING (~4 wks: Oct 8, 22, 29; Nov 5. Second Hour Exam 11/05 or 11/12 |
|
|
User Requirements, Object Life Cycles, Class/subclass membership criteria. |
S&M: An O-O Approach to Domain Analysis (OLC) in SENotes 7/89. |
|
Design by Contract |
|
|
Dynamic Behavior and State-Event Models |
(HO: Behavior
Modeling with UML, OMG Tutorial ad01-03-03.ppt) |
|
System Dynamics (Object Communication Diagram (OCD), Object Interaction Diagrams (Sequence and Collaboration diagrams) |
(HO: Microwave Oven Controller; BDE OOMenu State Model: (Class+Method+State)
|
|
State Models (object class/method STD's) |
(XUML Ch. 7, 9; HO - StateModels.ppt, BDE OOMenu and Method State Models |
|
Domain Partitioning, Bridges |
XUML Ch. 141, 15, 116, 17 |
|
Substitution Principle, State Model Inheritance |
(FOOD Ch. 10, 11, 12; HO - CoherentOOAModels.ppt, McGregor&Dyer: SIGSoft 10/93 (61-74)) |
|
Assignment #4 due 10/tbd; #5 due 10/tbd; Hour exam on Nov 5 or 12. |
|
|
91.522 PART III COOL FRAMEWORK
PROJECTS<\h4> |
(~5 wks: Nov 12, 19, 26; Dec.
3, 10; Project Reviews: Dec 17) |
|
Sub-domains and Packages |
(OLC Ch. 7&8; FOOD Ch. 7&9) |
|
COOL Framework Evolution |
(HOs- BDE/UG; GENCPP info) |
|
LCP State Model Architecture, JuicePlant Demo |
(OLC Ch. 9; FOOD Ch. 6, 10; HOs- OLCArchUserGuide, JPSim.ppt) |
|
GEN/BDE Integration |
(HOs- bde2sch, GENCPP, 01f522projects\bde1Proj_pk.doc) |
|
LCP/BDE Integration |
(HOs- bde2SM; OP-class User Guide) |
|
Event Logs, Distributed Collaboration |
(HOs- DBDE.ppt, 01f522projects\bde2ProjRept011219.txt) |
|
Assignments 5, 6 , 7 TBD: (these
will be Project-related); |
|
Project Topic Discussion:
bde log/replay bi-connected
to make two-person game.
./03f522/03f522RefactoringProjects.htm
./03f522/03f522RefactoringSlides.htm
./03f522/03f522asgnt4_mvk_rjl.htm
..\COO-LCP\ShlaerMellorSTDDefense.htm
Object-Oriented Software
Engineering enhances COOL and/or projects from a student's own development
environment. [02f523 text: Eliens: "Principles of O-O Software Dev."
(2ed.), A-W 2000].
Part I and II exams
(including in-class and take-home problems): each 25%;
Part I and II assignments:
17% total; part III collaborative design projects): 33%.
It is not mandatory to get running code;
the quality of your design documentation is more important. Quality depends on
adequate presentation of requirements, planning, design and verification. The
latter includes pre- and post-condition assertions and test cases.
For my 02s522-592 project suggestion, see
Block Diagram Converter (BDC) project at
http://www.cs.uml.edu/~lechner/02s522/02sBDCProject.htm
OOAD student projects may use any OO
development environment which can produce portable and maintainable design
documentation. Proprietary, non-portable formats are not acceptable.
For COOL projects, a unified schema and data compatibility with existing
components is an ABSOLUTE requirement!).
(Six factors essential for a maintainable
project legacy, that count equally toward project grades):
|
Problem analysis |
(reverse engineering, new
requirements, class interfaces) |
|
Project plan |
(incremental build/test specs,
work breakdown responsibilities) |
|
Design specs |
(information, communication and
state models, event and action specs., pre- and post-conditions) |
|
Source code |
(change history, coding style,
embedded assertions, compilation warnings, test drivers), |
|
User Guide |
(version history and re-use
info, readability, thoroughness), |
|
Build/Test/Debug scripts and
logs |
(test specs and coverage, bug reports, analysis of predicted vs. actual results). |
Information modeling comes first:
01f522 Part I is about the first major challenge of OOAD. Real-world
designs require information models that can support code generation for
database navigation and persistence. Information models are needed regardless
of the implementation language.
Behavior modeling comes next: 01f522
Part II concerns dynamic behavior models which can supp;ort event-driven
distributed concurrent systems, regardless of implementation language.
Detailed design and
implementation: 01f522 Part III is last but not least. It analyzes
inheritance and encapsulation design decisions which must precede
implementation with an OOPL, and framework concepts for code generation and
prototyping.
Note: Neither text fully
matches this sequence, and neither does justice to information modeling. We
will read both texts sequentially in parallel, to appreciate these similarities
and differences:
(1) FOOD Part II (Ch. 3-7) uses many UML diagram types in applications, then in Part III (Ch. 8-15) covers more sophisticated O-O design and programming principles (as in course 91.531).
(2) OLC emphasizes OOA; it very briefly
reviews info models (Ch. 2) covered in detail in their earlier book [S&M:
O-O System Analysis '88]. OLC emphasize dynamic models (Chaps 3-6) then domain
composition and integration (Chap 7-8). Their architecture for transitioning OOA
to OOD (Ch. 9) inspired our COOL framework component LCP, with which we
simulated their Juice Plant case study.
Overview of
COOL: The Collaborative O-O Laboratory
[COOL at UML/CS is not to be confused with
other adopters of the COOL acronym: e.g., COOL:Jex (www.ca.com)
or COOL:Joe (www.appdevadvisor.com)
(both are referenced in Heineman et al: CBSE p. 526)].
The COOL object-oriented framework consists of three generic design support tools: GEN, LCP and BDE. These tools use each other in synergistic ways. JPSim, BDE and LCP all use GEN. JPsim is a major test case for LCP, based on the case study in Shlaer-Mellor's OLC text. An early inspiration for GEN was Bachman's Architecture Definition facility (ADF). All COOL components were developed as 91.522/3 projects and reside in $CASE.
In COOL, an event-based distributed software
system is specified as a persistent relational database of block diagrams. This
database includes ERD or UML class diagrams to specify an application's
information model, OCD object (class) interconnection diagrams to specify
collaboration paths, and STD state-transition diagrams to specify event-driven
asynchronous behavior for each class method. State model action routines in C++
implement object behavior.
GEN (Database Code Generator) translates
Extended ER diagrams into an application-specific library of 'C' database
support code. This library maintains a persistent RDB and a memory-resident
OODB; chgen converts the RDB into linked C structs; gencpp converts the RDB
into linked C++ classes. Both chgen and gendb maintain persistent relational
links as foreign key attributes in flat ASCII relational tables. (Ref:
$CASE/gen/*/*/doc/.). For an overview of GEN-style Object-Relational DataBases,
see
http:/www.cs.uml.edu/~lechner/ObjRelDBv2/
LCP (Life Cycle Prototyping) is an executable
event-driven state model interpreter inspired by Shlaer-Mellor's Object Life
Cycles approach. See
http://www.cs.uml.edu/~lechner/COOL/
JPsim (Juice Plant Simulation) is a
non-trivial application of LCP and GEN which simulates the large case study in
the OLC text. JPsim's data and state models can be browed from a UML/CS account
via this URL:
http://www.cs.uml.edu/~lechner/97f522/jp2htm/ksuresh/DEMO/
BDE (Block Diagram Editor) creates and
maintains a hierarchical file of generic block diagrams for an application. Supported
diagram types include Entity-Relationship, Object Communication, and
State-Transition Diagrams. BDE prototypes exist in C, C++, Visual C++ and Java
for Wintel and Unix Xwindows platforms. An on-line visual User Guide to BDE is
at
http://www.cs.uml.edu/~lechner/bdeUG2htm/
BDE exports a text-based canonical
representation for generic block diagrams. BDE's tabular output is converted
into schema definition tables for GEN code generation, state diagram tables for
LCP interpretation, PostScript for printing and html for browsing. Existing
conversion tools include:
|
bde2htm (bde2gif) |
converts a file of block diagrams into hyper-linked html files. |
|
bde2sch (b2t/t2b) |
converts EER Diagrams into schema tables for GEN. |
|
bde2SM (bde2STD) |
converts State Diagrams into state model tables for LCP. |
|
bde2XML |
(TBD in 02f 522/3 ?) converts BDE diagrams to XML. |
(Another converter bde2xml (TBD in 02f 52x) will
convert any GEN RDB to/from XML.)
CAVEAT: COOL components should be regarded as
evolving legacy code, which is in various stages of development. Non-robust
legacy code is especially common within BDE's graphic components. Text-based
work-arounds exist for GEN and LCP use without BDE. The 02f BDC project is
intended to avoid X-Windows or MSWIndows graphics library dependence.