Home > Archive > Software Engineering > October 2006 > component fitting into a software architecture
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]
| Author |
component fitting into a software architecture
|
|
|
| Every software system should have certain architecture, the
architecture could be simple(i.e. single pattern) or a more complex one
that is composed of multiple architectures.
I am assuming that, in order for any component to fit into a certain
system architecture it has to conform to some rules that the
architecture requires to find in the component. for example one of the
things that must be satisfied in Eclipse plugins is the Activator class
that allows eclipse to control the lifecycle of the plugin. another
example, is the EJB lifecycle control interface (i.e. Activate,
passivate ...). These rules or methods seem in the interet of the
system only as the client will not use them. so it sounds like a
component has two types of interactions, interaction with other
components in the system and interaction with the system itself. if the
component captures the rules that are required for the interaction with
the system then we might be able to say this component fits into the
specified system regardless of its functionality.
My question is, can I generalize this idea for all software components.
in another word, can I say that every component must have certain
rules(e.g. methods) that allows it to fit into any selected
architecture and these rules are the things that distinguishes the
component that fits into system A from another same component that fits
into system B as both systems have different architecture.
| |
| H. S. Lahman 2006-10-23, 7:01 pm |
| Responding to Aned...
> My question is, can I generalize this idea for all software components.
> in another word, can I say that every component must have certain
> rules(e.g. methods) that allows it to fit into any selected
> architecture and these rules are the things that distinguishes the
> component that fits into system A from another same component that fits
> into system B as both systems have different architecture.
If one is going to access the component in a distributed environment or
one needs to design components to be portable across disparate
development environments, Yes. However, I would put a somewhat
different spin on this. As I see it there are really two distinct sets
of requirements for the component.
One set is that of the component's clients that collaborate with it.
The problem here is that one can access the same semantics with
different syntaxes (interfaces) so different clients may want to use
different interfaces than the one provided with the component out of the
box. The basic solution to this problem is providing custom wrappers
for each context that map the interface the client wants to see to the
interface the component actually provides. Such wrappers range in
complexity from simple Facade patterns to complex interoperability
infrastructure layers. This decoupling allows one to address reuse
without touching the basic semantics (or implementation) of the component.
The other is the set of requirements that are generated by the computing
environment itself. Some of these (e.g., endian) are handled
transparently by simply compiling and linking where the component lives.
Unfortunately the industry has not sorted itself out yet to provide
standard notions like the Facade pattern that allow one to deal with the
rest of these requirements without touching the component semantics.
Therefore some of these requirements must be explicitly addressed by the
component semantics itself (as opposed to a wrapper for client
requirements). IOW, the component itself must provide additional
facilities to deal with the computing environment requirements. Those
facilities are not limited to methods; they can include shared memory,
exception infrastructures, socket/RPC infrastructure, and a bunch of
other stuff besides an interface method. Thus the component may have to
provide different facilities for different computing environments.
*************
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
|
|
|
|
|