Comprehensive System for Systematic Case-Driven Software Reuse

Comprehensive System for Systematic Case-Driven Software Reuse ´ Michal Smia lek1 , Audris Kalnins2 , Elina Kalnina2 , Albert Ambroziewicz1 , Tomasz Straszak1 , and Katharina Wolter3 1

3

Warsaw University of Technology, Poland [email protected] 2 IMCS University of Latvia, Latvia [email protected] HITeC e.V., University of Hamburg, Germany [email protected]

Abstract. Reuse of software artifacts (blueprints and code) is normally associated with organising a systematic reuse framework most often constructed for a specific problem domain. In this paper we present a system (language, tool, reuse process) where software reuse is based on building and retrieving of so-called software cases (large compound artifacts) that can be reused between domains. The system is opportunistic in that software cases result from usual (non-reuse oriented) activities where also semantic information is added. This information is used to support regular development but may serve later to retrieve software cases. Having this common semantic basis, we can organise a systematic cross-domain reuse process where application logic of one system can be reused for systems within different domains.

1 1.1

Introduction Motivation

In 1967, McIllroy [1] has formulated a vision of global software reuse based on the production of “software integrated circuits”. Despite many success stories it has to be admitted that this vision is still not fulfilled. The fundamental problem that did not find proper solution is the ability to cope with growing complexity of software systems and broadness of their problem domains. Thus, it is extremely difficult to find relevant assets for reuse and then apply them to the current problem at hand. The found solutions are usually very abstract (like generic design patterns) or specific to only a given problem domain (“domain-specific software ICs”). Reuse of generic solutions certainly helps in producing better systems but no significant productivity gains can be accomplished (considering the amount of work to find a generic solution and adapt to the current problem). Domainspecific approaches necessitate significant effort to conduct domain analysis and prepare assets for reuse. Thus, they are economically viable only for producing large families of similar systems (like eg. cell phone software). Software development organisations that would like to adopt reuse processes face important

2

´ M. Smia lek, et. al

barriers (see [2]). These barriers are associated with the complexity of reuse activities (preparing assets for reuse considering lack of proper tool support) and in resistance of developers and managers to undertake reuse activities “for the uncertain future”. As identified in a survey by Frakes and Kang [3], practically all approaches to software reuse are based on domain engineering. There, domain engineering is identified with software product lines (see below) and is declared as a key approach and research direction. The survey also stresses the importance of approaches to reuse pattern-based architectural frameworks with component technologies as technical enablers. Several important research directions have been identified: formal specification of architectures for automated construction of systems; broadening the scope of domains that can participate in the reuse process; behavioural contracts for components; reasoning support for component libraries; ability to predict variabilities in software assets needed by the re-users. The last research direction has been identified as a key point. In this paper we present an approach to software reuse that follows most of the postulated directions and can be classified as a domain engineering approach. The main difference to the current trend of product lines is that we deliberately exclude variability and commonality analysis. Instead of preparing assets for reuse, we promote opportunistic reuse which is often neglected as ad-hoc and unorganised. In our approach we make this opportunistic reuse systematic and organise it around so-called software cases. Software cases are produced in a systematic process which is compatible with the most typical iterative approaches (either agile or formal). The process starts with writing use cases and is followed by architectural design and coding (repeated over iterations) where traces (detailed mappings) between these elements are generated automatically. Through following of this process, the software cases are prepared for reuse by adding semantic information to the requirements specifications. The effort of adding this information is relatively small and can be done even by unskilled people (domain experts). Reuse of software cases is accomplished by retrieving so-called software case slices. These slices can be extracted by determining similarity of sketched use cases for a new system with those stored in a reuse repository. By using this approach, a significant reduction of effort can be accomplished which is shown through a validation experiment. What is important, this reduction is possible even when the new system is built for a new problem domain. 1.2

Related work

Our approach to case-driven reuse is based on use cases as basic indexes to software cases. Thus, we will relate our work to reuse approaches where requirements for the software systems are formulated with use cases. This research direction has been set in 1997 by introducing Reuse-Driven Software Engineering by Jacobson et al. [4]. In this approach, use cases drive both the software development and reuse process. Use cases are adorned with specific variability information. This variability analysis is supported with feature analysis as introduced in [5].

Comprehensive System for Systematic Case-Driven Software Reuse

3

