UML/MDA Demos

In the download, I am seeing a document about how to use an OE database for a repository, but I don't see a document that talks about installation in EA. You might also want to tell people how to get an EA trial.

In the download, I am seeing a document about how to

use an OE database for a repository, but I don't see

a document that talks about installation in EA. You

might also want to tell people how to get an EA trial.

Hi Thomas,

Yes. The demo materials are built around Enterprise Architect from . So those who do not have a licensed EA version will need to download a trial version of EA to run the demos.

The configuration of an OE10 database as an EA model repository is included for people's interest. Unfortunately, only OE10.0B is supported as OE10.1A included the release of the new type 4 jdbc/odbc driver. I am speaking with Sparx tonight about implementing support for the new type 4 driver.

Currently, there is no document covering the installation of the OpenEdge plugin for EA. Something to begin working on...

Phil

If there is anyone listening who is just beginning to poke around UML, wondering if it might be useful, I strongly encourage you to get the trial edition as it has a quite full example built in. There are also some solid "10 minute intro" pieces on their website.

Project Background:

-Legacy application migration/transformation to SOA

-Team with no experience in UML/MDA techniques

-Team with no OO experience

-4GL (ABL) developers

Taking into consideration these facts, would there be any gain/advantages in adopting UML/MDA?

Whether or not there would be any benefit, depends on a number of factors, such as:

1. How willing are these developers willing to learn?

2. How large is the system you are transforming?

3. Do you have any expertise in SOA?

4. Are your developers willing to learn about OO?

Certainly, there is an excellant possibility of benefit, but only if the people involved are willing to learn and adapt their techniques.

To me, SOA is a natural for OO ... not that OO is required, but that one really has to imitate it to a large extent to do SOA, so why not just do it?

Of course, this is a case where some appropriate mentoring is likely to be very useful.

Factors:

1.Developers are willing to learn SOA approach, not necessarily OO although.

2.Quite big.

3.Not really, we are basing our architecture on parts of the OERA prescription.

4.I don't think so, learning curve seems tough.

Let me put it this way: suppose the team is not willing to learn/adopt OO, is there any benefit in using UML/MDA on the process/service design level?

Well, the unfortunate truth is that all of the OERA examples thus far are .p and .i, so it is certainly the case that you can use UML, OERA, and SOA without moving to .cls files.

But, I think there is a questionable perception here, especially if you plan to do all of this with only in-house resources. You seem to have the idea that OO is hard and SOA not so hard, but in fact there isn't much difference in the skill of decomposing behavior into services than in decomposing into objects. To me, you basically have to go through the same adaptation to a thought process, but by implementing without classes, you need to use an imitation construct instead of the real thing. The hard part is the mindset, not the coding.

Let me put it this way: suppose the team is not

willing to learn/adopt OO, is there any benefit in

using UML/MDA on the process/service design level?

I believe there is always a benefit in spending some time on defining and designing before actual construction... and well-defined methods supported by easy-to-use tools provide less excuse to skip such important steps.

UML can most definitely be utilized to model scenarios in non-OO environments, and MDA generation and transform processes can also be constructed to support non-OO situations.

However, OO and UML/MDA are intrinsically related; UML was afterall the result of combining similar yet distinct OO design methods. Therefore most training in UML/MDA presupposes familiarity with OO concepts. So I am a little doubtful that skipping OO and yet trying to adopt UML/MDA would be wholly successful.

Certainly, you could have some people who have the UML/MDA skills and tools come in and help you apply the approach to your situation and thereby hide all the OO stuff. But I'm not sure that is entirely desirable either.

Certainly, you could have some people who have the UML/MDA skills and

tools come in and help you apply the approach to your situation and

thereby hide all the OO stuff. But I'm not sure that is entirely desirable

either.

