91.522 Object-Oriented Analysis and Design
http://www.cs.uml.edu/~lechner/01f522/01f522syllabus.htm
(This syllabus is maintained with MSOffice97® and is subject to change)
|
|
|
|
| '01Fall Class Schedule: | '01fall Office Hours (OS105B): |
91.522.201: Wednesday 5:30-8:15 in OS4 ___ |
Wednesday 4-5PM and 830-10 PM (others by email appointment) |
91.522 PART I: INFORMATION MODELING |
(~4 wks: Sep. 5, 12, 26, Hour Exam, 9/28) |
|
|
|
|
|
|
|
|
|
|
91.522 PART II STATE-EVENT MODELING |
(~5 wks Oct. 3, 17, 24, Hour Exam 10/31)* |
|
|
|
|
|
|
|
|
|
|
|
|
91.522 PART III COOL FRAMEWORK |
(~6 wks, Nov. 7, 14, 21 , 28; Dec. 5, 12) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is not mandatory to get running code; quality of design documentation is more important. Quality depends on adequate requirements, planning, design and verification. The latter includes pre- and post-condition assertions and test cases.
Checklist of documentation requirements for a maintainable project legacy: (these six factors will count equally toward project grades):
|
|
|
|
|
|
|
|
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.
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) POOD 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 (Ch. 2) emphasizes OOA; it very briefly reviews info models (Ch. 2) , which were covered by 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.
http://www.cs.uml.edu/~lechner/01f522/01f522Asgnts1and2.htm
(Six factors essential for a maintainable project legacy, that count equally toward project grades):
|
|
|
|
|
|
|
|
|
|
|
|
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, the major test case for LCP, is based on the case study in Shlaer-Mellor's OLC text. The major 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 database of block diagrams. This database represents ERD or UML class diagrams to specify an application's information model, OCD object(class) interconnection diagrams and STD state-transition diagrams too specify control sequencing and method calls. State model actions are programmed in C++ to implement object behavior.
GEN translates Extended ER diagrams into an application-specific library of 'C' database support code. This library maintains a memory-resident OODB of C structures emulating C++ classes, which is saved as a persistent RDB of ASCII relational tables. (Ref: GEN project tree at $CASE/gen/ver_11.)
LCP (Life Cycle Prototyping) is an executable event-driven state model interpreter inspired by Shlaer-Mellor's Object Life Cycles approach. See COOL: 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/index.htm
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 | converts a file of block diagrams into hyper-linked html files. |
| b2t/t2b | converts EER Diagrams into schema tables for GEN. |
| bde2SM | converts State Diagrams into state model tables for LCP. |
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.
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 2kf523 project suggestions, see: http://www.cs.uml.edu/~lechner/91.523/98f523projects.htm
OOAD project teams of two to four students are encouraged to use our locally-developed software engineering framework (COOL) of portable generic tools. Browse or download a PowerPoint(TM) slide presentation on COOL at http://ww.cs.uml.edu/~lechner/COOL/