Evaluation of Business Rules Maintenance in Enterprise Information Systems

Transcription

1 POSTER 2015, PRAGUE MAY 14 1 Evaluation of Business Rules Maintenance in Enterprise Information Systems Karel CEMUS Dept. of Computer Science, Czech Technical University, Technická 2, Praha, Czech Republic cemuskar@fel.cvut.cz Abstract. Enterprise information systems maintain a significant number of business rules defining complex business processes and constraining data. Contemporary technologies often fail to easily maintain these rules over multiple layers to avoid restatement and duplication. This lack of a single location for business rules makes development and maintenance expensive and error-prone because it is difficult to 1) locate rules and 2) find all instances of a rule in the case of restatement. In this paper, we evaluate four approaches to design and implementation of such systems and compare their qualities in a case study. Approaches include a standard Java EE solution and the novel aspect-oriented design focused on dealing with the rules. Critical metrics include SLOC and rule restatement as they define the maintenance efforts. Keywords Enterprise information systems, aspect-oriented programming, business rules. 1. Introduction Every Enterprise Information System (EIS) implements various business processes and maintains corporate data. Consequently, it consists of a large stack of business rules determined by implemented business processes and data constraints. These rules and constraints are reflected throughout the whole system, from the database through application logic to the User Interface (UI). A common EIS uses the three-layered architecture [5] distributing the logic into three components: the persistence layer maintaining resources the application layer implementing business logic the presentation layer presenting data and operations Business rules spread into all these layers where are interpreted with a different purpose. In the presentation layer, they partially validate the input as client-side form validation and conditionally-rendered components, e.g., only some users are eligible to perform some operation or view the data. In the application layer, they perform full input validation and verify preconditions of executed operations not to violate business process flows. Finally, in the persistence layer, they facilitate basic constraint validation and restrict returned collections of data according to given constraints, e.g., return all active projects led by John. As matter of fact, most of business rules repeat throughout the system as they are considered in all layers (vertical repetition). Furthermore, many rules also repeat inside a single layer (horizontal repetition) as we discuss in more detail in Section 2. For example, only administrators are authorized to execute certain methods. In such case, the business rule definition repeats many times in a code base, i.e., an explanation what it means is restated. Maintenance of such code is very difficult, tedious, and error-prone as there is no single place to update when we want to change a rule. There are various approaches modifying the architecture or introducing some workaround to deal with this common issue. We present their overview in Section 3 with an emphasis on the overall concept. Unfortunately, so far there is no implementation fully dealing with business rules repetition. In this paper, we compare three approaches dealing with business rules repetition to the unoptimized implementation. We discuss them in Section 4. To measure efficiency of the approaches, we conduct the case study in Section 5 and measure the rules repetition and maintenance difficulty. We finally conclude in Section Background Business rules represent a fundamental part of every EIS as business processes determine them. They consist of various types of conditions, from data constraints through access policy to operation preconditions. To illustrate their importance, consider the following small Issue Tracking System whose domain model is in Fig. 1. The system maintains Projects consisting of Issues. For each issue, there are submitted activities such as a comment and a commit. Each User stands in one of three roles: a user, a developer, or an administrator, and is assigned to zero or more projects and zero or more issues.

