5. Related Work

An approach described in this paper is being developed within a new paradigm which covers several branches in computer science including programming, data modelling [1,2,3] and system design. The concept-oriented paradigm is based on several general principles that distinguish it from the currently existing theories and approaches. In the context of programming the most important concept-oriented assumption is that system functionality is concentrated on space borders. In contrast, in object-oriented paradigm it is assumed that most of functionality is concentrated in objects themselves. Concept as the main programming construct allows the programmer to describe effectively not only what happens in objects but simultaneously what happens when they are being accessed.

The concept-oriented programming can be considered a continuation of a very general and deep principle of Separation of Concerns formulated by Dijkstra [4]. The main idea of this principle is that any problem or system functionality can be viewed from different points of views or concerns. One specific feature of our approach is that we distinguish two main concerns any program consists of: BMs and RA. Currently there exist different techniques for separating business methods from representation and access functionality but they can be broken into two main categories: methods based on dedicated middleware and approaches based on programming languages.

The idea of middleware-based approaches consists in creating special software and hardware environments where a conventional program will run. Such an environment offers a number of functions that are intended to support custom RA functionality. This special environment can exist and be accessible to running programs in very different forms, for example, as part of an operating system, an object container, a service, a dynamically or statically linked library etc. However, the main property of this approach is that the programming language remains the same while the support is provided by developers of the middleware. In particular, it is not easy to develop a new custom environment or adapt the existing environment to the purposes of each concrete program.

One wide-spread class of middleware is techniques for remote procedure calls. Examples of such middleware platforms are CORBA and RMI/EJB [5,6]. Such an environment provides facilities for creating remote references and then making transparent method calls. Although such an approach provides much more flexibility in comparison with the manual remote method invocation, they still have serious limitations. First of all we are not able to change the format of remote references and the underlying invocation protocol. Such middleware platforms may fit well to the purposes of one system but may be inappropriate for another system. Their adaptation possibilities are very limited and such an environment is separated from the rest of the program.

A more flexible approach to separating two concerns consists in using reflective environments and metaobject protocols [7,8,9]. The idea of this approach consists in providing a mechanism for changing the behavior of the language from this very language. Normally programming languages are defined in such a way that their behavior cannot be changed. In particular, we cannot change how objects are represented and accessed because it is defined at the level of the language environment. The reflective approach allows the programmer to change this environment and to influence its behavior. Such an approach can be viewed as an intermediate between middleware and programming languages because on one hand the programming language (reflective) environment is separated from the language itself like in middleware approaches. On the other hand, the programming language has special constructs for influencing and changing the environment where it will run.

In the approaches based on programming languages an environment is created within the language itself and using this very language. In other words, the program is responsible for creating and maintaining its own run-time environment. The functionality, which is normally implemented in some standard middleware, is now an integral part of the program written in the same programming language as the rest of the system.

One wide-spread technique to automating intermediate RA functions consists in using static or dynamic proxies [10]. Proxy is a special class that emulates an interface of the corresponding target class but inserts some intermediate functionality. These intermediate functions of the proxy class are called before target methods and hence they effectively intercept all target object method invocations. The trick here consists in using proxy class instead of the target class. Thus it is not a real interception but rather a normal sequence of method calls. In other words, in the source context a reference to the proxy instance is created and hence its methods are called when it is used. Then it is the task of the proxy to decide what to do if some its method has been called. Normally, after some processing the corresponding target method is called. One disadvantage of this approach is that it requires significant manual support and is not very general. It is more a special technique or programming pattern rather than a programming paradigm. Here are other disadvantages of this approach:

• If a target class changes we need to manually change its proxy class.
• For each target class we need to develop its own proxy while in many cases proxy functions are rather general and can be used by many target classes.
• It is difficult to impose behaviour in a nested manner (creating a proxy for proxy).
• It is difficult to develop custom references which are stored by value instead of native references.

An interesting solution to the problem of developing custom references and intermediate behaviour consists in using smart pointers in C++ [11]. However, it is also a specific technique rather than a general programming approach. A more general solution consists in using the mechanism of annotations. The idea of this approach (called attribute-oriented programming) consists in marking places in code where some intervention is needed by special tags. Other related approaches that can be used to automate intermediate RA functionality are mixins [12,13], subject oriented programming [14] and multidimensional separation of concerns [15]. All these methods allow the programmer to specify how behavioural granules (concerns) have to be distributed throughout the system.

