12 Jul
2011
12 Jul
'11
11:17 p.m.
On Tue, Jul 12, 2011 at 5:51 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi Usman,
On 12 Jul 2011, at 16:38, Usman Bhatti wrote:
Here you can find some code snippets but todays task was more of a
reflective effort to understand and assess things to implement in Moose.
Gofer new
squeaksource: 'DelaunayTmpStuffs';
package: 'ADLFamix';
load.
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.
What is of interest here is to see how the following scenario can be
implemented with such an ADL:
•only A can-create B: only classes declared in module A can create objects
of classes declared in
module B.
For the above scenario, we can construct two modules according to user
specification (can represent 2 groups of packages or classes). So, modules
are aggregations of Famix (Named?) entities. But the module still remains
independent of any particular Famix abstraction: for example, a module can
represent all class in a package com.example.mine.* or methods in all
classes having a particular name.
Now, I am not sure if Andy's rule engine would be useful, but we've found
that Moose API can be sufficient for describing rules and Arki for
specifying the above-mentioned scenario and checking it.
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.
MooseGroup is only used to specify famix entities encapsulated inside a
module. Now, we need to turn our attention to other entities in an ADL
(connectors and rules) so that the ADL remains generic and doesn't get tied
to the task of rule checking.
thanx
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."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev