[cme-dev] Adding to the definition of concerns on the code level

[Juri Memmert <memmert@xxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I've been tinkering with adding additional information to the definition
of concerns for Java code.

What I envision is this:
If I have a class Cl1 that belongs to concern C1 and Cl1 directly
manipulates a field F of class Cl2 (which is part of concern C2), it is
quite probable that the field F is also part of concern C1.
Any access to any method M in C2 which allows Cl1 to write F signifies
that M and F are part of C1.

Example:
public class Cl1
{
	// Assume the fields are set somewhere in the class
	private Object theObject;
	private Cl2;
	...
	public void test1()
	{
		cl2.doSomething(theObject);
	}
	public void test2()
	{
		cl2.theObject = theObject;
	}
}
public class Cl2
{
	// Assume the fields are set somewhere in the class
	public Object theObject;
	...
	public void doSomething(Object anObject)
	{
		theObject = anObject;
	}
}


Furthermore, all methods that are called from Cl1 and in the end set
data from within Cl1 in one of their own fields also might be part of C1.

Example:
public class Cl1
{
	// Assume the fields are set somewhere in the class
	private ParameterObject theParameterObject;
	private Cl2;
	...
	public void test1()
	{
		cl2.doSomething(theParameterObject);
	}
}
public class Cl2
{
	// Assume the fields are set somewhere in the class
	public Object theObject;
	...
	public void doSomething(ParameterObject aParameterObject)
	{
		theObject = aParameterObject.getObject();
	}
}
public class ParameterObject
{
	// Assume the fields are set somewhere in the class
	private Object theObject;

	// Assume getters and setters
}

The same goes for methods within Cl2 that set data on the ParameterObject.

The same does NOT necessarily apply if the following scenario occurs. It
might, but it doesn't have to:
public class Cl2
{
	...
	public void doSomething(ParameterObject aParameterObject)
	{
		if (aParameterObject.getObject() != null)
		{
			// Do something to the internal state of Cl2
		}
	}
}


I do not think that we can capture all these cases in the CME right now
in a convenient manner, and, from what I have seen, definitely not
automatically for a large body of code.
I would welcome this functionality because it handles a few use cases I
need to do adequate modeling / representation of concerns, so I will
implement something to identify this in any case...
I would like to know whether you think this should be part of the query
engine or whether you'd like this to be a separate piece of functionality.
Furthermore, I'd like to know whether you have use cases for this kind
of functionality.

To give you an impression of what I would want to do with it:
- - When identifying a concern in the code, it often is the case that the
queries that I can come up with are too limited since there are
scenarios like the ones mentioned above that I haven't captured. Thus
concern definitions remain unclear.
- - When discussing how to implement a new feature, I would like to
identify the impact of change with reasonable accuracy. If I know how
far into the existing application I have to go to find all places a
certain set of fields is manipulated indirectly, this is much easier.
- - When I want to extract a feature from an existing body of code, the
methods that match the scenarios above are no always the methods that,
through declarative completeness, would be abstract, but several steps
removed from that. I would like to know about them and possibly include
them, or at least look at them to understand how the manipulation is
performed.



	Juri

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCc5wedlXiXRccbPMRArDKAJ48JsQPt4tLw+RCZbNeUfSQWSQDcwCgvqrT
jt9+4q7TLBVoDgX+3yg7K0M=
=+sL2
-----END PGP SIGNATURE-----