7.3 Mapping the business model to the implementation

Catalysis provides specific techniques for component design. Actions are refined into collaborations and collaborations into ports. Retrievals are used to reconcile components with the specification model. Consider the situation illustrated in Figure 48. Here there are two coarse-grained components for accounting and dispatch, but they are based on different business models. Any system that integrates them must be based on a type model that resolves the name conflicts in the base components. For example, our model must define customer in such a way that the subsidiary customer and payer concepts are represented. We must also include invariants to synchronize operations.

Interfaces cannot be fully described in programming languages; the context in which they are used (pragmatics) is relevant. Often the only reason people accept lists of operations as specifications is because their names suggest the expected behaviour. We must say what components do as well as what they are; i.e. include type models, invariants, rulesets and protocols. The first three were covered in above, now let us now see how we can describe the protocols rigorously.

 

Figure 48 Retrieving a model from components.

Just as connectors must be encapsulated in objects, they can also be specialized and generalized. Templates, or frameworks, are used to define connector classes. We define and specify each class and its interfaces. Next the connector classes are defined. Then message protocols for each class of connector can be defined using sequence and/or state diagrams. We must always ensure that a business model, common to all components, is clearly defined using a type model rich enough to define all parameters of the connector protocols. Points of potential variation should be handled using plug-points. Business rules should be encapsulated by the interfaces.

Components will be used in contexts unknown to their designer(s) and so need far better 'packaging' than simple, fine-grain classes in class libraries. They should be stored and delivered with full documentation, covering the full specification and all the interfaces and ports and their protocols. It is mandatory that components should be supplied therefore with their test harnesses. Good component architectures require that components should be able to answer queries about their connexions at run time: complaining rather than collapsing under abuse by other software.