Eclipse Modeling Framework

Look back in your material from the convention because there were two presentations on UML

UML 101 http://www.psdn.com/library/entry!default.jspa?categoryID=48&externalID=539&fromSearchPage=true

and Modeling with Enterprise Architect http://www.psdn.com/library/entry!default.jspa?categoryID=249&externalID=620&fromSearchPage=true

So, suffice it to say that PSC is very much interested in UML and is apparently using it quite frequently in consulting arrangements. I think it is safe to assume that they are paying attention to EMF as a part of this, but I think their current stance is not toward actually bundling it in with OEA, but rather toward supporting existing UML tools since these are highly developed. The current fave ... for a couple of years now ... is Enterprise Architect as featured in the talk above. You should check them out at http://www.sparxsystems.com and get the demo.

It is a very impressive product all the way around and at a very reasonable price. PSC has done an add-on piece that will read and write a Progress .df file and build a model from it. They said at the conference that this would probably show up on PSDN, although it would seem like a good candidate for the open source thing we have been discussing too.

The one limitation on it for round-tripping the .df at this point is that it preserves the area information ... which is a good thing ... but it means that one needs a database with the right .st file setup to use the .df that is output. Myself, were I going to do database changes, I think I would do these in the dictionary and look to something like Prorefactor to make the changes in the code and only then suck the .df into EA.

Since the Progress dictionary doesn't include join information, the PSC tool has a component which will "guess" at table relationships based on indices and identical field names. Obviously this works really well to not at all depending on the naming conventions in the particular database.

It also has a piece which will draw a diagram based on the tables and relationships. The current versions of this seem to have some limitation because they can't handle diagrams with hundreds of tables, but I'm not sure that would be useful anyway. However, one can define packages, e.g., for each application within an ERP system, move the tables into those packages, and then automatically generate the diagram for the package. Really pretty cool.

EA is way ahead of where EMF is at this point, so I would definitely give it a look, if this is an area you are interested in. Thus far, I am very impressed by the product. They have a product which links to Eclipse, but it is really only useful for Java. My expectation is that they will be providing something more general in a future release.

Given that I couldn't be in two places at one time, I wasn't able to attend that session.

I'll be sure to take a look at the EA, it sounds interesting.

Unfortunately, the PPT doesn't include the demo, but if you get the trial version from Sparx, it has a pretty good demo built in which will give you a pretty good idea of what it does. There is also a good, very brief introduction to UML on their website.

EMF & GEF are already bundled

with OEA as it supports the T4BL functionality. And I definitely

wouldn't assume that more isn't coming with OEA. Indeed I would

expect T4BL to be more completely built out moving forward. But

again, this doesn't automatically imply UML as EMF supports any

modeling language such as a T4BL modeling language which is

"UML-like" but tailored towards the OpenEdge ABL and most likely

well short of the complete functional breadth or syntactical rigor

of UML. Where UML is preferred, the best approach is simply not to

reinvent wheels. There are numerous UML options already available

for Eclipse many of which could be configured towards supporting

OpenEdge. It is true that there is an existing relationship between

Sparx Systems and Progress but that doesn't necessarily exclude

other options.

Indeed I would expect T4BL to be more completely built out moving forward.

It needs to be torn apart first ...

Seriously, anything that rigid and specific is unlikely to get used.

It needs to be torn apart first ...

Seriously, anything that rigid and specific is

unlikely to get used.

If I may ever so politely suggest that it's easy to tear anything apart both literally or figuratively. But it requires more thought and effort to propose alternatives and/or suggestions for improvement. Without suggesting that reasonable opinions here would ever be constrained in any way, I would like to gently nudge this discussion in a more positive direction.

Use this forum to express any thoughts you have that could open up the field of modeling and model-driven architecture to the OpenEdge development community. Obviously, that may include - but certainly should not be restricted to - discussion of the capabilities of T4BL.

Some open questions to consider regarding modeling/UML/MDA:

