<< October 2010 | Home | December 2010 >>

DCI and Services (EJB)

Data, Context and Interaction (DCI) is a way to improve the readability of object oriented code. But it has nothing specific to say about things like transactions, security, resources, concurrency, scalability, reliability, or other such concerns.

Services, in terms of stateless EJBs or Spring Services, have a lot to say about such concerns, and indeed allow the cross-cutting concerns like transactions and security to be configured outside of the code using annotations or deployment descriptors (XML configuration), letting programmers concentrate on business code. The code they write contains very little code related to transactions or security. The other concerns are handled by the container in which the services live.

Services however, constrain developers to think in terms of higher order objects which deliver functionality. Object orientation (OO) and DCI let programmers program in terms of objects; DCI more so than OO. In those cases where the programmer wants to have objects with behaviour, rather than passing the object to a service, they can use DCI.

If objects are to provide rich behaviour (ie. behaviour which relies on security, transactions or resources), then they need to somehow be combined with services, which naturally do this and do it with the help of a container, so that the programmer does not need to write low level boiler plate code, for example to start and commit transactions.

The idea here, is to explore combining a service solution with a DCI solution. Comparing SOA to DCI, like I did in my white paper, shows that the DCI context is analagous to the code which calls a service in a SOA solution, and that a context does not really explicitly exist in a SOA solution. However, thinking a little more abstractly, in DCI an encapsulation of behaviour would be the context together with its roles. In SOA, this encapsulation is the service itself. So it is possible to realign the ideas in that white paper, to think of a context as being a service. If the goal is to create a hybrid between services and DCI, so that all of the concerns listed at the start of this article get handled by a hybrid solution, then the roles still exist as they do in DCI, but the context becomes a "service" in the technical sense.

Time for an example. Imagine a train company which owns electrified tracks along which trains run. They have a business partner who provides the electrical energy, who is offering cheaper energy to consumers who can forecast their energy consumption so that the partner can make their production more efficient. To deliver these forecasts, the train company checks the timetable for regular passenger transport, as well as all its cargo contracts for bespoke cargo trips. This allows them to simulate all train trips for a given time period and calcuate the energy requirement. Now, the company is a national one, and has thousands of kilometers of track and hundreds of trains running. They have created detailed maps of the terrain over which their tracks run, so they know the uphill and downhill segments and their power consumption changes. They want to build some simulation software to handle the forecasting. At the same time, there is a non-functional requirement to complete calculations extremely quickly, so rather than making them sequential, a parallel solution is required. Here is the proposed object model:

  • Trip: Consists of a Train and a list of TripSegments.
  • Train: consists of a list of Locomotives, and a list of Wagons. The assembly of a train comes from the Timetable.
  • Locomotive: Has an efficiency, a weight and rolling friction factor.
  • Wagon: has a weight and rolling friction factor.
  • TripSegment: has a Segment, and the average speed along which the Train will travel on that segment, during its trip.
  • Segment: a stretch of track, which has a length, positive hill climbs and negative hill decents. Has a starting station and an end station, which are not relevant to the energy calculations - it is the distance which counts.
  • Timetable: a service which provides all Trips for a given time period.


In order to make each trip be calculated in parallel, I have chosen to use a feature of EJB whereby the container creates a new thread and does the calculation on that thread. It means with a simple annotation on a method, I have almost no boiler plate code to write! In order to use that annotation, my context needs to be an EJB, but seeing as the application is running in an enterprise Java application server anyway (so that I can for example have a nice website as a front end), this is no big deal.

So, the architecture of this solutions is: a web request to run the calculation is received which makes a call to my process layer (aka application layer). The process layer calls the timetable to get all trips for the requested period, and for each trip it calls the context to do a calculation in parallel. The process layer waits for all calculations to complete and returns the result to the web layer to present the results to the user. Here is the context:


@Stateless
@Context
public class ForecastingContext implements ForecastingContextLocal {

	/**
	 * an asynchrounous method for determining the energy requirements of the given trip.
	 */
	@Asynchronous
    public Future forecastEnergyRequired(Trip trip) {

		BehaviourInjector bi = new BehaviourInjector(this);
		
		//the context simply casts objects into roles, and starts the interaction
		EnergyConciousTrip t = bi.assignRole(trip, EnergyConciousTrip.class);
		double energy = t.forecastEnergyRequirements();
		
		return new AsyncResult(energy);
    }
}

