Syllabus for Spring 2002 (02s522)

Approximate Schedule:

Follow-on project course 91.523: OOSE or 91.592 Directed Study

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].

Assignment submission policy (Please Note):

I strongly encourage emailed FAQ's and discussion of assignments. All relevant FAQ's and responses will be forwarded to my alias: 01f522 for the class.

Attachments must be PLAIN TEXT ONLY, NOT base64-encoded WORD or other binary files. Default BASE64 attachments from Windows mailers and Unix/Pine will be rejected.

Unix editors append text files by the command :r filename (elm) or ^R filename (pine). If all else fails, save-as text, select/copy and paste if necessary. See attached Quick Reference to Unix access and text processing commands.

01f522 GRADING POLICY

OOAD Projects (Updated for 02s522/02s592)

For my 02s522-592 project suggestion, see Block Diagram Converter (BDC) project at

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!).

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/

(Six factors essential for a maintainable project legacy, that 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.

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.

[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.

COOL Components GEN, LCP, BDE and JPSim:

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

LCP (Life Cycle Prototyping) is an executable event-driven state model interpreter inspired by Shlaer-Mellor's Object Life Cycles approach. See

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:

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

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:

(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.