Use cases did trace to the other artifacts in the software process like design models and code. In contrast to our work, no tool support for automatic generation of traces existed as use cases were written in natural language. The direction set in [4] is followed by many software product line approaches. Detailed guidelines for specifying use cases for system families have been given in [6]. An example notation for use case scenarios, modelling their variability and deriving specific scenarios is given in [7]. Another approach in the context of product line testing can be found in [8]. However, no real automation mechanisms for deriving and mapping design and code from use cases have been developed. A recent paper [9] shows an approach to automatic derivation of scenarios out of use case descriptions adorned with variability information. In order to automate the transition from use cases to code, we need rigour in specifying use cases. A constrained language approach is introduced in [10] where the essential scenarios are treated as reusable elements of the application logic. This approach does not yet resolve the problem of automation as it simply suggests manual traceability to design. In [11], the scenarios are traced to code automatically through analysing test logs from a testing tool. Thus, scenarios are written in a test scenario language of the test tool. In [12] the approach to use-case based reuse is extended. The presented REUSER system compares structural information contained in sequence diagrams associated with use cases. By creating a partial sequence diagram one can find all similar diagrams and associated use case diagrams. Comparison is based on graph-matching technology. However, this approach is limited to structural comparison. No indication on similarity of problem domains is given. On the other hand, [13] uses semantic information from the WordNet terminology [14]. With this approach, similarity of problem domains for different use case models can be determined.

2

Scenarios for case-driven software reuse

The process of case-driven software reuse (CDSR) is designed to be compatible with typical software development methodologies. It assumes iterative development which is centred around use cases. Figure 1 illustrates the general activities of CDSR in the form of a UML activity diagram. It can be noted that for the purpose of this paper the process is simplified and does not include - for instance - testing and deployment. We now describe two typical scenarios where the difference is in retrieving legacy use cases (see highlighted action in Fig. 1). In a basic - non reuse-oriented - scenario, the developers start a new project by sketching use cases. While writing initial use case descriptions, all the terms used are defined within a domain vocabulary associated with this new software case. Next, they plan for several iterations. Each of the iterations consists in developing a set of use cases. For each of the use cases, detailed scenarios are written. While writing scenarios, a complete domain vocabulary is constructed. This is done in a tooling environment which assures strict coherence between the vocabulary and the terms used in scenarios’ text. After completing these detailed functional requirements, an automatic transformation generates the ar-

4

´ M. Smia lek, et. al

Fig. 1. Creation, storage and retrieval of software cases

chitectural blueprints of the system. Within this architectural framework, code is developed. The code for the application logic is taken directly from architectural sequence diagrams (interaction model). The code for the business logic is written manually for every generated business logic component and interface. This is repeated until the complete system is built. The final action is to store (copy) the created artifacts (requirements, architecture/design and code) without modifications to a repository. The above scenario is compatible with “normal” software development using any of the available use case driven iterative methodologies. The main difference is in giving enough rigour to use cases to be able to perform automatic transformations to architecture. The result of the process is a so-called software case with its general structure presented in Figure 2. A software case can be defined as a combination of precisely mapped requirements, design (architecture) and code being the result of a specific project. The use case model in a software case is structured so that all the terms used within use case descriptions are linked to a vocabulary which is central to all the use cases. To make the vocabulary comparable to the vocabularies of other software cases, it is linked to a global terminology. Thus, the resulting repository of software cases has a semantic backbone common to all the distinct software cases (see again Fig. 2). The global terminology is used within the second scenario which contains the retrieval activity of Figure 1. In this scenario, after sketching the requirements (use cases and the related vocabulary), the developers run a query on the repository of past cases. The query tool uses similarity measures that compute semantic (WordNet based) and structural (graph based) distance between the newly sketched scenarios and the legacy complete scenarios. This is illustrated in Figure 3. When a matching use case is found within one of the stored software

Fig. 2. General structure of a software case repository

Comprehensive System for Systematic Case-Driven Software Reuse

5

Fig. 3. General scheme for use case based retrieval of software artifacts

Fig. 4. RSL model example

cases, all related design and code artifacts can be retrieved. In particular, the retrieval engine shows the mapped interaction diagrams that define the application logic (user-system interactions) for the given use case and components that realise the business logic (data processing algorithms). After finding relevant use cases, their contents (scenarios, see Fig. 4) together with the vocabularies and associated logic can be merged into the currently built software case. The rest of the process remains basically very similar to that without the retrieval step (the process is in fact presented as simplified to perform retrieval only once). Scenarios for other use cases are written and the vocabulary updated. Then, the architectural models are generated. It can be noted that now only some of the business logic components have to be written from scratch. These components that map from the legacy use cases are already written and necessitate only some adaptations. In the following sections we will give more technical details on the major steps of the above two scenarios.

3

Writing semantically rich requirements