How can we leverage M/UML/MDA to make the OpenEdge developer more productive? To make OpenEdge applications more competitive in their respective markets? Enhance value to the end-user ? Improve quality? Reduce total lifecycle costs? Accelerate application transformation and continuous innovation?

There's a broad canvas so get out your brush and start painting.

I've been building and using various forms of program generators since 1979. Any tool that I have used for any real development has been one I built myself, despite looking at a great many other tools hoping that I wouldn't have to build my own. From that experience base, there are two major principles that seem to me to be key.

One is what I think of as "no compromise", by which I mean that the generator must never keep one from accomplishing what one would do if one were not using a generator. Any generator which covers a common case, but then needs to be set aside in favor of hand coding is a generator whose value I question because it ceases to be of value the minute one gets to the hard problems.

This is similar to the problem that I had with report writer products until I came to Actuate. That was the first time I had a tool which would allow me to continue to use it for arbitrarily hard problems, exactly the place where one most wants the fancy features which a report writer can provide.

This doesn't necessarily mean no hand coding, to be sure. That is a goal, but not an absolute requirement. But, one must be able to encapsulate the hand coding in such a way that one can change a template and regenerate a new instance with the code automatically included in the new code in the appropriate place. It also means that one should be able to continue to use all of the power in the template and only override the special code. I.e., one shouldn't ever be in a position where the need to insert special code makes features of the template that are used in other programs unavalable for the program with the special code.

The other principle is openness. By this I mean that the tool should never include black boxes with behavior I can't modify. For something I built myself, this is obviously not a problem, but it is certainly a problem with a lot of other generator products I have seen. The minute one has a black box, one has a limitation where one can't change the model or improve the model or amend the model. It is almost guaranteed that if person A creates a model that not only will person B want to do things a little differently, but also that person A will themselves want to do it differently a few years down the line when language features change or just one's perspective has shifted. Without openness, one is trapped.

While it may limit my enthusiasm, I have no problem with starting off by initially only tackling a small portion of the development requirement, so it isn't the limited scope of T4BL that is the source of my feelings about it. Those feeling come from the fact that it is closed and, worse yet, what it produces conforms to a model which I think is dated and out of place in a language with OO features. So, this is not an issue of wanting a few twists here and there, but of thinking that one needs to start over again from the beginning with the concept.

One of the problems here, of course, is that I have a strong bias which says that, if the language now has OO features, they are something that one shold be using, especially in the context of OERA. But, at this point, all of the published models for what PSC thinks OERA code should look like are all still .p, .w, and .i code. So, the starting problem is not even having a concrete model for what it is that one should be generating.

Some open questions to consider regarding

modeling/UML/MDA:

How can we leverage M/UML/MDA to make the OpenEdge

developer more productive? To make OpenEdge

applications more competitive in their respective

markets? Enhance value to the end-user ? Improve

quality? Reduce total lifecycle costs? Accelerate

application transformation and continuous innovation?

Let's split the model in three parts:

1) backend tier (internal, fine grained components)

2) service tier (external, medium to large grained components, a facade on top of tier 1)

3) user interface tier calling tier 2

