Component Based Development and Advanced OO Design
Mark Collins-Cope

PDF version

---

1. Introduction

“Components” have been in the news, on and off, for a few years now. Coverage of component related topics has, however, tended to be dominated by discussion of what we call component inter-connection technologies, by which we mean the likes of .NET, J2EE (EJBs) and to some extent CORBA. We believe this focus on inter-connection technologies, whilst important in its own right, misses a bigger picture. In this paper I discuss some of the wider issues related to CBD, and in particular issues of component design.

2. Why components?

To explore of the wider issues surrounding component based development (CBD) it is necessary first to take a step back and ask: why do we want components in the first place?

The (currently unfulfilled) vision of CBD is one of constructing software from pre-defined building blocks, which are “wired together” to create a useful software application.

Inter-connection technologies are clearly important in this: if you can’t get two components to actually communicate at all, it’s obviously unlikely you’re going to be able to build an application from them! Interconnection technologies like .NET enable components written in different programming languages (managed C++, C#, VB.NET, etc.) to communicate – either on a single machine in a distributed machine environment. This - in conjunction with other services such as MTS (Microsoft’s object transaction monitor environment) - provides a development infrastructure that can underpin an enterprise CBD approach. Similarly Sun’s J2EE, although limited to the Java language, provides an alternative component inter-connection environment.

But, coming back to the original question, what is the motivation behind components? If you take a second or two to think about it, it’s apparent the plug and play vision of CBD is primarily intended to reduce the cost and time to market of software development, without compromising on software quality. This is achieved by re-using existing components, which may be either bought from external third parties (of which there are a number now) or developed in-house. So the primary motivation behind components is re-use.

Re-use has been one of the holy grails of software development since I started in working in the software industry some eighteen years ago. Re-use can and does happen (all those applications running under Microsoft Windows re-use a core kernel of code supplied by Microsoft, and standard programming language libraries that have been re-used for years). Methodology and programming language enhancements - such as the wide-spread adoption of the object-oriented software development paradigm – have increased the potential for achieving re-use quite dramatically (polymorphism is particularly important in this).

Component inter-connection technologies are yet another step in the right direction, so why isn’t all software developed by plugging components together?

The answer to this question lies in the answers (or rather the lack of them) to a number of more fundamental questions:

• What actually is a component?
• What makes a well designed re-usable component?
• How do you achieve re-use of both business (domain) and technology (infrastructure) components?
• What architectural issues need to be addressed to achieve component re-use?

The remainder of this paper discusses the answers to these questions.

3. What is a component?

This may sound like a surprisingly obvious question, but a cursory view of magazine articles, and even some recently published books, shows us that the term “component” is in danger of becoming all things to all men – and consequently completely meaningless. Here’s how Ratio sees it

Firstly, a component is an binary (non-source code) unit of deployment. By unit of deployment I mean it is a constituent part of a larger application – such as a “.class” file in Java, an “assembly” under .NET, a “.dll” file under Windows, or even a “.o” file under Unix. A component is something that would be typically shown as one of the building blocks of an application using deployment diagrams in UML. The emphasis on non-source code is to ensure that components are used in an unmodified fashion. If you change the source of a component you are effectively creating a new component - with all the consequent costs of additional testing, maintenance, duplication (or worse: non-duplication) of bug fixes and so on.

Secondly, a component implements (one or more) well-defined interface(s). This means, purely and simply, that the mechanisms by which the component can be called by its client developers (it’s Application Programming Interface if you like) is clearly defined and hopefully documented. Note that defining a component interface is more than just defining a set of method or procedure calls. It is equally important to document the component’s behaviour (the semantics of its interfaces).

Thirdly, a component provides access to an inter-related set of functionality, in the sense that each of the methods or procedures exposed by the interface(s) are in some way related to each other (otherwise, why are they in the same component?)

Finally, and most likely forgotten, a component may have its behaviour customised in well-defined manners - without access to the source code. This is an important aspect of components if the re-use vision is ever to be achieved. Whilst low-level (technically oriented) infrastructure components such as graph-drawing widgets may be self-contained, any re-usable business (domain) component is likely to require some mechanism by which its behaviour can be modified. Whilst the core functionality of the component will always be the same, different applications may require slightly different functionality (for example if business rules vary across applications).

From the above I hope the following points should be clear:

• an object is not a component. Object exists at run-time, whilst components are binaries that are deployed. Having said this, components are very likely to be implemented using object technology, and it is not unforgivable that we may talk about the “objects (or classes) in a component” as a short-hand for “the classes that when compiled together will create a binary component.”
• All enterprise Java beans (EJBs) are not components. Even ignoring the run-time versus deployment issue, a single enterprise Java bean is unlikely to be usable (let alone re-usable) without other EJBs to collaborate with. Similarly, all .NET (or for that matter any other) classes are not destined to be components in their own right. The majority of components will be made up of many classes.
• The customisable nature of components brings them closer to the territory previously occupied by frameworks. A framework (such as Microsoft Foundation Classes, or Java Swing) will typically implement call-backs of one form or another - in OO terms, the developer typically implements an interface defined in the framework, and this has the effect of the framework invoking developer code at its convenience. Customisable components are often implemented in exactly the same fashion.

4. Well designed components

So we’ve decided that a component is a (potentially) re-usable unit of deployment with a well-defined interface, however this, on its own, is not sufficient to guarantee that a component is actually of any use to any one. Components must be designed well if they are to be usable or re-usable.

In many ways, the criteria that define a well-designed component are no different to the criteria that have been used to underpin good modular software design for many years. Components should be highly cohesive internally - they should be implemented by a set of highly collaborative classes – and should be loosely coupled – where possible one component should not rely on another component being there (although in certain circumstances this is unavoidable - in which case one component can be said to be dependent on another).

Examining the design issue more deeply, we can divide the attributes of a well designed component into four major areas:

• Functionality.
  A component should implement the right functionality, and this means the component designer must have a good understanding of the context(s) in which their component is to be used. The most elegantly designed, beautifully coded component in the world is of no use if no-one uses it! For customisable components it is important the designer understand the variations in functionality that may be required.
• Interface.
  Interfaces must be well designed and easy to use. The Interface Segregation Principle (ISP) [Martin-96.3] helps here, stating that different interfaces should be provided for classes of types of client developer (although internally all interfaces should be implemented using a common set of underlying classes). It is also important that component interfaces present a clean abstraction to the component user. An interface that presents a clean abstraction will use concepts (classes, types) that are familiar to its client developers, and in particular will hide irrelevant implementation detail.
• Granularity.
  Considerable thought needs to go into the scope (breadth-wise and depth-wise) of the functionality provided by a component. Here, a number of additional design principles can be of assistance, in particular:
  • the re-use release equivalence principle or RREP [Martin-96]. The RREP states that the unit of re-use is the same as the unit of release – in other words that it is important to release components at the right granularity);
  • the common closure principle or CCP [martin-96] - which says we should package things together (into single components) that are likely to change together;
  • the common re-use principle or CRP [martin-96], by which classes that are re-used together are packaged together in a single component. An important corollary of the CRP is that classes that aren’t always re-used together shouldn’t be packaged together as a component. This means, in effect, that if you find a number of components share some common behaviour, it will be necessary to factor this behaviour out into a new “lower-level” component on which the aforementioned component will be dependent (fans of Extreme Programming – XP - call this the OAOO – or once and only once rule). Of particular importance to CBD is separating the re-usable from the non re-usable.
