91.522 Object-Oriented Analysis and Design with MDD - Fall 2008

[Monday 5:30-8:30 on-campus at UMass-Lowell; a 3 credit graduate course.]
----------------------------------------------------------------
RJLRef: $PH/08f522/08f522CourseDescription.htm; last update: 080811

This course will cover Object-Oriented Analysis and Design (OOAD) and its application to Model-Driven Development. MDD is a modern way to generate source code for distributed systems. Specific applications include the code generation tools themselves and will be presented as case studies.

Course prerequisites and Software Engineering context are in $PH/08f522/08f522Syllabus.htm.

Required text:
Craig Larman: "Applying UML and Patterns", 3rd edition, P-H 2005.

Course Description:

This course is about object-oriented analysis and design (OOAD).
Background in a modern O-O programming language is recommended,
but more important is interest in software architecture and code generatino from models.

Modern OOAD is about modeling, not programming. OOAD formalizes requirements into precise and complete models that both define software and are understandable by humans. Since programs define behavior, state models for behavior and activity models for synchronization are just as important as data models to describe object or entity classes and relationships.

A software development framework is an integrated suite of tools and libraries. A popular trend today is toward Model-Driven Development. An MDD framework is specialized for automatic code generation. To gain insight into MDD, we will study a minimal set of framework components that is under ongoing development at UMass-Lowell.

MDD is one alternate to the use of off-shore programming labor. Like off-shoring, it raises the bar to successful career development from coding to design to analysis and from components to systems. Current MDD frameworks are very expensive and their cost must be amortized across one or more Software Product Lines (SPLs). [See for example Building Distributed Applications - Problems and Innovations by Jack Greenfield of Microsoft, co-author of Software Factories, Wiley 2004.]

For more details, see http://www.cs.uml.edu/~lechner

MDD Frameworks:

For MDD, models must be precise and complete enough to support automatic code generation, and abstract enough to support the development of product families that span multiple programming languages and OS/HW platforms. Models are effective only if they can be trusted to be no more ambiguous than source code is today. Graphic models facilitate communication among users, analysts, designers and programmers.

In MDD, graphic design tools are used to specify platform-independent models based on a common architecture for event-driven distributed system applications. Graphic models are augmented with pre- and post-conditions that can be inspected to ensure that they meet application-specific run-time requirements. These requirements usually include persistent data management, and constraints on instance-level dynamic behavior and on message-based control flow.

Platform-specific source code links class methods together. This 'glue' code can be generated automatically from graphic models and event type specifications, then executed to visualize and debug behavior, by tracing state transitions and events.

The COOL Framework for MDD:

Prior 522-OOAD and 523-SWEng classes developed and used an integrated framework of MDD tools (www.cs.uml.edu/~lechner/COOL-FAQ). (COOL stands for CASE Object-Oriented Laboratory.)

The COOL framework is based on UML2. UML2 is the Unified Modeling Language standard promoted by the Object Management Group consortium at omg.org, of which UML is an academic member.

COOL's architecture follows MDD principles. Graphic models are converted to relational tables; these tables share a common version-control repository like CVS. COOL-GEN generates application libraries that manage persistent data as ASCII files. COOL-LCP interprets control flow and supports event-driven object interaction. Designers specify system behavior by composing atomic state actions. State actions are atomic procedures written in the target language C++ or Java, by experienced programmers who need not know all about high-level system requirements. COOL-BDE provides graphic support for specification of all three types of models and visualization of runtime behavior.

Client/server messages are events with parameters. These messages originate in a client process and are sent to a server process which responds with appropriate state actions. They may also be used within Active Instances to decompose synchronous methods into a hierarchy of state models.

COOL Framework Components:

This course uses three MDD-based framework components:

(1) GEN: A code generator for data or class models.

GEN reads models that describe the runtime properties and relationships of application data objects and converts them into a back-end code library and API for persistent data management and access. GEN supports both LCP and BDE by auto-generating code for persistent database management and access.

(2) LCP: An Event dispatcher and State model interpreter.
LCP mediates inter-process message flow for client/server inter-object communication. Its state models define intra-object dynamic behavior, including user-level GUI activity and atomic-level interactions. LCP supports logging and replay of state and event traces. Its network models constrain inter-object communication.

Platform-specific source code to link state actions together is generated automatically from the two-dimensional graphic models and event type specifications. LCP uses code from GEN to manage its database of models for table-driven event dispatching and state transitions. LCP supports BDE with uniform control-flow modeling conventions for BDE's GUI-based graphic editing software.

(3) BDE: A generic block diagram editor for graphic models.
Three specializations of the generic diagram type supported by BDE are used in COOL itself:
A. UML class models for GEN code generation to support any persistent data application. Class diagrams are converted into metadata inputs for GEN's code generator and to event and state model tables for LCP's interpreter.
B. State-event models for LCP interpretation of control-flow in class methods, including BDE's editor. State diagrams are converted into state transition tables and event type definitions for LCP's runtime interpreter.
C. Inter-process interaction models for LCP's event-driven active object communications.
BDE uses GEN outputs for graphic data access, and LCP state models to control its editing behavior. BDE provides design model inputs and can potentially provide runtime visualization support during runtime of COOL framework-based applications.