2 2 K. CEMUS, EVALUATION OF BUSINESS RULES MAINTENANCE IN ENTERPRISE INFORMATION SYSTEM quire significant effort and often lead to inconsistencies in the code base. The authors in [11] recommend the Don t Repeat Yourself principle suggesting capturing every piece of knowledge just once in code. In the following chapters, we evaluate various approaches dealing with business rules repetition and measure their efficiency in development and maintenance efforts. 3. Related Work Fig. 1. Data model of the Issue Tracking application The persistence layer facilitates access to resources, e.g., in a database. It provides storage-independent API to maintain resources with a respect to data constraints. For example, a project s name can never be empty, a user must have a role, etc. Furthermore, it returns collections of instances satisfying given conditions, e.g., it returns issues assigned to the user or all opened issues belonging to the project. The application layer ensures data validation on its input plus it verifies preconditions of each operation. The modeled processes determine them. For example, a user instance on the input must have unique username with length between 6 and 15 characters and a strong password. Furthermore, only unauthenticated users are permitted to sign up. Finally, the presentation layer delivers data to users and facilitates the access to business operations. Web services, input forms as well as UI buttons must respect business rules. For example, the inserted issue must have a name longer than 5 characters, or only the project developers can mark the issue as resolved, i.e., hit the button resolve. Unfortunately, a single rule may cross-cut both horizontally and vertically throughout the system. Consider the operation Resolve an issue. In the presentation layer, the resolve button is visible only when 1) The user is a project developer 1 and 2) The issue state is opened 2. These preconditions are verified also in the application layer, in case the presentation layer is bugged or hacked. This is the vertical repetition. Now, consider the first rule. Such a complex precondition must be verified before execution of all operations restricted to project developers, or before rendering all UI buttons restricted to them. This type of repetition, i.e., the repetition inside of the single layer, we consider the horizontal repetition. Both kinds of repetition cause tedious and error-prone maintenance [6]. Moreover, there are usually multiple technologies as they may differ per layer or component. As there is no single point to update, the manual changes re- Business rules maintenance is a well-known challenge already discussed for many years. The authors of [4] explore a few approaches to business logic maintenance on Java EE platform and conclude with suggestion of using object-oriented design patterns to reduce the maintenance efforts. The authors in [9, 10] propose focusing on business rules, and maintain them on various levels of abstraction to have them maintainable by both developers and domain experts. They suggest maintaining them using CASE Tools and then referencing them from the code to allow their automated transformation. In [2], the authors suggest a similar approach emphasizing the business rules as an important concern. The core idea lies in concerns decomposition and their runtime weaving through aspect-oriented programming. We provide more detail of this approach in the following section. This approach, as well as the previous two, relies on power of domain-specific languages [7]. These custom languages tailored for the particular domain benefit from their fit to the domain, comprehensibility, and the possibility to delegate the responsibility to domain experts. Contemporary EISs usually build on the top of the Java EE or.net platforms, both with similar underlying principles. On the Java platform, the basic idea of dealing with business rules lies in Bean Validation [1]. This technique uses meta-programming (annotations) to enrich the code with additional information, such as constraints and preconditions. We discuss this in greater detail later as it is on of the considered approaches. Model-driven development represents another approach to avoid code duplication [8]. It suggests maintaining various models on a few levels of abstraction and having them automatically transformed into more specific levels, which facilitates the knowledge reuse. Unfortunately, this approach has difficult maintenance as it usually supports only forward transformation. When we perform any change to the code, it is very difficult to propagate it back into the model. Nevertheless, this approach does not conflict with the previous approaches, thus it is possible to use them together to minimize manual code duplication and information restatement. 1 A user with a role developer and assigned to the project. 2 State of the is opened.