• Dependency management.
  Good dependency management is key to component based design. You must have a clear idea exactly what (in terms of other components) your component is dependent on, and what it isn’t dependent on. Good dependency management is supported by the following design principles:
• The acyclic dependency principle or ADP [Martin-97]. This principle states that the dependencies between a set of components should not have any cycles between them. Consider two components which are mutually (and hence cyclically) dependent on each other – each requiring the other when deployed. In such circumstance we should surely ask why do we need two components? If the components can’t be deployed separately, then the reality of the situation is that we’re actually dealing with a single component, and that releasing the two components separately can only make the client developers life more difficult!
• The stable dependencies principles or SDP [Martin-97]. The SDP states that a component should only depend on components that are more stable (less likely to change) than itself. Violating this rule means that the dependent component is likely to be in a continuing state of flux as its author strives to keep up with the changes being make to the components it is dependent upon. This principle ties in nicely with the Architectural Reference Model (CBD-ARM) I’m going to discuss in the next section.

5. Architecture and re-use

Having discussed some aids to good component design, I’m now going to take a look at the closely related issue of software architecture. Here I’m using the term architecture to mean the structural inter-relationships between the components that make up a system, be they developed in-house or bought from third parties.

5.1. An architectural reference model for CBD (CBD-ARM)

Figure 1 provides a layered architectural reference model [Collins-Cope+2000]which helps us discuss architecture in more detail, and assists in good component design. Note that the layers presented in this model are placeholders for components – not components themselves (and hence the model presented does not preclude dependencies between non-adjacent layers), and that dependencies (between components) are created by either directed association (shown as a line with an simple arrowhead in UML) or implementation of an abstract interface (shown as a line with an open triangle arrowhead in UML).