The context does nothing special, apart from contain the @Asynchronous annotation which tells the container that calls to this method need to occur on a new thread. Unlike perhaps more standard DCI, this context has no constructor which takes objects which will play roles, rather the interaction method "forecastEnergyRequired" is passed the object which gets cast into a role. The reason is that I have no control over the instantiation of the context, because it is an EJB, meaning that the container does the instantiation for me!. I have not sub-classed BehaviourInjector (which is an option in my framework), because stateless EJBs can be called by multiple threads at the same time, and BehaviourInjector is not thread safe.

Here are the two roles:


/**
 * this role is played by a trip so that it is able to 
 * give a prediction about how much energy will be 
 * needed to undertake the trip.
 */
@Role(contextClass=ForecastingContext.class, 
		implementationClass=EnergyConciousTrip.EnergyConciousTripImpl.class)
public interface EnergyConciousTrip {

	double forecastEnergyRequirements(); //role
	List getTripSegments(); //data
	Train getTrain(); //data
	
	static class EnergyConciousTripImpl{ //role implementation
		
		@CurrentContext
		private IContext ctx;
		
		@Self
		private EnergyConciousTrip self;

		/**
		 * energy consists of a longitudinal component (ie along the track due to 
		 * aerodynamic forces and rolling resistance) as well as altidudal component
		 * (ie due to climbing or descending).
		 * 
		 * E = mgh //ie potential energy for climbing / descending
		 * E = Fd  //ie energy required to overcome resistive forces
		 */
		public double forecastEnergyRequirements(){
			
			//give the train some scientific behaviour and determine
			//its total weight and average efficiency
			ScientificTrain train = ctx.assignRole(self.getTrain(), ScientificTrain.class);
			double totalWeight = train.getTotalWeightKg();
			double avgEff = train.getAverageEfficiency();
			
			//add up all energy per segment
			double energy = 0.0;
			for(TripSegment seg : self.getTripSegments()){
				
				double segmentEnergy = train.getResistanceForce(seg.getSpeed()) * seg.getSegment().getLengthMeters();
				
				segmentEnergy += totalWeight * seg.getSegment().getAltitudeChange();
				
				//each locomotive can pull, but has an efficiency which needs to be factored in!
				//it needs more energy than just pulling wagons, because its inefficient
				segmentEnergy /= avgEff;
				
				energy += segmentEnergy;
			}
			
			return energy;
		}
	}
}


/**
 * played by a train, when it needs to provide scientific details about itself.
 */
@Role(contextClass=ForecastingContext.class,
		implementationClass=ScientificTrain.ScientificTrainImpl.class)
public interface ScientificTrain {

	double getResistanceForce(double speed); //role
	int getTotalWeightKg(); //role
	double getAverageEfficiency(); //role
	List getWagons(); //data 
	List getLocomotives(); //data
	double getDragCoefficient(); //data
	
	static class ScientificTrainImpl { //role impl

		@Self
		private ScientificTrain self;

		/** 
		 * resistance force is the rolling friction as a 
		 * result of weight, as well as aerodyamic drag.
		 */
		public double getResistanceForce(double speed){
			double resistanceForce = 0.0;
			for(Wagon w : self.getWagons()){
				resistanceForce += w.getWeightKg() * w.getRollingFriction();
			}
			for(Locomotive l : self.getLocomotives()){
				resistanceForce += l.getWeightKg() * l.getRollingFriction();
			}
			
			resistanceForce += speed * speed * self.getDragCoefficient();
			
			return resistanceForce;
		}

		/** total weight of wagons and locs. */
		public int getTotalWeightKg(){
			int weight = 0;
			for(Wagon w : self.getWagons()){
				weight += w.getWeightKg();
			}
			for(Locomotive l : self.getLocomotives()){
				weight += l.getWeightKg();
			}
			return weight;
		}

		/** average of all locs in the train */
		public double getAverageEfficiency(){
			double avg = 0.0;
			for(Locomotive l : self.getLocomotives()){
				avg += l.getEfficiency();
			}
			return avg / self.getLocomotives().size();
		}
	}	
}

