Well developed applications adhere to the concepts of Design by Contract and Encapsulation. [shutterstock: 367431665, Daniel Jedzura]

Well developed applications adhere to the concepts of Design by Contract and Encapsulation. [shutterstock: 367431665, Daniel Jedzura]

ABAP development: Agreements must be kept!

Design By Contract and Encapsulation are two central concepts in software development. They promote security and stability. Well developed applications adhere to these principles.

But for whom does this mean security and stability? For the client and the supplier!

Typically, a module makes contracts available. Each of these contracts describes what is expected as input, what is done, and in some cases, what is returned as a result. In software development, the same principle holds as in other areas of life: “Pacta sunt servanda!” (Latin; English: agreements must be kept).

Here too, as in life, there will sometimes be differences of opinion as to what constitutes successful fulfillment of a contract.

ad_banner

The encapsulation referred to above means, on the one hand, that the client does not need to know how the assured service is actually performed. On the other, it means that the supplier has the opportunity to check the required inputs before continuing to work with them.

The Classic Bank Transfer

An analogy is to picture the classic paper-based bank transfer: Mr. Fisher fills out the bank transfer form. As inputs, he enters the name of the recipient, the IBAN, the transfer amount, the purpose of the payment and, optionally, the transfer date (and also the date and his signature).

Mr. Fisher places the form in the designated box.

To Mr. Fisher, it doesn’t matter in the slightest whether if it is Mr. Miller or Ms. Taylor at the bank who receives the form and carries out the transfer.

In turn, Mr. Miller or Ms. Taylor each has the option check the input parameters, e.g. whether the IBAN is correct or the transfer form has been signed correctly.

In addition, the bank checks whether the account has sufficient funds to cover the transfer. If all boundary conditions are in order, the transfer is made and, as a result, the amount disappears from Mr. Fisher’s account and appears in the account of the recipient.

A confirmation of the transfer is also generated for the remitter.

Perspective on Problems

If one was to circumvent this defined contract and access the internal transactions directly, a number of problems could occur for both sides:

Let’s suppose that Mr. Fisher never learned how to fill out a bank transfer form but always made a call to Mr. Miller or Ms. Taylor at the bank. But now, for some reason, Mr. Miller or Ms. Taylor can no longer be reached.

In any case, Mr. Fisher can no longer transfer any money and, since he is a slow learner, it will take several months until he learns to fill out a bank transfer form. During this time, invoices accumulate, he receives reminders including reminder fees and overdue fines and finally a letter from a collection agency.

From Mr. Fisher’s perspective, this is a less than desirable situation.

From the bank transfer scenario, we can clearly see that direct write/read access to an internal field of a module is not subject to any plausibility checks at all and can therefore endanger the integrity of the application.

Now, let’s consider the situation from the bank’s perspective. What problems can arise here? Let’s suppose that Mr. Miller and Ms. Taylor are both convinced of the inherent goodness of their fellow humans and that they carry out all the wishes of any person without query or suspicion.

So, either Mr. Miller or Ms. Taylor is working on Mr. Fisher’s bank transfer form and all required checks are okay. Then the telephone rings and a voice requests that the transfer amount should be transferred to the recipient’s account as intended but that it should be debited from Mr. Schmitt’s account rather than that of Mr. Fisher.

Of course, Mr. Miller or Ms. Taylor comply immediately with the wishes of this mysterious voice. Incidentally, Mr. Schmitt is very surprised the next time he reviews his account statements. From the bank’s perspective, this is not a desirable situation, either.

Looking at ABAP

Now, leaving the analogy aside, we return to the programming situation: ABAP offers programmers opportunities to circumvent defined interfaces and to directly access internal fields that are normally hidden.

As a consequence, the principles of Design By Contract and Encapsulation described above are circumvented.

From the bank transfer scenario, we can clearly see that direct write/read access to an internal field of a module is not subject to any plausibility checks at all and can therefore endanger the integrity of the application.

Furthermore, the accessed field can disappear at any time, e.g. in the context of a software update. Direct access to fields within a module thus compromises not only the security but also the stability (robustness) of an application.

For this reason, VirtualForge CodeProfiler for ABAP provides test case no. 304, tailored specifically to this situation. This tool is capable of finding such code sequences and thus enables QA to review these and the developer to clean them up.

This article was first published by Virtual Forge.

You might also like

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *