You might try looking at some of the classic Design Patterns, your problem could be solved (possibly) by any number of them. For instance, several of the Structural patterns might do the trick:

• The Adaptor Pattern

  Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

• The Facade Pattern

  Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

• The Proxy Pattern

  Provide a surrogate or placeholder for another object to control access to it

Or possibly even these more Behavioral patterns:

• The Command Pattern

  Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

• The Mediator Pattern

  Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

NOTE: these links are to a C# specific site, but the UML they show and the patterns they describe are langauge independent.

In my current project, I have solved something similar by using the Mediator pattern (and a little bit of the Command pattern as well). I have a number of Report classes, each which takes a Calculation class, a Graphing class and a Request (which is where the Command pattern comes in) and then makes various calls to the Calculation modules with data in the Request, and then feeds the results to the Graphing class and then returns its output.

This allows me not only to vary the interactions of the Calculation and Graphing modules (similar maybe to your DataManager and Report), but also to re-use a my Calculation classes in a number of different situations, as well as easily allow me to add, modify and subclass my Graphing modules.