Lets forget about tier 3 in modeling. It would be great if you could express the UI in a declarative form, but that requires an ABL-rendering engine (see the directions forum

A data-driven architecture, which seems to be Progress' favorit, consists of defining datasets and defining dataset operations. Tier 2 is about defining messages (datasets) and mapping them to the internal tier 1. Modeling could help out with defining datasets, operations and the mapping to the fine grained components. It could generate client side proxies, web services and dataset definition.

Tier 1 is a composition of the internal business logic. It's about constraints, persistence mapping, transaction boundaries, workflow and clever organization of your components. Modeling could help with static class diagrams. It would be nice if you could somehow define entities and relationships, which can be reused at tier 2 (definition of datasets). Modeling should be an abstraction layer. You should for instance be able to work with conceptual types like "business calender" and "memo" instead of the implementation types date time and character X(512).

I think modeling would be valuable:

- if it guarantees consistency of the model (for instance entity relationships)

- if it helps you creating a tiered architecture (generate proxy classes). This will only work if the runtime supports the architecture.

- if it reduces coding by abstracting aspects (declarative cascading delete for instance)

- if it helps you organize your code

- if it supports code editing outside the modeling environment

I don't believe in modeling for the modeling. I don't believe in sequence diagrams, state diagrams and use case diagrams (too simple or too complex). I do believe in specialized diagrams for certain aspects...

Let's split the model in three parts:

Well, two comments ... one is that I would vote for pointing to the OERA specifically in terms of implemention, which is what your layers seem to be. The other is that this is implementation, not necessarily model. One of the ideas in MDA that I really like is that one progresses from a CIM (computation independent model) to a PIM (platform independent model) to a PSM (platform specific model) through transformations. The PSM from one transformation can be the PIM for another transformation so that, for example, one can create partitioning into layers at one level and apply a specific UI at another level.

To be sure, a lot of people who use models never abstract them that far from the implementation, but they are losing some flexability by doing things that way.

Lets forget about tier 3 in modeling.

I don't know why we should. After all, the people in the Java world are way ahead of us in this generation stuff, .NET too, I think, and so a Java or .NET client might come from more immediately available technology than any of the rest of it.

Modeling could help out with ...

Along with the whole rest of the application...

- if it helps you creating a tiered architecture (generate proxy classes). This

will only work if the runtime supports the architecture.

Why do you equate tiered architecture with proxy classes?

What specifically do you mean by the runtime support ... i.e., what is or isn't there today? (Note, I'm not saying that there isn't something missing, since I have said that elsewhere, but I'm just wondering what you mean specifically)

- if it supports code editing outside the modeling environment

This is a very interesting point, but one that I have a somewhat different twist on myself. To many people, the ability to round trip is considered essential to finding a modeling environment acceptable, but I think this is based on a fundemental failure to really accept the modeling environment. I.e., it is a judgement that the modeling environment is capable of doing the simple stuff, but the "real" programming has to happen by having "real" programmers writing "real" code. Well, perhaps when your model to code capabilities aren't good enough, that is the best that one can do. But, if they are good enough, there is no longer any real need to work on the generated code directly, except for testing and experimentation. At that point, really all the work should be on the model, the templates and transforms, or on the foundation.

I don't believe in modeling for the modeling.

Well, you are free to have your own belief structure ... but I think in modern architectures and business contexts, modeling is increasingly valuable and important to manage complexity, mitigate risk, and facilitate communication (did I get that right, Phil?). Have you looked at this presentation?

http://www.psdn.com/library/entry!default.jspa?categoryID=249&externalID=620&fromSearchPage=true

This is a very interesting point, but one that I have

a somewhat different twist on myself. To many

people, the ability to round trip is considered

essential to finding a modeling environment

acceptable, but I think this is based on a

fundemental failure to really accept the modeling

environment.

Yes. Or possibly just discomfort working with an abstraction of code rather than the code itself. And there is simply just a lot of confusion about where the line between where modeling/code generation and manual coding should be drawn.

I.e., it is a judgement that the

modeling environment is capable of doing the simple

stuff, but the "real" programming has to happen by

having "real" programmers writing "real" code. Well,

perhaps when your model to code capabilities aren't

good enough, that is the best that one can do.

MDA characterizes three model abstractions of code: CIM (Computation-Independent Model), PIM (Platform-Independent Model), and PSM (Platform-Specific Model). Some make the mistake of assuming that the distinction between these model is just the level of detail; that is, the PSM is a lower level of abstraction/has more detail than the PIM and in turn the PIM is a lower level of abstraction/has more detail than the CIM. And although there is a correlation there, the real distinction is the stakeholder audience and their respective technological literacy: the CIM is a model that should include no notion of technology and simply be an expression of end-user goals the processes to achieve them; the PIM is a model that assumes technology but in a platform-neutral way; and the PSM is a model that assumes a specific technology or set of technologies. In other words, each of these models may possibly be as detailed as the others, the distinction is the level of technological assumptions that each includes: none, general, specific.