3 POSTER 2015, PRAGUE MAY Compared Approaches The paper considers four approaches for design and implementation of an EIS. They significantly differ in the resulting qualities of the code and development and maintenance efforts. In this chapter, we describe the approaches to highlight their fundamental ideas, and in the next chapter, we evaluate them in a case study. Unoptimized development The first approach considers completely unoptimized development. There are used no frameworks or tools for business rules management or representation, and no efforts are made to optimize them. It captures them in a programming language directly in places where they must be considered. Java EE framework stack A standard part of the Java EE platform is JSR 303: Bean Validation briefly mentioned previously. This approach annotates the model fields by additional constraints such for strings matching the pattern for non-empty strings. In addition, it allows annotating business operations to restrict the access by security policy. For DEVELOPER ) makes the operation available only to developers. It is also possible to design and implement custom annotation to express all required constraints. In addition, a framework for the UI development RichFaces 3 reads a subset of these annotations and automatically adds constraints into presented input forms. For example, when we create an input box for an field, it automatically adds its client-side constraint. Unfortunately, this type of business rules representation suffers from serious limitation. These constraints have to be valid all the time, which fits only for a few rules. Usually, a significant portion of constraints is defined by the current business operation and user s context, which we are unable to cover in the annotated model. We are forced to tangle these rules into the code as we mention in the first case. Object-oriented design Authors in [4] suggest using object-oriented design to minimize information restatement. They propose use of validator objects encapsulating rules as self-standing objects and just reference them in proper places. It is also possible to group up simple validators into more advanced validators. For example consider the Issue. Its fields such as name or description are restricted by constraints about their length. In every place validating the Issue object, we invoke these validators to verify these constraints without actually duplicating the validating code, although, it restates the set and configuration of used validators. To avoid that, we create an IssueValidator encapsulating all validator invocations related to the Issue validation. Then we just reference the IssueValidator 3 without any information restatement. We do the same for all business operations if necessary. The down side of this approach lies in multiple interpretations of business rules. While in the application layer we use them to validate the input, in the presentation layer we just translate them into client-side language to perform client-side validation. In the persistence, layer we just use them for integrity constraint declaration. All these different interpretations cannot be covered by simple validator objects. This approach works only in the application layer as we are not able to transform the validators into different technologies and the technology for the UI design usually does not support this kind of validators. Aspect-oriented design The authors of [2] consider business rules as an aspect. They suggest capturing them in a convenient domain-specific language and encapsulate into business operation contexts, i.e., sets of preconditions or post-conditions applied on the particular operation [3]. Then these contexts are referenced from the code, and the rules injection is performed at runtime. This approach deploys automated transformation of business rules into various interpretations, which cannot be done with the object-oriented approach. This helps to deal with the vertical restatement. In consequence, the business rules restatement is very efficiently reduced as they are only in the context definitions. On the other hand, this approach suffers from a significant overhead at the beginning, which results in its difficult first deployment. It requires many changes as it recognizes many aspects: business rules, UI layouts, widgets, etc. For all of these aspects and technologies, there has to be implemented a proper, complex aspect weaver. 5. Case Study To compare the considered approaches, we conduct a small case study. We implement the Issue Tracking system from the previous chapters and measure its business rules restatement, maintenance efforts and SLOC 4. We implement all four approaches on the top of the Java EE 6 platform with JavaServer Faces 2.1 for the UI. Aspect-oriented design approach also uses implementation of the concept provided by the Rule Guvnor project currently using JBoss Drools 6 as a domain-specific language for business rules description. In the project, we identified 33 business operations restricted by 116 constraints including basic model constraints. There are implemented 14 different views providing all 33 business operations. As we can see in Tab. 1, the SLOC metric shows some differences among approaches, although they are not significant. The SLOC analysis does not say much about maintenance efforts. However, in the table we see that the aspect-oriented design has undefined presentation layer SLOC. Currently, there is no implementation 4 Source Lines of Code