The key factor for the above described reuse process to become possible is a semantically rich use case language. We use the Requirements Specification Language as specified in [15] (see also [16]). The main characteristic of this language

6

´ M. Smia lek, et. al

is that it offers a detailed syntax for use case scenarios. This syntax is based on writing simple subject+verb+object(s) sentences, and is presented in Figure 4 (see left). Moreover, scenarios written in RSL are composed of hyper-links to a vocabulary central for a given software case (see center). As it can be seen in the figure, the vocabulary is organised around phrases - like seek : for : user - that constitute predicates (verbs+objects) of the scenario sentences. Normally, all the subjects and predicates should be linked to the vocabulary (not all shown on the figure for clarity). What is important, all the phrases are grouped by the nouns which gives order to the vocabulary and is used for automatic transformation (see the next section). It can be noted that the process of writing use cases is very rigourous. The scenarios are written in a constrained language close to natural but all the words need to be uniformly specified in a vocabulary. This poses a problem for traditional requirements engineering tools which normally operate on paragraphs of text. Thus, we have developed a comprehensive RSL editor which highly supports writing vocabulary-oriented scenarios which is illustrated in Figure 5. The developers write their scenarios (see top right) in a scenario editor. While writing sentences, the editor automatically updates the domain vocabulary with used words (adding verb-object phrases; see Fig. 5 bottom right). The above activities, supported by the RSL editor can be seen as compliant with writing traditional requirements specifications. In such specifications, the vocabulary (often in the form of a domain class model) is prepared together with the functional specification. The RSL tool assures high level of coherence between these two major parts relieving the developers from manual synchronisation. This is in accordance with the approach proposed in [17], where the requirements specification resembles a wikipedia with extensive use of hyper-links.

Fig. 5. The RSL editor

Comprehensive System for Systematic Case-Driven Software Reuse

7

In addition to the above activities which come from general software engineering practice, we introduce an extra activity of linking vocabulary entries with a global terminology. This is illustrated in Fig. 4 (see right). Each of the words in the vocabulary (both the verbs and the nouns) has to be assigned to a WordNet element which is used as a global terminology for specifying senses of words. This again is highly supported by the RSL editor which offers all available senses of a given term (see Fig. 5, very bottom). The above features of RSL can be used for transforming and mapping use case scenarios into architectural models and code. RSL was carefully designed to allow for generating very detailed component models with associated detailed application logic. Moreover, these generated components can be reused through comparing use case scenarios and retrieving traces from these scenarios to components. This will be explained in the following two sections.

4

Generating and mapping design from requirements

The algorithms for transforming from requirements to design were implemented in the model transformation language MOLA4 [18]. MOLA, as any other such language assumes that both the source and the target models are written in a meta-model based language. The RSL’s meta-model is specified in [15]. The target models are expressed in UML with its meta-model defined in [19]. The target architectural model conforms to the requirements specification written in RSL by realising use case scenarios in a given logical architectural framework. Thus, two aspects need to be considered: static structure of the system and its dynamics in fulfilling the application logic (ie. use case scenarios). These two aspects are specified at component level for the architectural model and then refined up to implementation class level. The structure of the generated architecture depends on the chosen architectural style. The architectural style includes the definition of the system and model structure, the related set of design patterns and the general design principles that are applied. The selection of the most appropriate architecture style depends on non-functional requirements for the system but it is out of scope for this paper. Here we will give an example of an architectural style conforming to a wide range of typical non-functional constraints. It is based on the most popular layered approach to architecting contemporary business systems. We assume four layer design with Presentation, Application Logic, Business Logic and Data Access layers. Another basic principle used, is component based design at all layers, with components comunicating through interfaces. In addition, several popular design patterns are used. First, the whole design is based on a simplified form of the MVC pattern, where no details of the view part are given. For each domain element a data transfer object for exchanging data flowing between layers and a data access object encapsulating persistence related operations is built. For the domain elements participating in business logic, corresponding business layer objects are created. 4

http://mola.mii.lu.lv

8

´ M. Smia lek, et. al

Fig. 6. Transformation of a vocabulary into a component structure

Fig. 7. Transformation of a scenario to a sequence diagram

The above described architectural style provides clear guidelines as to what elements should be created in the target model of the transformation. Figure 6 illustrates the correspondence between requirements and the obtained static structure on the example introduced previously (compare with Fig. 3). The most non-trivial problem is to generate operations for all the interfaces. This can be done only using a thorough analysis of scenario sentences within each use case. During the analysis corresponding system behaviour is built and operations to relevant interfaces are added. The generation of messages and the corresponding operations depend upon the category (actor-to-system, systemto-actor, system-to-system) of the analysed sentence. Figure 7 illustrates the principles how the messages (and associated operations) are generated from the sentences and the receiving lifelines selected.

