3.3 Enterprise Reuse Through Components

Component and domain-component reuse are also effective approaches to reuse, but only if you build them to be reusable and then actually reuse them in practice. Bertrand Meyer presents a collection of best practices developing components in section 3.4.9 "Rules for Component Builders" ( Software Development, May 1999). What factors determine the goodness of a component? According to Meyer, it's careful specification of the component, correctness, robustness, ease of identification, ease of learning, wide-spectrum coverage, consistency, and generality. To achieve these goodness factors, Meyer describes several best practices, starting with design by contract describing the preconditions, postconditions, and invariants of your operations, classes, and components. Meyer also argues that you need to name your components appropriately (to separate the concepts of command and query in your designs) and to separate options and operands in your operations. The article ends with a description of the Trusted Components Project; an attempt to develop a set of rigorously developed components that everyone can trust (visit http://www.trusted-components.org for details).

You won't reuse something that you can't trust.

In section 3.4.10 "Components with Catalysis/UML" ( Software Development, December 1999), Desmond D'Souza discusses the importance of common enterprise architecture to support reuse of components across projects. He describes challenges to enterprise architecture (challenges addressed by the Infrastructure Management workflow) and argues for processes, standards, and management practices to support what he calls "the integrated enterprise." D'Souza describes techniques that support component-based development, techniques taken from the Catalysis...