 |
component-based developmentfrequently asked questions |
|
component-based developmentfrequently asked questions |
|
|
|
|
|
| please read component ecosystems the context for CBD | Component-Based Development
(what is it, how is it similar, how is it different?)
Component (what is it? how many have I got? always software? same as Object?) Reuse (why important? will it happen? how measure?) |
What is CBD good for?
What organizations are currently doing CBD? Is CBD a genuine innovation, or just new terminology and hype? |
|
‘Since the beginning of the cycle industry, local blacksmiths and mechanics have participated in constructing small numbers of bicycles to order. Standardization had two opposite effects on industry: it further enhanced mass production, and it strengthened the position of those small workshops. A considerable number of local bicycle makers could offer a "home-made" product to the residents of their small village at a price somewhat lower than that of factory-produced bicycles because of their lower overhead costs. Some large companies had specialized in the manufacture of standardized components, delivering them to both bicycle factories and local workshops. Thus three classes of machine could be distinguished. First, there were the mass-produced bicycles made by bicycle factories. Only the largest of these factories manufactured all components themselves; most of them had contracted out the manufacture of saddles, tires, and the like. Second, there were bicycles made by local workshops, constructed from proprietary components made by specialized forms. And the third class of bicycles, made by special departments of factories as well as by small workshops, was known as "de luxe" machines, produced without much regard for costs.’
Source: Wiebe E. Bijker, Of Bicycles, Bakelites and Bulbs: Toward a Theory of Sociotechnical Change (Cambridge MA & London UK: MIT Press, 1995), p 96. My diagram is based on his page 35.
We then get a spread of possibilities, from conventional development at one end, and extreme componentization at the other end. One of the key questions to be addressed by a designer is how far does it make sense to componentize in a particular situation. In order for CBD methods such as SCIPIO to address this question usefully, we need to say that the entire range of possibilities is included within the scope of these methods.
A similar problem arises with distributed computing. Some people regard distributed systems as an alternative to centralized systems - in other words, centralized systems are not distributed. We prefer to say that all systems are distributed. We regard centralized systems as a special case with only one location. This way of putting it provides explicit foundation for the degree of distribution to be analysed and designed.
What is common to many such definitions of software component is the notion that a component has an inside and an outside, and a relationship between the two. There is also an implied context for the relationship.
The outside of a software component is an interface satisfying such-and-such properties. It provides a service or commodity to human agents or other software artefacts.
The relationship between inside and outside is described using such concepts as specification, implementation, or encapsulation.
The context for the relationship states how the software is to be managed and used, within a defined process for software development and maintenance. If the context is not stated (and it usually isn't), then concepts such as encapsulation and reuse are ambiguous.
Definitions provide a basis for counting things. If you have no basis for counting something, then you have failed to define it properly. And this has consequences for other definitions as well. For example, if you don't know how many components you have, then you don't have a basis for defining and measuring software reuse.
And I prefer to use the term executable software component when I want to be clear that the executable software is included in the package.
However, reuse as traditionally understood is only one of several alternative ways of achieving economies of scale in software production and deployment. A narrow definition of reuse may be unduly restrictive.
| Simplification | Removing one or more steps from an unnecessarily complicated process, or reducing unnecessary variety in the process. | This can often by done by replacing components to produce stepwise improvements. |
| Integration | Joining two or more previously unconnected or uncoordinated processes into a larger coordinated process | This can often by done by inserting additional components to create new links. |
| Transformation | Creating a radically new process. | Disassembling the components, and putting them back together in a new way, can often achieve this. |
| Functionality | Use of pre-existing components allows faster delivery of greater functionality. |
| Maintainability | The modular structure of a component-based solution allows individual components to be replaced easily. |
| Usability | Use of standard components supports commonality of GUI. CBD also supports desk-top integration, which gives the user a single view of heterogeneous data. |
| Efficiency | Performance bottlenecks can be identified, and the need for performance tuning can then usually be localized in a small number of performance-critical components. Components can be internally optimized to improve performance, without affecting their specification; components can be moved between platforms to improve performance, without affecting the functionality or usability of the application. |
| Reliability | Given a formal and complete specification of a component, the reliability of a component comes down to the simple question: does the component provide a correct and complete implementation of its specification. The reliability of the application as a whole is a separate issue, but is clearly enhanced when the application is constructed from reliable components. |
| Portability | The specification of a component is platform-independent. So a component can be quickly rebuilt for a new platform, without affecting any other component. (With some tools, this will often require no alteration to the internal design, merely a regeneration of the executable portion.) |
In conversion projects such as Year 2000 or Euro, the task is to get the entire legacy portfolio compliant with a specific new requirement, such as four-digit dates or a change of currency. The challenge is to break this task into manageable chunks.
A chunk of legacy system makes a component. Each chunk needs to be tested and implemented separately. Clean interfaces need to be defined between the chunks, so that converted chunks can interoperate with unconverted chunks. Management will be reassured when they see a growing number of converted chunks successfully tested and incorporated into production systems.
As each chunk of legacy system is converted, it is provided with two parallel interfaces: one for communicating with unconverted chunks, and one for communicating with converted chunks.
The alternative is a very high-risk strategy: big bang conversion, where the entire legacy portfolio is converted from non-compliance to compliance in a single overnight integration test and implementation.
Component-based development is therefore the only low-risk strategy for Year 2000 and Euro conversion projects.
Many other organizations are holding a watching brief - they are attending industry and vendor briefings, or joining the CBD Forum, but have not yet started doing CBD seriously.
A number of large software vendors have made a major commitment to Component-Based Development, including Forte, IBM, Microsoft, SAP, Sterling and Sun.
It is likely that there will be a steep growth in CBD within the next 12-18 months, particularly after IT organizations have got through Year 2000.
Then you’d start to describe the process: The potter scoops up some wet clay from the bottom of a river; she slaps it around, spins it and shapes it, before sticking it in an oven. ‘Hold on’, says the Martian, ‘Do you really expect me to believe that a potter, however skilled, can make a waterproof pot out of wet clay?’
And when you put it like that, of course, it is hard to believe. If we hadn’t seen it done with our own eyes, we’d start to doubt it possible.
Component-Based Development is equally implausible. The software engineer scoops up some wet COBOL from a legacy system, slaps it around a bit, wraps a few shells around it, and voila! - a fully interoperable, CORBA-compliant business object.
Or so the hype-merchants would have us believe.
| Increasing automation and maturity of tools | Existing CASE and OO vendors are starting to move into the CBD marketplace, and there are some exciting new players as well. Use of the current tools still demands considerable manual effort. Shells and interfaces often have to be built by hand, and the matching of component requirements is poorly supported. Over the next couple of years, we can expect the tools to become more powerful and easy to use, covering a greater range of the CBD processes. This will enable still greater productivity and scaleability. |
| Greater differentiation of software work | Each advance in software engineering makes it more difficult for the software engineer to remain a true generalist. Some software engineers will become specialist component engineers, deploying formal methods to create and verify robust and widely reusable software components. Others will concentrate on satisfying local business requirements, designing context-sensitive and user-friendly interfaces. |
| From component scarcity to component abundance | A lot of the discussion of component-based development today is based on the premise that good components are scarce. A lot of the techniques are based on this mindset of component scarcity. However, if CBD takes off, we will quickly move into a world of component abundance. Indeed, we may even get into a world of component pollution, in which it becomes an antisocial act to overpublish redundant components. |
| Increasing variety while decreasing variation | Standard components that can be configured in countless ways. For a business using CBD effectively, this establishes the possibility of mass customization, whereby the business can respond flexibly to the needs of individual customers, without losing economies of scale and scope. |
| Creation | Building new components, (re)using available stuff where possible. |
| Assembly | Building applications from components. |
| Publication | This is the act of making a component available to a defined public. There may be nested publics - thus a component may be published internally, or to beta customers, before it is published to the entire marketplace. Alternatively, a beta version of a component may be made freely available for a limited time period, and then withdrawn, to encourage people to pay for the commercial release. Publication usually involves some form of publicity. This is part of the publication process, and not an optional extra. |
| Dissemination | The word originally refers to the process by which a plant spreads its seeds. Some plants launch their seeds into the wind or pop them into the air, others use animals or birds to carry their seeds great distances. Some seeds fall on stony ground, some seeds lie dormant in dry sands for many seasons until the rains come. Similarly, some components may be tossed around by the random winds of the Internet, while others may be safely carried to fertile application ground. The original developer of the component cannot know - but may try to influence - how and when and where and by whom and for what purpose the component may be used. |
| Matching | A would-be component user is looking for a component. Perhaps with a definite specification; perhaps only with a rough idea of what is needed. Meanwhile the component publisher is looking to maximize the use of a given component. To focus either on the searching process or on the publication process is to see only half the picture. We should rather think of this as a matching process, in which the user and publisher collaborate. This collaboration may be initiated either by the user (demand-pull) or by the publisher (supply-push). |
| Requirements | How do we know what we want to do? |
| Architecture | How do we balance structure with flexibility? |
| Investment | Who pays for an organization to get
into component-based development? Not only are new tools and skills required,
but the acquisition and verification of the components themselves may incur
an upfront cost.
Either this comes from the budget of a single development project - in which case it will be expected to payback within this project. Or it comes from some central infrastructure budget - in which case there are other management issues to address. |
| Procurement | To what extent do traditional software procurement processes conflict with CBD? |
| Security | To verify the security of your information and systems, you may need to look inside the components you are using, and it may be important to know their physical location. According to CBD purists, we aren't supposed to be able to do this. |
| Feature Interaction | How do I know that two components I want to use might conflict in ways I don't yet know about? (This is a problem already widely studied in the telecoms world, and is now starting to become relevant for software engineers.) |
| Testing | A component may be expected to satisfy
many different requirements, in many different contexts. The original developer
of the component may be unaware of the uses to which the component may
be put. So how can it be adequately tested?
For a more detailed discussion of this issue, CLICK HERE. |
| Configuration Management | Many organizations aren't very good at keeping track of a few large applications. How are they going to keep track of a vast number of much smaller components? |
| Tools | What tools do I really need? And how do I make effective use of them? |
| Display the boundary of a system | Illustrate the boundary of a system | Represent the static structure of a system | Model the behaviour of a system | Reveal the physical implementation architecture | Extend your functionality |
| Use Case Diagrams | Collaboration Diagrams
Sequence Diagrams |
Class Diagrams | State Transition Diagrams | Component Diagrams
Deployment Diagrams |
Stereotypes
Packages |
UML is supported by many vendors. Apart from Rational's own modelling tool, Rose, there are several other modelling tools that support the UML.
|
|
|
|
|
veryard projects is an active member
of the SCIPIO Consortium and the CBD
forum.
We provide consultancy and training to user and vendor organizations. Please contact us to discuss your requirements. |
This page updated May 19th, 1999.
Copyright © 1997, 1998, 1999 Richard Veryard
