Example Case

Figure 1 represents a client-server based logistics management system called Global Parts System Architecture (GPSA), which will be used as an example case for identifying the problems that will be addressed by the proposed research. GPSA is developed by IBM Netherlands and is used by the IBM organization worldwide.

The client software consists of three layers. The top layer is an application layer, which provides user interface to logistic applications such as stock allocation, navigation of products, ordering of products and forecasting on usage and availability of products.

The middle layer is called service layer, which provides a set of functions to the application layer. These functions are implemented by the components Log Management, Preference Management, Security Management, Command Management, Window Management, and Version Management. Due to space limitations we will not elaborate on these components and only describe them when necessary. The bottom layer is a communication layer that implements protocols for data exchange.

Similar to the client software, the server can also be divided into three layers. The top layer implements a set of logistic applications that are used by the client systems. The server manages a central database in which various kinds of product specifications are stored. The middle layer provides a set of services, such as database management functionality, client communication and coordination functionality to access the database and to preserve the consistency of data within the network. The bottom layer is used for communicating with the clients.

Figure 1. Architecture of GPSA, to be used as a research test case

Problem Statement

Using the example case we will now present two business evolution problems that may be experienced in the design of a broad set of systems. Then we will briefly refer to the state of the art software engineering techniques and describe the problems that are addressed in this proposed research.

Business Evolution Problems

New business requirements and forecasts on the possible use of the system demand extensions to the current architecture. By referring to the architecture, we can identify the following two problems:

- Evolution of client applications may require modifications to the service layer

The current user demands tend to show two characteristics. Firstly, the users desire to connect and use the system through various kinds of devices from small hand-held mobile computers to desktop machines. Secondly, users require more and more client-tailored applications that align better with their specific context.

The current architecture is based on the assumption that client software is executed on a standard desktop platform and cannot run efficiently for example on hand-held platforms. Porting the current client system to different platforms therefore may have a direct impact on the component Window Manager in service layer.

It may be also difficult to tailor applications with respect to the client’s needs because, in the current system, the local client applications serve basically as data entry terminals and the gross of the application functionality resides at the server. For example, if a client requests to have a tailored logistic planning functionality at the client site, the protocol between the client and server site must be changed accordingly. This has a direct impact, for example on the components Log Manager and Command Manager.

- Integration of the system with business platforms may require modifications to service layer

During the recent years, there is a tendency of integrating more and more business processes together. Logistics applications are becoming integral part of workflow systems. The GPSA system is expected to integrate with third party components and systems as well. This may require modifications to the service layer. For example, integrating the GPSA system with a customer’s platform may require more strict security policies. This will cause a direct impact on the component Security Manager of the service layer.

Problems with the state-of-the-art Object and Component Technology

The state of the art object and component technology may offer some possibilities to cope with the evolution problems of the GPSA system. First of all, a product-line architecture [12][11] can be developed for creating different versions of the product based on the customers needs. Further, various application frameworks [2] can be built for the logistic domain and the system domain, which will enable flexible composition of applications through instantiations from the components of the framework. Application frameworks can be tailored with respect to the changing context through refinement and substitution using common object-orientation mechanisms such as inheritance and polymorphism. One may apply various patterns to support the adaptability of the system. For example, the Model-View-Controller (MVC) pattern [5] helps to decouple the user interface code from the application code. This pattern supports porting of the client service layer to different platforms so that different devices can be connected. The Command pattern [15] can be used to dynamically extend user interface menus. By using Bridge and Strategy patterns [15] it is possible to dynamically adapt implementation of the components and to support dynamic configuration and tailorability.

The current GPSA system has been in fact developed using these principles. A common product-line architecture has been developed and implemented as an application framework. The user interface design has been based on the MVC pattern. Various other patterns have been applied to cope with the evolutionary requirements. Despite of these useful techniques, however, there are still a number of problems that could not be solved satisfactorily:

- Crosscutting concerns (aspects)

The current software engineering approaches are generally based on the separation of concerns principle, in which objects and components are used to represent the concerns. However, certain concerns cannot be easily captured by these[1] abstractions.

Consider, for example, the MVC pattern. This pattern is based on the assumption that the application functionality and the user interface can be decoupled from each other by locating these concerns into separate components. The view component implements the interfacing functionality whereas the model component implements the application. There is a change-propagation protocol between these components, which notifies the views if the corresponding model is changed. Although this pattern works well for a number of applications, certain problems may be experienced within the context of the GPSA system. First of all, if the system is ported from a desk-top machine to a hand-held machine, not only the view component, but also the model and even change propagation protocol need to be adapted to cope with the demands of the new environment. Moreover, integrating the system with the client’s application context may even require changes to the service layer. In other words, evolution or changes to client’s application generally affects multiple components in different layers. To cope with this problem, these so-called crosscutting concerns, or aspects [6], must be adequately represented as first-class architectural abstractions, so that they can be refined, extended and composed.

We have also identified some system-level aspects that hinder the evolution of the GPSA system. For example, although, a specific architectural component LogManager has been defined, logging is a concern that is scattered over various components. Integrating the system into the client’s context may require changing the logging functionality, which on its turn will require updating all the components that include logging code. Another example of an aspect is the dependency among the components Log Management, Command Management and Security Management. This dependency does not necessarily causes a problem in a static configuration. However, if the service layer is modified, for example, to integrate with the client’s specific platform, this dependency may cause modifications to multiple components. For example, the architectural component SecurityManager keeps track of security information for all existing connections. It checks user ids and passwords to ensure that secure data is only accessed by the right clients. This has a direct impact on LogManager and CommandManager and requires the interaction between these components. The component CommandManager requires knowledge about the security modes for enabling the commands to appropriate clients, whereas the component LogManager is also responsible for securing the logged data.

Unfortunately, as published by various researchers and as experienced within the context of the GPSA system, the current component models cannot represent aspects adequately [6]. This generally increases complexity and reduces adaptability and extensibility of the crosscutting concerns.

· Tailoring is not trivial and requires tool support

To fulfil the expectations of the GPSA clients, two complementary requirements must be met: (1) enhancing the tailorability of the system by separating the fundamental concerns from each other; and (2) by providing tools for tailoring the system according to the client’s needs. The first requirement has been discussed in the previous section. In the literature, various researchers and practitioners have indicated the difficulty of tailoring[2] product-line architectures and application frameworks for specific business needs. Even for a simple architecture, the set of refinements can be quite large.