Subject: A Guide to my OOAD/SWEng home page (for 91.411 SWEng I) RJLRef: $PH/COOL/COOLFrameworkSummary070918.txt Hi, Fred. First I want to congratulate you for engaging SWEng1 students with HCI applications for Kennedy Day School. Please let me know if I can help in any way. Brighton is not far from Needham if you need any support there. Since no one else is promoting SWEng at UML/CS I am eager to find ways in which my home page resources on OOAD/SWEng (91.522/523) might be useful in your course 91.411/412. I recommend team-based projects with specs that motivate students to learn about model-based design. These projects can evolve over multiple years but not without version control. (Dr Claypool used Eclipse and I hope you can use it and also CVS to smooth the way for re-use and enhancement.) [This rather long-winded explanation took longer to write than to read. However, my first boss, Marty C., who watched me do system analysis / system engineering for 15 years at GTE/SES, confirmed that I tend to think on paper. I'm convinced that this is a result of imperfect memory. :-) ] (TBD: A hyper-linked version in $PH/COOL-FAQ/COOL_Overview2007.htm - but don't hold your breath.). PS: Another shorter summary of the COOL framework is in http::/www.cs.uml.edu/~lechner/COOL/whatisCOOL.050228.txt. Bob Lechner ================================================================ COOL_Overview2007 Contents: Focus of 91.522 OOAD and 91.523 SWEng Online Resources for 91.522/523 Overview of Previous Application Projects: Model-Driven Development with COOL COOL Framework Components: GEN, LCP, BDE Current Status and Near-term Goals Long-term Framework Enhancements Conclusions Focus of 91.522 OOAD and 91.523 SWEng The primary focus of both courses has always been model-driven development. Student projects over the years have produced a generic framework to capture 2D graphic models using a generic block diagram editor (BDE), and generate code from these models using other components (GEN and LCP). Links to all these are at http://www.cs.uml.edu/~lechner/COOL on my home page. Some students applied this code generation technique to applications, while others used it to extend the COOL framework itself. This is possible because its components are based on the same model-driven architecture and metadata format that is used for application development. But the learning curve is likely to be too steep for seniors, just as it is for many grad students, unless they have prior exposure to framework-based software development methods (most likely from better teachers than I :-) Relatively few part-time grad students have used model-driven frameworks that go beyond Java-Beans-style database applications. Those who have expeience naturally want to continue using their favorite proprietary application generator. Proprietary tools have the major disadvantage of opacity: their constructio is invisible. Their implementation is very complex and much more difficult to maintain than just to use as a black box. I believe it is valuable to expose all students to the internal construction details of a model-driven framework. This is feasible with a minimally functional, maximally generic toolset. Benefits to the instructor are a more uniform development style, with more readable design specifications at higher level than source code, and with less time wasted on custom programming for generic functions like persistent I/O and database management. These advantages are a practical necessity for non-trivial projects that evolve over multiple semesters. Online Resources for 91.522/523: http://www.cs.uml.edu/~lechner contains many non-trivial examples of data and state modeling, and links to external sources. Many of these are linked thru /usr/proj3/case/*; /usr/proj3/case also contains copies of textbook sources NOT in the public domain, but readable by UML/.CS students. These resources may be useful if your course includes OOA&D. My local resources consist mostly of multi-year OO AD and SWEng projects by 91.522/523 student teams, and many related hyperlinks to OOAD and SWEng literature online. Our multi-year framework component development projects are accessible at http://www.cs.uml.edu/~lechner/COOL/COOL-{BDE,GEN,.LCP}. Their main branches of COOL components (GEN, BDE,LCP) have CVS repositories. Offshoots from these components, and application projects, are grouped chronologically under /usr/proj3/case/semesterXcourse# .. Most of these courses are linked from my home page (e.g. //www.cs.uml.edu/~lechner/06f522).. My goal this fall is to move the chronological sort UNDER a major grouping by project/topic areas. I started this process with framework components in http://www.cs.uml.edu/~lechner/COOL/COOL-{BDE,GEN,.LCP} . Naturally, this will play havoc with all of my internal hyperlinks:-( I'll need html-savvy editing tools that can find (and correct?) all the brokenlinks. Overview of Previous Application Projects: Many projects based on COOL-style modeling were investigated over multiple semesters by 91.522 OOAD ansd 91.523 SWEng classes. For example, we worked on model-driven C++ code generation and control flow for the Hominoid example with Java code in Page-Jones: "Fundamentals of O-O Design in UML" (A-W 2000). This could lead to maze-building and traversing games. We also worked on a distributed version of the card game "Set" that depends on pattern recognition for card-set selection [See www.setgame.com for the vendor's game demo.] Our Set game is based on GEN, LCP and BDE (see below). Its latest version (http://www.cs.uml.edu/~lechner/06f522/) used OpenGL graphics for the playing card layouts rather than BDE. We also designed (data and state models for) a distributed version of BDE itself. It goal is to allow simultaneous editing of (distinct parts of) the same diagram by a geographically dispersed collaborative design team. The same techniques are applicable to other collaborative design apps which use constructive graphics. LCP is our interpreter for state models that specify and drive the Hominoid and SetGame applications. These techniques were inspired by Shlaer-Mellor's Object Life Cycle text (P-H 1992) and UML's StateMate. In previous semesters, students applied LCP to non-game apps like the Microwave Oven controller (in lots of OO/SE texts) and logic simulation (of a 4-bit up-down counter). Another common example (that we have not implemented) is the Elevator Controller. By far the largest application that we implemented was a process control simulation (of the Juice Plant case study in "Object Life Cycles:Modeling the World in States"). In addition to the data and state models for Juice Plant Active Classes, BDE defined, and LCP interpreted, the layout of the JuicePlant piping network to implement transfer of liquids from storage tanks to pasteurizing tanks.. Model-Driven Development with COOL: My goal was to provide a simplified general-purpose framework with these generic capabilities that can be applied to any application domain: (1) BDE, a graphic 'Block-Diagram Editor' to define models as annotated diagrams, (2) GEN to generate code from application-specific static information models, (3) LCP to interpret event-driven control flow from application-specific state models.. Along the way we discovered that BDE can also draw instance-level interaction diagrams ('wiring diagrams'). These can be incorporated into LCP's database to constrain the types of event instances that can pass between the state models of Active Class instances (actors). These instance-level path constraints specialize class-level OO behavioral specs. The latter only constrain class-level communication paths for each event type/class. A design diagram database is one or more files containing relational tables. These tables are line-oriented and can be stored along with source code in a unified version-controlled, line-oriented repository such as CVS. [Caveat: GEN and LCP still lack namespace support, which can avoid name-clashes when scaling up to large-scale component-based systems.] COOL Framework Components: Diagram capture is the first stage of model-driven code generation or interpretation. Graphic models are drawn by our block diagram editor BDE. BDE has an object-oriented editing menu, in the sense that both class and method are selected from their respective radio button sets independently in any order. Once selected, that method can be repeatedly applied to instances of that class on the drawing canvas. Diagrams from BDE support the other two COOL components GEN and LCP. (See http://www.cs.uml.edu/~lechner/COOL/COOL-BDE/). All 3 tool components share a common metadata format for their input or output 'design database' content. All the diagrams for an application can be stored in one or more files as a Relational Database (RDB). The COOL Framework components (GEN, BDE, LCP) have non-cyclic dependencies at the version level, This permits boot-strapping: (augmenting an application with new data models for added compocnents). LCP and BDE depend on CHGEN for their back-end database APIs. BDE captures diagrams into a design database with I/O support from CHGEN. [LCP support to BDE is TBD.] GEN and LCP can use either BDE or an alternate manual (boot-strap) work-around for their data and state model inputs. GEN: GEN produces source code that is compiled into a library ('pr_util.a'). This library API handles persistent I/O and acces to any data whose format is based on EERD data model diagrams (preferably normalized ones). The persistent data 'state' for ANY apaplication can be modeled as an Extended ERD (Entity-Relational Database) model, where 'Extended' means adding relation links for class-based or delegation-based inheritance.) GEN interprets the EERD model[s] and generates 3 types of code: (1) Persistent I/O to a multi-typed text file; (2) Compilable methods to access or update attribute values for objects in the dadabase; (3) Inter-object links that permit efficient navigation among related objects. The source code produced by any GEN version is application-specific, but all dependencies are solely the result of the data model or schema that defines the application's persistent database to GEN. This database is internalized (loaded) into multi-threaded linked lists of object content, for easy navigation among objects and access to data members. When externalized (saved), this database is line-oriented ASCII text and can easily be put under revision control in a source code repository. LCP: LCP has a pre-processing phase which generates a state model database from state diagrams (States, Transitions and Event Types) and an Active Class and Instance database from LCP's own EERD [meta-]model. States are labeled with class method names. Transitions are labeled by events and (TBD) guard condtions. Event instances are created objects having attribute values. Event types represent message types between functions executing in concurrent processes. Event instances generalize function calls (passing parameter values on the callstack). . LCP's run-time phase consistes of an interpreter for a state model database. This interpreter is an event queue manager and dispatcher which mediates the interface between sender (client) and receiver (server). The event dispatcher makes a fuinction call to an action routine for the receiver's current state. Application-specfic local 'atomic' state actions must be manually programmed by application's developers. Appropriate labeling conventions enable LCP to bind these action calls to their respective state diagram contexts at link-time. BDE: BDE is a front end to produce inputs for our code generator family GEN and our control flow interpreter LCP. Versions of BDE exist for X-Windows and Java but not for Windows or OpenGL BDE captures 3 types of diagrams in an Object/Relational Database. These represent information content, class behavior, and component interactions: (1) EERA Diagrams guide database code generators CHGEN,GENCPP,GENJAVA. These emit C, C++ and Java source code, respectively. (2) State Diagrams guide a control-flow interpreter LCP. LCP can interpret nested method calls and/or concurrent event-driven state model object behavior protocols. (3) Event-based Interaction Diagrams specify inter-class communication constraints and instance wiring diagrams. These can be used to simulate logic design or concurrent software. BDE supports one-way conversion to a hyper-linked web-browsable format: Any Diagram Node can be linked to nested sub-diagrams and/or to data model definitions or action code definitions text The COOL Framework components (GEN, BDE, LCP) have non-cyclic dependencies at the version level which permit boot-strapping: LCP and BDE depend on CHGEN for their database back-ends. BDE captures diagrams into a back-end design database that is also supported by CHGEN. [LCP support to BDE is TBD.] Current Status and Near-term Goals: I hope to achieve two goals before 91.522 or 91.523 is offered in spring 2008: 1. Regroup the chronological ordering of directories in /usr/proj3/case. Case needs a major grouping by project/topic areas. Nested within each topic would be versions that evolved semester by semester. To avoid major disruption of existing hyperlinks, I began this process by adding home-page links to the framework component directories with their sequential versions, in http://www.cs.uml.edu/~lechner/COOL/COOL-{BDE,GEN,.LCP} . Naturally, this will play havoc with some inter-file hyperlinks. (Html-savvy editors that can find all broken links would help a lot.) 2. Fix bugs to make the framework (especially BDE) more robust. BDE is too unstable for productive use, so we reverted to text-based work-arounds. Changes to data and state models (enhancements) are easily translated into code by reuse of CHGEN and LCP; however, bugs plague the source code of BDE and other C-language application projects that evolved over many semesters. Control-flow bugs can be fixed by using text-based work-arounds to revise the state models which LCP interprets to select and execute state actions. When bugs are found in application source code, fixes can be recompiled and retested. However, back-end code library bugs or enhancements are difficult to migrate backwards from source code to the code generator CHGEN. Bugs found in auto-generated database library code must also be fixed in the code generators,. because otherwise the new code generated after data model changes will over-write the manual fixes and re-introducing these bugs. Long-term Framework Enhancements: In the long run, we need to make the following improvements to the COOL framework and to its software development process: (1) standardize class methods and data models among GEN and BDE versions. This will simplify maintenance by code sharing and data compatibility over different languages and platforms; (2) migrate bug-fixes into code generators (GEN versions) as soon as they are found. This is easier said than done: Fixing code is more laborious without tool support for this extra manual process step. (3) migrate past project enhancements into version control (CVS) repositories. This was neglected due to turnover between semesters and enrollment pressures that emphasized OOAD at the expense of good software engieering practice. (4) enhance COOL data models and GEN versions by adding namespaces or Domains. This is required to smoothly integrate independently modeled components without collisions. between tags that identify data model classes. (5) work to extend generic models to both GUI front-ends and communication back-ends. Auto-generating these will increase programmer productivity in developing distributed multi-user applications, including collaborative design with the COOL framework itself.. (6) contribute a more robust version of the COOL Framework as an open-source project. Open-source development can potentially add collaborators from outside UMass Lowell. (7) Enhance BDE's class-based architecture to better exploit GENCPP/GENJAVA. BDE's GUI source code is C++ class-based, although BDE uses CHGEN's C-code library to support its persistent back-end database. BDE's use of this API needs to be rewritten to call GENCPP's C++-library. By adding BDE's custom C++ classes to its data model, more class methods coud be auto-generated. using GENCPP or GENJAVA. BDE's front-end GUI uses X-Windows. It should be rewritten to use OpenGL. BDE's Java version is (almost:-) GUI and database-compatible with BDE in C++. However it is custom code and should be rewritten to use the Java code library from GENJAVA. BDE's GUI protocols are modeled as state diagrams within comments. BDE could easily capture these behavioral models as an LCP database.. Then a new version of BDE could be built that used LCP to interpret its control flow.. To do this we must revise BDE by partitioning its source code into state action methods that are called from the state model interpreter LCP. (8) Implement the state model action code for the previously designed distributed version of BDE itself. THis would allow simultaneous editing of (distinct parts of) the same diagram by a geographically dispersed model-driven development team. Other collaborative design apps would also benefit. Conclusions: I believe that generic model-driven approaches to software design and development, such as OMG's Model-Driven Architecture (MDA), are the wave of the future. They are important for professional programmers who want to rise above the coding level, because manual coding based on such models is a rote job that can easily migrate to cheaper labor pools in the future. Building models that are precise and complete enough for automatic code generation is an alternative to manual software implementation from models (specifications that combine 2D graphics and formal constraints). However, this requires additional layers of sophistication and a longer learning curve. The COOL framework provides visibility into MDA tool implementation. The COOL components can be used to evolve the specs for multi-year version-controlled team projects in which all students can participate in model-based design. and advanced students can contribute to the evolution of this framework.