|RE: [gmt-dev] The four compoents (was Initial CVS structure)|
Hi Jorn > From: Jorn Bettin [mailto:jorn.bettin@xxxxxxxxxxxxxxxx] > The directory structure should be > org.eclipse.gmt.workflow > org.eclipse.gmt.mapping > org.eclipse.gmt.transformation > org.eclipse.gmt.textgeneration I wondered why you hadn't incorporated my comments into the home page. We clearly have an understanding gap. The first three components are all fundamental to UMLX working at all. It's as if you're distinguishing function declaration, function invocation and parameter passing as different aspects of a programming language. Workflow -------- To me, workflow is the sequencing of transformations. It may occur in three ways. a) explicit sequencing through use of causal information flow between transforms connected in a hierarchy of UMLX diagrams. b) explicit parallelism through use of parallel information flow between transforms connected in a hierarchy of UMLX diagrams. c) implicit sequencing as a result of schema analysis to deduce a transformation sequence from the specification in the PIM to a PSM that exploits the resources in the PDM. Pethaps c) is what you mean, but I see it as just one of many advanced UMLX optimisation activities. a) and b) are part of UMLX. Mapping ------- The ability to do mapping is fundamental to UMLX. It is not possible to perform interesting transformations without reacting to two or more inputs, which inevitably means a mapping between them. UMLX does mapping already. Mapping as part of an MDA tool, is one of the many different transformation phases between DSVL and code. I would therefore suggest that mapping sits as part of org.eclipse.gmt.transforms.mapping org.eclipse.gmt.transforms.types org.eclipse.gmt.transforms.scheduling org.eclipse.gmt.transforms.communication org.eclipse.gmt.transforms.partitioning ... Transformation -------------- Everything is a transformation. The compiler provides the ability to do transformations (model to model) mappings (models to model) text generation (model to text). The transforms library provides the wide variety of facilities that will be necessary to transform DSVLs into PIMs and other DSVLs into PDMs and then map them to produce a PSM and then to produce code. Text generation --------------- Text is just a particular view of a model. I could draw a UML diagram of a text document - at its most trivial a list of characters. more interestingly a list of words which are lists of characters. ... paragraphs, indentation, prefix/suffix wrapping. This is what my text thread was about. If we have an appropriate text model, then text generation is a model transformation, with a trivial serialisation to finish off, and whren we come to do XMI generation in C we won't have library support so this approach supports creation of XML in a text model that is easily output in any language. If a text model is defined, then the UMLX support is simple, and code generation is supported by org.eclipse.gmt.transforms.generation.java org.eclipse.gmt.transforms.generation.cxx > To assess the capabilities of your code and to determine the > appropriate > location, can you please provide us with an overview of the > design of the > tool, say in the form of some UML package diagrams that show us what > subsystems you've got, what is exposed on the subsystem > interfaces, and what > the dependencies between subsystems are. Until I put my code in to CVS, I guess it is difficult for you to grasp quite how small it is. In order to get GME to export XMI, there is an XmiEmitter add-in, that creates the XMI model understood by the NormalizeXxx transformations. This code is GME-specific but otherwise dependent only on the XMI standard. It should really become part of GME itself. In order to get GME to support UMLX editing, there is a Umlx.xmp paradigm, which uses a UmlxDecorator add-in to draw icons appropriately. This code is GME-specific but otherwise dependent only on the UMLX language definition. Everything else is transformations, An overview of the subsystems just makes it into the paper for Twente, which subject to comments, I plan to put at gmt-home/doc/uml/UmlxGraphiclaLanguage.pdf. The UMLX compiler is defined by transformations which execute at two levels. At M2 where transformations are compiled and at M1 where the compiled transformations are executed to compile user models. For M2 the UmlxCompilation system compises the 4 transformation sub-systems, AnnotateSchema, AnnotateTransform, GenerateScan, CreateBuild. For M1 the UmlxExecution system comprises the 3 transformation sub-systems, AnnotateUsage, Scan, Build In order to interface with GME there are a further 3 transformation sub-systems for M2, NormalizeSchema, NormalizeTransform, NormalizeUsage, which normalize the XMI of the arcs-and-nodes corresponding to visible graphics as edited within GME, to the XMI of the arcs-and-nodes corresponding to information concepts as defined by UMLX. The dependencies between transformations are established by the schema that define each interface. Additionally in the NiceXSL implementation there are utility functions that are shared. Most of the transforms from most of the GME-independent sub-systems are shown in the UmlxToXslModels that I sent you and, subject to comments, will put up as org/eclipse/gmt/doc/umlx/UmlxCompiler.doc. Each sub-system when coded in NiceXSL is a single file varying in size from 100 to 2000 lines. Hence my suggestion of three areas, one for each isolated add-in, and one for the UMLX compiler that in bootsrrap form is small enough to be flat. tools/gme/XmiEmitter tools/gme/UmlxDecorator umlx/... In compiled form, we will have to decide whether there is a genuine boundary between UMLX-compiler-only transforms, shared code generation and optimisation and non-compiler transforms. If I choose to build a UMLX compiler for a GRID, I suspect I use nearly everything, so that we will end up with org.eclipse.gmt.transforms.mapping org.eclipse.gmt.transforms.types org.eclipse.gmt.transforms.scheduling org.eclipse.gmt.transforms.communication org.eclipse.gmt.transforms.partitioning org.eclipse.gmt.transforms.qvt.compilation org.eclipse.gmt.transforms.qvt.optimisation org.eclipse.gmt.transforms.generation.java org.eclipse.gmt.transforms.generation.sql org.eclipse.gmt.transforms.optimisation.expressions org.eclipse.gmt.transforms.optimisation.types Regards Ed Willink ------------------------------------------------------------------------ E.D.Willink, Email: mailto:EdWillink@xxxxxxx Thales Research and Technology (UK) Ltd, Tel: +44 118 923 8278 (direct) Worton Drive, or +44 118 986 8601 (ext 8278) Worton Grange Business Park, Fax: +44 118 923 8399 Reading, RG2 0SB ENGLAND http://www.computing.surrey.ac.uk/personal/pg/E.Willink ------------------------------------------------------------------------ (formerly Racal Research and Thomson-CSF) As the originator, I grant the addressee permission to divulge this email and any files transmitted with it to relevant third parties.
Back to the top