Hi Usman,
On 12 Jul 2011, at 16:38, Usman Bhatti wrote:
Hi all,
We are working to develop an Architecture Description Language (ADL) in Moose. The
objective of the development is to define a language that allows to specify different
components of an architecture so that these entities can be manipulated directly
(analysis, visualization, etc). The architecture definition will be used to check rule
conformance, for example. However, we would not want to restrict ourselves to any
particular usage of the ADL.
Today, we have implemented a preliminary version of ADLFamix by implementing modules that
actually contain MooseGroups. Based on these modules, we can now write Arki queries for
rule-checkling, for example. Now, we are contemplating about the next step because
different people implement different things in an ADL. Some describe rules that specify
connectors that can exist between modules. However, this approach ties connectors to rules
and we cannot define a connector without any rules associated. Connectors can be defined
separately or these can also be inferred from Famix associations of the Famix entities
contained in modules. Also, rules can be built into modules so that each one has its own
repository (however, it is not always possible to associate a rule to any particular
module).
Do you have code snippets?
Btw, I worked with Andy Kellens a while ago on getting Soul to work with Moose / Pharo. We
got pretty far and got a prototype working, but it did not get any further. Perhaps it
would be an interesting thing to look into this, because then we get the reasoning
mechanism for free.
In any case, you do not want your ADL to have anything to do with FAMIX. It should define
constraints based on any input objects. Maybe I did not understand what you are doing, but
why do you need MooseGroups? These are specific to Moose, but you should not necessarily
need them for describing your constraints.
Cheers,
Doru
The purpose of the mail is to get feedback from the
people on the group about an ADL in Moose and its features. We are thinking in terms of,
but not limited to:
1) fundamental features (modules, connectors, rules, ??)
2) objectives: rule checking, architecture inference (e.g. reconstructing plug-ins from
java models in moose), ??
3) ??
thanx
Moosecians @ RMod
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"It's not how it is, it is how we see it."