Comprehensive System for Systematic Case-Driven Software Reuse

9

Fig. 8. The retrieval engine with visualisation of software case slices

Fig. 9. Reuse of application logic through reusable transformations

In order to support reuse, mapping links from requirements to architecture (and further to detailed design) are built by transformations. Rich mapping links provide the basic prerequisite for traceability and software case slicing as described in the next section.

5

Reusing software cases

According to the second scenario described in section 2, the newly built use cases should be compared for similarity with use cases stored in the repository. The retrieval engine uses the initial sketch as a query. In the following we will use the example from Fig. 4. The query is based on the use case scenario from “Software Case 2”. With this simple query we result with the engine showing the use case from “Software Case 1” as most relevant. This is shown in Figure 8 (bottom). After determining the similarity we can browse through the found software cases and use cases. Moreover, we can determine slices which originate in the most similar use cases. The slice contains all the interfaces and components that are used within the interaction diagrams associated with the given use cases. This is illustrated in the upper part of Fig. 8.

10

´ M. Smia lek, et. al

Fig. 10. Reuse of business logic through updating code

When an appropriate slice is determined, we can retrieve all the elements contained therein. These retrieved elements are illustrated in Figures 9 and 10 (please compare with Fig 8). In the first figure we can see the possibility to reuse code based on the common application logic. We assume that the developers have reused the original use case scenarios. They have substituted the original notion “user” with the new notion “guest”. This resulted in the transformation engine generating a new interaction diagram, leading to code that is depicted in the lower part of the figure. This can be also compared with the sequence diagram in Fig. 7. This new application logic code is ready to be used in the new system. What is also available for reuse is the business logic code. This code is called from the application logic operations and performs certain data processing activities. In Fig. 9 calls to this code are highlighted and the code itself is presented in Fig. 10. The developers can follow the relationship between the generated application logic (Administration) and business logic (UsersServices) component. Analogous relationship is generated for the new system (see left in Fig. 10). What is not generated is the code of the operation. This code has to be taken from the old software case and reworked (see highlighted code in Fig. 10).

6

Conclusion and evaluation results

With the presented approach, the software artifacts produced within a software project are combined into software cases which drive reuse. The reuse environment contains many software cases which can be searched through and the most relevant for the problem at hand – retrieved. Unlike for typical software product line approaches, the effort of preparing a software case for reuse is highly reduced. What is also important, this effort pays off in the current project as it also enables automatic transformation to design. The CDSR approach can be also used for building families of systems. A family is produced implicitly, and not explicitly as in product lines. This implicit “family construction” is performed through creation of consecutive software cases that constitute variants of the previous software cases. The following software cases of the family are added by finding the most similar one and adapt-

Comprehensive System for Systematic Case-Driven Software Reuse

11

ing it to a slightly different problem at hand. Thus we can call this approach an “opportunistic product line”. The CDSR system was developed within the ReDSeeDS (www.redseeds.eu) project and consists of the RSL language, a comprehensive tool suite (ReDSeeDS Engine) and the CDSR process description (ReDSeeDS Methodology). In order to confirm the validity of the CDSR system, these tools were used within a comprehensive validation cycle in the industrial context. The cycle was lead by Fraunhofer IESE with the participation of four industrial software development teams (see Acknowledgements). One of the teams had experience with a product line. The other teams had previously experienced only ad-hoc reuse. During the cycle, the following experimental validation activities were performed. 1. RSL training and case creation and retrieval training (two day tutorials). 2. Case creation. More than 20 software cases, with a total of over 300 use cases were created. The domains ranged from financial systems to rescue systems. 3. Case reuse. Four new software cases (over 80 use cases) were created through retrieving and reusing elements from the old cases. The domains for these new systems were significantly different than for the previous ones. Also, four other existing software cases were extended to create variants. Depending on the similarity of problem domains, the size of reuse ranged from single use cases and associated design/code to 90% of the whole software cases. 4. Acceptance and usage analysis, using the UTAUT method [20]. The qualitative analysis of supplied extensive questionnaires shows very promising results. The user attitude in four areas (effort expectancy, facilitating conditions, self efficacy, behavioural intention) is positive. In other four areas (like performance) it is neutral. This means that the users of the system (experienced software developers) believe that the approach would reduce their personal effort and has enough technical support (tools) to be effectively applied in real life. Moreover, the users show significant intention to use this technology in the future. On the other hand, the users do not expect that using the system influence the performance of their work. It has to be noted that the current results are obtained for the ReDSeeDS Engine prototype and not for a commercial and mature product. The users have raised several issues which can further improve the overall acceptance of the system and the CDSR approach. Detailed results of this study are available as a ReDSeeDS project report. The above study showed applicability of CDSR to a broad range of problem domains. It was performed using the transformation algorithm presented in section 4. Also, other transformation algorithms can be used and are currently developed within ReDSeeDS. These algorithms capture the implications stemming from non-functional requirements. Obviously, the limitation of CDSR is that the transition from non-functional requirements to transformation algorithms is a manual process depending on experience of the transformation writers. Acknowledgments. This work is partially funded by the EU: RequirementsDriven Software Development System (ReDSeeDS) (contract no. IST-2006-33596 under 6FP).

