Home > Archive > Software Engineering > October 2006 > Component reuse
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Assuming that a developer is developing certain Java system according
to the Component-Based Software Development approach, and he came to a
point that he wants to find a reusable component that can fit into the
building of his system. what are the general requirements that he needs
to consider in order to find one that fit in to the system. I am
assuming here that the functionality is one of course, but what about
the architectural aspects (i.e. doing the wiring between the component
and the system). To me, I think that in order for a component to fit
into a system it must define some methods that will be required by the
system. for example the system requires a public method called run()
then the selected component must have this method, regardless of its
functionality, otherwise the component will not fit in the system.
can any one give me other examples rather than methods?
Many Thanks
| |
| H. S. Lahman 2006-09-26, 7:00 pm |
| Responding to Aned...
> Assuming that a developer is developing certain Java system according
> to the Component-Based Software Development approach, and he came to a
> point that he wants to find a reusable component that can fit into the
> building of his system. what are the general requirements that he needs
> to consider in order to find one that fit in to the system. I am
> assuming here that the functionality is one of course, but what about
> the architectural aspects (i.e. doing the wiring between the component
> and the system). To me, I think that in order for a component to fit
> into a system it must define some methods that will be required by the
> system. for example the system requires a public method called run()
> then the selected component must have this method, regardless of its
> functionality, otherwise the component will not fit in the system.
There are only three things one needs to worry about : semantics, syntax,
and implementation. The first two are related to functional
requirements while the last is related to nonfunctional requirements.
Semantics.
You must be sure the semantics of the component service is what the
client in hand the wants. This comes down to the definition of the
service subject matter. IOW, the view of what the component /is/ must
match the client's view of what the service must /be/. The relevant
questions are:
Is the component subject matter complete? That is, does the component
semantics include everything the client expects of a service semantics?
Is the component subject matter clearly bounded? That is, is it clear
what semantics the component "owns" and what it does not?
Is the component subject matter cohesive? The more disparate the
responsibilities, the more likely it is that the component has overlap
with the client itself that can lead to conflicts. Cohesive components
are also more robust in the face of volatile requirements; two cohesive
components are easier to manage in maintenance than a single component
serving double duty.
Syntax.
In software reuse contexts syntax is equivalent to an interface. The
relevant question are:
Is the component interface at the level of abstraction that the client
needs? That is, do the interface's messages have the granularity of
control that the client expects?
Does the interface reflect the invariants of the component subject
matter? Generally the more the messages reflect the fundamentals of the
subject matter while the details are relegated to parametric data
values, the more robust the interface will be for reuse.
Is the interface pure message-based (i.e., {message ID, <by-value data
packet})? Generally interfaces that pass problem space object
references are fragile because of the high coupling and implementation
exposure. [For distributed interfaces there is also usually substantial
overhead in managing object references across distributed boundaries.]
Corollary: Is the interface synchronous or asynchronous? Message-based
asynchronous interfaces are the most general and can be implemented in
any environment while synchronous interfaces tend to introduce more
coupling and may not be implementable with all clients.
What preconditions must prevail for the component to process particular
messages? Are there assumptions in the interface about the ordering of
messages? Are there data consistency issues across messages in addition
to within message data packets? One must be sure that the current
structure of the client can ensure such preconditions.
Does the interface capture the semantics fully? That is, can the
interface be used as-is to access all the functionality the client needs?
[For any complex semantics it is always possible to provide multiple
syntaxes to access that semantics. The important question for
interfaces is the last. If that is true one can always provide a
wrapper (e.g., GoF Facade pattern) to convert the interface the client
wants to use into the interface the component actually supplies.
(Though for components close to the object level, the overhead of
providing that mapping may be prohibitive.)]
Are the DbC preconditions, postconditions, and processing invariants
clearly and unambiguously defined?
Implementation.
There must be some way to evaluate whether the implementation will meet
nonfunctional requirements for things like size and performance. For
large components there may be benchmark data and whatnot so that one
does not need to inspect the implementation. However, for smaller
components one usually needs to inspect the internals.
One also needs to evaluate side effects. Is the component
implementation self-contained or does it depend upon other components'
behaviors? Does it depend on external data not provided in message data
packets? Does it modify external data not defined in postconditions?
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| Mark Dalgarno 2006-10-04, 6:39 am |
| quote:
Originally posted by Aned
Assuming that a developer is developing certain Java system according to the Component-Based Software Development approach, and he came to a point that he wants to find a reusable component that can fit into the building of his system. what are the general requirements that he needs to consider in order to find one that fit in to the system.
Hi Aned,
I guess the first thing to ask is how far along the way are you to building the system? In my experience it is better to think about using a reusable component when designing the system architecture than it is to try and find something that will plug into an existing system. But that will also depend on how big a system you're working with.
Aside from the functionality of the component itself other factors such as how stable is the component and the company that develops it, is there an escrow scheme if the company folds?, how is it licensed e.g. do you need to pay a runtime use fee?, how is it documented and supported?, does it come with source code etc. can be important. Depending upon the role the component is to play in the system it can be a strategic investment. You may also want to speak to your marketing people to see whether the different functionality offered by the component will be acceptabel to the user base - in most cases I've looked at components that are available on the market offer significantly more capability than could be developed in-house but they rarely do exactly what you want so some compromise may be needed.
quote:
I am assuming here that the functionality is one of course, but what about the architectural aspects (i.e. doing the wiring between the component and the system). To me, I think that in order for a component to fit into a system it must define some methods that will be required by the system. for example the system requires a public method called run() then the selected component must have this method, regardless of its functionality, otherwise the component will not fit in the system.
can any one give me other examples rather than methods?
You might want to find out about the component's configuration options to see how flexible it is. You can also think about wrapping the component in some way to get just that subset of functionality you want from it and also to make it easier to plug something else in if needs be. Regarding architectural aspects you may need to think about evaluating the component in terms of its performance or other non-functional attribute such as security, resilience etc. It really depends on the nature of the system and the component itself how far you go with this.
Hope that helps. |
|
|
|
|