12 Jul
2011
12 Jul
'11
4:38 p.m.
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).
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
12 Jul
12 Jul
5:51 p.m.
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."
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
13 Jul
13 Jul
10:11 a.m.
One idea would be to create some small language where one can:
- define "modules": a module is a group of something (MouseGroup). Modules could
be defined from name patterns (e.g. "Test*") ; scope membership
(org.eclipse.core.*) ; entity type (Methods, Class, ...) ; ...
- define relationship between modules: the 4 Famix relationships spring to mind (Access,
Invocation, Inheritance, Reference) + possibly a generic Dependency (union of the 4). One
could also think about intermediate generalization (e.g. TypeAccess=Inheritance+Reference
; MemberAccess=Access+Invocation ; ...) or more specialized relationship (e.g.
implements=inheritance of interface ; extends=inheritance of class ; ...)
- define rules on modules and relationship: logical expressions on relationship between
modules (e.g. "only M1 can-invoke M2": only methods of module M1 can invoke
methods of module M2)
We would rather not implement all this, because it can go very far.
For example, there are people here working on matching a FeatureModel to an existing
system to transform it into a Software Product Line.
This could possibly be handle by this language with arki behind checking the rules ...
So our line of thought was: What is the smallest amount of effort we can spend to have
something usable and extensible ?
The next step after that could be to be able to change the description of a given
architecture and have a tool showing us how to implement it in the source code and helping
us to do it ...
nicolas
----- Mail original -----
De: "Usman Bhatti" <usman.bhatti(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Juillet 2011 23:17:15
Objet: [Moose-dev] Re: Famix ADL
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:
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?
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.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:37 p.m.
Hi,
Having a language would be nice, but there are already many things you can do reasonably
with the collection protocol + the FAMIX API.
Take the example of looking for the namespaces matching a certain name pattern (*uml*)
that are not allowed to invoke namespaces matching another pattern (*ui*). The script
below does that (usable in an Arki report):
| some |
some := self allNamespaces select: [:each | '*:uml:*' match: each name].
some select: [:eachSource |
eachSource invokedNamespaces anySatisfy: [:eachTarget |
'*:ui:*' match: eachTarget name ]]
It's not quite elegant, but it works reasonably well for a pragmatic checking. As we
notice repetitive queries, we can create shortcuts for them.
Cheers,
Doru
On 13 Jul 2011, at 10:11, Nicolas Anquetil wrote:
One idea would be to create some small language where one can:
- define "modules": a module is a group of something (MouseGroup). Modules
could be defined from name patterns (e.g. "Test*") ; scope membership
(org.eclipse.core.*) ; entity type (Methods, Class, ...) ; ...
- define relationship between modules: the 4 Famix relationships spring to mind (Access,
Invocation, Inheritance, Reference) + possibly a generic Dependency (union of the 4). One
could also think about intermediate generalization (e.g. TypeAccess=Inheritance+Reference
; MemberAccess=Access+Invocation ; ...) or more specialized relationship (e.g.
implements=inheritance of interface ; extends=inheritance of class ; ...)
- define rules on modules and relationship: logical expressions on relationship between
modules (e.g. "only M1 can-invoke M2": only methods of module M1 can invoke
methods of module M2)
We would rather not implement all this, because it can go very far.
For example, there are people here working on matching a FeatureModel to an existing
system to transform it into a Software Product Line.
This could possibly be handle by this language with arki behind checking the rules ...
So our line of thought was: What is the smallest amount of effort we can spend to have
something usable and extensible ?
The next step after that could be to be able to change the description of a given
architecture and have a tool showing us how to implement it in the source code and helping
us to do it ...
nicolas
De: "Usman Bhatti" <usman.bhatti(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Juillet 2011 23:17:15
Objet: [Moose-dev] Re: Famix ADL
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:
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
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?
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.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
16 Jul
16 Jul
12:20 p.m.
On Wed, Jul 13, 2011 at 7:37 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
Having a language would be nice, but there are already many things you can
do reasonably with the collection protocol + the FAMIX API.
Take the example of looking for the namespaces matching a certain name
pattern (*uml*) that are not allowed to invoke namespaces matching another
pattern (*ui*). The script below does that (usable in an Arki report):
| some |
some := self allNamespaces select: [:each | '*:uml:*' match: each name].
some select: [:eachSource |
eachSource invokedNamespaces anySatisfy: [:eachTarget |
'*:ui:*' match: eachTarget name ]]
It's not quite elegant, but it works reasonably well for a pragmatic
checking. As we notice repetitive queries, we can create shortcuts for them.
The idea of FamixADL would be to reduce the above expression to (something
like):
module UML: self allNamespaces select: [:each | '*:uml:*' match: each name].
module UI: self allNamespaces select: [:each | '*:ui:*' match: each name].
cannot-call: select: [:eachSource | eachSource invokedNamespaces anySatisfy
]
cannot-access: another rule
and then finally, we specify:
UML UI cannot-call
UML UI cannot-access
...
Because, we can have multiple modules and multiple rules...
Cheers,
Doru
On 13 Jul 2011, at 10:11, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
One idea would be to create some small language where one can:
- define "modules": a module is a group of something (MouseGroup).
Modules could be defined from name patterns (e.g. "Test*") ; scope
membership (org.eclipse.core.*) ; entity type (Methods, Class, ...) ; ...
- define relationship between modules: the 4 Famix relationships spring
to mind
(Access, Invocation, Inheritance, Reference) + possibly a generic
Dependency (union of the 4). One could also think about intermediate
generalization (e.g. TypeAccess=Inheritance+Reference ;
MemberAccess=Access+Invocation ; ...) or more specialized relationship (e.g.
implements=inheritance of interface ; extends=inheritance of class ; ...)
- define rules on modules and relationship: logical expressions on
relationship
between modules (e.g. "only M1 can-invoke M2": only methods of
module M1 can invoke methods of module M2)
We would rather not implement all this, because it can go very far.
For example, there are people here working on matching a FeatureModel to
an
existing system to transform it into a Software Product Line.
This could possibly be handle by this language
with arki behind checking
the rules ...
So our line of thought was: What is the smallest amount of effort we can
spend to
have something usable and extensible ?
The next step after that could be to be able to change the description of
a given
architecture and have a tool showing us how to implement it in the
source code and helping us to do it ...
nicolas
De: "Usman Bhatti" <usman.bhatti(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Juillet 2011 23:17:15
Objet: [Moose-dev] Re: Famix ADL
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:
> 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?
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.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4908
days inactive
4912
days old
5 comments
3 participants
participants (3)
-
Nicolas Anquetil -
Tudor Girba -
Usman Bhatti