Loosely
Coupled Verses Tightly Coupled
(Component level abstraction Verses Object level abstraction)
|
| |
Most
components are built by assembling subcomponents. Again
these components are assembled to build larger and larger
components and finally the product. For example, many
parts are assembled to build the components for the
car, such as engine and transmission etc. Then these
parts are assembled to build the automobile. Likewise,
many chips and electronic components are assembled to
build computer-parts such as, graphics-card and hard-drive. |
| |
It is desirable to build most components
by loosely coupling its subcomponents. Some cases,
it is possible to use loosely coupled subcomponents
to build the larger component. But, in other cases,
the subcomponents must be tightly coupled to build
the larger component.
|
| |
For
a great product design, it is very useful to build and
use mostly loosely coupled components or parts. This
allows specialists (who have core competence in the
part making technologies) to independently build the
components, such that, they offer plug-in interface
to quickly assembled into the product. This substantially
cut the complexity and costs. For example, this allows
the product to be quickly adaptable to changing user
needs or incorporate latest technological advancements,
by updating each component independently. |
| |
To
identify loosely coupled components, it may be helpful
to understand the differences between the characteristics
of the loosely coupled and tightly coupled parts. Tightly
coupled parts are very hard to separate and often use
irreversible manufacturing process. For example, the
IC chips are manufactured by fusing metal-oxide and
silicon. It is a complex chemical process and not meant
to be reversible. Likewise, the alloys made by mixing
metals, or steel-radial tires are built by infusing
steel wires and rubber. Usually tight coupling processes
are complex and require very high degree of skill and
knowledge. |
| |
Loosely
coupled components are easy to assemble and easy to
remove or replace. For example, battery in the car is
a loosely coupled component. Also, automobile tire is
a loosely coupled component, which can be replaced when
it is used out, by a new tire. However, the battery’s
manufacturing process tightly couples its subcomponents
(e.g. lead plates, casing and Acid etc.). Computer chips
(e.g. CPU, DRAM) are usually loosely coupled to the
board (e.g. mother-board or graphics-cards) and they
can be quickly replaced. |
| |
However,
many components for the computers (e.g. CMOS process
to make the IC chips) and for the cars (e.g. mixing
metals to make alloys for the parts or casting-molds
to shape the metal parts) are manufactured by tightly
coupling their ingredients (or parts). Many cases, this
tight coupling cannot be avoided. But, may be possible
to put the component (that is created using tightly
coupling its subcomponents) in to a casing, so that,
the component can support loosely coupled interface
to use as a subcomponent to make a larger component. |
| |
According
to these examples, none of the existing software classes
(e.g. Java/Swing or Windows GUI-API & DB or EJB-Objects)
could be loosely coupled components. For example, the
GUI-objects (or presentation logic) and data-objects
(application logic) are tightly
fused to build the parts of the application.
Detailed explanation is provided later pages, to show, why
the OOP cannot be used to build loosely coupled systems. |
| |
To
build software applications using loosely coupled components,
we invented a new process and plug-in components: CF/AC,
where CF encapsulates the manufacturing process that
tightly couples the OOP Objects, and support loosely
coupled interface for the resultant AC to easily
plug-in (or plug-our to independently update or even
to replace it). |
| |
| Where does our
technologies fit in the overall software landscape? |
| |
The
Objectives of the technologies are to help developers
to build superior next generation online-GUI applications
than ever possible at far less cost. Before the advent
of the Internet, developers used VC++ or VisualBasic
to build the information technology applications (e.g.
information systems, data where housing, data analysis,
visual simulation data entry and processing etc.). |
| |
These
applications usually require us to write several hundred
thousand lines of code or even millions of lines of
code. They used Windows GUI-API (or UNIX/X11/Motif)
to build the front end user interface. |
| |
Many
of these applications are built using Object Oriented
Paradigm. If you map the relationships or interactions
between the Objects, it might look like the figures
#3, #5
and #7
(please note: The CBSDF preserves the AC seperation
as in fig#6).
Where, fig#3 shows, how one can use OOP to build a part
or component (i.e. an AC) of the application by tightly
coupling the Objects. Then fig#5 shows, how two components
(or ACs) are tightly coupled to add the second component
to the application. Then fig#7 shows three components
… I hope you get the picture. |
| |
Please
recall how you write the OOP. Also recall that the concept
of AC doesn’t exist in the OOP; but applications
must have them in some form. How one incorporates a
new AC that needs many Objects to build, as shown in
Fig#3? |
| |
One
may create all the needed Classes or one Class at a
time. Then usually instantiate or add each Object to
the application and write integration code to set data
or get data as shown in the Fig#3.
There is no ideal place or standard process to include
this code, so one may add each of the Object instantiation
and initialization code in one of the existing files
(i.e. files for the first AC). Usually all the GUI-components
are grouped (See Fig#5).
If two Objects exchange data, when the two ACs communicate,
those objects may be placed in the same file. Usually
upon the user action on one AC, its callback may call
other AC’s methods. The code for the callback
may be added in a different file. |
| |
If
one builds the Cars in this way, to incorporate each
part such as the battery: he should add each ingredient
(e.g. lead plates and Acid etc.) at a time and manually
adjust to meet the needs. It is ugly and hard to even
imagine, but please imagine about it. Fortunately, the
battery maker encapsulates the tight coupling in a casing
that offers much simpler Component-level
abstraction. |
| |
Large
application may contain thousands of such ACs or components
(or parts). In OOP process, we used to end up with millions
of lines of tangled code and numerous Object
level dependencies (Fig#7),
where the Objects are tightly coupled with each other.
The OOP can provide only Object
level abstraction. This code (in all the files)
is compiled to build the application’s executable. |
| |
Therefore,
maintenance of large applications becomes problematic
because, it’s difficult or nearly impossible to
predict what sort of effect a simple change might have
on other parts of such tightly coupled system (especially
a year or two after its release; or to a new recruit,
even he is talented and has 10 years experience). If
small change is difficult, just imagine the complexity,
if one needs to replace a large AC (e.g. AC15
in Fig#2, if it includes many sub-ACs & Objects).
|
| |
Furthermore,
developers are usually confronted with other challenges,
such as, poor design, documentation and time pressure
to adapt to the evolving needs. Large ACs almost never
removed, but tried to add additional code to update
many of its Objects to get the desired results, while
keeping old code and Object-dependencies, to reduce
the uncertainty. However, our loosely coupled AC can
be removed (or replaced, if a new AC/CF is ready) in
few minutes. |
| |
It
is the main objective of the researchers for decades
to invent ideal plug-in components that can avoid this
tangled mess ( Fig#7)
and create a loosely coupled system, such as, the one
shown in the Fig#8
& Fig#10.
The Fig#7
shows traditional Object-level
abstraction and their complex interactions, while
Fig#8
shows Component-level abstraction
and their simpler plug-in interfaces. Both have three
ACs and can accomplish the same. Both may be compiled
to build the same application. But, the Fig#8
encapsulated each AC in a single cohesive code-block
(the AC is built using the same old Objects as shown
in the Fig#3)
and uses simple mechanism such as, service-oriented
interfaces to integrate the ACs. |
| |
| Success of the
Web in the mid 90s & Emerging Online Applications |
| |
Today
businesses are building increasingly complex J2EE or
.NET online-applications that generally use the HTML,
DHTML & Jscript as front end. These applications
are no smaller or less complex than those VC++ applications
a decade ago (even though we ended up having inferior
text-based or primitive HTML GUI elements). The software
developers using the same tightly coupled Object integration
in the Servlets (or ASPX) files to build the online-applications. |
| |
Users
are increasingly demanding better visualization or online
graphics. Today’s information driven economy,
the graphics intensive or “rich” online-applications
are essential to improve the productivity and to reduce
the mistakes of the knowledge workers. A picture is
worth thousand words, to cope up with the information
overload. Today, we do not have a viable online-GUI
to build rich online applications such as, visual-analysis,
visual-simulations, decision-support, location-based
or GIS, command & control systems. |
| |
Despite
worldwide effort by leading organizations (e.g. Microsoft’s
XAML, Macromedia’s MXML/Flash and W3C’s
X3D, SVG) they cannot create a viable online-GUI technology
any time in the near future. They readily admit that
these technologies can never match even 50% of the functionality
of the traditional GUI-API (e.g. Java/Swing, UNIX/X11
or Windows-XP). |
| |
Please
forgive me for the rude unsubstantiated assertion, but,
based on my years of research and competitive analysis
of their future plans and projected directions, with
out our technology, world may never see a viable online-GUI-API
(or at least in the next few years). Using our GUI-API
technology, today we can create far superior online-GUI
applications than ever thought possible on the traditional
GUI-platforms (e.g. Java/Swing) at fraction of the cost. |
| |
If
you have seen the sample components in my Zipped folder,
you would notice complex component hierarchies. Those
components use Zero coupling between the components,
therefore can be created in matter of minutes (once
all the CF for the ACs are independently created). The
couplings would be created only when one component communicate
with other component. The components in the most of
the example do not exchange data with other components
therefore they have Zero coupling. |
| |
Please
understand that, one of the main objectives of our component
technology (i.e. CBSDF) is to build such million lines
future graphics intensive applications, using loosely
coupled components to eliminate nearly 70% of the development
costs. Today US businesses alone spend nearly US$70
billion a year to build such information technologies
and enterprise applications. |
| |
| Causes for the
complexity explosion & Our Solutions |
| |
1. |
Software
today is a technology in crisis, where its complexity
has far outrun our ability to comprehend it. It’s
next to impossible to understand what is going on in
software whenever a program runs longer than a few hundred
lines of code—and today’s software applications
contains millions of lines. What we don’t understand,
we can’t fix or maintain (e.g. to adapt to evolving
need): 25 percent of commercial software projects are
canceled, which meant $60 billion in losses in 2000
in the U.S. economy alone. |
| |
|
| |
Most
software modules may be built using good Objects that
usually have good abstraction and hides internal complexity.
However, the OOP-Object oriented paradigm forces us
to write tangled code that tightly integrates the Objects
( Fig#3).
The code structure of these modules, even containing
few Objects, would degrade and the modules loose their
abstraction and modularity. The modules further integrated
to build larger and larger modules by writing more tangled
code ( Fig#7).
Larger systems contain thousands of tightly coupled
modules. Therefore, maintenance becomes problematic
because, it’s difficult or impossible to predict
what sort of effect a simple change might have on other
parts of the system. |
| |
|
| |
The
CBSDF introduced a new kind of modules: “AC”,
that are custom build using “CF”, which
separates the manufacturing and AC’s service-interfaces.
This overcomes the problems, since each CF is an independent
module and each of the AC is “loosely coupled”
to the rest of the software system by service oriented
plug-in interface (a simple link); and further can offer
CASE tools to automatically validate these links. Therefore,
the custom application may be noting but a collection
of loosely coupled plug-in and easily replaceable parts
( Fig#8,
#9,
#10).
|
| |
|
2. |
Unfortunately,
the OOP technologies suffer from several problems. During
evolution and customization for reuse, components are
affected by changes arising from new functional and
nonfunctional requirements, new variation points, new
software architectures and component deployment strategies,
new versions of a computing environment that effect
component communication, etc. Due to those changes,
class/object code structure erodes quickly (as we add
patches), resulting in complexity explosion, performance
degradation and redundant implementations of similar
features, thereby reducing the modules’ or components’
reusability and system maintainability. |
| |
|
| |
The
Generative process offers an innovative approach to
alleviating the above problems, as changes affecting
AC can now be more effectively managed during the generation
( Fig#2)
rather than at the component level. Using generative
programming, we can produce custom components (i.e.
AC) from small or fine-grained highly flexible and independent
elements (e.g. CF and GUI-API) that can be considerably
simpler than executable components themselves, keeping
the complexity of an evolving component system under
control. |