The layers of the model may be summarised as follows:

• Highest (and most specific) in the layering is the application interface layer. This layer is responsible for managing the interaction between the 'outside world' and the lower layers within the application. It typically consists of components providing GUI interface functionality - managing the interface to human users, and/or components providing external system interfaces - managing the interface to external systems. This layer often contains what Jacobson et al. call boundary classes [Jacobson+94]. Components in this layer are unlikely to ever be re-used.





Figure 1 – the CBD -ARM^TM

The example application shown in figure 1 shows two classes packaged as components within this layer. The GUI debit dialog box class implements an application specific dialog (to enter a debit). The file exchange manager class reads an external file format. Both classes use the application specific debit class from the layer below to process the information they receive from the outside world.
• Below this is the application specific layer. This layer is comprised of components that encapsulate the major business processes and associated business rules that are automated within the application. Typically, the components in this layer will contain many classes akin to Jacobson’s (use case) 'control' objects [Jacobson+94], although it is important to note that this layer also acts as the “wiring” layer for the (potentially re-usable) components in the layer below. Again, components in this layer are unlikely to be re-used.
  The example application shown in figure 1 shows two classes packaged within an application specific debit component. Control flows to the debit class when it is called by classes in the higher level interface layer. The debit class will then drive account component in the layer below to implement its functionality. This will typically involve several method calls on account component interface. The other class in this component – the app. debit rules class- implements the debit-rule checker interface (derived from the lower level account component) to customise its behaviour.