Probably the most interesting approach to solving the problem of separation of concerns is aspect-oriented programming (AOP) [16]. Aspects describe intermediate functionality (and data) injected into the points in the program which are specified by means of regular expression. Thus aspect can be viewed as a special programming construct that modularize intermediate functionality. An important property of this approach is that aspects know explicitly the points where the intermediate functions will be injected while the target classes do not know what other code will modify their behaviour (Fig. 6). Such a structure of relationships between the module with the code to be injected and the modules where it has to be injected can be viewed as declaring in an aspect all the target classes (the target classes being unaware of this aspect). In this sense our approach is characterized by the opposite direction of this relationship (see DG5). Namely, the module with the code to be injected is unaware of the points where it will be used (the target modules). These are the target modules that declare the modifications they need.

Figure 6. Aspect-oriented programming vs. concept-oriented programming

6. Conclusions

In the paper we introduced a new programming construct called concept. Concept is defined as a pair of one object class and one reference class having their own fields and methods (possibly with the same name). Concepts are organized into a hierarchy using inclusion relation with the main purpose to specify how objects have to be represented and accessed. The main idea is that an object is represented by its parent reference which replaces a system default reference. An approach to programming based on this new construct is called concept-oriented programming. This approach assumes that a system consists of two types of functionality: target BMs and intermediate RA functionality. Accordingly, it is important to be able to implement both types as an integral part of one program using one programming language. This new approach to programming can be applied to very different complex problems such as access control and interception, security and object protection, persistence, debugging, tracing and logging, memory and life-cycle management, containers, remote objects, distributed computing, protocol stacks and many others.

References

[1] Savinov, A. Principles of the Concept-Oriented Database Model, Institute of Mathematics and Informatics, Academy of Sciences of Moldova, Technical Report, 54pp., November 2004.

[2] Savinov, A. Hierarchical Multidimensional Modelling in the Concept-Oriented Data Model, Proc. the 3rd international conference on Concept Lattices and Their Applications (CLA'05), Olomouc, Czech Republic, September 7-9, 2005, 123-134.

[3] Savinov, A. Grouping and Aggregation in the Concept-Oriented Data Model, ACM Symposium on Applied Computing (SAC 2006), April 23-27, 2006, Dijon, France (accepted).

[4] Dijkstra, E.W. A Discipline of Programming. Prentice Hall, 1976.

[5] Roman, E., Sriganesh, R.P., Brose, G. Mastering Enterprise Java Beans. Wiley; 3 edition.

[6] Enterprise JavaBeans Technology, http://java.sun.com/products/ejb/

[7] Cazzola, W., Ancona, M. mChaRM: a Reflective Middleware for Communication-Based Reflection. Technical Report DISI-TR-00-09, DISI, Universita degli Studi di Genova, May 2000. 29 pages.

[8] Kiczales, G., Rivieres, J., Bobrow, D.G. The Art of the Metaobject Protocol. MIT Press, Cambridge, 1991.

[9] Kiczales, G., Ashley, J.M., Rodriguez, L., Vahdat, A., Bobrow, D.G. Metaobject protocols: Why we want them and what else they can do. In: Paepcke, A. (ed.) Object-Oriented Programming: The CLOS Perspective, 101-118, The MIT Press, Cambridge, MA, 1993.

[10] Blosser, J. Explore the Dynamic Proxy API, Java World, November 2000. http://developer.java.sun.com/developer/technicalArticles/DataTypes/proxy

[11] Stroustrup B. The C++ Programming Language, Second Edition, Addison Wesley, 1991.

[12] Smaragdakis, Y., Batory, D. Implementing layered designs with mixin-layers. Proc.ECOOP'98, 550-570, 1998.

[13] Bracha, G., Cook, W. Mixin-based inheritance. Proc. OOPSLA/ECOOP'90, ACM SIGPLAN Notices, 25(10), 303-311, 1990.

[14] Subject-Oriented Programming, http://www.research.ibm.com/sop/

[15] Multi-Dimensional Separation of Concerns, http://www.research.ibm.com/hyperspace/MDSOC.htm

[16] Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.-M. and Irwin, J. Aspect-Oriented Programming, Proc. ECOOP'97, LNCS 1241, 220-242, Jyvaskyla, Finalnd, 1997.