There is nothing fancy in these roles - simply the engineering calculations to work out the energy requirements. I have chosen to implement the role implementations inside the role interface, but there is no reason the role implementations could not exist in their own classes.

Finally, here is the process layer:


@Stateless
public class EnergyForecastingService implements EnergyForecastingServiceLocal {

	@EJB
	private TimetableLocal timetable;

	@EJB
	private ForecastingContextLocal forecastingContext;
	
	@Override
	public EnergyRequirementResult forecast() throws InterruptedException, ExecutionException {
		
		long start = System.nanoTime();
		List> results = new ArrayList>();
		EnergyRequirementResult result = new EnergyRequirementResult();
		result.setTrips(timetable.getTripsForPeriod(null, null));
		for(Trip trip : result.getTrips()){
			//start it in a parallel thread
			//it will be simulated using a DCI context...
			Future e = forecastingContext.forecastEnergyRequired(trip);
			results.add(e);
		}
		
		//ok, all started, lets wait until all are done...
		result.setEnergyRequirement(waitForResults(results));
		result.setCalculationTimeNs(System.nanoTime() - start);
		
		return result;
	}

	private double waitForResults(List> results) throws InterruptedException, ExecutionException {
		double energyRequired = 0.0;
		while(!results.isEmpty()){
			List> assimilated = new ArrayList>();
			for(Future result : results){
				if(result.isDone()){
					assimilated.add(result);
					energyRequired += result.get().doubleValue();
				}
			}
			results.removeAll(assimilated);
			
			//lets give CPU time to other threads while we wait...
			Thread.sleep(5L);
		}
		
		return energyRequired;
	}
}

The process layer uses these funny "Future" objects which allow it to not only get the result from a calculation which has run on another thread, but also to query whether that thread has completed or is still running. The only boiler plate code needed to handle this multi-threaded code is analysis of results while waiting for them all to complete.

The context and its roles look like this:



One interesting side point, is that the EnergyRequirementResult is a class in the context's package (namespace), because it only makes sense to create it from the context. It can be used outside of the context as a read only object to read the results, but it is strongly coupled to the context. It doesn't really make sense for it to exist without the context, and thinking in terms of components, or code re-use, it makes sense to place it in the same namespace as the context. The context and its roles, are afterall a component which can calculate energy requirements - they encapsulate the behaviour to do this.

It might look strange that the behaviour is not simply added to the train and trip objects. But it's hard to see the benefits when looking at such a small project. Imagine a huge project where the object model is much more complex, and there are many many more use cases. If you look at the object model in this example, the train and timetable can be used in many more applications than just one which does energy predictions. Typically within an enterprise, we keep rebuilding similar object models with relevant parts of data, and differing behaviours for each OO solution. DCI lets you build a large single object model, with behaviours constrained to the contexts in which they are relevant. This allows the data model to become sufficiently complex to make it usable within the entire enterprise, but not so overly complex that making changes to it breaks it. Of course it is also arguable, that things like drag coefficients and rolling friction coefficients have no place in an object model of an application related to passenger load planning or whatever else the enterprise needs to do. In terms of making applications flexible to change, it can help if each application has its own object model, even if it results in code duplication within the enterprise.

In this example I have turned my context into an EJB, because I want to take advantage of boilerplate code which the container can handle for me - in this case concurrent computing. Similarly, if my context needs resources, transactions, security, etc, I would use an EJB for my context, and pass the resources which the container injects into it, into the roles using my BehaviourInjector framework (see its documentation for details). I have solved the banking example used in many DCI articles, by making the contexts EJBs, letting the container handle transactions, and getting hold of the EntityManager (for interacting with the database) by letting the container inject it into the context, which the BehaviourInjector can in turn inject into roles.

If contexts are to be "services" in the technical sense, it also makes sense for an enterprise to build a context repository to sit along side their service repository. These are places for software people to look, when needing to see if problems they face have already been solved. Just as we have tools for searching service repositories and we create documents to list all our services, we will need to do the same for contexts, if DCI is to really be adopted by the enterprise world.