Great in theory. But what happens in practice.

Although there are many exceptions, modeling is assumed to a technologist's discipline. I can't quote any statistics but I believe the overwhelming majority of professionals in software development who use modeling methods and tools come from a coding background each of whom has more or less settled on their own respective set of favorite programming languages and platforms, and arrived at modeling to assist the coding effort. So it is little wonder that most models out there are typically PSMs.

But,

if they are good enough, there is no longer any real

need to work on the generated code directly, except

for testing and experimentation. At that point,

really all the work should be on the model, the

templates and transforms, or on the foundation.

So then the code gets generated and then added to and changed by coders. If the round-trip capabilities of the tool in use are decent, these code changes can then be imported and retrofitted into the model.

Why? Why can't all the changes be done in the model and all the code be generated?

In theory, this is possible. But there are a few things that get in the way of 100% code generation.

To model everything just means that the "coding" has been shifted into another paradigm and toolset. For example, instead of using OpenEdge ABL in OEA, you are now required to express functionality using OCL in some modeling tool. There are some benefits to this approach (like being less tightly-coupled to a particular programming language), but they are considered by many to be marginal. It would also be difficult to assume that the "coding" effort would be reduced to any great degree.

To model everything also assumes that it is known and understood how to model every little special case and exception which oftentimes takes more time and effort than to code in your comfortable ol' programming language. And to model everything simply results in diminishing returns due to the diminishing scale. One of the productivity benefits of modeling it being able scale using patterns and reusable abstractions. One-offs, special cases, and exceptions are by definition "difficult" to reuse and reapply.

I'm not saying that everything can't be modeled. I'm just questioning whether it is economical to do so. (And this from someone is definitely more a modeling proponent than modeling skeptic.)

I don't believe in modeling for the modeling.

Nobody should.

Well, you are free to have your own belief structure

... but I think in modern architectures and business

contexts, modeling is increasingly valuable and

important to manage complexity, mitigate risk, and

facilitate communication (did I get that right,

Phil?).

Sure. And although I wholeheartedly believe in the importance of these benefits, they are somewhat peripheral to core business benefits that modeling/UML/MDA needs to support and in a clear and demonstrative manner in order to gain greater traction and adoption in the OpenEdge developer community. Greater productivity, greater customer value, greater quality, greater agility, reduced total lifecycle costs, etc. And although there is plenty of evidence available to support that M/UML/MDA does indeed support these benefits elsewhere, the maturity of the technology as it directly applies to OpenEdge technology would prevent anyone from making any assertive claims here or at Exchange. I hope that changes in the very near future. And some hard evidence is emerging from recent OpenEdge projects.

Or possibly just discomfort working with an abstraction of code rather than

the code itself.

All things considered, modeling is just another language, but to many people, an unfamiliar one.

Although there are many exceptions, modeling is assumed to a

technologist's discipline.

While there are those who suggest that one of the advantages of abstracting a model sufficiently to have a real CIM is that it is then accessible to business analysts who don't need to be coders, I am inclined to be a little skeptical of this working very often. Of course, it is also true that a lot of coders don't really have the right mindset either.

To model everything just means that the "coding" has been shifted into

another paradigm and toolset. For example, instead of using OpenEdge ABL

in OEA, you are now required to express functionality using OCL in some

modeling tool.

OCL or Action Language.

To me, the problem with allowing round tripping is that it is unlikely that the changes made in the code will actually map back into the model in the way that one would have done that same work had the work been done on the model. E.g., what should have been expressed as a constraint in OCL will instead be stuck in with some Action Language because that is where the programmer happened to put it. To me, that degrades the quality of the model and the more one does of it, the more degraded the model will get.