12

´ M. Smia lek, et. al

References 1. McIlroy, M.D.: Mass produced software components. In Naur, P., Randell, B., Buxton, J.N., eds.: Software engineering concepts and techniques, Proceedings of NATO Conference on Software Engineering, New York (1969) 88–98 2. Sherif, K., Vinze, A.: Barriers to adoption of software reuse. A qualitative study. Information and Management 41 (2003) 159–175 3. Frakes, W.B., Kang, K.: Software reuse research: status and future. IEEE Transactions on Software Engineering 31(7) (2005) 529–536 4. Jacobson, I., Griss, M., Jonsson, P.: Software reuse: architecture process and organization for business success. ACM Press (1997) 5. Griss, M.L., Favaro, J., d’ Alessandro, M.: Integrating feature modeling with the RSEB. In: Proc. 5th International Conference on Software Reuse (1998) 76–85 6. Gomaa, H.: Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison Wesley (2004) 7. Bertolino, A., Fantechi, A., Gnesi, S., Lami, G.: Product Line Use Cases: ScenarioBased Specification and Testing of Requirements. In: Software Product Lines Research Issues in Engineering and Management. Springer (2006) 425–445 8. Kamsties, E., Pohl, K., Reis, S., Reuys, A.: Testing variabilities in use case models. Lecture Notes in Computer Science 3014 (2004) 6–18 9. Choi, W.s., Kang, S., Choi, H., Baik, J.: Automated generation of product use case scenarios in product line development. In: 8th IEEE International Conference on Computer and Information Technology, CIT’08. (2008) 760–765 10. Biddle, R., Noble, J., Tempero, E.: Supporting reusable use cases. Lecture Notes in Computer Science 2319 (2002) 210–226 11. Egyed, A., Gr¨ unbacher, P.: Supporting software understanding with automated requirements traceability. International Journal of Software Engineering and Knowledge Engineering 15(5) (2005) 783–810 12. Robinson, W.N., Woo, H.G.: Finding reusable UML sequence diagrams automatically. IEEE Software 21(5) (2004) 60–67 13. Blok, M.C., Cybulski, J.L.: Reusing UML specifications in a constrained application domain. In: Proceedings of 1998 Asia Pacific Software Engineering Conference. (1998) 196–202 14. Fellbaum, C., ed.: WordNet: An Electronic Lexical Database. MIT Press (1998) ´ 15. Kaindl, H., Smia lek, M., Svetinovic, D., Ambroziewicz, A., Bojarski, J., Nowakowski, W., Straszak, T., Schwarz, H., Bildhauer, D., Brogan, J.P., Mukasa, K.S., Wolter, K., Krebs, T.: Requirements specification language definition. Project Deliverable D2.4.1, ReDSeeDS Project (2007) www.redseeds.eu. ´ 16. Smia lek, M., Bojarski, J., Nowakowski, W., Ambroziewicz, A., Straszak, T.: Complementary use case scenario representations based on domain vocabularies. Lecture Notes in Computer Science 4735 (2007) 544–558 17. Kaindl, H.: Using hypertext for semiformal representation in requirements engineering practice. The New Review of Hypermedia and Multimedia 2 (1996) 149–173 18. Kalnins, A., Barzdins, J., Celms, E.: Model transformation language MOLA. Lecture Notes in Computer Science 3599 (2004) 14–28 19. Object Management Group: Unified Modeling Language: Superstructure, version 2.1.1, formal/07-02-05. (2007) 20. Venkatesh, V., Smith, R.H., Morris, M.G., Davis, G.B., Davis, F.D.: User acceptance of information technology: Toward a unified view. MIS Quarterly 27 (2003) 425–478