Event Based Programming :Loose Coupling In Applications

What is an Event Based System?

A software system is said to be event-based if it parts interact primarily using event notifications. In this context, a part is anything containing code, such as a module of functions, an object, or a component made up by classes and objects. Notifications are basically signals sent from one part to another, in response to an event.

Source:  Book “Event Based Programming, Taking events to the limit written by Ted Faison.

Merits of Event Based Systems:

• It is easier to build, test and maintain.
• It reduces the overall complexity of the system.
• It tries to solve the problem of coupling in systems.

All architectures cannot completely solve the problems of system design hence Event Driven Architecture has some side effects too including:

• An increase in complexity at the local level : Parts that interact in event-based systems are generally simpler from coding standpoint but their operations can be difficult to understand without understanding the whole or seeing the rest of the system.

In the merits of Event Based System,i made mention of event-based systems trying to solve the problem of coupling. At this point, one will ask what is actually coupling?.

Coupling

It is the single greatest problem in large software systems. To measure coupling in a system, one will define coupling as the measure of the strength of association established by a connection from one module to another. In the event context, module  can be considered component.

One coupling scenario is circular coupling. Build tools like Maven helps to minimize this type of coupling between module dependencies.  Coupling is mostly cited with another parameter called cohesion.

In their paper, Stevens et al. defined cohesion as the degree of connectivity among the elements of a single module.

Theorem 1 from Ted Faison: It is impossible to build a software system in which all components are completely decoupled from each other.

Common coupling scenario is coupling introduced by instantiation of  classes which can be solve by a binder.

In the next blog event(trying to process my blog with events) will look at more coupling scenarios and how to fix them, and expressed coupling mathematically.

the word coupling represents a measurement of some kind between the i-th part and all the other n-1
parts in the system. In the next section, I’ll introduce a mathematical symbol to represent coupling.
A bit later I’ll show how to measure coupling.
An important job during the design phase is to reduce the overall coupling in a system to the
lowest level possible. But a problem arises: How do you know when you’re finished? In other words,
how do you know when coupling is at the lowest level possible? The goal is to ensure that all complex
classes and components are entirely decoupled from other components. To accomplish this, and
because you know that you can’t eliminate coupling completely from a system, you must find ways
to shift coupling around in the system until it occurs only in desirable places. The rest of the chapter
shows ways to accomplish this nontrivial goal.
The Coupling Symbol
Coupling is a kind of dependency between two entities, but no universal symbol exists to represent
coupling in software diagrams. Unified Modeling Language (UML) relies on the use of stereotypes to
depict relationships. The <<uses>> dependency is often used to indicate a dependency between
components, as shown in Figure 1-2.
Figure 1-2. Showing coupling with the UML <<uses>> stereotype
The diagram simply tells you that C1 uses C2. The problem is that there are many ways for C1 to
use C2, so you have no idea what sort of coupling exists between C1 and C2, or if there is any coupling
at all. If there is, does it affect compile time, run time, or both? Is the coupling due to the use of userdefined
types or not? Knowing the kind of coupling you’re dealing with is not an exercise in futility,
because each kind can affect different phases of the software development life cycle in different
ways, introducing constraints in the project.
Given the significance of coupling in software systems, I’ll use a dedicated symbol to represent
coupling in diagrams and logic equations. The symbol is 􀁶. Using this symbol, the previous diagram
becomes the one shown in Figure 1-3.
In some math and physics textbooks, the symbol 􀁶 is used to indicate a proportionality relationship.
The decision to use this symbol for coupling was not entirely arbitrary, because proportionality
is a form of dependency. For readers wishing to reproduce the symbol in their own documents, the
coupling symbol is available in the Symbol font in Microsoft Word. The symbol is not a Greek letter
and should be read as coupling or is coupled to. There are several ways in which classes, objects, and
components can become coupled, so I’ll use subscripts to denote the specific kind of coupling in
effect at a given time.
􀂦􀀠

~ by frankappiahnsiah on September 3, 2009.