[Moose-dev] Re: Accesses and invocations example

[Stéphane Ducasse]

On 15 juin 07, at 17:53, Usman Bhatti wrote:

> Hi,
>
> I was just starting to compute invocations and access information  
> for my methods and attributes. Could someone provide an examplary  
> file for this purpose or could point to a possible explanation? I  
> am just looking at the meta model present on the web site but  
> couldn't understand enough to start my implementation.

An access represents the fact that a method accesses a given attribute
	accessedIn = method
	accesses = attribute/field

> Do I make one entry for each invocation and access?

Yes
taken from http://smallwiki.unibe.ch/moose/lansamplemodel/? 
action=MimeView




(FAMIX.Access (id: 336)
			(accessedIn (idref: 28))
			(accesses (idref: 5))
			(readWriteAccess true)
			(stub false))

An invocation
	receivingVariable is the receiver
	candidate is the possible list of methods that could be invoked
	invokedBy is the method in which the message send is performed
	invokes is the name of the message

	in the past there were also the receiving class and the baseclass?
	Doru do they still used?

(FAMIX.Invocation (id: 2)
			(candidate (idref: 3))
			(invokedBy (idref: 4))
			(invokes 'name:(Object)')
			(receivingVariable (idref: 5))
			(stub false))

>
> Secondly, I would like to know the difference between namepaces and  
> packages as they are seen by MOOSE. Because, as i understand,  
> namespace is an equivalent to a package as far as their different  
> use at the level of programming languages is concerned (Java vs  
> C#). Therefore, my MSE file only contains namespaces but no packages.

In some languages namespaces and packages are different things in  
Smalltalk for example a package does not
have any scope associated with: it is just a container of entity used  
for deployement.
So basically in your case you can map your package to namespace (I do  
not know in C# if this is the same as in java but in Java
namespace . . . does not define nesting of component just naming).
But I may have forgot :)

Stef