4 4 K. CEMUS, EVALUATION OF BUSINESS RULES MAINTENANCE IN ENTERPRISE INFORMATION SYSTEM Component Unopt. Java EE OOD AOD Data Model A Application Layer Presentation Layer B ? Presentation Layer C ? Other 0 89 D 209 E 273 F A Including annotations. B Only in Java files, i.e., backing beans. C Only in XML files, i.e., UI description. D Custom annotations. E Validators implementing business rules. F Business rules declaration in the domain-specific language. Tab. 1. SLOC efficiency transforming the business rules into the presentation layer so we cannot implement nor measure it. The current implementation of the approach for the presentation layer, Aspect Faces 5, supports only layouts, widgets, and model structure but not business rules. Tab. 2 shows business rules restatement in the considered approaches. The unoptimized approach is the worst case; there are no efforts devoted to avoiding duplication. The results show inconvenient constraint distribution throughout the all layers for all but the aspect-oriented design. Although the standard Java EE solution partially deals with the business rules, it still leaves a lot of constraints uncovered and tangled into code base. The object-oriented approach slightly improves the unoptimized solution as we do not restate the constraint definitions themselves, i.e., how to validate it, anymore. However, we restate invocation of validators, which is still tedious and error-prone as we might easily overlook some occurrences. Furthermore, we are unable to deploy this approach into the presentation layer as the technology does not allow it. Contrary, the aspect-oriented design does not duplicate the invocations nor restate the constraints definitions. It only addresses declared contexts to know what rules apply. Therefore it looks like the best solution, however, right now there is no implementation transforming business rules into the presentation layers, which falls back to the worst case. Nevertheless it is supposed to directly use no rules in the presentation layer, it is supposed to be able to deliver the functionality only through the context references. Considering the maintenance efforts, the important criteria are 1) high business rules cohesion, 2) low or no business rule restatement, and 3) the fewest possible places to edit. Looking into the results in Tab. 2, we see that the unoptimized solution is very difficult to maintain. There is high restatement as in code is 299 constraints while the application domain declares only 116, and multiple different technologies to maintain. The Java EE solution slightly reduces the restatement, but the number of technologies is increased by the Java annotations representing another place to consider. Contrary, although the measurement of objectoriented design results suggests no improvement, encapsu- 5 Constraints Unopt. Java EE OOD AOD In model A In SQL B In business ops. C 78 3/56 D 62 0/33 E In UI (Java) F /? E In UI (XML) G /? E Other 0 12 H 15 I 116/33 J A Annotations above fields and referenced validators. B Constraints in SQL to retrieve proper data from the database. C Constraints in bodies of business operations. D If conditions / annotations above methods and parameters E Constraints / annotations or tags referencing the context. F Only in Java files, i.e., backing beans. G Only in XML files, i.e., UI description. H Annotations representing constraints. I Number rules in contexts in domain-specific language. J Number of validators. Tab. 2. Constraint restatement lation of constraints into singleton validators significantly reduces error-proneness. The combination of this with the standard Java EE solution provides better results. The best solution seems to be the aspect-oriented design as it reduces both restatement and the number of technologies. It tangles throughout the code only addresses of business contexts declaring sets of rules to apply. Unfortunately, as there is no implementation transforming the rules into the presentation layer, the results cannot verify this hypothesis. 6. Conclusion Business rules represent a crucial part of an EIS; they define processes and constrain data. EIS developers face the challenge of business rules maintenance due to their amount and scope of systems. In this paper, we explore four approaches to the EIS design and conduct a case study to compare them. Our results suggest that the standard Java EE solution is only slightly better than the unoptimized approach as the rules restatement remains high as well as the amount of affected technologies. Consequently, the maintenance efforts are high because we must check many places to perform even the minor changes. As the best choice of considered approaches, we recommend aspect-oriented design avoiding the rules restatement and duplication. It also minimizes the number of technologies defining the rules to one, the domain-specific language. Such an approach benefits from high cohesion of the rules and possibility to engage domain experts into development. Unfortunately, this novel approach is not yet fully implemented, and there is no implementation transforming the rules into the presentation layer. Subsequently, we are unable to verify its efficiency in the UI, although it promises interesting results. Furthermore, although the approach delivers high efficiency, its initial deployment and development of supporting tools bears very high initial overhead into the project, which disqualifies it from efficient use for small and medium-sized systems.

5 POSTER 2015, PRAGUE MAY 14 5 Acknowledgments The research was supervised by professor Michael J. Donahoo, Ph.D. from Baylor University in Waco, Texas, and Tomas Cerny from the Czech Technical University in Prague. This research was also supported by the Grant Agency of the Czech Technical University in Prague, grant No. SGS14/198/OHK3/3T/13. References [1] BERNARD, E., AND PETERSON, S. Jsr 303: Bean validation. Bean Validation Expert Group, March (2009). [2] CEMUS, K., AND CERNY, T. Aspect-driven design of information systems. In SOFSEM 2014: Theory and Practice of Computer Science, LNCS Springer International Publishing Switzerland, 2014, pp [3] CEMUS, K., CERNY, T., AND DONAHOO, M. J. Automated business rules transformation. In Procedia Computer Science Journal. Elsevier, [4] CERNY, T., AND DONAHOO, M. J. How to reduce costs of business logic maintenance. In Computer Science and Automation Engineering (CSAE), 2011 IEEE International Conference on (2011), vol. 1, IEEE, pp [5] FOWLER, M. Patterns of enterprise application architecture. Addison-Wesley Longman Publishing Co., Inc., [6] FOWLER, M. Refactoring: improving the design of existing code. Pearson Education India, [7] FOWLER, M. Domain-specific languages. Pearson Education, [8] KLEPPE, A. G., WARMER, J. B., AND BAST, W. MDA explained, the model driven architecture: Practice and promise. Addison-Wesley Professional, [9] MORGAN, T. Business rules and information systems: aligning IT with business goals. Addison-Wesley Professional, [10] THEODOULIDIS, B., AND YOUDEOWEI, A. Business rules: Towards effective information systems development. Business Information Systems uncertain futures (2000), [11] THOMAS, D., AND HUNT, A. The pragmatic programmer: From journeyman to master, 1999.