From lechner@cs.uml.edu Mon Sep 19 18:35:21 2005
From: Bob Lechner
<lechner@cs.uml.edu>
Subject: XML vs. high-risk aspects of
COOL-GEN/LCP/BDE
To: jingyoko@hotmail.com (Jing Tan), ralmonte@cs.uml.edu (Almonte)
Date: Mon, 19 Sep 2005 18:33:12 -0400
(EDT)
Cc: 05f523
RJLRef:
$PH/05f523/COOLFrameworkRiskFactors.htm
[,.txt]
This is a draft - to be expanded and
possibly revised,
but not before you're sleeping:-) Please
read it -
then we can discuss it more quickly Tues
evening.
Thanks,
R Lechner
I hate to discourage such highly
motivated
05f523 students as Robert Almonte and Jing Tan,
but my advice is to first find, and then
concentrate
on dealing with what we all agree are
HIGH-risk
factors in COOL framework projects.
1. XML use is a low-risk factor in
COOL-GEN/LCP/BDE
I regard providing schema input to chgen/gencpp
as perhaps the lowest-risk factor
because I know
how to do it. This is true because
(1) chgen
option -datinput allows .msdat
input
and option -metafile allows .msdat output in chgenv11.
(2) pr_dump_row
allows depth-first (span-tree order)
saving of table rows if desired.
(3) Nestable
Begin/End-Block brackets allow discarding
pkey
and first fkey from clusters of tree-structured data.
A tree-structured pr_dump
option (low-risk, TBD)
makes any .dat
file directly mappable to XML trees.
Generating the code for these 2-way
converters
for any schema.msdat
file is an extrension of
chgen/gencpp.
(XML's IDREF types are used for the
residual foreign keys outside of the
spanning tree
in what is in general a relational data
network.)
Again, this is a well-understood
problem,
hence low-risk and deferrable; it is not
even on the
direct path toward persistwent
data exchange (OMG/XMI),
because tables can be converted to/from
XML
without first selecting a spanning tree
(with its risk of non-uniqueness).
This merely requires converting foreign
keys within
the spanning tree as well as the ones
outside of it
to/from XML IDREF data items.
[See $PH/COOL-LCP/StateModelRev05f.ppt
new slides
on bde2sch conversion and on pfkey compression]
The rest of this note may turn into the
gist of
my 10-min talk at the CS seminar on
faculty
research areas (on Wed 9/21 3-4PM in
OS311).
2. Goals of COOL Framework for MDD
---------------------------------
There is
new wave of computer-based aids for software
development; its buzzword is
Model-Driven-Development(MDD).
OMG's
evolving standard UML2.0 (Unified Modeling Language
calls this MDArchitecture
(MDA); the Open Group
generalized it to MDD to avoid some OMG
constraints.
MicroSoft
calls it Domain-Specific Software Factories
using DSLs
Domain-Specific-Languge (DSL).
The goal of MDD is automatic code
generation
from model-based software designs. Commercial
developers
are used to generating access code from
models for static
data structures such as
Entity-Relationship Diagrams
for relational databases. Embedded system developers
are familiar with state machine models
for dynamic behavior.
The Embedded Software community has been
using
state-machine models for years (e.g., iLogix, Kennedy-Carter,
PathFinder
Soluions, and Bridgeport/ProjectTechnology
(now Accelerated Technology, part of
Mentor Graphics).
COOL is my own 3-component architecture for
Model-Driven-Development (MDD). The
Applied Math
side of my brain loves the abstract
modeling aspect
of MDD; my engineering side wants to buid things,
and experience makes me believe that the
real problems
of MDD can only be appreciated by
actually
implementing COOL as a prototypical
version of MDD,
and applying it to non-trivial
applications.
What could be more non-trivial than the
components
of COOL itself? That question can only
be answered
by applying COOL to real-world applications,
after
extending COOL to allow collaborative
development
by a team of distributed and dispersed
software
engineers (simulated by a network of
students :-)
3. The real high-risk factors in
COOL-GEN/LCP/BDE?
--------------------------------------------------
Robert Almonte
(04s522, 05f523) certainly identified
lots of them in COOL-GEN,
on documentation and the learning curve
for code-generation
{chgen,gencpp}/src maintainers, not to mention the problem.
of re-integrating genv13 code
improvements with older but
also portable gencpp.
The same problems arise in COOL-LCP,
which models behavior
using state diagrams for
event-driven control flow.
This is much more application-sensitive
and API-oriented:
The LCP interpreter has few
platform-porting problems,
until we attempt distributed concurrent
processing.
I believe LCP's
high-risk factors are distributed
event communication channels and
surrogates,
namespace problems and the absence of
shared memory,
and avoidance of race conditions during
event dispatching.
LCP has an analogous problem to chgen schema format:
the choice of encodings for event
messages.
For these, Robert again correctly
identifies XML as a
good candidate. But again, conversion of
EventInstance
table format is a low-risk problem, with
a first cut
being the same schema-driven converter
that any other
schema table can use.
[More to come-RJL]
Distributed setGame
project refs:
$PH/05f523/DSetGameProjRept_ra.doc
$PH/05f523/04fdsg_raReportR05f.doc
> From jingyoko@hotmail.com Mon Sep 19 16:30:29 2005
> From: "Jing
Tan" <jingyoko@hotmail.com>
> To: ralmonte@cs.uml.edu
> Cc: lechner@cs.uml.edu
> Subject: Re: Xml describing data
for CHGEN.....
> Hi,
>
> I've taken a look. It looks good.
I'm going to try to modify the genjava
> code (parser part) to generate java
codes by a xml file. Hope it works.
>
> Thanks,
> -jt
>
> >From: "Robert Almonte" <ralmonte@cs.uml.edu>
> >To: "Bob Lechner"
> >Date: Sat, 17 Sep 2005 19:47:09
-0400
> >
> >Hi all,
> >
> >This is a little sample how XML
can easilly describe CHGEN' schema almost
> >in plain English
> >(There is not need for CHGEN
manual to understand it).
> >
> >I have no describe the XML'
schema (XSD) for this file. CHGEN's parser will
> >love it because it won't have
to check for types.
> >the XML parser takes the xml
file and the xsd (schema) and validates it.
> >
> >If you do this, you will be
able to see it nicely and the DOM structure of
> >the XML.
> >
> >From last week discussion ,
this how it will look like. Just take in mind,
> >that this was a quick draft.
> >
> >
> >----------------------
> >o
----------------------------------------------------------------
> ><?xml
version="1.0" encoding="UTF-8"?>
> >
> ><!--
> >
> >gen_schema.xml
- created on 09/17/2005
> >
> >
> >This file describe an example
of how the GEN schama file
> >
> >would look like if we were
using Xml.
> >
> >
> >-->
> >
> ><!--
> >
> >The model tag defines the top
level of the structure model.
> >
> >In this case, the attribute
'type' contains value Relatioanl,
> >
> >which indicates that this a ERD
structure definition. It also
> >
> >could be Objected-Oriented or
any future model no invented yet.
> >
> >-->
> >
> ><model
name="Multi-League Game" type="Relational"
version="0.0.1">
> >
> >
> ><table
name="Tournament">
> >
> >
> ><attribute name="tournamentId" surname="ID" dataType="ObjectIdentifier"
> >type="PKEY"/>
> >
> >
> ><attribute
name="name" surname="Name" dataType="String"
type="DATA"/>
> >
> >
> ><attribute name="playerId" surname="fkey"
dataType"ObjectIdentifier"
> >type="FKEY"/>
> >
> >
> ></table>
> >
> >
> ><table
name="Player">
> >
> ><attribute name="playerId" surname="ID" dataType="ObjectIdentifier"
> >type="PKEY"/>
> >
> >
> ><attribute
name="name" surname="Name" dataType="String"
type="DATA"/>
> >
> >
> ><attribute name="tournomentId" surname="fkey"
dataType"ObjectIdentifier"
> >type="FKEY"/>
> >
> ></table>
> >
> >
> ><table
name="League">
> >
> ><attribute name="leagueId" surname="ID" dataType="ObjectIdentifier"
> >type="PKEY"/>
> >
> >
> ><attribute
name="name" surname="Name" dataType="String"
type="DATA"/>
> >
> >
> ><attribute name="playerId" surname="fkey"
dataType"ObjectIdentifier"
> >type="FKEY"/>
> >
> ></table>
> >
> >
> >
> ><!--
> >
> >This is how we could take care
of any type of relationship.
> >
> >Binary relationship between
Tournament and Player.
> >
> >The attributes 'from' and 'to'
only are considered by the semantic
> >
> >analyser
if the 'direction' attribute is UNIDIRECTIONAL.
> >
>
>(direction="UNIDIRECTIONAL").
> >
> >-->
> >
> ><relationship name="TournamentPlayerAss" type="M:N"
>
>direction="BIDIRECTIONAL"
> >
> >from="Tournament"
to="Player">
> >
> ><id
type="AutoNumber"></id>
> >
> ><fromId></fromId>
> >
> ><toId></toId>
> >
> ></relationship>
> >
> >
> ><!--
> >
> >Binary relationship between
League and Player.
> >
> >-->
> >
> ><relationship name="LeaguePlayerAss" type="M:N"
direction="BIDIRECTIONAL"
> >
> >from="League"
to="Player">
> >
> ><id
type="AutoNumber"></id>
> >
> ><fromId></fromId>
> >
> ><toId></toId>
> >
> ></relationship>
> >
> >
> >
> ></model>
> >
> >
>
>
_________________________________________________________________
> Express yourself instantly with MSN
Messenger! Download today - it's FREE!
>
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>