It's important to remember that you could build this solution with pure services, or pure OO. DCI is simply another, and valid way of solving the problem, which concentrates on separating the behaviour from the data in order to make the code more reviewable, while at the same time remaining object oriented, so that the model which the users and customers have, stays similar to that which the programmer uses. Is creating roles and injecting behaviour into the Train and Trip objects better than putting those methods into a service which does the same thing? I don't know... It is certainly less OO, but is that a bad thing? Perhaps its just down to designers choice and feeling comfortable with the resulting code. So long as reading the solution compares to the users and customers stories, that is the important thing. Mappings between the users/customers world, and the programmers world are unnecessary and cause bugs as well as unsatisfactory users, because the programmer concentrates on solving his problems, rather than the business' problems.

You can download all the source code for this train app from here.

PS. I have no idea if train companies need to forecast energy requirements, or even if they work with energy partners. The creativity of this blog article should not hamper the readers understanding of how to create a service/DCI hybrid, in order to benefit from the way a container handles the concerns listed at the start of this article!

© 2010 Ant Kutschera

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!

DCI Plugin for Eclipse

The Data, Context, and Interaction (DCI) architecture paradigm introduces the idea of thinking in terms of roles and contexts. See some of my white papers for a more detailed introduction into DCI, but for this blog article, consider the following example: a human could be modelled in object oriented programming by creating a super huge massive class which encapsulates all a humans attributes, their behaviours, etc. You would probably end up with something much too complex to be really maintainable. Think about when a human becomes a clown for a kids party; most of that behaviour has little to do with being a programmer, which is a different role which the human could play.

So, DCI looks at the problem differently than OOP and solves it by letting the data class be good at being a data class, and putting the behaviours specific to certain roles into "roles", which in my DCI Tools for Java library are classes.

Certain roles interact with each other within a given context, such as a clown entertaining kids at a birthday party. The roles which belong to an interaction are part of the context, and in DCI the context is a class which puts data objects into specific roles, and makes them interact. The context and its roles form the encapsulation of the behaviour.

I have updated my library, so that there are two new Annotations, namely the @Context and @Role annotations. The @Context annotation is simply a marker to show that a class is a context. The @Role annotation is more important. It is placed onto the role interface class and tells the context where to find the role implementation, and additionally requires that the programmer specifically state to which context the role belongs.

The code ends up looking looking as follows. First a unit test which creates and calls the context:


    @Test
    public void testExecute() {
    	
    	//create an adult (the clown) and some children, 
    	//and let the party start...
        
    	Human adult = new Human();
        List children = new ArrayList();
Human child = new Human();
child.setName("Johnny");
children.add(child);
child = new Human();
child.setName("Jane");
children.add(child);

ClownContext cc = new ClownContext(adult, children.toArray());
cc.startParty();

//check the party went well...
assertEquals(0, adult.getHappiness());
for (Human c : children) {
assertEquals(1, c.getHappiness());
}
}
}


There is nothing special about the code above. It simply creates some data objects and passes them to the context, and then starts the party (the interaction, or use case). Next, the context class is shown:


/** the context in which a clown entertains some kids. */
@Context
public class ClownContext extends BehaviourInjector {

    /** the object who will play the clown role */
    private Object adult;
    
    /** the objects who will play the kid role */
    private List children;

/**
* Creates a new Context object. takes "objects" rather than specific types to allow it to be reusable.
*/
public ClownContext(Object adult, Object[] children) {
this.adult = adult;

this.children = new ArrayList();

for (Object child : children) {
this.children.add(child);
}
}

/** start the interaction */
public void startParty() {
Clown clown = assignRole(adult, Clown.class);

clown.applyMakeup();

IIterable kids = getIterable(children.iterator(), Kid.class);

clown.makeKidsLaugh(kids);
}

}


The context has a few noteworthy points. First of all, it extends the BehaviourInjector. By doing this, it has access to the assignRole(Object, Class) and getIterable(Iterator, Class) methods. Note the @Context annotation at the top - it's important for not only helping the programmer spot that it's a context, but also for the Eclipse plugin which I created and which I introduce below.

You might have spotted that the context above is not tightly coupled with the Human class. The reason is simply to make the context and its roles usable in the future, with data classes which I currently know nothing about. It is feasible that a robot might one day do parties by dressing up as a clown!

