[Moose-dev] Re: Famix ADL

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: Modules could be defined from name patterns (e.g. "Test*") ; scope membership (org.eclipse.core.*) ; entity type (Methods, Class, ...) ; ... 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 ; ...) relationship between modules (e.g. "only M1 can-invoke M2": only methods of module M1 can invoke methods of module M2) an existing system to transform it into a Software Product Line. the rules ... spend to have something usable and extensible ? a given architecture and have a tool showing us how to implement it in the source code and helping us to do it ... wrote: 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. 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). reflective effort to understand and assess things to implement in Moose. 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. implemented with such an ADL: objects of classes declared in 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. that Moose API can be sufficient for describing rules and Arki for specifying the above-mentioned scenario and checking it. 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. 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. about an ADL in Moose and its features. We are thinking in terms of, but not limited to: reconstructing plug-ins from java models in moose), ?? -- 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