Re: [gmt-dev] standards for dependency management in the GMT code base

["Jorn Bettin" <jorn.bettin@xxxxxxxxxxxxxxxx>]

> First of all, if this has to be THE standard for GMT dependency
management,
> then it has to be placed on www.eclipse.org/gmt, or possibly on
> www.mdsd.info, but not exclusively on the SoftMetaWare site.

It's a suggestion for GMT . If I write software, those are the principles
that I use, so that's how it ends up on the SoftMetaWare site. The result is
component based code. Many other people use the same or very similar
techniques to componentise software. What's the big deal?

You may choose not to adopt such principles for FUUT-je. The question then
is who will want to evolve and maintain FUUT-je...

> Second of all, if this has to be a standard for our contributors to adhere
> to, it should be readable by us as a standalone document. Well, of course,
> we assume general litteracy on the subject of MDA and related concepts :-)
> This does not include KobrA or Product Line Engineering or Bertrand Meyers
> book. So, what are: commands, basic queries, derived queries and objects
in
> the context of component specification? I truly do not know and this is
> important. I was almost fired once because of a discussion about "view"s,
> where my view was a database view and my opponents view was an MVC view.

I don't want to write another book just now ;-) That's why I provide
references. In the agile spirit, I'm actually trying *not* to write too
much, and to avoid "write-only" documentation. Maybe in the next version
I'll quote some more design by contract fundamentals.

> Third question, what should the component specification look like in
> practice for example for Fuut-je, and more important, for applications
being
> developed with Fuut-je. There is never a 1-1 relationship between model
item
> and implemented item. The interfaces for the implementation are generated
> and not specified. This would mean that the model, together with the
> generation rules are the specification (this is of course very true). This
> also means that we should find a way to generate the interface
specification
> in a way that is consistent with your standard (extra work, extra
templates)
> or find a better way to externalize the rules than looking at a template
> implementation.

The concept of fully externalised interfaces applies to the hand-crafted
code of a reference application and. From there you abstract a suitable
model + meta model and template code.  The model from which you'd like to
generate would of course only consist of component specifications and their
structure (how they relate to each other, and which components need to
implement the specifications).

> My reaction to examples containing Foo and Bar is always that this theory
> could not be rooted in practice, and that I would start trying to
understand
> it if it is changed to a nuts and bolts, order and products, or a students
> and courses example. My reaction to "cool stuff" is similar. I do not
think
> we want to associate ourselves with a nerdy environment. Please make a
real
> example out of it!

In Craig's book you'll find an example with a ShoppingCart. My day only has
24 h...
If I have time I'll produce the variant with Customer, Product etc. That's
our example anyway, right?

> I have also a serious question. Assume that we are going to use Apache, or
> worse, Shark, as an open source component. Is it then our responsibility
to
> externalize a component specification in our standardized way for this
piece
> of open source software? I think not. We can also not ask the authors of
the
> open source software to do that.

Agree.

However, external software is (should?;-) typically only accessed by one or
a few components of a client IF you want to achieve loose coupling. These
components should act as a wrapper/boundary around the "foreign" software,
so that you again end up with limited dependent-type-sets. The alternative
is strong coupling and the resulting issues. For some "friendly" components
with a small set of types you may choose not to worry. But as you know, many
pieces of software contain an anthill of types, and it's good practice to
just have one well-controlled interface with such an anthill, so that only
selected ants are allowed through.

> It may be a very considerable piece of work
> though and an essential piece in the externalized component specification.

That work can be a very worthwhile investment to avoid a maintenance
nightmare.

> Is this a stumbling block for using open source software? Actually I think
> it is.

See the document for my thoughts on that ;-)

Jorn

Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534