Assigning the role is where the behaviour is "injected" into the data object. The iterable which is created is a special role, which can automatically cast the human children into the role of a kid attending a party.

Next, take a look at the role interface. This class defines the methods which data object must have to play the role, as well as the behaviour which will be added to the object.


@Role(contextClass = ClownContext.class, 
	  implementationClass = ClownImpl.class)
public interface Clown {

	/** put some makeup on (initialise) */
	public void applyMakeup(); // role

	/** makes kids laugh */
	public void makeKidsLaugh(IIterable kids); // role

public void setHairColour(Color c); // data

}


The role interface has the @Role annotation which tells the behaviour injector firstly to which context the role belongs, and secondly where the actual implementation (behaviour) can be found. In the clown role specified above, two behaviours are added (applying make up and making kids laugh). The application of make up additionally requires that the clown be able to set his hair colour, so that method which the human class must have is also specified here.

Finally, the role implementation class:


public class ClownImpl {

	@Self
	private Clown self;
	
	/** @see Clown#applyMakeup() */
	public void applyMakeup(){
		self.setHairColour(Color.GREEN);
	}

	/** @see Clown#makeKidsLaugh(IIterable) */
	public void makeKidsLaugh(IIterable kids) {
for (Kid kid : kids) {
kid.laugh();
System.out.println();
}
}
}


The role implementation does not need to implement the role interface! It is simply a class which the behaviour injector relies upon to find behaviour which it cannot find in the data object. The @Self annotation on the clown field called self is a reference to the object playing the clown role, and is similar to "this", just that "this" would be a reference to the instance of the role implementation, rather than the object playing the role. It allows you to access the data methods of the data object.

Now, as well as helping the programmer to mentally associate contexts with roles, these two annotations allow static analysis of the code to be performed. Using the Eclipse JDT framework, it is possible to obtain individual tokens of source code, even when the class files don't compile, in order to build up a model of contexts and roles within a Java project. I created a little DCI Outline view for Eclipse, similar to the class outline, except rather than showing classes, it shows the contexts and their associated roles. Here's a screen shot:



The view shows all contexts which it finds in the selected Java project. For each context, it shows the package, followed by a list of its methods, and then all the roles that belong to it.

For each role interface, the package is listed, followed by a list of methods which the role interface contains. At the bottom of a role branch, is the role implementation class.

The idea of this plugin is to give the programmer a view of what contexts are available and what roles they contain. It puts contexts, roles and their methods into the mind of the programmer letting them think in terms of DCI, exactly the same way which a standard class browser lets the programmer think in terms of classes.

Double clicking on a role interface, role implementation or context will open it in the editor.

The plugin has limited validation capabilities and can determine for example, if a context specified in a role annotation cannot be found within the project, and highlights this so that the programmer can see there is a problem. In such cases, the view looks like this:



The code from this example can be downloaded here.

A full instruction manual, together with the the DCI Tools for Java library, and the Eclipse Update site can be found at here.

Attention: No clowns were harmed during the writing of this blog.

© 2010 Ant Kutschera

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!

Dynamic Mock Testing

Have you ever had to create a mock object in which most methods do nothing and are not called, but in others something useful needs to be done?

EasyMock has some newish functionality to let you stub individual methods. But before I had heard about that, I had built a little framework (one base class) for creating mock objects which stubs those methods you want to stub, as well as logging every call made to the classes being mocked.

It works like this: you choose a class which you need to mock, for example a service class called FooService, and you create a new class called FooServiceMock. You make it extend from AbstractMock<T>, where T is the class you are mocking.

As an example:

public class FooServiceMock extends AbstractMock<FooService> {

    public FooServiceMock() {
        super(FooService.class);
    }


It needs to have a constructor to call the super constructor passing the class being mocked too. Perhaps that could be optimised, I don't have too much time right now.

Next, you implement only those methods you expect to be called. For example:

public class FooServiceMock extends AbstractMock<FooService> {

    public FooServiceMock() {
        super(FooService.class);
    }

