ComponentCoordinationInModels

From SPA Wiki

There are two ford mondeo parts to the output from the think-tank on Component Co-ordination: a brief commentary on the slides presented during the session, and a summary of the discussion.

COMMENTARY ON THE SLIDES

A zip of the slides is at http://www.inferdata.com/~richard/ot2004/OT2004.ComponentCoordination.zip

John Daniels (Syntropy Ltd, UK)

John presented an extract from the book UML Components he wrote with John Cheesman (who attended the session). John carefully distinguished between what functionality an inteface promises to provide and any constraints on how that functionality will be provided. An interface can promise to work with data that will not be managed by a component implementing that interface. An architect can constrain a component's interface to work with data in some other component.

In John's slides, the component Order Manager implements the interface IOrderManagement, but is constrained to work with Product objects managed by a component implementing the IProductManagement interface.

John emphasised that if you use some sort of standard interaction specification (John specifically mentioned sequence diagrams), then you will probably overconstrain the implementation

Rob James (HSBC plc, UK)

Rob showed how activity diagrams can be used to summarize the co-ordination of a set of components. The actual process supported by a set of components is specified using publish/subscribe-style events. When a component hears an event of a kind it subscribes to, it executes an operation (specified with a precondition and postcondition) and publishes its result(s) as more events. From all the publish/subscribe connections, you can infer the overall process (and show it on an activity diagram).

For Rob, workflow is a component within the system, an "equal among equals" with the components delivering functionality. It is important to be able to include points at which people make decisions affecting the flow of information through a process using exactly the same notations and semantics for describing component co-ordination. This makes it possible to describe a complete end-to-end system inclusive of people and software using using a single language.

Richard Mitchell (InferData Ltd, USA)

Richard showed a style of modeling in which the specification of two (or more) pieces of functionality in different business components can be combined using logical-and. A common reason to combine functionality is to move from open specifications of functionality that the business doesn't regard as atomic to closed specifications of functionality the business does regard as atomic.

Earl Waldin (Paranor AG, Switzerland)

Earl presented a fragment of a business process in which the co-ordination of functionality in different components is via object flow: the co-ordination designer specifies that an object produced as output from one operation is the input to another operation. The semantics of the object-flow diagrams (OFD) is that an operation executes when its inputs appear.

As a secondary point, Earl explained that the need to process more than one object at a time in a process is handled by broadcast semantics.

SUMMARY OF THE DISCUSSION

The think tank did not provide a single list of desirable characteristics of a language for specifying how a set of components work together. Instead, it produced a list of some factors the designers of such a language might consider, presented in question form:

- should the language be declarative or imperative? (there was general agreement that "imperative" doesn't necessarily imply "design-level")

- should the language provide an easy mapping to system design, or is a hard route acceptable if that allows users of the co-ordination language to work more effectively?

- should the language be readable by business people, or do they need commentary (as well? instead?)

- should the language allow its users to talk about existing systems, or should they be presented abstractly as one or more logical components?

- how carefully should the language separate functionality provided by components from the processes that result from coordinating them?

- how important is it that the result of specifying that a set of components work together in a certain way is testable (e.g., by a suitable simulation tool)? Should we go further and ask that the result has deducible properties?(there was general agreement that an executable acceptance test for a system of components codifies the co-ordination between them)

- what level of tool support is needed to make the language effective in actual use?

- are English and program code enough, or do we need formal notations other than code?

- coordinating components entails combining behavior and combining information models. Are the issues different for these two aspects?

Back to OtTwoThousandAndFourOutput.