Introduction to Form-Oriented Analysis
What is the business logic of an enterprise system? How do I specify it in such a way that I know how to transform it into a running system, by skill and by automated tool support? Form-oriented analysis is a holistic approach to the modeling and development of business logic for enterprise systems.
Enterprise systems are a distinct and highly complex class of systems. They are characterized by their pervasive importance for enterprises themselves, making them mission critical, by their extreme multi-user capability, by their tolerance of heavy loads, and by their tight integration with the business processes, which makes every enterprise system installation unique. In short, they are one of the most fascinating yet most demanding disciplines in software engineering.
Enterprise applications can be singled out within the domain of database applications in general through a number of typical characteristics, which are usually not discriminating if seen in isolation, but which together characterize enterprise applications. An example of a database application very different from enterprise applications is a typical genome database.
Enterprise applications store amongst other things data describing events in time. The enterprise system is critical for ensuring data consistency and allowing action consistent with those data in particular. An enterprise system installation controls a certain defined domain, and the correct assignment of the installation and domain is itself part of this consistency effort, i.e., installing and using the system a second time in parallel in the same domain leads to serious problems. This does not mean, that multiple installations with correct information about their domain cannot cooperate. It just means that enterprise system installations are in a certain sense territorial.
Form-oriented analysis is a novel framework, which is easy to learn and practically applicable yet theoretically powerful. It introduces the form-based system specification as the key notion for the conceptual definition of business logic. It explains state-of-the-art modeling languages and their usage for specifying business logic and for the subsequent building of enterprise systems. The techniques presented here are applicable to enterprise systems of all sizes.
Enterprise Systems
Enterprise systems are a type of system where so-called business rules are automated. The term business rule refers to a high-level data manipulation rule, which is executable manually or mechanically. Business rules or parts thereof which are not mechanically executable require as a matter of fact human intervention, especially human judgment. This may occur in the case of primary data input, e.g., a machinist reports to the system that one of the company's vans is currently inoperative. Or it may occur at even more obvious decision points, e.g., the bank in the town finally decides that you can get a mortgage for your house.
But business rules also contain straightforward computations, which we expect today to be executed by a system, or which we even require to be done, not only for convenience, but also for security and data integrity, like the tax on a purchase computed by a cash desk.
There is an intricate relationship between business rules and enterprise systems. Enterprise systems have a distinctive look and feel, because they are mainly systems for managing business rules. On the other hand, if you have a business rule, it is at least conceivable that it will be executed or supported by an enterprise system. Take as an example your mortgage. If you ask your banker about it, the banker should and probably will draw up a financing plan in which you can see what you have to pay each month and what you still owe afterwards. The banker will probably do this on a small office application on a PC. Such an application is certainly not what we typically call an enterprise application. But, nevertheless, in the same way it might be quite possible that you can get the same plan from the web portal of the bank, perhaps created by a part of the bank's enterprise application. You may doubt that this web system offers such a huge added value over the PC, but in any case it hints at the common properties of business rules.
Form-oriented analysis defines a uniform viewpoint on business rules, the form-based metaphor. We will learn a general method for describing business rules as functionalities, or features of a form-based system. The motivation is not in any way the assumption that business rules must be executed with form-based systems. It is rather the goal to have a common notation, which allows comparisons of different business rules in a common language. If we therefore model a business rule like the mortgage computer above as a part of a form-based system, it is based solely on the assumption that it is possible to model the system in such a way, but not on the belief that it is necessary to do so.
One interesting advantage of this uniform modeling approach for form-based systems is, indeed, that by subsuming business applications under this model we single out a well-defined category of system properties in the following, slightly tricky sense. By viewing every business rule as performed with a form-based application, we abstract from the properties of the application, which make no difference in this type of interface. For example, whether a system is used from a touch screen on dedicated terminals, or as a web application over the Internet, might not make a difference with respect to the description of the form-based interface. These differences nevertheless can and should be recognized, but they somehow belong to a different kind of property. The key advantage is to gain a useful classification of different types of system requirements. We therefore introduce the term business logic requirement in order to refer to such requirements, which we can express as requirements of the system within our form-based metaphor. In other words, the subsumption of applications under the form-based metaphor is our operative method to separate the business logic requirements from the whole requirement mix. Business logic requirements form the part of an organization's business rules that are to be mechanically executed by the enterprise system.
A full requirements description of a system will consist of the business logic requirements gained in this way as well as all more general requirements. Form-oriented analysis focusses on the domain of business logic requirements. This does not reduce the importance of the other requirements in any way. Who knows ? Perhaps by making the modeling and implementation of business logic requirements more efficient, one key added value of this methodology may be that more care can be taken for these other requirements.
Modeling Enterprise Systems
Form-oriented analysis defines a precise notion of form-based systems, i.e., the notion of submit/response style applications. This means that in the following we can use the phrase form-based in an informal manner, whenever we want to refer to something that is at least in some sense form-based. On the other hand, whenever we need to refer to an exactly defined concept of form-based systems, we can talk about our submit/response style systems, and we can refer to all the details of the definition, which will be given there.
This notion of submit/response style systems is therefore the framework in which we can model business rules, and it can be seen as a novel concept of a virtual business machine, i.e., a machine, which is directly able to execute business logic, regardless of whether it includes human interaction or not. We can now forge the important notion with which we want to refer to business logic requirements in their form as executable programs of this virtual machine. We call the program of this virtual machine the business logic of the application.
These considerations lead to another key concept in our considerations, namely executable specification. If our business logic can be conceived as the program of a virtual business machine, then our specification method is nothing less than a high-level programming language. In fact, some decades ago, the concept of such languages for data-centric applications appeared so natural that the terminology "fourth generation languages" was coined for these types of languages. This term "fourth generation language" can now be said to be tied to the even more specialized look-and-feel of such a language, like ABAP-4 in the SAP system. Like this example, fourth generation languages are typically tightly integrated into single-vendor platforms. The modeling method presented here can nevertheless be seen as an integration of practical experiences from fourth generation languages into a state-of-the-art modeling style. In principle it is therefore conceivable that a future business platform running as a virtual machine on common platforms can interpret business logic directly.
High-Level Transactional Programming
A central topic of form-oriented analysis is the distinction between high-level programming and specification.
High-level programming is a programming paradigm, which is on the abstraction level of specifications. Yet a high-level programming paradigm must be effectively translatable in efficient code on standard platforms.
The vision of high-level programming is certainly not restricted to the idea of a fully automated translation. This idealized concept of the translation of the functional specification into a running system on a current platform is neither state-of-the art, nor the most desirable concept. The high-level programming vision rather exploits the broad range of programming notions. Consider higher programming languages, which indeed started as a kind of abstract notation, but which were often not translated automatically, but manually. The task of the programming language was to encode knowledge about good program design.
The most important use of a high-level program is perhaps as an input for a generator. The generator translates the system description into a target code, i.e., it can be compared to a compiler approach. However, the translation process is more transparent, in that the target code can be edited. The difference between a high-level programming paradigm and a general specification paradigm is that the former allows only those specifications that are known to be translatable into code. This is not a contradiction of the previous statement, that the translation can also be transformed manually. However, one must be aware of that the code generated from the high-level program may not be a complete implementation: it may well be that there are still system parts that have to be developed manually on the target platform. One could also say that there are also tasks of tuning, which have to be done manually, since the problem is not to generate some code that fulfills the specification and is executable, but to generate efficient code.