• Next is the business domain specific layer. This layer consists of components that encapsulate the interface to one or more business classes. Although specific to the domain (area of business) of the application, these components should be seen as at least potentially re-usable amongst a number of applications. This layer typically contains the 'entity' classes discussed by Jacobson et al in [Jacobson+94].
  The example application in figure 1 shows an account component in this layer. The account component interface is driven by higher layer components to undertake account related activities - such as the debiting and crediting of money to or from a particular account. As discussed in the previous point, the account component provides a debit rule checker interface (abstract class) to enable its behaviour to be customised (e.g. can go overdrawn, can't go overdrawn, etc.) This is an example of the Open/Closed Principle or OCP [Meyer-97, Martin-96.2] in action.
• Then comes the technical infrastructure layer. This layer is made up of custom (not bought in) components that are potentially re-usable across any domain, providing general purpose 'technical' services such as persistence infrastructure, general programming infrastructure (e.g. lists, collections), general purpose observer mechanisms, and so on.
  Our example application in figure 1 shows a general purpose persistence component (framework if you like) in this layer.
• Finally, and most re-usable of all, is the platform software layer. This is comprised of standard or common-place pieces of software that are purchased to underpin the application (e.g. operating systems, distribution infrastructure, CORBA/DCOM, etc.) The example application in figure 1 shows a relational database and a GUI class library forming the basis of the underlying application.

A number of simple rules assist the component developer when using this model:

1. there should be a simple and clear mapping between component structure and source code structure (the simplest being a 1-1 mapping);
2. there should be a 1 to 1 mapping between component structure and stereotypedpackages in UML (assuming UML is being used during the design process) – we recommend use of the «component subsystem » stereotype;
3. the level of a component is the highest level of any of its constituent classes;
4. components should not (and by the above definition, cannot) cross layers;
5. component dependencies should be either within the same layer or to a lower layer. Even then, dependencies to components within the same layer should be avoided if at all possible;

5.2. Technical versus domain architecture

Considerations of architecture can be broadly separated into two categories: the technical architecture - which is concerned with the underlying platform that needs to be in place to build the application in the first place (does it use Oracle, does it use MQ Series, is it .NET based, is it J2EE based, does it run on Windows, etc.); and the domain architecture – the business domain related components you buy or build to implement business specific functionality.

The CBD-ARM just discussed splits rather neatly along these lines: the technical architecture being made up of components in the platform and infrastructure layers, and the domain architecture being made up of components in either the interface, application or domain layers.

A coherent approach to CBD requires that architectural issues are addressed at both levels. It’s unlikely you’ll be able to re-use two components together if one is based on J2EE and Oracle, and the other is based on .NET and SQL-Server, so a coherent technical architecture is clearly a pre-requisite for any serious component based development to succeed.

5.3. Re-use of business or domain components

Re-use of domain components (those implementing business or domain related functionality, rather than general purpose technical functionality) requires a similar focus on the appropriate layers of the CBD-ARM. It’s interesting to note that the vast majority of commercially available components fall clearly into the “technical” component category – providing general purpose functionality such as graph drawing, XML parsing, and so on.

Re-use of business components, in our experience, most often occurs internally within organisations – if you work for a large company, just ask yourself and how often you and your colleagues re-invent the wheel! The CBD-ARM is specifically intended to encourage this, with its separation of application and domain layers, and has underpinned many of the re-use programmes we have worked on with our clients.

6. Other issues

Although strictly beyond the scope of this paper, its worth mentioning a few other issues that crop up when trying to get CBD really happening:

• Process
  You can’t just expect components to pop out of thin air during development. To get component re-use happening seriously, you must have a development process that supports component identification and component evaluation part of an overall focus on architecture (as discussed earlier) early in the development lifecycle. Despite their claims, commercially available OO development processes pay scant attention to these issues. Note also that even when potentially re-usable components are identified, experience shows that two or three development iterations are required before the components become truly re-usable.
• Funding
  A particularly sticky issue is who pays for “re-usable” component development. If, as with many, your organisation expects the project manager and their team to deliver software projects within an agreed budget, you can’t really complain when they have little or no interest in re-use! We’ve seen different organisations attack this issue in different fashions, with varying degrees of success.
• Developer ethos and reliability
  Many developers are wary of software developed by others, particularly if they have experience of unreliable software being delivered to them. Changing this requires that internal components must undergo the same level of testing and reliability checking as applications intended for real end users(!)
• Organisational structure
  Once you have a component in place, there will inevitably be requests for enhancements and bug-fixes. Some form of support team will clearly be necessary.
• Communication and internal marketing
  One of the biggest blocks we’ve found to internal component re-use is a complete lack of what is best called “internal component marketing”. No-one is going to re-use something they don’t know exists. Even when they do know about a pre-existing component, developers will want to discuss what it does and how it does it in much the same way they would if they were buying a software product from an external third party. Evangelising the benefits of a re-usable component library requires skills more akin to those expected of sales and marketing staff – and this can present problems.

7. Summary

In this paper I’ve discussed some of the wider issues pertaining to CBD and the closely related topic of advanced OO design. Whilst component inter-connection facilities such as those provided by J2EE and .NET are clearly important, there are many other equally important issues to be considered if the vision of CBD is to be achieved, even partially.

High on the list of additional priorities are having a common understanding of what exactly constitutes a component, having a good understanding of the more advanced principles of OO design that assist in component development, and having a clear understanding of the architectural issues surrounding CBD.

Further information on the issues discussed in this paper can be found in the references that follow (or you can email markcc@ratio.co.uk)

8. References

[Martin-96]	Robert C. Martin, “Granularity”, C++ Report, Nov-Dec 1996.
[Martin-97]	Robert C. Martin, “Stability”, C++ Report, Feb 1997.
[Collins-Cope+2000]	Mark Collins-Cope and Hubert Matthews, “A Reference Architecture for Component Based Development”, OOIS 2000 (proceedings published by Springer). Also available at http://www.ratio.co.uk/techlibrary.html. See also “UML is Upside Down” – Issue 4 of ObjectiveView Magazine.
[Jacobson+94]	Ivar Jacobson, Magnus Christerson, Partrik Jonsson, Gunnar Övergaard, “Object Oriented Software Engineering - A Use Case Driven Approach”, Addison-Wesley, 1994.
[Meyer-97]	Bertrand Meyer, “Object Oriented Software Engineering (second edition)” - Prentice Hall Professional Technical Reference, Published 1997.
[Martin-96.2]	Robert C. Martin, “The Open Closed Principle”, C++ Report, Jan 1996.
[Martin-96.3]	Robert C. Martin, “The Interface Segregation Principle”, C++ Report, Aug 1996.