An essential in such schemes is the definition of the interface: one
object doesn't care how the other works, or what it does in detail; but
it does have to know what requests it can send.
Polymorphism is one of the most powerful principles of software engineering,
allowing us to create very extensible and flexible systems. We can make
kits of components that can be configured in ways not envisaged by the
kit's designer (rather like Lego).
But how do you test such systems? How do you test the components? One
feature of CBD is that, as the designer of a component, you do not know
what other components yours will be coupled to at run time: that is determined
by another designer, who takes your component as a black box and assembles
it with others. (The distinction between the two designers is like the
designer of a Lego brick and the designer who makes a house from them.)
Verification for pluggable components
Two sets of software developer deal with each component: its designer,
and its clients, who assemble systems or larger components within which
it is used.
Building reliable components is a much tougher job than building a conventionally
modular system. In the latter, if there is any question about the interfaces
of your module to another, you can peer over the partition and have an
informal chat about it with the other module's designer. But if you're
designing components, you don't know who that other designer might be;
and they might be in another company; and the other component might not
have been thought of yet.
This separation also presents an obstacle to testing. It's difficult
to do exhaustive tests if you don't know what components it will be used
with. For example, the drawing editor could be tested with some basic shapes
like squares and circles; but we can't be sure that it will work with any
new class of shape that might be invented next week. The distributed system
might appear to work atop RMI, but will it still work if COM is substituted?
Because the clients do not see its internal workings, they are restricted
to black-box tests.
complete solutions for object oriented analysis and design (OOAD)
complete solutions for component-based development (CBD)
complete solutions for process definition (that includes testing)
(consultancy, courses, workshops, mentoring, seminars, development)