    /** 
     * this is a method which exists in FooService, 
     * but I want it to do something else.
     */
    public String sayHello(String name){
	    return "Hello " + name + 
              ", Foo here!  This is a stub method!";
    }	


To use the mock, you'll notice that it doesn't extend the class which it mocks, which might be problematic... Well, there are good reasons. To do the mocking, the abstract base class is actually going to create a dynamic proxy which wraps itself behind the interface of the class being mocked. To the caller, it looks like the FooService, but it's not actually anything related to it. Anytime a call to the FooService is made, the first thing which the proxy does is log that call, using XStream to create an XML representation of the parameters being passed into the method. Then, the proxy goes and looks in the instance of the mock class to see if it can find the method being called (well at least a method which takes the same parameters and has the same name and return type). If it finds such a method, it calls it. In our example, the sayHello(String) method would get called. It returns the result if there is one, to the caller.

In the case where it cannot find the method, it throws an exception, because it assumes that if it was not implemented, you didn't expect it to be called. You could of course change this to suit your needs, maybe even calling the actual FooService.

So, how to you use the FooServiceMock to create a FooService instance which you can use to mock your service? In the test, where you setup the class under test, you do this:

    FooServiceMock fooService = new FooServiceMock();
	
    //perhaps tell it about objects you would
    //like it to return...
	
    instanceOfClassUnderTest.setFooService(
                               fooService.getMock());	


The setFooService(FooService) method on the instance of the class you are testing is in my case present, but you might not have it and may need to use reflection to do it. It's a question of how testable you write your classes, and is a design choice.

The getMock() method on the AbstractMock class is the method which creates the dynamic proxy which wraps the instance of the mock.

You can now test the class. There is however still something useful you can do after testing, i.e. assert that the right calls were made in the correct order with the right parameters. You do this in the test class to:

    assertEquals(1, fooService.getCalls().size());
    assertEquals("[sayHello: <String>Ant</String>]", 
	                  fooService.getCalls().toString());


The above tests that the sayHello(String) method was called just once, and passed the name "Ant".

There are times when you might want to clear the call log, between parts of the test. For that, call the clearCalls() method on the mock object:

        fooService.clearCalls();


Finally, here is the code for the AbstractMock, which you might want to tweak, depending upon your needs:


/*  
 * Copyright (c) 2010 Ant Kutschera, maxant
 * 
 * This file is part of Ant Kutschera's blog, 
 * http://blog.maxant.co.uk
 * 
 * This is free software: you can redistribute
 * it and/or modify it under the terms of the
 * Lesser GNU General Public License as published by
 * the Free Software Foundation, either version 3 of
 * the License, or (at your option) any later version.
 * 
 * It is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied
 * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
 * PURPOSE.  See the Lesser GNU General Public License for
 * more details. You should have received a copy of the
 * Lesser GNU General Public License along with the blog.
 * If not, see .
 */
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.util.ArrayList;
import java.util.List;
import com.thoughtworks.xstream.XStream;

/**
 * base class for mocks who need to log their calls.
 *
 * @author   Ant Kutschera
 */
public abstract class AbstractMock {

/**
* xstream is used for creating a serialised xml
* representation of objects
*/
private XStream xstream = new XStream();

/** every call to the class being mocked is logged */
private List calls = new ArrayList();

/**
* the interface which needs to be exposed, ie the
* class of the object being mocked
*/
private Class interfaceClass;

/**
* Creates a new AbstractMock object.
*
* @param interfaceClass the class of the object
* being mocked
*/
public AbstractMock(Class interfaceClass){
this.interfaceClass = interfaceClass;
}

/**
* @return a list of strings, one for each call
* containing the method name followed by each
* parameter as an XML string as created by XStream.
*/
public List getCalls() {
return calls;
}

/**
* resets the list of calls.
*/
public void clearCalls() {
calls.clear();
}

/**
* @return a proxy which wraps the instance, so
* that it can automatically handle
* unimplemented methods.
*/
@SuppressWarnings({ "unchecked", "rawtypes" })
public T getMock() {
ClassLoader classLoader = getClass().getClassLoader();
Class[] interfaces = new Class[] { interfaceClass };
InvocationHandler ih = new InvocationHandler() {

@Override
public Object invoke(Object proxy, Method method,
Object[] args) throws Throwable {

Method m = getMethod(method);

if (m == null) {
//TODO you could change this if you like...
//maybe make it configurable?
throw new RuntimeException("unexpected call to "+
"a method not in the mock: " + method);
} else {
String s = m.getName();
if (args != null) {
for (Object o : args) {
s += ":" + xstream.toXML(o);
}
}

//trim white space between xml tags as well as
//new lines anywhere!
s = s.replaceAll("\r", "").replace("\n", "");
for (int i = 0; i < 10; i++) {
char[] spaces = new char[i * 2];
for (int j = 0; j < spaces.length; j++) {
spaces[j] = ' ';
}
s = s.replaceAll(">" + new String(spaces) +
"<", "><");
}

//log the call...
calls.add(s);

//now call the mock implementation!
return m.invoke(AbstractMock.this, args);
}
}
};

return (T) Proxy.newProxyInstance(classLoader,
interfaces, ih);
}

/**
* the method with the same name/params, if it exists in
* this class, otherwise null.
*/
private Method getMethod(Method method) throws
IllegalAccessException, InvocationTargetException {

for (Method domainObjectMethod :
getClass().getMethods()) {

if (match(method, domainObjectMethod)) {
return domainObjectMethod;
}
}

return null;
}

private static boolean match(Method method1,
Method method2) {
return namesAreEqual(method1, method2)
&& typesAreEqual(method1, method2);
}

private static boolean namesAreEqual(Method method1,
Method method2) {
return method2.getName().equals(method1.getName());
}

private static boolean typesAreEqual(Method method1,
Method method2) {
Class[] types1 = method1.getParameterTypes();
Class[] types2 = method2.getParameterTypes();

if (types1.length != types2.length) {
return false;
}

for (int i = 0; i < types1.length; ++i) {
if (!types1[i].equals(types2[i])) {
return false;
}
}
return true;
}
}


Have fun!
©2010 Ant Kutschera

Tags : , ,
Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!

User Mental Models

I've spent the last 6 weeks looking into an interesting paradigm called Data, Context & Interaction (DCI).

I've written a few introductory papers, and some tools too.

DCI has the following goals:

