Grounding EUD on Software Professionals Knowledge Artifacts supporting integration
Stefania Bandini, Carla Simone
Department of Computer Science, Systems and Communication
University of Milano-Bicocca
Via Bicocca degli Arcimboldi, 8
20126 Milan (Italy)
e.mail: {bandini,simone}@disco.unimib.it
Abstract
Component based design as a technique supporting application tailorability raises a crucial problem: to define the criteria governing the composition of components so that the greatest level of flexibility is guaranteed according to user needs and different applications. This is specifically relevant when composition involves the integration of services and COTS. This problem is common between end-users when they engage in EUD, and software professionals. This fact emerged during a project aimed at developing a Knowledge Management system handling the core-knowledge needed to integrate software components to design complex web services architectures. The core of the system was based on knowledge artifacts used by different software professionals in their interactions among themselves and with the customers. This chapter describes the above experience and the lessons learned that can be useful in EUD, when it is interpreted as a creative discovery of components to be integrated.
Background and Motivations
The success of software applications supporting end-users in their every day activities are based on two main factors: on the one hand on the quality of the application in terms of criteria like correctness, robustness, maintainability and the like, and on the other hand on the degree of compliance the application shows with end-users changing needs in the short and medium run. These two factors are in some way contradictory. In fact, quality presupposes a set of professional skills, knowledge and abilities in the design and development of the application that are typical of software professionals. Compliance with needs presupposes a deep knowledge of the context where they raise that is owned by end-users only.
In order to overcome the above contradiction End-User Development (EUD) and tailorability are two approaches focusing on differentways to empower end-users: the former makes them active in the construction of the applications supporting them, while the latter refers to properties the software artifacts have to possess in order to make EUD possible. Each approach has been articulated in different ways according to how development and tailoring are interpreted. Without pretending any sort of systematic analysis, two coarse level strategies can be identified. The first one interprets software development as the end-users construction of specific pieces of software In this view, the problem is to provide them with new programming paradigms and languages that are more usable than the traditional ones and possibly integrated in a production environment guaranteeing basic software qualities (Goodell et al. 1999). The second strategy interprets software development as constructing new applications from existing components. In this view, the problem is to provide end-users with composition mechanisms that help them achieving the goal. These distinctions do not prevent that, in real situations, both approaches could be combined to give in the hands of end-users increasingly powerful tools to adapt applications to their needs. However, for the time being each research effort seems to be focused on one of the two main approaches only.
The contribution of this chapter goes in the direction of a component based approach (Herzum and Sims 2000 ). The main motivations are both conceptual and technical. First, in our interaction with end-users during projects aimed at the design of supportive tools we recognized that the notion of “system” is the most naturally (although often unconsciously) applied by them to speak about their context, their activities and goals. Components and their interactions are closer to the notion of system than to the one of procedure (algorithm) typical of programming. Second, constructing applications from components more easily fulfills the quality requirements since components are developed by professionals (presumably) with the necessary skills. Moreover, the current trend in professional development is based on reuse and composition which again call for a modular, component based approach. Hence, component based architectures are likely to become the most widely ones structuring new applications, i.e. the software artifacts most candidate for adaptability.
Component based design can be further refined into two main categories: the composition[1] of a set of components ideally belonging to the same adaptable application or as the integration of self-standing components made available by different suppliers , the so called services or COTS (Morisio et al 2000, Morisio et al 2001). This distinction is reflected in two activities performed by software professionals: systemconfiguration and system integration that, although conceptually similar, are pragmatically quite different. The former is more about the composition at the functional level while the underlying infrastructure is in some way provided together with the components themselves. The latter implies the coherent selection of both functionalities and infrastructure components making them operational.
Accordingly, EUD can be viewed as composition or integration and end-users as composer (Teege 2000) or integrators. Both views are possible, and again may coexist in the same reality. However, we focus our attention on the role of integrator since the current and expected trend in software production is likely to create this situation in an increasing way. In this view, integration is an activity that requires a specialized support to improve EUD.
One of the main aspects characterizing integration is that it exacerbates the role of the so called non-functional requirements in obtaining the quality of the final application from the end-user point of view. In fact, beside functional requirements oriented to guarantee the desired set of functionalities and their correctness, non-functional requirements have to be taken into consideration during composition since many solutions are possible for the same set of functionalities, with different properties in terms of non-functional requirements (Chung et al. 1999). The latter are more oriented to the pragmatic aspects of the application, which are the ones more related to its current context of use. As alluded earlier, the knowledge about the context of use is specifically owned by end-users.
As a consequence, EUD based on integration requires that end-users can access information not only concerning the functionality incorporated in the various components but also information about their characteristics that affect the fulfillment of the desired non-functional requirements. It is important to notice that this need is recognized also by professionals playing as system integrators. In fact, these characteristics are seldom described in components documentation. On the contrary, they emerge from the combination of the experiences gained by the different kinds of professionals cooperating in the production team: professional experts in technical aspects, in the application domain, in the organizational contexts, in the risks that some solutions are more likely to run into, in the overall costs of an experienced solution.
This points to the cooperation aspect of software production, an aspect that is relevant in EUD too (Mørch et Mehandjiev 2000). In fact, tailoring applications used and shared among several users (typically, cooperative applications) implies to look at them as a team of non-professional designers with different experiences, contexts, goals, skills and so on. The final solution results from the combination of all those end-users experiences, stratified in their current and past tailoring activities. In other words, tailoring becomes an activity where explicit and tacit knowledge are jointly put at work.
The management of explicit and, especially, tacit knowledge (Nonaka and Takeuchi 1995) is perceived by professional developers as a crucial factor for the success of their core activity. Hence, it is worthwhile to look at them and see how they find solutions to overcome this problem in order to improve the quality of their products and the productivity of their design effort. From this observation it is then possible to conceive of tools than can be given in the hands of end-users to support EUD. The following sections will illustrate this point.
The chapter is organized as follows. The next sections illustrate our experience in the design of a tool supporting the software professionals of a system integrator company to improve the effectiveness of their production processes. The outcomes of this experience are then reconsidered in the light of EUD in order to identify tools that may be used in combination with other tools proposed in the literature. Final considerations highlight how the proposed approach could be further developed.
2. Knowledge artifacts supporting professional design
We have been recently involved in a project sponsored by an American Telecommunications Company (Telcordia Technologies - Morristown - NJ) whose aim was the design of a technological support to software integration, one of the company’s core business(Bandini et al. 2002-a, Bandini et al. 2002-b ).The problem triggering the project was the need to improve the productivity of the problem solving effort integration requires to design software solutions in front of customer requests. The latter are of course all different: however, the required problem solving refers to recurrent design aspects and relies on the overall experience the involved professionals gained in previous integration efforts. The challenge was to identify a support that is actually usable and used by these professionals and at the same time powerful enough to manage the complexity of integration. It was immediately evident that improving the productivity in this context means to facilitate the stratification of experience and the fruition of the related knowledge without breaking the mechanisms actually put at work by these professionals to interact and cooperate. A knowledge acquisition campaign was conducted to uncover these mechanisms and base the solution on them. In the following those aspects of this study are reported that are relevant to the theme of EUD.
The roles involved in the integration process are both technical and non-technical. Beside the obvious software competencies owned by software engineers, integration requires the competencies of business managers about the market in terms of technological products and customers needs to define the company’s strategies, and the competencies of consultants about the direct interaction with customers in order to define the most suitable solution in front of their specific needs. Moreover, software engineers competencies are specialized according to various technical domain: for example, web technology, communication technology, and so on.
In this situation of fragmented and specialized competencies, leading to fragmented and specialized professional languages, what makes cooperation possible? In the specific case, what makes sharing of experiences possible? The observation showed that people playing the above different roles form an implicitly defined community of practice that is identified on the one hand by the common goal to make the company successful in the software competitive market and on the other hand on a community language that makes the community survive through the exchange of the experiences needed to achieve the above goal (Wenger 1998).
The community language became the focus of the investigation. It borrows elements from all the involved specialized professional languages but it is different from any of them. In fact, it captures the subset of concepts and relations that are meaningful for cooperation, and what is more important, at the level of detail that makes mutual understanding possible. Those concepts and relations with their level of specification constitute the elements of tacit knowledge artifacts that are cooperatively maintained and used by the professionals during the integration processes. These artifacts were incorporated in the design of the aimed technological support to integration. Before describing it more in details, it is interesting to notice that a similar situation was recognized in another project targeted to a completely different domain. The path to discover the pertinent knowledge artifacts was quite similar and led to an analogous technological solution (Bandini et al. 2003).
2.1 The knowledge artifacts
The design of software products through the integration of COTS, encompasses the selection of a set of components that fulfill the functional and non-functional requirements answering the needs of specific customers. The former concern both the user oriented functionalities and the services provided by the infrastructure supporting them, the latter concern various aspects of the quality of the desired solution. In other words, the aim is to define the application and the infrastructural components architecture that can interact guaranteeing an acceptable degree of quality.
2.1.1 The Components Model
The company’s jargon recognizes two kinds of components that are called Business Components (BC) and Middleware Service Components (MSC), respectively.
A business component is the implementation of a business concept that is a specific functionality. For example, a credit-card system component implements the business logic that deals with the process of payment by credit card. It was recognized as a common practice that functionalities are associated with BCs by definition: hence components implement well-known business concepts, and experts use that knowledge to assembly software systems. MSCs define the environment for business components, and therefore support their inter-operation. One relevant attribute of a MSC is its compliance with standards. An Enterprise Java Bean (EJB) container is an example of MSC that defines the services an EJB component can access and, in particular, how it communicates with other EJB components.
One of the core aspects of integration experience concerns the knowledge about how the above components can be safely combined. To this aim, a set of basic relations are used to link the two kinds of components. BCs can be related by collaboration by dependency meaning that it is part of the experience that a component requires another component to provide its functionality. For example if there is a BC that supplies the billing functionality, it is common practice that also a BC that supplies the tax handler functionality must be included since the two functionalities are logically co-related. A similar relation holds among MSCs. Compatibility by dependency means that a well-experienced compatibility relation is defined between two MSCs. For example, it is well-known by web experts that the Tomcat web server and the JBoss EJB container can be used together to develop web-based applications. Finally, two symmetric relations link BCs and MSCs: the requires relation encapsulates the need of a BC for services that can be supplied by one or more MSCs. The supplies relation identifies the different services supplied by the MSCs and can be viewed as the logical counterpart of the BCs requires relation.
In the above description the crucial point is that all the recognized knowledge has to be “part of the experience”. In fact, relations do not express “official” knowledge that can be derived from components documentation (in the broad sense). They express facts that have been experienced: they can complete but also contradict the official information. In this respect, they incorporate the core knowledge characterizing the company’s community of professionals.
Beside relations by dependency, the professionals use two other relations: collaboration by design and compatibility by design. These relations capture the stratification of experience in terms of integration of BCs and MSCs (respectively) towards an open-ended set of software products that can be delivered to the costumers. Experienced architectures can be re-used as they are or taken as a starting point in the negotiation with costumers.
Figure 1:The Component Model
The above described component model is summarized in Figure 1 and constitute the first knowledge artifact that professionals use to organize the Component Repository (Comp-Rep). The advantage of transforming it in a computational artifact is that is can be endowed with functionalities supporting the selection of components. Typically, it helps professionals in completing the selection in case of missing components linked to the selected ones in terms of by dependency relations. Moreover, the requires relation is used to identify all the MSCs that supply at least one of the services required by the BCs. It might be the case that none of the MSCs that are available provides a required service. To handle this situation, the concept of ghost-MSC is introduced as a place holder to complete the system architecture. The support identifies the characteristics that the actual MSC must have in order to satisfy the requirements: this information guides its acquisition in the market or its implementation. Relations by design are more problematic since they require human reasoning for their usage in the construction and validation of the ongoing architecture. In fact, relations by design can express needs that the previous solutions could not have been considered. Anyway, the given structure of the Comp-Rep helps professionals in identifying the new solution and to insert it as a piece of experienced design, i.e., as a new piece of core knowledge. In addition, the knowledge acquisition campaign highlighted patterns that are recurrently applied to obtain consistent solutions. Basically, for any pairs of BCs related by by design relations, the patterns search the Comp-Rep for MSCs or combination of MSCs in terms of by dependency relations that can construct a path connecting the MSCs required by initial BCs. Figure 2 proposes typical ways by which a by design relation can be “implemented” by different structures of MSCs linked by compabilityby dependency relations or by the compliance with the same standard (case d).
Figure 2: possible configurations that satisfy the compatibility relationship between MSCs
These patterns have been incorporated in a rule-based module that can be activated by the designer when desired. This kind of interactive support is especially useful for new-comers, un-experienced professionals who are unaware of the common practice of the professionals community. In fact, this practice emerges from, and can be experienced in, the dialogue supporting components selection.