Having someone do design that you never really take ownership of would clearly not be very desireable and would tend to mean that the design work was soon abandonned. But, that doesn't mean that the design work can't be accompanied by mentoring. Indeed, the ideal mentor would guide you to the thought process so that much of the concrete design was something you yourself actually produced, assuming that you are your own domain expert for the application. The mentor could also guide you in patterns of implementation, whether using .cls or .p solutions.

Thomas, Phil, thanks for your insigths.

I see you both agree on the fact that using UML/MDA is rather pointless unless you also adopt OO. However it seems strange to me that OERA doesn't mention this OO dependence anywhere, OERA/SOA is based on defining business entities, tasks and workflows rather than on objects. OOABL is not mentioned in the examples I have seen around OERA at PSDN. Is there any other documentation I should be looking at that I am missing?

From a pure theorical point of view adopting OO seems a daunting task, and I think there should be very good reasons on why one should choose the OOABL path instead of a more mature OO language (Java, PHP, etc.), don't you agree?

I see you both agree on the fact that using UML/MDA is rather pointless

unless you also adopt OO.

Not really ... look at all of the UML in recent PSC publications without a .cls in sight

Seriously though, I think that our position is more that:

1) Modeling is a good thing, regardless of the programming paradigm;

2) OO is a good thing ... and it isn't really that hard; and

3) The most natural relationship is between UML and OO code, but it isn't the only relationship possible.

However it seems strange to me that OERA doesn't mention this OO

dependence anywhere,

Becasue it isn't a dependence. PSC is bending over backward to make sure that people understand that it is possible to adopt OERA without having to dive into OO ... but that doesn't eliminate the fact that ultimately OERA concepts fit very naturally into an OO programming model so one is likely to have to kludge a bit imitating objects if one is going to stick with .p code.

OERA/SOA is based on defining business entities, tasks and workflows

rather than on objects.

And, defining objects is based on defining business entities, tasks and workflows. An object has a natural encapsulation which makes it well suited for this purpose, but one can imitate this with .p code.

OOABL is not mentioned in the examples I have seen around OERA at

PSDN. Is there any other documentation I should be looking at that I am

missing?

What's missing is PSC examples and whitepapers catching up with the fact that objects are now available. You aren't missing it; it just hasn't happened yet.

From a pure theorical point of view adopting OO seems a daunting task

Not really. Writing OOABL still uses most of what you already know about ABL, just packaged differently. In order to write good OERA/SOA programs, you need to learn to think in exactly the same terms that you need to write OO ... so really, using OO constructs actually makes that easier to express.

I think there should be very good reasons on why one should choose the

OOABL path instead of a more mature OO language (Java, PHP, etc.), don't

you agree?

OOABL is still ABL and there are many things about that which are more pleasant than having to grapple with the primitiveness of Java or C#. To be sure, Java in particular has a richness of tools available for it that we don't yet have for ABL, but that is being worked on.

I'd agree, UML/MDA is perfectly ok for the 4GL / ABL.

Muz

Hi All,

We have traditionally not used a modelling tool or "standard" development methodology in the past for our application, however this is about to change.

In fact we have just purchased a couple of licenses of EA from SparxSystems to start "playing with it".

Basically what we have today in our development process, in this order:

- A User Requirements (functional specification)

- A Technical Specification (usually done by the developer), with information such as basic screenshots, schema changes, programs affected, etc.

- Developer coding based on Technical Specification

- Testing (test scenarios based on these specification documents).

We are now looking into establish a standard modelling tool to document all these steps, and UML with OA (Sparx) seems the way to go.

We are using OE 10.0B and not able to move to 10.1 (OO) at least for another year. However, we are also implementing SOA concepts and separting business rules and UI (in fact, some UI is in Java via Progress Appservers).

I don't expect this to be an easy/quick implementation (about 5 Business Analysts, 15 developers, 5 testers) .

I would like to receive feedback and some help (also provide feedback as we go) on the whole process.

Thanks and Regards

Jonny Oenning

Linx ADS

Melbourne - Australia