  • To improve the readability of object-oriented code by giving system behavior first-class status;
  • To cleanly separate code for rapidly changing system behavior (what the system does) from that for slowly changing domain knowledge (what the system is), instead of combining both in one class interface;
  • To help programmers reason about system-level state and behavior instead of only object state and behavior;
  • To support an object style of thinking that is close to peoples' mental models, rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages.

The problem recognised by this paradigm is that system behaviour gets fragmented in traditional OOP, over a large number of classes and sub-classes. The code directly related to a use-case gets fragmented and "lost". The boundaries for the behaviour end up being class boundaries and pieces of behaviour are stuck with the data on which they operate, so that the code has high cohesion. If you want to read the code related to a use-case, you will struggle to extract it and understand it. I agree with these problems, but have not really encountered them personally for a long time, because I do most of my work predominantly in the SOA paradigm.

When I first read these goals and all the articles I could find about DCI, I interpreted them as roughly:

  • Separating system behaviour from data, to give behaviour first class status;
  • Allowing the programmer's mental model to become the same as the user's mental model and hence reduce the number of mappings between programmer's and user's mental models;
  • Making code use-case centric, rather than class- or data-centric;
  • Making code reviewable and having less reliance on testing, by keeping fragments of use-case code physically close so it's not fragmented.

I thought about these interpreted goals hard, because I was convinced that in the applications I help to write, we were achieving them. I questioned the DCI forums at length about why a SOA architecture couldn't achieve these goals. When I say SOA, I don't mean the modern version involving metadata to describe remote interoperable services like Web Services. I mean services, like what people used to write in the early 2000's when EJB stateless session beans first came out. Java classes which were stateless and contained just behaviour. Let's call such service "local services" to distinguish them.

Today around 12pm, I finally understood what the people at the DCI boards meant, when they said that my ideas were not DCI and could not fulfil the DCI goals... The very first DCI goal shown above relates to object oriented code. It does not mean make it more readable by splitting the behaviour out and having dumb data objects used by behaviour which is implemented elsewhere, such as happens with SOA. It really means, letting the code stay object oriented. I found that really stange, that in 2010, people still want to really program in traditional object oriented styles. Let me explain. In a Zoo, you have animals, and they can all "talk" to some extent. So you create a model which uses a super-class "Animal" which has a talk method which each animal class can override. Then maybe you introduce some movement and provide a "walk" method (hmm... snails... guess we need a new level in our inheritance tree to differentiate between walkers and sliders... oh dear our inheritance tree is exploding...).

Fair enough for a zoo. But in software, especially business software, how often do we really model behaviour inside the entity classes? Consider a bank account, and transferring money between two of them. Does the account transfer money from itself to another one, or does "something else" do it? Or think about a complex set of tickets which are related, for example a train ticket, a hotel booking and a ticket to a concert. You could buy these as a discounted package. The package might be just clever enough to give you the price based on adding up the price of its parts, but would you expect the package object to work out the package discount, or would it be the system which works out the discount, and sets it as an attribute on the package object?

In cases where it is something else providing functionality, rather than an entity, we use services. Services meld really well with object oriented data models. The services contain no data, just functionality, and the data model contains data, but no real functionality.

I am sure there are users, business analysts and requirements engineers out there, who think of these behaviours as belonging to objects, rather than the system, but for me, this thinking is wrong. DCI aims to make the programmer's mental model the same as the user's, so now we have a problem, because these user's are not thinking "right". But if you think about it, we don't write software for a single user. We write software for lots and lots of users (I once wrote an app costing nearly a million CHF for 3 users, but that was an exception). How can we ensure that their mental models are the same? And there is usually more than one programmer doing the writing, so how can we ensure their models are also the same? In agile programming, the users, customers, programmers, analysts, architects, business people and all other stake holders get together and talk. During that discussion, it is fine to encourage user's with a "strange" way of looking at the world to think a little differently (it might involve beer, donuts, or threats, but it is possible). To take a users mental model without encouraging them to refine it is dangerous. Typically, software is created to improve the user's life. If you ask a standard computer user with no IT training, to tell you what they want, in my experience it is not usable. We once asked our user's to define the colours of new system which would replace a 20 year old green-screen system. Their input: light green, a bit of dark green. Black text. They had no concept of modern software and what it could do for them or how it might make their lives easier. You are definitely allowed to encourage users to expand on and improve their original mental models.

So what about software which manipulates things on screen, i.e. the UI part? Imagine a word processor. You are typing away and have the feeling that you are on a type writer. You then want to add a picture. To add a picture, the program needs to respond to your click, open a file dialog and show you the files in a directory. You choose a file, click OK, and the picture is read and displayed where the cursor was. You click the "center" button to centre justify the picture. What goes on, in the user's head? What handles each of these inputs? Is it a document which responds to his wanting to insert a picture, or the system? Is it the document which puts the image in the document, or the system? Is it the document which formats the picture to become centred or is it the system? In my world, it is the system which does this, and as such, I can program these things to be part of my MVC controller which handles complex state updates. In my world, the controller would not tell the document to centre the image, but would do so itself. The document object contains the system state and knows where the image is in the document, and that the paragraph has the centred style. But the document does not have the ability to do anything useful itself.

In Eclipse RCP UI programming, clicking a button to load a file is handled as an action; you don't even have the choice of letting your "document" react to the event, unless you are backward thinking and have code in the action which fetches the document from the data model and calls the "insert image" method on it.

I just spent ten minutes getting my wife to open the word processor and describe to me what happens when she inserts an image and left justifies it. My wife is a standard user, who is word processor and browser proficient. When talking about actions and reactions (e.g. clicking the ok button in the file dialog which inserts the picture into the document), she always referred to either her or the system doing the work. If I asked her not to refer to herself, rather an element of the word processor, it was always the system which did the work. If I were programming the word processor, I therefore wouldn't be allowed to attach the behaviour to the button or document, rather the button causes the system to load the file. I could create a class called the system, but for me, a controller which relies on using services to do the work is acceptably close to the user's mental model.

Maybe I am just at an advantage, because I have lived in the service world for so long. Either way, the thing to take away is that local services empower the programmer to have a mental model close to the user's mental model, so that code becomes simpler to maintain. They also let the system behaviour be first class just as data is, and make code more reviewable by allowing it to be use-case-centric, which reduces reliance on testing.

©2010 Ant Kutschera

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!