Moreover, I don't believe that kind of roundtripping very often goes back to the CIM, but rather gets stuck somewhere in a PSM ... which is OK until there is some deeper architectural change and one wants to return to the base and regenerate a new PSM.

As to reduction in effort, I think the impact is different at different stages of the life cycle. Certainly, there is a big front end investment in creating a foundation library and working out all the MDA transforms, but that is not an on-going investment when one updates the model. For any small, focused programming change, the difference of writing in ABL or AL is probably small, but, if one makes more significant architectural changes, then the productivity gain can be very large. Also, a very non-trivial aspect of generated code is that, once one works out the bugs in the generator, the code is very uniform and very stable. This results in an enhanced user experience where the functionality is uniformly high and consistent and it results in substantially lowered support requirements because everything just works because there are no program by program quirks put in by inventive programmers. Modifications also tend to be very inexpensive because one can focus directly on the needed change, often at a very abstracted level, and not find oneself having to unravel some ball of spaghetti which an earlier programmer left behind before one can even figure out where the change can be made.

Greater productivity, greater customer value, greater quality, greater agility,

reduced total lifecycle costs, etc.

Yup! While I can't testify to this specifically based on UML and MDA, I certainly can based on our own program generation technology called Specification Driven Development. How does 1000 lines of code ready for integration level testing per programmer per hour over a three month project strike you for greater productivity?

I hope that changes in the very near future.

Working on it ...

There do seem to be lots of tools in Eclipse for modelling work (http://www.eclipse-plugins.info/eclipse/plugins.jsp?category=Modelling). Is there any "pre direction" direction you could offer?

I think another point to make is that, in my experience anyway, modelling works really when you first build a system and have few developers. However, maintaining a model that is tied to DB and code (more so code) becomes much harder because many tools (e.g. AndroMDA) don't handle that well. They will only output certain code pieces "once" and you then need to hande code stuff yourself. So, doing something like a REFACTOR becomes quiet difficult as the tool will change its parts for your but not the bits you have edited by hand. I also have not found a tool that will let you change the model in such a way that it helps you with the DB upgrade (e.g. re-name fields or move them). Usually the tools just remove/add fields.

There do seem to be lots of tools in Eclipse for

modelling work

(http://www.eclipse-plugins.info/eclipse/plugins.jsp?c

ategory=Modelling). Is there any "pre direction"

direction you could offer?

Hi Murray,

Unfortunately, there is nothing to announce regarding the Eclipse modeling projects and any "pre-direction" direction. The projects themselves currently lack some significant maturity and completion. And there are several proprietary third-party tools out there for Eclipse including Enterprise Architect that can be leveraged as substitutes.

Phil

I think another point to make is that, in my

experience anyway, modelling works really when you

first build a system and have few developers.

However, maintaining a model that is tied to DB and

code (more so code) becomes much harder because many

tools (e.g. AndroMDA) don't handle that well. They

will only output certain code pieces "once" and you

then need to hande code stuff yourself. So, doing

something like a REFACTOR becomes quiet difficult as

the tool will change its parts for your but not the

bits you have edited by hand. I also have not found

a tool that will let you change the model in such a

way that it helps you with the DB upgrade (e.g.

re-name fields or move them). Usually the tools

just remove/add fields.

Yes. This is an important point. Some tools provide functionality to synchronize code/schema changes back to the model. As long as this synchronization is maintained, then refactoring via the model is definitely possible.

On the DB upgrade issue, yes, many tools do not handle this well. Some tools such as Enterprise Architect provide the ability to set model baselines which can then be used to identify deltas and thereby generate things like incremental df files. But this is not something that has been fully implemented.

Phil

And, not merely are they substitutes, but they are

considerably more robust than what is currently imagined for EMF.

But then, that isn't a pre-direction direction either.