The Model Driven Software Network

Raise your level of abstraction

Dear folks,

Finally, AtomWeaver was released as a public beta version. It's still a bare-bones, somewhat buggy IDE, but good enough to try some real world things. The release cycle will be frenetic until the v1.0 release day (hopefully) at September 1. Bugs will be ironed out and features will be added. Updates will be posted every other day on the AtomWeaver site at http://www.atomweaver.com .

The installation is very simple: extract zip file to a folder and run. No need to touch the OS. When updating the beta version, just unzip over the current installation. This release is Windows only, but Linux and Mac versions are on the horizon.

As stated before, AtomWeaver is commercial in nature, but a free version, sporting a full ABSE implementation, will be available. ABSE is a public specification (well, it *will* be, because I'm yet to start on the specification doc...).

Documentation is still scarce, but I am working to improve it, specially on the tutorials front. Because ABSE is such a different approach, it may be hard to initially "get it" without a good introduction. Don't give up! It will pay off sooner or later.

For those new to AtomWeaver and ABSE, here's a short intro:

ABSE is a pragmatic model-drivel software development method. Most similar current approach is DSM (Domain-Specific Modeling) as described by Kelly/Tolvanen. Unlike previous attempts at modeling like UML and MDA, ABSE follows a "not perfect world" philosophy where you can mix generated and custom code right on your models. It also introduces the "light model" concept, where most of your models might be made of custom code. An ABSE model is a tree, made up of "Atoms". The host system will "execute" the tree to obtain the intended generated artifacts.

AtomWeaver is a "meta-IDE" (not tailored for a specific platform or language) that implements ABSE. Unlike other systems like Eclipse, AtomWeaver is lean (5Mb zip file) and self-contained (one package). A single approach to modeling: There aren't 120 overlaping ways to do modeling like in Eclipse. I hope this focus will help on fostering wide MDSD adoption. AtomWeaver can easily be put alongside your current development setup. For instance, I am currently using it alongside VS 2008: AtomWeaver models and generates the full project, and VS 2008 compiles and debugs.

There is much more to say, but I guess this is not the appropriate place. You can get a better (if not confusing) introduction to ABSE at http://www.abse.info .

If you are a MDSD enthusiast/early adopter, please give AtomWeaver a spin and send me some feedback. I need it!

Thanks guys, it has been quite a journey up to now. More to come! :-)

Views: 182

Reply to This

Replies to This Discussion

Congratulations. I´ve echoed the release in the modeling languages portal http://modeling-languages.com/blog/content/atomweaver-public-beta-also-released-week
Thanks Jordi!
Congrats, Rui. The 5Mb download was refreshing. Looking forward to learning more about the real world possibilities of AtomWeaver.
Thanks Rafael.

I like "lean and mean". Also, keep in mind that, from the 5Mb download, 1.8Mb is from the VS2008 redistributable! That leaves AtomWeaver at a mere 3.2Mb.

AtomWeaver is a native C++ app, built from an ABSE model. The model currently has around 42000 Atoms, from which 34000 are auto-generated. These Atoms generate 208k lines of code.
Hi Rui,

> If you are a MDSD enthusiast...
well...

> ...send me some feedback. I need it!
> There is much more to say, but I guess this is not the appropriate place.
> http://www.abse.info

...I browsed your site and can agree to your problem analysis. I would very much like to discuss your approach and compare it to the conclusions that we have came to. Doing that in detail might develop into a lengthy, but probably fruitful discussion. So where and how would you prefer feedback?
Andreas,

If you think the discussion would be beneficial to the MDSD community at large, we can discuss here. It may be better to start another thread.

On the other hand, if you think the discussion would only be beneficial in an ABSE/AtomWeaver context, then we can discuss at AtomWeaver's own community site, recently started at http://community.atomweaver.com
Since I'd like to compare and discuss in general, it might be better to start here, because mentioning different aproaches in your product forum seems a little odd if not impolite to me.

So, first of all I like your "not perfect world" philosophy. I totally agree that it is important to give the user as much as possible the chance to switch "back to the roots", if a choosen modelling scheme becomes "too tight for reality". Since MDSD basically is all about "exploring bettter ways of requirements specification", i.e. finding alterntive, innovative languages, we must admit to ourselves that as long as it is called "MDSD" it is *by definition* not about mature languages.

Then, two questions came to my mind when reading the description of ABSE (while writing this, I have more or less "business applications" in my mind, i.e. rather voluminous models with a certain "abstraction tension" within them (i.e. between "lively business requirements" and a multiplicity of technical targets)).

1. Compared to "UML stripped down to 5%", i.e. class models and possibly state engines, how does my model look like? Is it similar in ABSE or quite different? From the information management perspective of my "business knowledge", what are advantages/disadvantages? More specific: would it be possible to export/import (reduced) UML models?

2. Do you apply something like the two-stage-MDA transformation? Our experience is, that a single-step transformation becomes hard to manage in the long run. In fact, more or less independently of MDA, we came just by the recurrent necessity of refactoring our templates to that same conclusion, i.e. there is a need for at least one if not many "inbetween concept layer(s)", be them explicit models or whatsoever.
"I totally agree that it is important to give the user as much as possible the chance to switch "back to the roots", if a choosen modelling scheme becomes "too tight for reality"."

The idea is not to "get back to the roots", although you certainly can, at some point, generate your project, dump ABSE and start working directly with code, as any traditional project.

The idea is to let the modeler decide how unpredictable would be the problem and/or its solution. All modeling approaches support variability. But there are two types of variablity: predictable and unpredictable. Current modeling approaches support the predictable kind. ABSE adds support for the unpredictable kind. A very simple example:

Everyone knows about getters/setters. Everyone knows how to generate these. But what if some "non-standard" code needs to be added in some cases? Quit using the getter/setter model in those cases? Or have a way to keep the model uniform, applying the getter/setter model for every class member?

void myclass::SetMember(int x)
{
m_member = x;
m_last_change = Now();
}

The second line does not belong to a regular setter pattern, but I can still use a setter model in ABSE. This is possible because ABSE supports "code" as a model variability primitive, apart from the usual string, int, boolean primitives. This defeats the idea of a "perfect model", but gets the "real world" work done.


A lazy answer to your two questions would be : ABSE is not UML neither MDA, and has nothing to do with these approaches, so direct comparisons are not easy to be made.

More elaborate answers could be:

1 - An Atom is a "concept", a free mapping from an idea to solution, or from an idea to another idea ...[repeat]... to solution. ABSE does not restrict developers into specific modeling patterns like UML with its diagrams. However, you can create ABSE concepts similar to those found in UML. In that case, exporting to UML would become easier.

2 - Are you talking about PIM/PSM? In ABSE Atoms themselves can be platform-specific or platform-independent (remember, Atom = concept). Atom Templates can be inherited and composed. With these two mechanisms you can build as many intermediate layers as you need. You get a good identification of these layers if you correctly group these Atoms into Atom Libraries. For instance, in my AtomWeaver model I have 17 Atom Libraries that form around 6 abstraction layers. Well, it's not a very good example to this discussion because all these libraries are on the solution domain. Still, that makes 6-layer separation in the solution domain, where one or more of these layers can be replaced by an equivalent solution...

RSS

Badge

Loading…

© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service