Product and Process Support to Component-Based Software Development Pere Botella 1 , Xavier Burgués 1 , Xavier Franch1, Jordi Marco1, Josep Maria Ribó2 , and Joan Vancells 3 1
Universitat Politècnica de Catalunya (UPC), c/ Jordi Girona 1-3 (UPC-Campus Nord) E-08034 Barcelona, Catalunya (Spain) {botella, diafebus, franch, jmarco}@lsi.upc.es 2 Universitat de Lleida, P. Victor Suirana 1 E-25003 Lleida, Catalunya (Spain)
[email protected] 3 Universitat de Vic, c/Sagrada Família 7 E-085000 Vic, Catalunya (Spain)
[email protected]
Abstract. In this paper we present the results of the CICYT ComProLab project, ref. TIC97-1158, which addresses to some particular points concerning component-based software development. We focus on comp onents as encapsulation of abstract data types. The project stresses three particular fields: statement of non-functional issues; process mo deling; and efficiency concerns on abstract data type implementations.
1 Introduction Component-based software development is a strategy aimed at building software systems as the combination of individual software components, many of them coming from standard software libraries. A component consists of two sections, a specification and an implementation. − The specification describes the relevant properties of the component in an abstract manner. From our point of view, it includes two parts: the functional one, stating how does the component behave, and the non-functional one, which declares additional requirements referred to some operational attributes (as efficiency). − The implementation provides executable code for the component, usually written in an imperative or object-oriented programming language, and it must satisfy all the properties stated in the specification. Different software components with the same specification may differ in their implementation; this happens because given a functionality, normally it is not possible to develop one implementation that is the best
in all operational respects. As a consequence, implementations will exhibit different non-functional behaviour with respect to the attributes of concern (those ones appearing in the non-functional specification). In this paper, we are going to introduce ComProLab, a project in the component-based software development area [1]. ComProLab emphasizes three particular points that are presented in the next three sections: − Non-functional issues. We have defined a language called NoFun for stating nonfunctional aspects of components, both at their specification and their implementation. − Software process model construction. We have defined a language called Promenade for defining software process models combining: a static part for defining the elements playing a part in the model; and a dynamic part for stating their relationships, both from a reactive and a proactive point of view. − Implementation efficiency concerns. We address to a particular point interfering with efficiency when using components as black boxes.
2 NoFun: A Language for Stating Non-Functionality Software components can be characterised both by their functionality (what the component does) and by their non-functionality (how the component behaves with respect to some quality factors like efficiency, etc.). Both aspects should be considered during their specification, design, implementation, maintenance and also reuse. For instance, focusing on reusability, a component retrieved from a library regarding only its functional behaviour may not fit into the non-functional requirements of the environment, hindering or even preventing its actual integration into the new system. A natural way to take non-functional information into account is to define a notation aimed at stating non-functional requirements of software in the software itself. In our approach we have explored this way by means of the definition of a language called NoFun (NOn-FUNctionality), whose first version was introduced in [2], and a brand new one in [3]. NoFun allows to state three differents kinds of information: − Non-functional attribute (short, NF-attribute): any attribute of software which serves as a way to describe it and possibly to evaluate it. Among the most widely accepted we can mention: time and space efficiency, reusability, maintainability, reliability and usability. In our approach, we allow arbitrary identification and definition of NF-attributes. − Non-functional behaviour of a component implementation (short, NF-behaviour): any assignment of values to the NF-attributes that are in use in the implemented component.
− Non-functional requirement on a software component (short, NF-requirement): any constraint referred to a subset of the NF-attributes that are in use in the component. Currently [3], we have fit the NoFun notation into the ISO/IEC 9126 standard. So, we have different kinds of modules for encapsulating NF-attribute definition. As part of our work, we have studied many applications of NoFun. First, we have enriched the Anna specification language for Ada with NoFun constructs [4], adapted to the required syntax (annotations inside Anna/Ada comments, allowing thus immediate compilation and manipulation with Anna tools). Also we have explored the advantages of using NoFun with respect to software maintenance and (specially) reusability. In [5] we have outlined that adding nonfunctional information in software components make them more robust when maintenance is due to environmental changes and delivery of new versions of software. In [6] we have studied in which way implementation selection can be guided by their non-functional behaviour, yielding to forests of selection trees which hold all the different feasible combination of implementations in given contexts. Next, the language has been used in the domain of software architecture [7]. Nonfunctional information has been added in a structured manner in components and connectors, and this seems to be useful in putting more knowledge in architectural styles, since differents between styles often emerge from non-functional criteria. Last, in the context of our new, emerging research project DALI (Development, Acquisition, aLignment and Integration of software components), successor of ComProLab, we are starting to use NoFun for describing different kinds of components, mainly COTS and ERP systems [8]. We firmly believe that acquisition of commercial software components can be improved with the use of notations and tools for describing the relevant aspects of components and for browsing in those sites that act as components repositories. A particular case study has been developed in the context of ERP systems procurement with promising results [9].
3 Promenade: A Notation for Stating Software Process Models A model for a software development process (i.e., a software process model) is a description of this process expressed in a process modeling language. The process can be viewed as the execution in a suitable order of a set of tasks intended to develop some documents. The tasks are managed by some agents with the help of some tools and using some resources. Hence, the definition of a software process model must state all the elements mentioned above. An important effort has been made to define well-suited process modeling languages and, as a result, some important features have been attained: object-orientation for modeling the structural part of the model; several paradigms for modeling its behaviour; increasing level of abstraction; and so on. However, there are several aspects involved in the act of modeling a software process using these languages that demand a more deep research (see [10, 11] for a more detailed study). This fact is widely recog-
nised in the process technology community and has yield to the rise of the so-called second generation of process modeling languages. One of these new languages is our Promenade approach, described in [12, 13, 14]. A process model in Promenade consists of two different parts. The static model is a conceptual model written in an extension of UML [12] (after a previous attempt using ObjectZ [15]). To be more precise: − We have enriched the metamodel of UML with some new elements which are specifically bound to the software development activity (tasks, documents, etc.) together with their association and generalization relationships. − We have defined a reference model for software development. This reference model provides a starting point common to any model, which can be later refined to formulate particular models. More specifically, the reference model contains all the tasks, documents, etc., that will appear in any component-based software development strategy. The use of UML concepts fits well in some characteristics of process modeling. For instance, complex tasks and documents can be decomposed in a natural way using aggregation. We use also the specialization concept (via generalization diagrams) for stating task refinements. This last point is specially important, because it allows the definition of different refinements for a task, which can be chosen even in execution time, leading thus to the ability of handling incomplete models. In other words, we distinguish between task definition and task implementation (refinement), obtaining a product-oriented view of the process. Concerning the dynamic part, which rules the evolution of the process, Promenade is intented to allow both proactive control (statement of temporal relationships between tasks [16]) and reactive control (response to events). Currently, we have just developed the proactive control [14]. The proactive control is built around the concept of precedence relationship. A precedence relationship states a temporal relationship between sets of tasks. The more salient features of this concept in Promenade are the following: − Unlike other approaches, precedence relationships can relate not only individual tasks but sets of them. This fits better to some usual situations in process modeling. − Instead of having a huge catalogue of predefined precedence relationships, there is just a predefined set of five basic precedence types. These types can be later combined through a precedence type generator to define new types. So, large precedence type repositories can be defined capturing all the identified types of relationships between tasks. − Concrete precedence relationships may be implicitly instantiated in execution time. This is useful when the involved sets of tasks are not totally known in advance. These so-called dynamic precedences are defined through logical predicates, and they come into existence for the tasks that fulfill the predicate during the software process.
Together with these constructs, Promenade exhibits some other ones related to modularity concerns. For instance, there are model combination operators which allows to combine different models into a single one. This combination may be of many kinds: a model can be put after another, allowing temporal connection; or a model can be merged with another, reflecting the join of different kinds of activities during software process. While finishing language definition, we are currently exploring some correctness concerns, both with respect the model itself and related to the correctness of a software development with respect to a model.
4 Efficient combination of Component Implementations In component-based software development it is crucial the distinction between the specification and the implementation of components. A result of this distinction yields to the information hiding principle, which states that the implementation of a comp onent is not allowed to access to the implementation of others. The only way in which an implementation can communicate with others is by calling the operations offered by them. In the case of abstract data type (ADT) components, this means that a data structure E cannot access the fields used to implement other data structures that are components of E. The information hiding principle collides, often dramatically, with a usual requirement on programs: their efficiency, mainly characterised by their execution time. The reason is that the access to a data structure implementing an ADT must follow the properties that define it, which were stated in an abstract manner without taking into account the problems related to its subsequent implementation (as it must be). In case of a context using ADTs with strong efficiency requirements (for instance, program analysis tools construction, system programming, geometric computing and combinatorial computing), their full reusability can become impossible and it may be necessary to carry out many modifications to fit it to this context; even more, such modifications can be so important to decide throwing away the implementation and developing a new one. This conflict between efficiency and modularity is a well known problem in the abstract data type framework, solved in many cases sacrificing modularity to achieve efficiency. The libraries that cope with this problem (e.g., LEDA and STL) present some others drawbacks due to the fact that they are designed with the concept of location (a pointer to access data) incorporated in the component from the very beginning. Therefore, the implementations that can be used for the ADT are restricted to a fixed set (which makes these libraries not flexible enough), the behaviour is less clear (locations and elements appear at the same level) and some classical low-level problems appear (for instance, meaningless uses of cursors and pointers). In our project, we have defined a general framework to reconcile both criteria, efficiency and modularity, obtaining thus efficient programs reusing existing implementations of ADTs without any modification, and following the information hiding princi-
ple [17]. The proposal is based on the definition of an alternative way to access data, that we call shortcuts [18]. Shortcuts are added to existing ADTs in a systematic manner, obtaining new ADTs (compatible with the previous ones) with this alternative access paths incorporated. Shortcuts are interesting because, besides of assuring O(1) access time to elements in the ADT, they present some nice properties: they are abstract (independent of the implementation of the ADT), persistent (movements inside the data structure do not affect them), secure (meaningless accesses are not allowed) and they preserve behaviour (the new ADT behaves as the old one, and the efficiency of the former operations keeps the same). These properties are the ones that distinguish clearly shortcuts from low-level concepts as pointers or cursors. We have developed the whole proposal on a particular case [17], although the conclusions of our work can be applied to any other container-like ADT, i.e. those ones arranging collections of items with an arbitrary (but completely defined) policy. For this case study, a complete mathematical model (with initial semantics) has been formulated, and the new implementation has been built with a systematic procedure (in fact, it has been formally derived from the specification) on top of the previous implementation for the ADT without shortcuts. Beside this, we have applied the shortcut concept to a widespread component library, the Booch’s one for Ada-95 [19]. The goal of this task has been to improve some particular aspects of the library that did not work out properly due to an incorrect implementation of their particular shortcut-like access. To solve the drawbacks, we have defined a new intermediate class adding our concept of shortcut in a similar manner as done in [17]. As a result of our experiment, the original library has been improved from many points of view: it has become possible to add new implementations for ADTs (which was not possible before); some programming patterns have been speed up; and the classes are better structured inside the library. It is worth to remark also that the reengineering process does not intefere with the previous behaviour of the library (both for functionality and efficiency) and, in consequence, existing software that use this library does not need to be modified; only recompilation is needed. We think that the steps followed in this particular case study can be generalised to other similar contexts.
References 1.
2.
Franch, X.; Botella, P.; Burgués, X.; Ribó, J.M. "ComProLab: A Component Programming Laboratory". In Procs. 9th Software Engineering and Knowledge Engineering Co nference (SEKE), Madrid (Spain), June 1997, pp. 397-406 Franch, X. "Systematic Formulation of Non-Functional Characteristics of Software". In Procs. 3rd IEEE International Conference on Requirements Engineering (ICRE), Colorado Springs (Colorado, USA), April 1998, pp. 174-181
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13. 14.
15.
16.
Burgués, X.; Franch, X. “A Language for Stating Component Quality”. In Procs. 14th Brasilian Symposium on Software Engineering (SBES), Joao Pessoa (Paraiba, Brasil), October 2000 Franch, X. "Including Non-Functional Issues in Anna/Ada Programs for Automatic Implementation Selection". In Procs. International Conference on Reliable Software Technologies - Ada Europe'97, London (UK), June 1997, LNCS 1251, pp. 88-99. Franch, X.; Botella, P. "Supporting Software Maintenance with Non-Functional Information". In Procs. 1st IEEE Euromicro Conference on Software Maintenance and Reengineering (CSMR), Berlin (Germany), March 1997, pp. 10-16. Franch, X.; Pinyol, J.; Vancells, J. "Browsing a Component Library using NonFunctional Information". In Procs. International Conference on Reliable Software Technologies - Ada Europe'99, Santander (Spain), June 1999, LNCS 1622, pp. 332343. Franch, X.; Botella, P. "Putting Non-Functional Requirements into Software Architecture". In Procs. 9th IEEE International Workshop on Software Specification and Design (IWSSD), Ise-shima (Japan), April 1998, pp. 60-67. Franch, X.; Pastor, J.A. "On the Formalisation of ERP Systems Procurement". In Procs. Continuing Collaborations for Successful COTS Development Workshop ECOTS), Limerick (Ireland), June 2000. Burgués, X.; Franch, X.; Pastor, J.A. "Formalising ERP Selection Criteria". In Procs. 10th IEEE International Workshop on Software Specification and Design (IWSSD), Shelter Point (California, USA), November 2000 Franch, X.; Ribó, J.M. "Some Reflexions in the Modelling of Software Processes". In Procs. International Process Technology Workshop (IPTW), Grenoble (France), September 1999. Ribó, J.M.; Franch, X. “Searching for Expressitivity, Modularity, Flexibility and Standarisation in Software Process Modeling”. In Procs. 14 th Brasilian Symposium on Software Engineering (SBES), Joao Pessoa (Paraiba, Brasil), October 2000 Franch, X.; Ribó, J.M. "Using UML for Modelling the Static Part of a Software Process". In Procs. 2nd
