|RE: [gmt-dev] gmt-home/description.html|
Hi Ed, Let's talk, instead of writing ever longer notes. Regards, Ghica van Emde Boas Bronstee.com Software & Services b.v. e-mail: emdeboas@xxxxxxxxxxxx, tel: +31 23 5474422, or: +31 6 53368747 (mobile) fax: +31 23 5473347 -----Original Message----- From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On Behalf Of Willink, Ed Sent: 20 June 2003 15:55 To: 'gmt-dev@xxxxxxxxxxx' Subject: RE: [gmt-dev] gmt-home/description.html Hi Ghica and all, > 1) > To me it was immediately clear that the diagram is an > informal use-case > diagram. Maybe Jorn can add a stick-puppet to make that more > obvious. True > UML therefore. Now I'm getting really confused. Use cases have external actors and internal actions, often identified by verb phrases. Surely Meta-Model isn't being used as a verb. If each is interpreted as "Create xxx", I lose track of what is information and what is action. > To my opinion we should never talk about transform providers > and transform > users, we could more formally introduce GMT-tool users, GMT-tool > configuration implementers, and GMT-tool developers. I'm not sure what you mean by GMT-tool configuration implementers. If we use 'Java language support tool suite' as an analogy for GMT. We have 'tool developers' - us, no problem. We have 'users' in two roles. a) programmers, who I would call library/transform consumers b) library programmers, who I would call library/transform providers Aren't we saying the same thing? transform consumers == GMT-tool users transform providers == GMT-tool configuration implementers with advanced users fulfilling both roles, sometims providing libraries, sometimes using them. > As far as I know, you have a different definition of what a > texture is than > we have. As long as that is the case, you will remain > baffled. In any case, > it is not an information model. Something should change: We > could introduce > your concept of texture in the tool (and call it something > else). Please > provide a clear description of your concept, intended for > dumbos like me. > Maybe you could try to understand again what we mean by texture. My definition was in my paper, and neither you or Jorn objected to it. "A texture is an arrangement of objects with connectivity, multiplicity, type, value and other constraints". A referee objected to the term so I have changed to using structure, which ;eaves 'texture' clear for whatever you want - see patterns later. > My conclusion is that the diagram is just fine as it is. Of > course there are > details possible in the form of class-diagrams or state > diagrams, or maybe > even activity diagrams, that will come at a later stage. I think that if one out of three committers doesn't understand the diagram, we have to do some work on it or him. > >>I see the mapping information as associations of > instantiations. So I > >>associate some properties of the PIM with some properties > of a PDM. Each > of > >>these may be substantial hierarchical models in their own right... > I agree to this. The rest of the paragraph is vague to me, > because I am only > unconsciously a user of TCP/IP communication. I'll try to guess at something in your world. A PIM might define how a mortgage account is to be maintained. A PDM might offer your favourite financial businness object libraries. There may be a automated derivationof a PSM that is acceptable to one client. However when you come to deliver the standard mortgage application (PIM) to another client in their standard environment (PDM) you may need to specify extra QoS properties (in the Deployment/Mapping model) e.g. results must appear with 1 second, results need not appear on bank-holidays, ... These extra constraints may enable an automated mapping on a good day, or provoke a load of diagnostics on a bad day. The latter may steer you to putting more explicit information into the mapping model, possibly mandating the realisation in an Applet to avoid communication overheads. > 2) What is your point here? To try to discover what the point is. Either: You agree, so we have made progress. You disagree constructively and we can make progress. You don't understand and we make no progress. I think that the only code we need to develop is a transform facility, flavoured by multi-input, text generation, workflow support, and adapters to 3rd party tools. The remaining 90% is transformation library stuff. > 3) Workflow. > All I know, is that to GMT users the tool looks like a > workflow tool. It > will be configured to fit the particular development > environment of the user > (e.g. application developers). We should adhere as much as possible to > workflow standards that are out there, presumably WfMC. We > should look into > that soon. I think you need to explain to me what you mean by a workflow tool. > To me, UMLX is a node in the workflow. I do not think it is > mature enough to > serve as the tool to implement the workflow with yet. We need > at least some > graphical tools that can define the workflow processes for a > particular > user. UMLX is potentially an irrelevance, but its facilities offer insights. The important issue is hierarchical transforms, which needs a joining the nodes up language, for whose abstract syntax we need an XMI representation. UMLX is just an example of a concrete syntax for the underlying abstract syntax. Eventually that abstract syntax should be QVT compatible. We can use whatever graphical tools you like provided they are compatible with the abstract syntax. UMLX is just convenient because it is closer than anything else I'm familiar with, but if you have other ideas please show us an intelligible example. > Textures: see above. > > Pattern: This is an unsolvable problem. I have been in big > trouble once, > because my opponent with better managerial influence, failed > to understand > that "view" as in database-view is something different than > "view" as in MVC. This is a different issue - different use of same term. Pattern has a casual colloquial use that really upsets the gurus. > Do a proposal for an alternative! I do not understand > what a pattern > solution is, do you mean "solution pattern"? that would be ok . This made me think hard about English grammar, of which I'm only a user not a theoretician. I think a noun phrase is adjectives then noun. So a "red balloon" is a balloon with a red qualification. So a "solution pattern" is a pattern with a solution qualification, presumably a pattern for solving problems ... think hard, research, do it, test, ... A "pattern solution" is a solution with a pattern qualification, which is what I, and I think you, meant, a solution for a pattern. Patterns -------- Perhaps this is where our misunderstanding stems from - I'm guessing again. I'm sure we all want a tool that is useful for implementing patterns. I think you see parterns as special, hence the elevated status of texture mapping over transformation. I see patterns as ordinary, hence I want to use an ordinary transform suite to do patterns. The purists argue that patterns cannot be implemented becuase any implementation must ignore the subtleties, possibly yet to be discovered, in the forces. The pragmatists argue that they want useful code now. Hear Hear! But to do justice to patterns we must not ignore the purist view. There is no one correct solution to interesting patterns, therefore a pattern library must contain many solutions, and must be extensible to accommodate further solutions. This requires an automated pattern implementer to choose between alternative solution alternatives. Therefore in order to support patterns, we need multiple transformation passes a) discover applicable patterns b) evaluate their forces c) choose the most appropriate solutions d) implement them Obviously a user may short-circuit this by pre-selecting a solution. (Implicitly by the PIM being so narrow as to offer no alternatives, by the PDM providing support for only one alternative. Explicitly by some constraint placed in the Deployment.) In providing a pattern solution, we must therefore provide not only the transformation that implements it, but also the context in which it is applicable and an evaluator for its forces. The transform is comparatively easy. The context may be easy - just a structure match on available meta-class instances. The forces are more interesting and I've given it little thought. But when we get there we will presumably need a transformation (suite) that implements each pass a pivot model that holds information between passes Each transformation that implemnents a pattern is activated by the (meta-)transformation that supervises pass d). 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. > Regards, > Ghica van Emde Boas > Bronstee.com Software & Services b.v. > e-mail: emdeboas@xxxxxxxxxxxx, > tel: +31 23 5474422, > or: +31 6 53368747 (mobile) > fax: +31 23 5473347 > > -----Original Message----- > From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On > Behalf Of Willink, Ed > Sent: 12 June 2003 10:21 > To: Gmt-Dev (E-mail) > Subject: [gmt-dev] gmt-home/description.html > > > Hi All > > Jorn, Ghica: I think this discussion should be on-list. > > I'm unhappy with our top-level detailed description. > > 1) Stylistic > > This may appear trivial, but actually I feel it's very important. > > The diagrams are hard to understand beyond a very superficial level > > The diagrams are in an informal notation for which only clues > as to meaning > are provided. It was a while before I noticed that the diagram showed > development > order, although I'm not certain that that is true. More > normally IMVHO data > is in > square boxes and processes are in rounded boxes, so we start > on the wrong > foot. > It would be much better if they were drawn in UML, probably > as activity > diagrams > where careful page positioning can indicate time, and swim lanes can > indicate > activity phases. > > A major problem is the failure to distinguish the activities of the > transform > provider and the transform consumer. While we certainly want > to be able to > support > users who consume their own provisions, it is essential to > keep apart the > meta-programming phase (transform provision) from the > compilation phase > (transform consumption). We should hope that a substantial library of > standard > (and proprietary transforms would become available. > > I'm baffled by the Texture Mapping ellipse. It presumably is > an information > model, but as such it can take no action so I'm not sure > where the mapping > comnponent that you try to keep distinct is. Figure 2 is > easier to argue > about > here. The concepts we must deal with are: > > Input models (and their meta-models) which may be PIMs and PDMs. > Ontput model(s) (and their meta-models) which may be PSMs. > Information to control the mapping process > Specification of algorithms to implement the mapping > An engine that executes the algorithms > > We are in agreement about input and output models, although I would > generalise > to M inputs and N outputs. Though note that a PDM is > Description, so it > defines > information about the platform, it does not contain > compilation algorithms, > although it may contain command lines or compilation options > and locations > of appropriate tools or libraries. > > You fail to clearly apportion the three mapping concepts into > the two icons; > > a texture mapping ellipse and a multi-stage transformation box. > > I think that we are seeking to meta-model everything, so that the > information > to control the mapping process is an instance of a mapping/deployment > meta-model. > The specification of algorithms is an instance of a > programming meta-model. > So our information in the PIM + PDM to PSM case comprises > PIM model + meta-model > PDM model + meta-model > PSM model + meta-model > Mapping model + meta-model > Transformation model(program) + meta-model > The first four are information only and so represent > input/output of an > information > engine. The latter is a program that probably needs > compilation in order to > be > efficiently executed by the information engine. > > I would therefore like to draw Figure 2 with three inputs (A, B, C or > Mapping) and > their meta-models, feeding a transformation engine which has > a side input > comprising > a transformation(s) ellipse and its meta-model. > > We combine Figure 3 and Figure 4, deleting the central Texture Mapping > ellipse, > (move it up as a third input if you like). The dependencies > are simple; the > programming meta-model depends on all the input and output > meta-models. If > we > use a UML-based programming language then these dependencies represent > re-use. > If we do this at the meta-levrl as in UMLX, the input and > output schema > represent > the data declarations, that just need to be related by a hierachy of > match-driven > evolution, presevation and removal operations. > > I see the mapping information as associations of instantiations. So I > associate some properties of the PIM with some properties of > a PDM. Each of > these may be substantial hierarchical models in their own right, for > instance > if I allocate a communication path in the PIM to a TCP/IP > communcation link, > the PDM will provide support for that link. Or more > realistically my mapping > directive causes TCP/IP elements rather than X25 elements to > be pulled in. > I make no distinction as to whether what is pulled in is a > very thin wrapper > for > pre-packaged IP, or a deep detailed model that supports > synthesis of the > entire > stack. In this latter case we find that there is a > substantial grey area in > that > activation of a PDM resource may activate a PIM that realises > it at one > layer of > abstraction allowing a further mapping to select which > particular Ethernet > driver > is required at another layer. > > 2) Components > > The document describes mapping components, transformation > components and > text generation components. > > My experience with UMLX, is that nearly all (56 out of 68 > drawn so far) > transformations > ard multi-input. This is because there is either a need to > merge external > inputs, or > internal inputs. For instance consider a compression > transformation. Pass 1 > may analyse > the data to be compressed to produce a compression model that > can then be > applied to > the data, so pass 2 is multi-input. This happens everywhere > that things get > non-trivial, > so multi-input is fundamental to transformations. There is > therefore no > sensible > distinction between an engine that transforms one input and one that > transforms multiple, > and an engine that transforms multiple inputs is also a > mapping engine. > > The mapping component is therefore supported by a multi-input > transformation > engine. > > Real mappings require real work to define suitable PIM, PDM, > PSM and mapping > models > and the transformations that operate upon them. > > We previously agreed that the text generation component is > arguably just a > choice of > output serialisation policies on a more general > transformation engine. In > this case > the activity is to design and implement a driver. There is no distinct > component and > no need for special integration. > > 3) Workflow > > There are three kinds of transformation that we may seek to apply. > > Foreign transformations implemented by some random third > party tool, that > may > well require input and output adapters and invocation in a > separate process. > A compiler would be an example of this. We would need to > produce specially > formatted input, and provide a custom translator to > re-acquire its symbol > table output for further processing. > > External transformations may be more accessible, probably > because they are > written > in Java and so may be amenable to direct passing of DOM or > equivalent models > within the > same process, rather than separate XMI files. > > Internal transformations are more interesting. We have a meta-level > specification of their > behaviour so that we may seek to optimise the way in which multiple > transformations > are invoked and synthesize more effecient composite > transformations. UMLX , > pending QVT, > is probably a good way in which to handle internal transformations. > > Few interesting transformations are single pass, so it is > necessary to be > able to > create appropriate sequential or parallel combinations of > transformations. > The UMLX > compiler has at least five major passes at different > meta-levels, with a > number of > sub-passes internally. Sequencing transformations is > therefore a fundamental > part > of a transformation engine that supports hierarchical > composition. One level > of > hierarchy defines the composition of its children. A useful > meta-model of > transformations must define a meaningful semantics of hierarchy and > transform composition. > > I have previously pointed out that top-level sequencing of available > transformation suites > can be automated by path analysis through the meta-models > from what the PIM > requires to > what the PDM offers. > > So we have just a transformation component that does mapping > inherently as a > by-product > of multiple inputs, workflow as a by-product of hierarchy and text > generation > with the aid of an output driver. > > We therefore need to develop 'just' > - the transformation compiler (for each transformation language) > - the transformation engine > - text output driver(s) > - standard interface(s) to external transformations > - custom interfaces to foreign transformations (low priority) > - one set of logging facilities. > - one set of debugging fafacilities. > to satisfy our XMI to XMI role, but also > - transformation language GUI > - debugging/logging GUI > to make the tool usable and > - MDA schema library > - MDA transformation library > to support MDA. > > Textures > -------- > > We must be very clear about the distinction between texture > (classes) and > texture > instances. A transformation defines texture (classes) whose > instances in > input model(s) > activate the transformation. This error occurs in the first > paragraph, which > concludes > with a non-sequitur about texture mappings. It is certainly > not appropriate > to speak of > such things without any further clarification. I'm unclear > whrether you wish > the > term to mean the activation of a special program, while I > mean the mapping > information > which drives a standard transformation engine. > > The requirement for a texture to feature in a single input model is > artificial. > If I'm correlating two inputs, I may look for textures A and > B in document 1 > and texture C and D in document 2, and when these share some > relationship I > react. > A, B, C, D therefore form part of a compound texture over > multiple inputs. > >From a > different perspective, if I break a given texture up into > sub-textures, I > will find > that the sub-textures acquire multiple inputs. > > Single input is an, I think accidental, property of GReAT, > which I believe > Adi thought could > be removed. Single input was an early design simplification for UMLX, > particularly given > the natural single input behaviour of XSLT. However, I > rapidly discovered > the power of > and need for multiple inputs and using the document() > capability of XSLT, I > have multiple > inputs working at minimal extra complexity. > > Multiple outputs is less essential, since multiple single output > transformations can > always produce multiple outputs, however this may involve > mass rework, so it > seems > pretty silly not to allow multiple outputs too. > > Pattern > ------- > > There are some people in the pattern community who feel very > strongly about > a pattern > establishing a context in which many different solutions are > available. We > should > therefore try to avoid using the term pattern loosely, and > certainly avoid > usage such as the title of figure 2 which is most certainly > not a pattern at > all. > When we must use the term pattern, we should probably say > pattern solution. > > 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. _______________________________________________ gmt-dev mailing list gmt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/gmt-dev -- This message has been scanned for viruses and dangerous content by MoveNext MailScanner, and is believed to be clean. _______________________________________________ gmt-dev mailing list gmt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/gmt-dev _______________________________________________ gmt-dev mailing list gmt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/gmt-dev -- This message has been scanned for viruses and dangerous content by MoveNext MailScanner, and is believed to be clean.
Back to the top