Building evolvable Software using ABAP and Event-Based Components

[peter_langner]

In this blog I want to introduce you to the concept of Event-Based Components (EBC) in Software development to develop better evolvable software. This concept is pretty good known in the C# community. But how about ABAP? I tried it out and want to share my experiences with this approach.

1. Coupling

If we want to build evolvable software, then we must find a way to control or at least reduce the coupling of its components. Only if we have small components, which are as independent from each other as possible, we can better test und rearrange them. We speak of a high software quality, if

• we have a low degree of coupling of its components,


• less complexity,


• if it is better to understand, test and maintain and


• enhances reusability.

Coupling is a measure of the strength of association established by connection from one component to another. And we speak of Cohesion as the degree of connections among the elements of a single components. A component is a self-documenting entity containing classes and/or objects.

To depict Coupling Ted Faison uses a dedicated symbol to represent coupling in diagrams. It is similar to the <<uses>> we know in UML and means "... is coupled to..."

Figure 1 - A dedicated symbol to represent coupling

Coupling is bad, but not all coupling is equal. Coupling affects…

• Compile time, run time or both and


• User defined types

We find the following types of coupling:

• Worst: Duplicated Logic -> use the DRY principle (Don't Repeat Yourself)


• Next worse: Coupling that impacts compile time -> Static Coupling


• Most benign form: Coupling, that occurs only at run time -> Dynamic Coupling

Coupling is called static, if the coupling between two objects effects build time.

Figure 2 - static coupling

This means, that to produce A‘s executable code from source code, some part of B must be present. This is the case, if A contains references to symbols in B, e.g. a constant, variable or method.

Coupling is called dynamic, if the coupling between two objects effects run time.

Figure 3 -dynamic coupling

Now what often happens is, that with a class A you refer to a method of class B. Then you have both types of coupling. Static, because a class be must exists during build time and dynamic, because it must be present during run time too, when the object is created.

Figure 4 - static and dynamic coupling

If you use an interface, you can remedy it somehow. Only the interface must be present at build time and the class with implements the interface is only needed during run time. But still A is coupled to the interface.

Figure 5 - Using interfaces for decoupling

(See also Ted Faison, Event-Based Programming - Taking Events to the Limit, APRESS, 2006, Chapter 1).

2. Event-Based Components

The Idea of Event-Based Components is to use events instead of coupling components directly with each other. Regarding coupling the following rules apply:

• The more complex a class or component is, the more it should be decoupled


• Coupling should be introduced into simpler classes and components first


• Reduce the overall coupling in a system to the lowest level possible


• Put the coupling into desirable places

In the following I want to show you the meaning of EBCs using the example of a calculator implemented first in C# and then in ABAP. The specification if shown in figure.

Figure 6 - specification of the calculator

The following picture shows you the implementation in C#. We have two classes, which implement the UI and the business logic, which are not coupled to each other. The coupling only exists to the "main" class Program. In the class, the configuration takes place, when the components are "wired up". This is the domain specific language (DSL) of the application.

Figure 7 - Implementation in C#

The figure 8 shows the same application written in ABAP.

Figure 8 - Implementation in ABAP

Unfortunately in ABAP we have must tell a method in which the event is, it should handle. Whereas in C# this information is only given when the event handler is set.

What can we do about that? Well what I did was to more or less write my own event handler. Instead of an event I declared am attribute with the name of the event, giving it the prefix "ON_" to tell the developer the special role of this attribute. It is a two component structure ZEBC_EVENT, which holds a reference to an object as well as a string, which contains the name of the method.

The macro ZEBC_WIRE_UP imitates a ABAP command to do the setting of the handler (see figure

Figure 9 - Implementation in ABAP with own event handler

3. Conclusion

After building this prototype I was able to try this out in reality programming a full fledged transaction. And indeed testing and rearranging the components was much easier. The price you pay is that the where-used list wouldn't show you the occurrences of the events anymore. But therefore you can be sure to find all occurrences in the configuration part of the object - and no where else.

• What are your experiences with coupling?


• Have you already heard of EBCs?


• Do you think you would give this a try?

I would really like to discuss this topic with you. Please leave a comment or join my Expert Networking Sessions EXP10916 or EXP10917 in SAP TechEd Amsterdam 2013. In the session I am also going to show the real live transaction build upon the principles of EBC.