The CoExSel Tool. Stine Lill Notto Olsen Kjersti Loe. December 19, 2005 Study in System Development

Transcription

1 The CoExSel Tool Stine Lill Notto Olsen Kjersti Loe December 19, 2005 Study in System Development

2

3 Abstract Component-based software engineering (CBSE) is an emerging software technology that focuses on building software systems by integrating previously-existing software components. It has the potential of developing high-quality software systems with lower costs and reduced software development time. To take advantage of these qualities, it is important that suitable components are selected. The process of selecting components may be difficult due to a large number of available components, and a possible need for trade-off analysis in regard to development costs, time-to-market, and reliability and functionality. This project aims to design a tool for supporting the developer when selecting components. The CoExSel tool gives the developer the ability to derive implementation requirements from customer requirements, and select components to fulfill the them. On the selected set of components, the CoExSel tool performs estimations such as costs, reliability and time-to-market. This facilitates the developer when analyzing trade-offs between possible new components to add the to the set of already selected components, and when deciding between different possible sets of components for an application.

4 Preface This document is the result of a project in the course TDT 4735 Study in System development in the autumn of 2005, at the Department of Computer and Information Science at the Norwegian University of Science and Technology (NTNU). The project is a depth study of component-based software engineering with focus on time-to-market, cost and reliability. We would like to thank our supervisor, Tor Stålhane for his involvement and for giving valuable feedback during the semester. We would also like to thank Edvantage Group and specially Jon Øyvind Stenerud, for cooperating with us and giving us valuable input on our work. December 19, 2005 Kjersti Loe Stine Lill Notto Olsen

5 System Development CONTENTS Contents 1 Introduction Background Motivation Report Outline Overview of Risks and Challenges in CBSE 4 3 Prestudy Component Definition Different Component Definitions Black-Box and White-Box The Component-based Life Cycle Developing with Components The V Model The Component-based Life Cycle Model The Y Software Life Cycle Model CBSD Process Using Design Patterns The Component-based Integration Systems Development (CISD) Model The Architecture Based Component (ABC) Model Summary of Models Current Software Component Technologies and Tools Distributed Component Models: EJB, CCM and DCOM Development Environments: ADE with ASL, SYNTHESIS and a UMLbased CASE tool Component Frameworks for the Development Process: OPC and CB-SPE tool Other Tools Summary of State-Of-the-Art Technologies and Tools Architecture and Patterns Definitions The Role of Patterns and Architecture Requirements Engineering ii

6 CONTENTS System Development Requirements Engineering (RE) in Traditional SE Requirements Engineering (RE) in CBSE UML Textual Use Cases Component Selection The Bi-directional Relationship Between Requirement Engineering and Component Integration Approaches to Component Selection Cost Estimation Analysis Traditional Cost Estimation Approaches Use Case Estimation Cost Estimation in CBSE A Software Architecture Classification Method COCOTS: A COTS Software Integration Lifecycle Cost Model Cost-Benefit Analysis Time-To-Market Estimation Reliability Analysis Software Component Reliability Analysis Part Count - An Additive Reliability Model Part Count - The Kubat model Research Agenda Goal and Research Questions Research Methods Overall Work Plan The CoExSel Tool Tool introduction The Role of the Tool-user Requirements Specification Open Project Requirements Use Case Projects System Requirements Projects Implementation Requirements Component Selection Calculations Research Questions How do we efficiently identify implementation requirements from customer requirements? How can we represent the implementation requirements? iii

7 System Development CONTENTS 6.3 What information about the component does the tool-user need and how can this be represented? How do we estimate time-to-market, cost and reliability for component-based software? Our Contribution Experience The CoExSel Tool Constructs an Important Connection Enables Trade-off Analysis between Functionality, Costs, Time-To-Market and Reliability Testing and Results Goals The Testing Process Fictitious Scenario Create a New Project Use Case of Billing a Customer The Implementation Requirements Connecting Implementation Requirements to Components Estimations Change in a Customer Requirement Remaining Functionality System Requirements Catalogues Connecting Components to Implementation Requirements Adding Experience to Components View Selected Components Discussion Maintenance Categorization Non-Functional Requirements The Value of Experience The Features of Use Cases The Value of Trade-off and Cost Estimation Usefulness of the preserved connection Usability Evaluation How do we efficiently identify implementation requirements from customer requirements? How can we represent the implementation requirements? iv

8 CONTENTS System Development 9.3 What information about the component does the tool-user need and how can this be represented? How do we estimate time-to-market, cost and reliability for component-based software? Conclusion and Further Work Conclusion Further Work A Pictures of the Prototype 67 A.1 Menus A.1.1 Menu Item: File A.1.2 Menu Item: Use Case A.1.3 Menu Item: System Requirements A.1.4 Menu Item: Action A.1.5 Menu Item: Components A.1.6 Menu Item: Help A.2 Tree-Menus A.2.1 Left Menu Implementation Requirements A.2.2 Left Menu Use Cases A.3 Templates A.4 Searching B Implemenation Requirements 73 C Estimations 74 C.1 Use Case Point Estimations C.1.1 Calculation Example C.1.2 Environmental and Technical Factors C.2 Estimating COCOTS Bibliography 83 v

9 System Development LIST OF FIGURES List of Figures 3.1 The V Model [19] The Component-based Life Cycle Model [11] The Y Software Life Cycle Model [12] Development Process Using Design Patterns [74] Summary of the CISD Model [63] The ABC Model [43] Provided and Required Interfaces The Cyclical Requirement-Component Dependency Model [64] The DesCOTS Structure [29] Selection of COTS in DesCOTS [29] Ordering of types of packaging [71] Investigation of Testing Strategies on Reliability Growth [24] Overall Work Plan Connection between Use Cases and Requirements The Role of the User Use Case for Generating Invoice Implement requirement Component Description Select Estimation Analysis Component Description View, Connect to Implementation Requirement Add Experience to a Component A.1 File Menu Item A.2 Use Case Menu Item A.3 System Requirements Menu Item A.4 Action Menu Item A.5 Components Menu Item A.6 Left Menu: Implementation Requirements A.7 Left Menu: Use Cases vi

10 LIST OF FIGURES System Development A.8 Use Case Template A.9 Implementation Requirement Template A.10 Tree Structures Template A.11 Search For Component A.12 Search For Component Result A.13 Search For Implementation Requirement vii

11 System Development LIST OF TABLES List of Tables 3.1 Summary of Models Summary of Models a values [34] C.1 Unadjusted Actor Weights (UAW) C.2 Unadjusted Use Case Points (UUCW) C.3 Technical Factors [55] C.4 Environmental Factors [55] viii

12 CHAPTER 1. INTRODUCTION System Development Chapter 1 Introduction There is a growing interest in component-based software engineering (CBSE). One of the main reasons for this is a change in the business and organizational context where applications are developed, deployed and maintained [9]. In addition, there has been a maturity in component technologies that permit building and assembling components into applications [9]. CBSE provides methods and guidelines when developing component-based systems. Although CBSE is promising, the lack of experience and tool-support is a challenge. 1.1 Background Component-based software development is closely related to reuse. The idea of reuse emerged in the late 50 s [16], early 60 s [46], from the simple idea; when developing new systems use components that are already developed [16]. And when developing new functions for a system, write the functions in such a way that it can be reused in other systems. The earliest successful reuse was the development of several reuse libraries [46]. These libraries consisted of functions, i.e. mathematical functions, which were referred to and used in new applications. In the 80 s, systems were always developed from scratch [46]. This included the development of hardware, software, and environments, such as compilers and debuggers. The 90 s introduced standardized hardware, and operating systems that became more general-purposed, as well as cheaper [46]. Reusing software components is a recent trend in software development [16]. Developing with components is based on the idea that hardware design and development is no longer built-fromscratch [16]. Today, hardware is often built from off-the-shelf components, which are cheap, because large quantities of the components are produced. The notion of software components rests on the analogy with the hardware components. Software components can therefore be visualized as a network of boxes communicating with each other via connecting wires [16]. Both traditional and component-based software development methodologies need to specify the requirements and overall architecture of the target software system [21]. Component-based software engineering (CBSE) differ from traditional software engineering because instead of building software from scratch, already existing components are selected from a component library and integrated into new applications [53] [41] [21]. Component-based software engineering can be divided into two processes; component development and system development with components [17]. Component development concerns how components are developed or discovered, while system development with components concerns how new applications are build from pre-developed components. The scope of this paper includes only system development with components. The essential questions in system development with components are [21]: Which existing components are best fit to implement the functionality of a system? 1

13 System Development CHAPTER 1. INTRODUCTION How can interdependencies and mismatches among components best be managed and integrated into seamless systems? We want to develop a tool that supports developers in answering the first of these two essential questions. The four major activities in system development with components are [44]: Component qualification and selection Component adaptation Assembling components into the system System evolution Component qualification and selection are about finding possible components that can be used when developing a software system, and deciding which of the components that are best fit to implement the system s functionality [44]. The component qualification and selection phase is therefore an essential activity in the tool we are developing. To study the suitability of a component, it is important to identify a component s properties, such as functionality, reliability, adaptability, etc. It is, however, also important to identify the functionality, quality, cost and time-to-market for the overall system, to identify the set of components which is best fit to implement the system in regard to the customer requirements. This information can be difficult to quantify, and in some cases difficult to obtain. With a number of available candidates and limited component information, there is a need for tools to help finding the right components [53]. Component adaptation is the process where components are adjusted to address possible sources of conflict before they are assembled or integrated into an architectural infrastructure [8]. Components must be integrated through a well-defined infrastructure, which binds the components together to form a system. The system can be evolved by updating components or assembling new components into the system. System evolution occurs when there is a need for repairing errors or adding new functionality. 1.2 Motivation The interest in CBSE has grown over the last years, and several organizations have noticed its prospects. There are three main advantages with reuse, which includes CBSE, recognized by the software engineering community [72]: Productivity: Using reusable code to build a software system, results in less effort needed to develop the same functionality from scratch. Less input effort with the same output leads to increased productivity [72] [53] [17] [66]. Quality: Using reusable code can lead to more reliable software systems. Defects in components are discovered and eliminated through use in already developed systems, which results in less errors in new systems [72] [66]. Business performance: Reuse can lead to more effective management of complexity, significantly reduced cost and time-to-market, and improved customer satisfaction [53] [17] [72] [66]. For these reasons, CBSE is promising. However, there are risks and challenges involved. For example, the possibility of selecting a set of components that lacks needed functionality, includes low-quality components, results in architectural mismatch, etc., introduces risks. Risks and challenges in CBSE, are further discussed in chapter 2. Several of these risks and challenges arise in the component selection phase. Component selection is therefore an essential activity in the 2

14 CHAPTER 1. INTRODUCTION System Development design of a component-based software system [53]. There are several tools created to support the selection of components in CBSE. The majority use a comparison between the requirement specification and component evaluations to drive the component selection process. Some tools help by having some form of artificial intelligence which proposes the candidate components. Other automatically develop adapters or wrappers. Some tools help by estimating costs, time-to-market OR reliability. However, there is a lack of tools which help the software developer in estimating costs, time-to-market AND reliability. In CBSE, there is often a trade-off between costs, time-to-market, quality and functionality. Hence, there is a need for tools to support the component selection process, and the trade-off analysis often made between different possible system implementations. These issues are addressed in the creation of the CoExSel tool. The CoExSel tool is to help the developer in the selection of components by supporting the trade-off analysis between functionality, costs, reliability and timeto-market, when developing new component-based software systems. To provide the user with more information about a component, we have included earlier experience with the use of the components. 1.3 Report Outline The rest of this document is organized as follows: Chapter 2 Risks And Challenges In CBSE, describes risks and challenges that can arise CBSE. Possible risks and challenges are important to emphasize when creating a tool to help in the CBSE process, which will reduce some of these risks. Chapter 3 Prestudy, describes existing work that is relevant to this study. It includes a literature study of theory relevant to software development with CBSE. It also includes how to estimate time-to-market, costs and reliability. Chapter 4 Research Agenda, introduces the focus of our work. It describes our goal, and the procedure and methods used to achieve these goals. Chapter 5 Introduction of The CoExSel Tool, gives an introduction of the CoExSel Tool and describes its main functionality and features. It provides a description of how the tool can be used, and states the tool requirements specification. Chapter 6 Research Questions, describes the ideas and discussions we had about how the Co- ExSel tool should be created, including which functionality and features the tool should have. This chapter highlights our contribution in the development of the tool. Chapter 7 Testing and Results, consists of a description of the testing process to validate usefulness of the CoExSel tool. This chapter also presents the results of the test, and includes a detailed example of how the tool can be used. Chapter 8.8 Discussion, contains a discussion highlighting pros and cons pertaining the CoExSel tool, based on the results on the test performed in chapter 7. Based on these result we also present suggestions of improvements of the CoExSel tool. Chapter 9.4 Evaluation, evaluates the usefulness of the CoExSel tool based on the prototype test and the discussion performed in chapter 8.8. Chapter 10 Conclusion and Further Research, contains conclusions and suggestions for future research. 3

15 System Development CHAPTER 2. OVERVIEW OF RISKS AND CHALLENGES IN CBSE Chapter 2 Overview of Risks and Challenges in CBSE An overview of the current problems in CBSE is necessary to validate the need for a new CBSE development tool. There is a great risk when acquiring components for new applications in CBSE. Difficulties can arise as from requirements that are incomplete, imprecise and contradictory. In addition, inadequate component libraries with lacking component information and where proper components are difficult to retrieve, magnifies the problem. For example, finding proper classes in a class library, might be challenging. In CBSE, requirements have to match the functionality provided by existing components. Hence, the process of requirements management is complex. Even if suitable components are selected to cover the requirements, it does not mean that the components function optimally together [28]. Selecting pre-existing components often requires trade-off analysis to adjust the system s architecture and to reformulate the requirements to make it possible to realize the system with the chosen components [17]. Another challenge in the component selection process, is to decide when the component selection process should take place. If components are selected too early according to the requirements analysis and definition phase, the selected set may not be able to meet all the system requirements [17]. An additional problem is that if the component selection process is postponed until after the requirements specification, there are no guarantees that components with the needed properties and functionality exist [19] [17]. Therefore, the final system requirements must be defined based upon the capabilities of the existing components to exploit the full benefit of component-based software development [1]. A trade-off analysis between the requirements can be necessary when several components offer the same main functionality, but there does not exist a set which fulfill them all. It is therefore important that component assessment and requirement definitions are done in concert [1]. The possibility of selecting inappropriate components in regard to functionality or quality requirements introduces a risk in CBSE. If this problem occurs, it is often not identified before late in the development process. Going back to the component selection stage will require an increase in development effort. The problem can arise because there are shortcomings in the description of the component s functionality is provided [29]. The level of details in a component s description restricts the level of details that can be used for selecting components [37]. If the component is 4

16 CHAPTER 2. OVERVIEW OF RISKS AND CHALLENGES IN CBSE System Development described by the main functionality, i.e. described by login -functionality, then requirements such as the user has three attempts to type the password, are too specific to use when choosing components. It is therefore important that the level of details in the component description, matches the level of details in the requirements. Also, no access to source code, insufficient documentation, limited description of the quality of the component, lack of testing on the target platform and in the target environment [60], are factors that can increase the risk. The system requirements might be changed during development. This requires that the components must be adapted or replaced. A greater risk is introduced if the components are difficult, or even impossible, to customize or tailor to the user s requirements, such as with black-box components. In that case a different set of components is required [60], which results in higher effort and cost. Architectural mismatch can also result in that a different set of components must be selected. Architectural mismatches are logical inconsistencies between constraints of several architectural elements being composed. Architectural mismatch occurs when the assumptions that a component makes about another component, or the whole the system, do not match [20]. Both problems cause an increase in effort and, hence, represent a risk in CBSE. Exception handling in component-based systems is a challenge because it is not guaranteed that independently developed components follow their published specification [56]. It is hard for component developers to know every context which a component can be used, hence, it is difficult to anticipate every exception [56]. To handle exceptions in components, it is possible to add the needed exception by compiling in complicated and carefully coordinated exception handling wrappers into all individual components [22]. This can be a challenging approach since there are no access to the internals of the component. The wrappers must catch all exceptions, which are context sensitive and systemic for that component. It can be a challenge for the component user to think of every context the component is used in [56]. In open source software, developers have access to internal component code and can create wrappers for the components exceptions by studying in the source code. In both exception handling methods, it can be a challenge when system failures are caused by interaction between components, since these cannot be handled in individual component exceptions [56] [22]. For handling system exceptions for the whole system, specialized exception handling infrastructures for component-based systems, are presented in [56] [22]. Exception handling between components is outside the scope of this work. Another risk with CBSE is the difficulty of estimating the effort of composing the components into a new application. In traditional software engineering, the effort is estimated based on some features of the software application, usually software size. However, this does not give a good representation of the effort needed to develop a new application in CBSE. To base the effort estimation on the size of the new code, can be error prone because the effort of understanding and selecting the reused code is not included [36]. To base the effort estimation on the size of the reused components, can also be error prone because often only a fraction of the reused components are used [36]. Therefore, effort estimation is a more complex and difficult task in CBSE than in traditional SE. The advantage of using CBSE will be increased if these risks and challenges can be reduced. 5

17 System Development CHAPTER 3. PRESTUDY Chapter 3 Prestudy A thorough understanding of CBSE is important before developing a tool to support this development process. Therefore, this chapter presents a literature study of component-based software engineering (CBSE) and aims to increase our knowledge about CBSE. Important research areas are component definition, the component-based development life cycle, a survey of state-of-the-art technologies and tools, architecture and patterns, and estimation methods for CBSE. 3.1 Component Definition The general idea is that components are the building blocks of CBSE. However, no precise and well-understood definition of components, in a software context, has been agreed upon in the literature [16]. One of the challenges in CBSE is the many similar but not identical definitions of a component, which may result in difficulties when discussing CBSE [16] [18]. It is therefore impoimportant to clarify the concept of components before discussing CBSE any further. This chapter presents two of the more widely accepted component definitions and explain the difference between black-box and white-box components Different Component Definitions The generic term of a component is; A component is a reusable unit of deployment and composition [18]. This concept is unfortunately to vague to be of use and a different term is desirable. Szyperski gives the following definition [18]: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies. An interface is a set of named operations that can be invoked by clients. Context dependencies are specifications of what the deployment environment needs to provide, such that the components can function. Another definition is given by D Souza and Wills [16]: A component is a coherent package of software that can be independently developed and delivered as a unit, and that offers interfaces by which it can be connected, unchanged, with other components to compose a lager system. These definitions have different details, but they converge to some degree. They both claim that a component is an independent software package that offers functionality through well-defined interfaces. A component will therefore only be visible through its interface. The separation of a component s interfaces from its implementation is an important feature. This means that a component can be deployed independently and integrated into an application without looking at the source code. If the component is delivered without the source code by a third party, the component may be adapted but cannot be modified. 6

18 CHAPTER 3. PRESTUDY System Development Black-Box and White-Box Components can be reused as black-box or white-box components, which are the two main types of software reuse. Black-box reuse hides all the inner functionality of the component. This means that the inner functionality of a component is not exposed to the developer and can only be reached through the specified interface. Example of black-box reuse is Commercial Off-The-Shelf (COTS) components. When buying COTS-components the buyers have little control over the source code. As apposed to black-box reuse, white-box reuse expose all inner functionality of the component. Hence, in addition to using the components through a well defined interface it can therefore be studied, reused, adapted and modified. An example where white-box reuse is used, is in Open Source Software (OSS) projects. The problem with white-box reuse is that a change in a component can lead to mismatch in applications that already use the old version of the component. To avoid this problem, OSS components are often used as black-box components. The developers have the source code available, but they do not look at it or modify it. Therefore, it is argued that OSS components are often used as COTS components [62]. 3.2 The Component-based Life Cycle The life cycle process includes the activities of developing a product or system, from the business idea to its completion of use [19]. Most component-based software life cycle models have their own features, and not all are suitable for all systems. The main purpose of a life cycle process is to identify and arrange the phases and stages involved during the development of software [11] [12]. When moving towards using component-based software engineering (CBSE), there is a need for some changes in the life cycle [19], which have resulted in new challenges for the developers [19] [12]. When developing a tool to help in the component-based software development process, it is important to study different life cycle models to understand the process where it is to be used. As mention in chapter 1, CBSE can be separated into component development and system development with components, and this paper only focuses on the latter. The next sections will present the general steps when developing with components. Section to section presents some models especially developed for CBSE and section discuss the summary of these models Developing with Components The development process of component-based systems have many similarities with the development process of non-component-based systems. They both include the requirements specification phase, the system design phase, the implementation phase, the testing phase and the maintenance phase [19]. However, in CBSE these phases focus on reuse of available components and not on system design. These phases, in addition to component selection and evaluation, system integration, verification and validation, constitutes the general steps in the component-based life cycle [15]. Requirements Analysis and Definition The requirement analysis involves identifying and describing the requirements the system should satisfy. The requirement specification defines the system architecture which allows component collaboration. It also specifies and defines the boundaries of the system, including the requirements of the needed components. The component requirements must be defined in a way that makes it possible for the developer to select or develop suitable components. To find the right component, there must be a number of possible candidates [17]. However, it is no guarantee that the right component exists. It is therefore wise to do the requirement specification in parallel with the component selection and evaluation. 7

19 System Development CHAPTER 3. PRESTUDY Component Selection and Evaluation The suitable component for a particular system must be identified, and often from a huge offer of components available. Components must be assessed based upon attributes such as quality, functionality, architecture and compliance with standards [7], and the functional-, nonfunctional-, and performance requirements of the system [1] [42]. Other component assessment attributes especially identified for COTS components can be found in [1]. Components are created with a specific system in mind, and the chance of finding a component that exactly matches the requirements for a new system is small [40]. To make a better match with the requirements, it is possible to evaluate a set of assembled components as an alternative to evaluating a single component [15]. The reason for this is that a set of assembled components can have different features than a single component. There is often a need for trade-offs if all the requirements cannot be fulfilled, for reasons discussed in chapter 2. The architecture and requirement specification can be adjusted to make use of the existing components [17]. Adapting components and making new components to match the requirements, is not an unlikely task during development [15]. System Design The system design will depend on the system specification and the architecture. The architectural design depends on the requirements as well as on the component model and component technology selected [15] [40]. A component model or framework shows the collaboration between the components. The design activity requires an exploratory process where the designer can try out a variety of schemes for the design [19]. This is an iterative process which the designer must repeat in order to find the most feasible combination of the component candidates [15]. The number of potential design solutions can be reduced with the use of reused and commercial components [40]. This because pre-developed components cannot be used with all possible design solutions, which can make the design activity a difficult step. System Implementation The implementation activity consists of the creation of glue code and component adaptation [15]. The goal of CBSE is to reduce costs by using pre-developed components. However, if the components selected are not the right ones, maybe resulting from a bad component description, or if an unsuitable component model is used, the costs of glue code and component adaptation can become large. There is therefore a chance that it is necessary to create components particularly designed for the system, during the implementation phase. System Integration System integration is crucial [40] and should begin early in the development cycle [15]. It comprises the integration of the implemented and selected components, and depends on the architecture, the component framework and the control flow between the components. The integration phase includes the component adaptation and reconfigurations of assemblies. It is seldom possible to predict all the effects and features of the system until integration. Hence, this activity also must include test-procedures for the component assemblies and for the whole system. Verification and Validation Before the system is delivered to the customer it must be verified and validated, and the two terms have a clear distinction. Verification is a process that determines whether the system meets its specific functional and non-functional requirements [15]. As opposed to the validation process which ensures that the right system is build so that it meets the customer expectations [15]. 8

20 CHAPTER 3. PRESTUDY System Development Verification is done by software testing and can begin as soon as the two first components have been integrated. Validation however, is performed by system inspection and cannot start before the final assembly has been added [15] [40]. System Operation Support and Maintenance A feature of component-based systems is that components can still be updated and maintained after it has been deployed in some applications [12]. This makes it possible to maintain and evolve the system by updating one or several components [15] [40]. New features can therefore be added without building a new system. However, when the developer buys components from different vendors it may not be conclusive who has the responsibility of supporting the system. This can make the maintenance process more complicated [15]. Also, adding a new version of a component can lead to problems and unpredictable behavior if it is not compliant with all the other components which use that component [15] The V Model The V model is used in many organizations when building complex long-life products [19]. Figure 3.1 shows an idealized V process model, which is a sequential model [15]. It begins with requirements and system specification. The next step is selecting appropriate components and integrating them into the system, which include finding and evaluating the components. The figure shows that after finding and evaluating the component, there is a need for component adaptation and testing before it can be integrated into the system. The system is verified and later maintenance is performed if needed. Figure 3.1: The V Model [19] The Component-based Life Cycle Model The Component-based Life Cycle model is presented by Capretz [11]. This is a general model that focuses on the changes and instability of the development process. The model tries to capture the overlapping and iteration of the phases; system analysis, domain analysis design, implementation and maintenance, as shown in figure 3.2. The model also expresses in which phases in the software life cycle the reusable library is taken into consideration. This model shows a smooth and efficient way of using reuse and its mechanisms. 9

21 System Development CHAPTER 3. PRESTUDY Figure 3.2: The Component-based Life Cycle Model [11] The Y Software Life Cycle Model The Y Software Life Cycle model is taken from the work of Capretz [12]. The Y model has been proposed as a model for software reusability during production of component-based software. As shown in figure 3.3 the planned phases are domain, engineering, frame working, assembly, archiving, system analysis, design, implementation, testing, deployment and maintenance. The qualities of the Y model emphasis reusability during the creation of software applications and the production of reusable components. Figure 3.3: The Y Software Life Cycle Model [12] 10

22 CHAPTER 3. PRESTUDY System Development CBSD Process Using Design Patterns The approach to apply design patterns in component-based development is purposed by Yau and Dong [74]. They have chosen to take advantage of design patterns to prevent designers from finding solutions to each design problem from scratch. In their model shown in figure 3.4, the components are identified and the design patterns are selected from the customer requirements and application specific constraints. The software design is fulfilled by using the design pattern instantiation information to instantiate the design patterns. The design is verified if it satisfies the selected design pattern and application specific constraints. The next step is to generate the component wrappers to produce the application software. Testing requirements and application specific constraints are done in the last step. Figure 3.4: Development Process Using Design Patterns [74] The Component-based Integration Systems Development (CISD) Model The CISD model in [63] is a procurement-centric model that supports the project planning and guides the development process. This model identifies the key engineering phases and their subphases which are often neglected in existing development models, such as the Waterfall and the Spiral models. The CISD model consists of three phases: product identification, product evaluation, and product integration. The product identification includes collecting and understanding the overall system requirements, identifying and classifying of COTS product into product sets, and then prioritizing these sets. The product evaluation includes integrating, evaluating and comparing these product sets to select the most suitable combination for integration. The product integration includes the building of all necessary adapters for the selected COTS products to implement the required system. Figure 3.5 shows a summary of the CISD model. The backward pointing arrows reflect on the iterative and incremental development of large component-based software products. 11

23 System Development CHAPTER 3. PRESTUDY Figure 3.5: Summary of the CISD Model [63] The Architecture Based Component (ABC) Model The ABC model in [43], aims to show that software architecture play a centric role in the whole lifecycle. It involves software architecture in each phase in the component-based software life cycle. The software architecture is used as a blueprint for system development. The ABC model reduces the distance between high-level design and implementation by mapping mechanisms and realizes the automated system composition and deployment on runtime component operating platforms, and makes architecture available at runtime for software maintenance and evolution [43]. Major issues in ABC include architecture-oriented requirement analysis, architecture design, architecturebased composition, architecture-based deployment, architecture-based maintenance and evolution of software systems. The process model of ABC is shown in figure 3.6. Figure 3.6: The ABC Model [43] 12

24 CHAPTER 3. PRESTUDY System Development Summary of Models The models presented in section to 3.2.6, have different features, which make them usable for different potential software development projects. Their diversity gives us knowledge about different component-based system development models. In table 3.1 a summary of these diversities are given. Model Advantage Disadvantage The V model The model has many of the general The model is, because phases discussed in 3.2. It of it s sequential struc- is often used [19], which means ture, especially used in that it is a well known model. projects with many stakeholders and long development time. The Componentbased The model consists of some of The model does not have Life Cycle the general steps, but has cho- the phases; component se- Model sen to rename them. It includes lection and system intepresses a reusable library and exgrationlection where the software life cycle takes the library into consideration. The Y model The model involves a frame working phase which is where a generic structure provides a skeleton for developing the system. A skeleton makes it easier for the developer to identify suitable components and the relationships between them [12]. CBSD Process Using Design Patterns The CISD model The ABC model The model is mostly concerned with the phases of requirements analysis, component selection and software design. It uses patterns and reuse of different patterns. The model helps analyzing the details of a new system from different levels with their phases and sub-phases. Uses a iterative and incremental integration of subsystems into the final system. The model uses a software architecture as a blueprint, which provides a top-down approach for achieving component-base reuse. Table 3.1: Summary of Models The model has as much focus on development of reusable components, as it has on system development with components. This correlates poorly with the system development with components focus in this project. The model automatically generates wrappers to help components in the integration phase, this leads to less control over the integration phase. The model lacks support when requirements changes. The model is architectureoriented and introduces software architecture in the requirement specification to achieve traceability between the requirement specification and system design. 13

25 System Development CHAPTER 3. PRESTUDY 3.3 Current Software Component Technologies and Tools As component-based software development (CBSD) has become an interest for both the research community and the software industry, many supporting technologies and tools have emerged on the marked [10]. The lack of standard definitions to establish rules for how to develop, configure, integrate and deploy components [2], gives no restrains on the current technologies or tools developed. This section will present several component technologies and tools available in the industry and on the market Distributed Component Models: EJB, CCM and DCOM A component model defines the semantics and syntactic properties of components, in addition to specify interaction between components [32]. A local component model can only operate within one host. The local component model; Java Beans and the distributed object technologies; Common Object Request Broker Architecture (CORBA); Java Remote Method Invocation (RMI) and the Component Object Model (COM), have matured into distributed component models [23]. Distributed component technologies enable communication between components across machine boundaries. Enterprise Java Beans (EJB), CORBA Component Model (CCM) and Distributed COM (DCOM) have the most standardized supporting tools for component-based software development (CBSD) [10]. Sun s Java-based EJB component model is divided into two parts; client-side- and server-side component. EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology [59]. OMG s CCM extends the CORBA object model and thus enable developers to implement, manage, configure, and deploy components that integrate commonly used CORBA services, such as transaction, security, persistent state, and event notification services, in a standard environment [69]. The CCM standard also allows more software reuse for servers and more flexibility for dynamic configuration of CORBA applications [69]. Microsoft s DCOM is a extension of COM, that allow software components to have reliable, secure and efficient communication over different networks in a completely transparent fashion [45] Development Environments: ADE with ASL, SYNTHESIS and a UML-based CASE tool Ning [47] [48] presents a prototype of the Architecture Design Environment (ADE). ADE is meant to help the system architect when developing an architecture that will meet the functional and technical requirements of a system. ADE is a graphical user-oriented environment that hides the syntactic details of Architectural Specification Language (ASL). ASL is an extension of the CORBA IDL interface. In ASL, the functionality of a component is described by its provided and required interfaces. Provided interfaces define the types of services the component can provide to other components, while required interfaces define the services it needs from other components to execute correctly. ADE prepares components for reuse by clearly describing their provided and required interfaces. It uses the components interfaces to check compatibility between components. If a component s provided interface does not satisfy a components required interface, ADE generates or partially build adapters to help integrating the components, as shown in figure 3.7. These adapters are components that provides an interface identical to the required interfaces and uses the provided interface. The ADE tool helps analyzing and building systems from selected components, but offers no support in selecting components to best fit to the requirements. Neither does it help estimating the trade-offs and costs of building the system with the selected components. Another large restriction is that it only supports components that are built upon ASL. SYNTHESIS is a component-based software development environment presented by Dellarocas [21]. 14

26 CHAPTER 3. PRESTUDY System Development Figure 3.7: Provided and Required Interfaces Dellarocas argue that SYNTHESIS will minimize the manual effort required to integrate independently developed components into new applications. SYNTHESIS is an application development environment that focuses on the interpendencies of the components, and treat the interconnection of components in a software system as a separated design problem. The SYNTHESIS application consists of three elements: the software architecture description language (SYNOPSIS), the online design handbook of interdependencies and associated coordination protocols, and the design assistant which generates executable applications by successive specializations of their SYNOP- SIS description. SYNTHESIS supports easier integration of code-level components, rapid multiplatform development, insight into the range of alternative implementations and easier application maintenance. The Aspect-Oriented Component Engineering (AOCE) methodology is presented in [30]. They also presents several software tools to support the use of this method. AOCE enables a new approach to characterizing component capabilities and reasoning about component interactions and provided/required services. To help support this method, they have extended their software tools to support large-scale component-based system engineering. These tools have been assembled into a component enviroment. The main tool is a UML-based CASE tool for better support in component modeling. Other supporting tools includes JComposer, SoftArch and JVisualise, which respectively supports modeling, implementation, and visualizations of complex component-based systems Component Frameworks for the Development Process: OPC and CB-SPE tool The Open Process Components (OPS) framework presented in [27], is for software process definition and enactment. In the framework, the software process modeling is constructed as sets of components, which interact in meaningful ways. The framework is created based on three categories of abstractions, which are; a meta-model that identifies fundamental process entities and relationships; a per component representation of process states and transition; and a set of class relationships layered in a structured fashion to produce type definitions for components. The OPC framework provides a basis for developing, integrating, maintaining, and reusing a variety of process representations. The CB Software Performance Engineering (CB-SPE) framework [4] is used to predict and analyze the performance of the assembly based on the properties of the constituent components. From the analysis the developers have more information when deciding on system design. The framework consists of two layers: the component layer, which relates to the component developer, and the applications layer, which relates to the system assembler. In the component layer, the component repository is found with component specifications. These specifications includes interfaces, which declare the component predicted performance properties that are platform independent. In the 15

27 System Development CHAPTER 3. PRESTUDY application layer the system assembler knows the characteristics of the environment in which the component will be deployed. Then he can choose the components, which better fulfill the settled platform dependent performance requirements. The CB-SPE framework focuses on the evaluation of performance properties and gives a prediction and analysis of CB systems Other Tools This tool was not suitable to categorize other with the other tools, but show a emerging technique, which we wanted to explore in our prestudy. technologies have no relations with each other. Sterling Software ADD portfolio presents COOL:Spex, which a component modeling tool that supports domain analysis, component identification, components and the import/export of component specification to implementation tools [8]. The COOL:Spex tool include general purpose diagramming tools, which support interface modeling, collaboration modeling and refinements concepts necessary for components specification Summary of State-Of-the-Art Technologies and Tools The technologies of this chapter are summarized in table 3.2, with their advantages and disadvantages. These technologies and tools are either to general to be of use for us or to specified with many limitations, which can not be overlook. Therefore none of these technologies and tools can be modified to fit to the tool, which we aim to develop. Technologies Advantage Disadvantage EJB, CCM and CCM and DCOM let different EJB lets only Java components DCOM components communicate, even communicate over components which are on different different networks. Comgrammed networks and are proponent interfaces in CCM in different languages. Component interfaces in EJB is easier to modify and maintain. and DCOM needs extra modification and maintenance. ADE with ASL; SYNTHESIS and a UML-based CASE Tool OPC and CB-SPE tool COOL:Spex These environments allows the support developers to use components when developing systems. The need for these tools exists in today s businesses, who wants to develop large and often complex systems or small systems to minimize workload, to minimize workload, help with design and focus on interpendencies of components. Helps integrating and implementing components to one system. These frameworks help the software process automation field to mature so that more attempt can be made. Increases the developers perspective on components. Table 3.2: Summary of Models ADE has focus on architecture and generates code. SYNTHESIS has focus on the interpendeincies of the components. The UML-based CASE Tool is developed to support the AOCE method. Their specific focuses, limits their potential. They provide the context for fitting the components together, which is not needed in our tool. General purpose tool, which is hard to modify to our needs. 16

28 CHAPTER 3. PRESTUDY System Development 3.4 Architecture and Patterns Components can interact with other components in different ways based on the functional role of the component. These interactions have been arranged into familiar and reliable structures, such as architectural patterns and other patterns. This chapter defines architecture and patterns, and describe their roles in CBSE Definitions An architecture describes the gross structure of the system [75]. The definition of software architecture is: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them [3]. The architectural design deals with the top level design decisions, including how the system is composed of interacting parts [26]. A pattern is a named and well-known problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and a discussion of its trade-offs, implementations, variations, and so forth [39]. In other words, a pattern has been proved to be a successful solution to a well known software development problem, which can guide the developers when selecting the appropriate architecture for a new application [57] [73]. There are three types of patterns: Architectural patterns: deals with the global properties and architecture of a system composed of large-scale components [18]. Design patterns: are used to describe the behavior of the inner parts of a component composition for a particular design, which includes the relationship and interactions among the components [74] [18]. Several design patterns can be used in one software design [73] and a collection of design patterns is called a framework [18]. Idioms: are low-level patterns that are dependent on the chosen paradigm and the programming language used [18] The Role of Patterns and Architecture The architecture forms a bridge between the requirements and the target system. A good architecture can help ensure that a system will satisfy the key requirements in such areas as performance, reliability, portability, scalability and interoperability, as well as suggesting a blueprint for a system s construction and composition [26] [75]. The design of the software architecture, which includes interconnection of components, design of module interfaces, selection of software and hardware platforms and distribution geometry, can be seen as a template on which components can be plugged into a new application [49] [26]. Creating an architectural template and plugging in components, is one way of doing the component-based software development process. The degree to which we are able to plug in components, the operative phrase in compositional development, relates directly to the degree to which components adhere to some set of predefined constraints or conventions [9]. Getting a good architecture is a critical success factor for a system s design and development [26]. An architectural framework such as CORBA, COM and JavaBeans, can help developers with component-based software engineering by reducing the problem of architectural mismatch by putting constraints on components. Architectural mismatch can arise when components from different environments are integrated, due to different data models, functional mismatches or resource conflicts [33]. For small- to medium-size companies, one determined architecture, a product-line 17

29 System Development CHAPTER 3. PRESTUDY architecture, is often used when developing new applications. Therefore, it can be argued that the component library used with a component-based development tool, only needs to contain components created for one common architecture. For example, if a developer has chosen the MVC-pattern, the components he selects must only include functionality that fits into either the model-, view-, or controller part of this pattern. If there are no such restrictions, it means that the developer will have the possibility to choose between several components than if the library were restricted to one architecture/pattern. Another advantage is that the developer can start selecting the most important components to the application, and later decide upon which architecture or pattern he wants to use. However, a great disadvantage is that the developer is responsible for making sure that the components he selects for the application he is developing, fits into the architecture/pattern he decides to use. Another issue with software architecture, is to identify those services that are shared among the software component infrastructure, rather than within one or more components [39]. This is an important distinction when selecting components and when testing the system. When selecting components, it is important to know what kind of services you are looking for in each component. Testing a particular components is not an important issue if the components are trust-worthy. However, the services provided by the infrastructure can contain errors and need to be tested. 3.5 Requirements Engineering This section will highlight the main difference between the requirements engineering process in traditional SE and CBSE. It will also present textual use cases, which helps when deriving requirements Requirements Engineering (RE) in Traditional SE A current approach to defining requirements is Requirements Engineering (RE) [50], which include eliciting, modeling and analyzing, communicating, and evolving requirements. These activities help developers understand how to specify the required behavior of a software system. There is a standard to help with these activities: IEEE Recommended Practice for Software Requirements Specifications [52]. The standard can be used as a guideline when constructing software requirements specification, which includes content and qualities of a good requirements specification Requirements Engineering (RE) in CBSE In traditional SE, requirements engineering (RE) is used to elicit the requirements for a new software system. This can be done before the system design phase has begun. This because the system s functionality will be built from scratch, which puts no restrictions on the requirements. This process is not appropriate in CBSE, because as dicussed in chapter 2, the requirements have to match the available components, which requires that RE and component assessment are done in concert. Traditional RE can be used in CBSE if the developer takes into consideration the components functionality during the requirements engineering process UML Textual Use Cases UML Textual Use Cases have a course-oriented and system-oriented view that makes them fit for requirements specification for component-based software [25]. Textual use cases describe courses of events between the actors and the system when the actors use some part of the system s functionality. Textual use cases can be created to cover the functionality in the customer requirements. This will result in that the use cases reflect the system s functionality requirements in a clear and understandable way. Use cases are helpful when creating functional requirements from customer 18

30 CHAPTER 3. PRESTUDY System Development requirements and they can be used with any development technology [6]. Fleisch [25] presents a more structured textual use case, to capture the requirements of component-based software. This structural use case captures the scenarios between the user and the system, as well as scenarios specifying the interactions between actors modeled inside the system. The use case can therefore also be a help when analyzing and validating interactions between the components used to compose the system. However, the use case he presents is more fit when the components inside the system can be identified as actors, as when using microcontrollers. One microcontroller can be seen as an actor, but it is a more complex task to identify Java classes or packages as actors. The reason for this is that Java classes and packages are more cohesive, which means that it is more difficult to look at it as an independent actor. Hence, this method is not fit for our purpose. 3.6 Component Selection Component selection is an essential activity in the design of a component-based software system [53], and hence, the essential activity in the CoExSel tool. Therefore, in this section we will go beyond the discussion about component selection done in section 3.2, and discuss several issues concerning the component selection activity. We will also present some methodologies that are developed to help with the component selection process The Bi-directional Relationship Between Requirement Engineering and Component Integration Tran et al. describes in [64], the Cyclical Requirement-Component Dependency model as shown in figure 3.8. In [64] they identify components as only COTS components, but in our opinion the model is relevant for all types of components. Figure 3.8: The Cyclical Requirement-Component Dependency Model [64] The cyclical dependency is identified as the consequence of two main problems [64]: 1. Creation of modification of a system requirement forces reexamination of COTS products that have been previously selected. 2. Selection of a new COTS product forces reexamination of all associated system requirements. If product s limitations are uncovered during later phases of the development, due to i.e. component defects or lack of functionality, system requirements that could not be 19

31 System Development CHAPTER 3. PRESTUDY supported with the currently selected COTS products often have to be re-evaluated and re-negotiated to ensure timely delivery of the system [64]. If using white-box components, this will be less of a problem due to the possibility of correcting the component s code. Tran et al. also identify several strategies to minimize the risks of this dependency problem [64]: 1. Ensuring appropriate support is available to enable early component evaluation. 2. Capturing strengths and weaknesses of all evaluated components to expedite re-evaluation. 3. Separating product limitations from technology limitations. 4. Prioritizing the system requirements based on their contribution to the usability of the final system. 5. Ensuring requirement-component dependencies are documented throughout the life cycle of the system Approaches to Component Selection There are a number of tools already created to support the component selection process. The majority use a comparison between the requirement specification and component evaluation to drive this process. When creating a new tool it is important to examine the existing tools. This section will therefore present a selection of existing tools created to help with the component selection process. CdCE: Context-Driven Component Evaluation The Context-driven Component Evaluation (CdCE) presented in [42], provides strategies and techniques for automating a repeatable process for assessing software components for a particular project. In CdCE the component selection problem is approached as a classification problem; assigning each component to a class based on its assessed suitability to the project. To be able to assess the components, the CdCE process begins with developing an ideal component specification with a standardized template. The ideal component specification is created of the requirements in the project and includes context-specific values, priorities and interplay of attributes. A system is trained to recognize suitable components, resulting in a short list of components. The context-specific aspects of the component are used to generate a test-suit, which allows meaningful comparisons between components. The results of execution the tests are evaluated, then the components are assessed and ranked based on their test results. In [42], they are interested in training classifiers to recognize suitable components based on AI-techniques. The techniques described in the paper are the C4.5 algorithm for generating decision trees and neural networks. Both classifiers were trained on the same ideal specification of components and a case study showed that both classifiers were able to find suitable components with high accuracy. DesCOTS: A Software System for Selecting COTS Components The work of Grau et al [29] presents the Description, Evaluation and Selection of COTS components (DesCOTS) system. DesCOTS is a software system that embraces several tools to support the activities of selecting COTS components. Their system, in difference to most existing tools, aims to support the whole component selection process. This tool is similar to the tool we are designing, so we will therefore explore it in more detail. The tool is structured as seen in figure 3.9. It consists of the Quality Model Tool (QM) which allows to define quality models, the COTS Evaluation Tool (EV) which allows the evaluation of components, the COTS Selection Tool (SL) which allows the definition of requirements that 20

32 CHAPTER 3. PRESTUDY System Development drive the COTS component selection, and the Taxonomy Tool (AD) which allows organize COTS domains as a taxonomy supporting reuse of quality models [29]. Figure 3.9: The DesCOTS Structure [29] The basis of the selection process in DesCOTS, which can be seen in figure 3.10, is the quality model. A quality model is the set of characteristics and the relationship between them which provide the basis for specifying requirements and evaluating quality. The quality model in DesCOTS is based on the ISO/IEC [35] quality standard, which defines the quality factors; functionality, reliability, usability, efficiency, maintainability and portability. The Quality Model tool provides functionalities to define software quality factors, to reuse them among different quality models, to state relationships among them, to assign metrics for their future evaluation and to define requirements patterns, among others [29]. Figure 3.10: Selection of COTS in DesCOTS [29] 21

33 System Development CHAPTER 3. PRESTUDY The COTS Evaluation Tool supports the evaluation of COTS components and has two main functionalities; managing the registration, modification and removal of COTS components into catalogues, and managing the COTS evaluations. The tool supports evaluating the components using the Quality Model defined with the Quality Model Tool. The COTS Selection Tool supports the formal definition of Selection Requirements, in terms of the Quality Factors of the specific QM. An example of a formal definition is Eval(Understandability) = High AND Eval(Attractiveness) = High [68]. This definition is used to automatically propose candidate components based on the priority of the formal selection requirements. The COTS Selection Tool also supports the management of the requirement list and the assignment of priorities to individual requirements. The tools in the DesCOTS system are independent from each other and can therefore be use individually. Data is imported into and exported from tools by the use of XML [67]. A disadvantage with this tool is that it is restricted to the use of COTS components. If it is possible to adapt the tool to use other components, such as Java classes and packages, is likely but not explored. The tool allows evaluation of COTS components based on quality factors in the quality model, but it do not support saving important reusability information such as previous use and experience, previous use in the developing application, exception handling, etc. Component-Oriented Requirements Expression (COREx) Method The COREx service-oriented method in [33] [37] is based on viewpoints that makes use of a service-model to map user requirements to components. The COREx has three iterative steps: requirements elicitation, requirements ranking and requirements modeling. The requirements elicitation step includes identifying different generalized viewpoints (for actor and stakeholder) as a starting point for finding viewpoints specific to the problem domain. The requirements ranking include ranking the requirements in three levels in terms of their benefit to the user, i.e. essential, important or useful. The result list of requirements together with potential components and services is the basis for component verification. Component verification in done, during the requirements definition, as a filter for establishing the availability of candidate components and services, and during design to establish how well the component and services match the desired functionality. The component selection is done by making selection filters, where each requirement has a checklist of component and service properties. The component and service properties are ranked as to how well they support the requirement. The requirements modeling include modeling viewpoints requirements and mapping these requirements to concrete software components and services, which is made possible by the component service descriptions. COTS - Acquisition Process (CAP) The CAP method in [51], is a repeatable and systematic method for performing measurementbased COTS assessment and selection. The CAP method consists of three components: The CAP Initialization Component (CAP-IC), the CAP Execution Component (CAP-EC) and the CAP Reuse Component (CAP-RC). CAP-IP includes identification of evaluation criteria for available COTS and prioritizing these criteria, a measurement for estimating the effort of applying all the criteria and a plan for performing the evaluations. CAP-EC includes exploration activities of COTS software and a review of all CAP-EC activities. It also includes activities for selecting COTS software, which comprise of data collection, evaluation, and decision making. CAP-RC includes storing the knowledge about COTS software for reuse in future COTS assessment projects. 22

34 CHAPTER 3. PRESTUDY System Development 3.7 Cost Estimation Analysis CBSE exploits the potential of reducing development time by using pre-existing software components. However, pre-developed components can be built for different architectures, programming languages, etc. This means that new costs such as integration and adaptation costs, are most likely introduced when integrating the components into a new system. I.e. an integration cost analysis can help selecting the best COTS products in terms of costs, by determining how much glue code and adaptation the components will need to be integrated. Therefore, cost analysis is important. This section presents cost estimation in traditional SE and CBSE Traditional Cost Estimation Approaches From traditional software engineering, cost estimation is done by approaches such as expert opinion, analogy and algorithmic models [5]. Expert opinion refers to cost estimations done by estimators using past experience to predict the costs of new systems [5]. A disadvantage with this approach is the dependency on the estimator s subjective opinion and past experience, which most likely will result in that different estimators give different cost estimates. Analogy is a more formal approach where cost estimates are based on comparisons between the new software and past projects [5]. A disadvantage with this approach is that accurate cost estimates depends on the access to past projects. Both expert opinion and analogy can be adopted by CBSE. However, algorithmic models were developed to estimate costs based on the properties (usually size) of the system to be developed Use Case Estimation Use Case Points (UCP) is a method used to estimate the effort of developing a software system, based on the use cases of the system. First, the actors and each use case are identified and given weight, depending on their complexity. Unadjusted actor weights (UAW) is then calculated as the product of the number of actors and the complexity weight, summarized over all actor types. UAW = #UseCases 0 #Actors Complexity weight The unadjusted use case weights (UUCW) is calculated as the sum of the number of transactions multiplied with a complexity weight, for all use cases. UUCW = #UseCases 0 number of transactions complexity weight, where a transaction is a set of use case steps which cannot be separated. Unadjusted use case points (UUCP) is calculated as the sum of UAW and UCW. UUCP = UAW + UCW Finally, the unadjusted use case points is then adjusted based on thirteen technical and eight environmental factors, which can be found in appendix C.1.2. There are several proposals for how to transform use case points to effort. A well accepted solution is to calculate the number of staff hours per UPC based on the environmental factors [55]; The number of factors in E1 through E6 that are below three are summarized N1. N2 is summarized as the number of factors in E7 through E8 that are above three. If the sum, N = N1 + N2, is two or less, then the UCP is estimated to need 20 staff hours. If N is three or four, 28 staff hours per UCP 23

35 System Development CHAPTER 3. PRESTUDY can be used. For N larger than four, 36 hours per UCP is estimated. However, if the sum N is larger than four, the risk is seen as unacceptably high and changing the project is recommended Cost Estimation in CBSE Most of the cost algorithmic models developed for traditional software engineering, cannot be fully adopted by CBSE because component-based software engineering introduce new cost factors. These are cost from effort needed to understand the software, pre-integration assessment and evaluation, post-integration certification of compliance with mission critical or safety critical requirements, and costs due to incompatibilities with other needed software and/or hardware [1]. Costs especially introduced when using COTS components can also be royalties, cost of licensing and redistribution rights, and indemnification against faults or damage caused by vendor supplied components [1]. In addition to these new cost-drivers, estimation models for traditional software engineering, are usually based on a number of parameters such as software size, including length, functionality and complexity [5]. With component-based software development, the size is not always an important factor of cost-estimation, as discussed in chapter 2. It is not given that integrating two large components will cost more than when integrating two small components A Software Architecture Classification Method Yakimovich et al [71] describe a detailed software architecture classification method for estimating the cost of COTS integration. In their work they focus on component-software interactions and use variables to estimate the distance between the architecture and the components. Every component is designed with assumptions concerning its interactions. To estimate the integration cost, the authors of the article represents the integration assumptions of single components and software architecture by an interaction vector V = (P, C, I, S, B). The variables P, C, I, S, B are the variables packaging, control, information flow, synchronization and binding. Component packaging describes how a component is packaged for integrating into a system. The two classes of packaging types are linkable and independent components. For the independent component, the classifications that represent the values of the component packaging parameters are: independent programs, overlays, dynamic linkage libraries, source code modules and object modules, shown in figure An example of the partial ordering is; The values for independent stand-alone programs are greater than values for other independent components such as overlays and dynamic linkage libraries because the latter can be put into the wrapper programs and thus converted into independent programs. The work of Yakimovich et al [71] describes the details of the partial ordering. Figure 3.11: Ordering of types of packaging [71] The estimation of the integration cost between a system and a COTS product, starts with finding the interaction vector V s of the system architecture and the interaction vector V p of the COTS product. A comparison of V s and V p is done and can result in different outcomes: 24

36 CHAPTER 3. PRESTUDY System Development V s = V p. The integration assumptions of the system and the product match. Then the integration cost considers only syntax and semantic of the interactions of this system and COTS product. V s V p. A number of assumptions are different, but those of the COTS product is still compatible with the assumptions of the system. The COTS product will work under architectural assumptions of the system after being integrated. This direction of compatibility is acceptable and the integration cost considers only syntax and semantic of the interactions. V s V p. A number of assumptions of the COTS product are compatible with the assumptions of the system. In such a situation, integration work must be done to work around the architectural mismatches. If it is permitted to change the COTS product, then it may be possible to modify the product so that it becomes compatible with the system. Here, a estimation of the cost of the COTS product modification must be done. If it is not permitted to change the product, then the architecture of the system must be changed or some glue code must be written to integrate the COTS product. Estimating the integration cost include finding an architecture, which both the system and the product are compatible with. This is done by finding a vector V c which is a common upper element of V s and V p, such that V s V s and V s V p. This will guarantee that all components of the system and the product can interact in the architecture with the interaction vector V c. The glue code for modifying the system, must have properties defined by V c and the costs depend on the distance between V c and V s and the distance between V c and V p. An example of the common upper element for packaging is; The system has packaging = independent programs and the COTS product has packaging = C++ class library. Then the minimal common upper element = independent programs, because independent programs have a higher ordering than libraries, which will work under independent programs. Although the proposed approach does not directly give the amount of effort in units, such as staff hours, it can identify problems for the component integration and suggest solutions COCOTS: A COTS Software Integration Lifecycle Cost Model COCOTS, presented in [1], is a model attempting to predict the lifecycle costs of using COTS components. The authors of the paper states that this model is still under development. The model is, however, interesting because it is built on what we identify as important cost-drivers. COCOTS an extension of COCOMO II [13], is a cost estimation model for developing systems both from scratch and with pre-existing source code. COCOTS is composed of four submodels addressing the initial development costs associated with integrating COTS components which are (1) assessment of COTS candidates, (2) COTS component tailoring, (3) glue code development and (4) increased system level programming due to volatility in incorporated COTS components. The total integration cost is the summation of the four subprocesses. The effort estimation of assessment (1) is split into initial filtering, which eliminates COTScomponents by based on basic functionality, limits the group of possible choices, and detailed assessment of each COTS component. The effort is estimated on: Initial Filtering Effort (IFE) = i=classes i=0 [(# COTS candidates in class) (initial filtering effort for class)] (3.1) 25

37 System Development CHAPTER 3. PRESTUDY Detailed Assessment Effort (DAE) = i=classes, by project domain i=0 [(# COTS candidates in class)(average detailed assessment effort for class)] where the average detailed assessment effort for a given class is qualified by the attributes usually assessed for that class [1]. Final Project Assessment Effort = IFE + DAE (3.2) Tailoring refers to the work needed to be done to a COTS component to integrate it into a system, including activities such as parameter initialization, input/gui screen and output report layout, security protocols set-up, etc. The project tailoring effort is estimated by: Project Tailoring Effort = i=classes,byprojectdomain i=0 [(# COTS tailored in class)(average tailoring effort for class and complexity)] (3.3) where the average tailoring effort for a given class is qualified by the complexity of the overall tailoring task usually associated with that class [1]. Glue code is the new code needed to integrate a COTS product into the system. The model calculates the amount of glue code as a function of the amount (or size) of glue code to be written, its estimated percentage rework, the constant A, the rated nonlinear architectural scale factor, and the individual rated effort adjustment factors [1]. Glue code effort = where A= scaling constant A [(size)(1 + CREV OL)] B (effort multipliers) (3.4) Size = size of the glue code in source-lines-of-code or function points CREVOL = percentage rework of the glue code due to requirements change or volatility in the COTS products B = an architectural nonlinear scaling factor Effort multipliers = 13 multiplicative effort adjustment factors with ratings from very low to very high A detailed description of the linear effort multipliers are shown in [14]. System volatility captures the effects of integrating new versions of COTS components and of changes in the system requirements. System Volatility Effort = (application effort) ([1 + (SCREV OL/(1 + REV L))] E 1) (COTS effort multipliers) (3.5) Application effort = new coding effort separate from COTS integration effects 26

38 CHAPTER 3. PRESTUDY System Development SCREVOL = percentage rework in the system independent of COTS effects due to requirements change REVL = percentage rework in the system independent of COTS effects due to requirements change. E = (COCOMO Scale Factors) COTS effort multipliers = 13 multiplicative effort adjustment factors from the glue code submodel A detailed description of the volatility effort multipliers and scale factors are shown in [14]. The total COTS integration effort in COCOTS, is treated as the linear sum of the four sources effort. The total COTS integration effort = Assessment Effort + Tailoring Effort + Glue Code Effort + System Volatility Effort (3.6) As an approximation, this works for now, but the true relationship between the terms is likely more complicated [1]. 3.8 Cost-Benefit Analysis A cost-benefit analysis of software reuse can give companies valuable information, when they are deciding to take advantage of reused components. However, benefit can come in many flavors, such as health, economical and social, and hence it can be difficult to map all benefits without having knowledge about the organization. Therefore will we in this study look at the economical aspect of benefit, because it can be quantified. The economical benefit can be analyzed by comparing costs with reuse and cost without reuse. Costs with reuse (C r ) are the cost occurring when development includes reusing components, in addition to developing from scratch. Cost without reuse (C wr ) are costs concerned with developing systems from scratch, i.e. traditional SE. When companies are deciding whether reuse is a worthwhile investment, the costs of reuse has to be identified. In [36], it is argued that there are costs connected to developing for reuse, for example making the component general. From two practical investigations of companies described in [31] [61], we observed the practice was instead to create simple components that can be reused. When the components were simple, they were also easy to modify for use in new software systems. This implies that the developing for reuse cost was not significant when estimating costs. Therefore we will not look at the developing for reuse costs. Costs that can result of developing with components are costs when trying to find the right component and overhead costs associated with reuse. When having simple components stored in a database, the cost of finding components is a search cost (C s ). There can be a need for modifying the components, hence a overhead cost (C h ), to make them fit a new software system s requirements [36]. This costs includes cost factors described in section 3.7, as well as wrappers and adapters to integrate the components into the new software system. These costs result in the total criterion for beneficial reuse: C s + C h < C wr C r (3.7) The economical benefit of using reuse as appose to not reusing must be larger than the search and overhead cost of reuse. 27

39 System Development CHAPTER 3. PRESTUDY 3.9 Time-To-Market Estimation Estimations for Time-to-Market is done in a model for estimating the development time and is based on costs. When costs is estimated and expressed in person-months, the model in [36] is: T dev = c Cost a (3.8) where c and a are constants, that will depend on development mode. For example, when developing Web Systems [58], the values are based on size of the system. The suggested values then are a = 0.5 if there are less than 40 web objects and a = 0.33 is there are more. C is suggested to be 2.0 for web-based electronic commerce projects. In COCOMO [36], the development modes are: Organic development mode: c = 2.5, a = 0.38 Semidetached development mode: c = 2.5, a = 0.35 Embedded development mode: c = 2.5, a = Reliability Analysis A reliability analysis can be performed early in development of software systems if it is based on a component reliability analysis [24]. In this study, estimation of reliability is included to support selecting the suitable component with the required reliability for reasons discussed in chapter Software Component Reliability Analysis In [24], an approach is presented to analyze the software reliability using component analysis. It is based on 6 steps for a analysis of component reliability. The six steps are: 1. Divide the software into components. 2. Characterize the properties of each component. 3. Characterize how usage stresses each component. 4. Model reliability growth of each component. 5. Superimpose component reliabilities. 6. Do confirmatory analysis during testing. Dividing the software into components implies that a component should have a fault density uniform across the component. Therefore are, components separated based on; which software that will run on processors with different speed, and which the pieces of software that are delivered at later times to system test. The properties of a component that affects the reliability, are the static and dynamic properties. Static properties do not depend on the processing done by the system, opposed to dynamic properties that do. The static properties include: fault density (FD), source lines (SL), code expansion factor (CEF) and fault repair efficiency (FRE). The dynamic properties include: fault exposure ration (FER), processing distribution (PD) and operational stress (OS). The characterizing of how usage stresses each component, must be done in two periods. The first period is during system test, which enables modeling reliability growth during system test. The second period, is during operation, which enables translation of the reliability values relative to test processing time into field or operational reliability values. 28

40 CHAPTER 3. PRESTUDY System Development a Type of Execution >5 very non-uniform, characterized by many infrequently-executed paths associated with branches and/or loops with many iterations.2, 5 moderately uniform <.2 nearly uniform, fem infrequently-executed paths associated with branches, few loops with iterations associated with each loop. Table 3.3: a values [34] The Extended Execution Time (EET) model [34], is used to model reliability growth of each component. EET is used because it calculates reliability based on the parameters summarized in the properties of each component. The EET formulas for Cumulative Failures (CF) and Failure Intensity (FI) are: CF = c (1 G(a, z)) F I = c b d G(d, z) (3.9) Where the G(a,z) is a transcendental function that can be represented by: G(a, z) = 1 0 e zxa dx (3.10) In table 3.3 the values of parameter a is illustrated with the non-uniformity of instruction execution. The relationship of the parameters used in the EET model for each component i to the characterized properties describes above and the processing time t expressed in machine instructions, is summarized below: z i = (a i + 1)b i t i c i = F D isl i F RE i (3.11) a i = P D i b i = F ER i MI i d i = OS i OSi (3.12) Superimposing the component reliabilities provides a composite model for the software system. The FRE factor for components can have three possible situations. First, it can be 1. Then the EET models for the components are Poisson Process model. The Poisson Process property is that; The cumulative failure and failure intensity functions for the superposition of Possion Process models is the corresponding functions for each component. Second, the FRE factor is not equal to one and then the EET models are not Poisson models. Third, the FRE factor is nearly one, and then the EET model is nearly a Poisson Process model. To do confirmatory analysis during testing, there is a need for a calibrated model for the software system. A calibrated model shows what the reliability growth will be during system test and can be used to investigate different orders of test cases on reliability growth. An example, taken from [24], of a calibrated model can be based on six components. The core components are CORE01 and CORE02. The components associated with feature A, are FEAT-A1 and FEAT A2, will be available at the start of system test. Feature B will be available in a later increment, with the B components FEAT-B1 and FEAT B2. To test these components, there are a number of available tests cases defined that stress the various components in various ways. In this example, it was also possible to determine how each test case stresses each component. This allows us to estimate how often the test case would occur during field operatio. To run the test cases, two strategies was considered. These were to; select test cases uniformly, not giving any weight to a particular test case over any other test case, and select test cases based on their operational profile. Figure 3.12 shows, the resulting reliability growth curves for these two strategies. The 29

41 System Development CHAPTER 3. PRESTUDY Figure 3.12: Investigation of Testing Strategies on Reliability Growth [24] solid line represents results from selecting test cases based on field frequency of occurrence while the dashed line are results from doing uniform selection of test results [34]. During system test, model predictions can be used to track and compare observed failure events. The observed failures are plotted versus cumulative failures predicted by the model. To track if the failure events fall within the specifies control limits, control charts are used. The control charts is analyzed to validate the model. The analysis can lead to a rejection or an approval of the model Part Count - An Additive Reliability Model The additive reliability model in [70], is based on that each subsystem or modules has been independently tested and the reliability of the complete system has to be assessed. The subsystem reliabilities are estimated and the system reliability is assessed using the additive model. Estimating the reliability of the subsystems is done during the component testing. The experienced intensity of software failure is denoted by λ(t). The mean value function, which is the expected number of failures in [0,t), and is denoted as µ(t). The relationship between λ(t) and µ(t) is given as: λ(t) = dµ(t) ; t 0 (3.13) dt Once µ(t) and λ(t) is known, future failure behavior can be predicted and reliability related decision can be made [70]. The system failure intensity, λ s (t), is the sum of subsystem failure intensities, λ i (t), i = 1,2...n. The relationship between λ s (t) and λ i (t) is given by λ s (t) = λ 1 (t) + λ 2 (t) λ n (t). (3.14) The expected cumulative number of system failures at time t, µ s (t) is given by Part Count - The Kubat model µ s (t) = n µ i (t) (3.15) i=1 The Kubat model found in [38], reflects the case of a software composed of M modules designed for K different tasks. Each task may need several modules and the same module can be used 30

42 CHAPTER 3. PRESTUDY System Development for different tasks and the tranisition between the modules follow a discrete time Markov chain. This implies that with probability q i (k) task k will first call module i and with probability p i j(k) task k will call module j executing in module i. The delayed time during the visit in module i by taks k has the probability density function g i (k, t). The failure intensity of a module i is α i. The probability that no failure occurs during the execution of the task k while i is R i (k) = 0 exp αit g i (k, t)dt. (3.16) The expected number of vistis in module i by task k, denoted by a i (k), can be obtained by solving module i is a i (k) = q i (k) + M a j (k)p j i(k). (3.17) The probability that there will be no failure when running for task k is given by i=1 R(k) = Π M i=1[r i (k)] ai(k) (3.18) and the system failure rate becomes λ s = K k=1 r k[1 R(k)], where r k is the arrival of task k. With starting point in equation 3.17, reliability can be R = Π M i=1(1 F i ) ai (3.19) where F is the failure probability. This leads to M a R 1 F i i (3.20) i=1 Therefore, the resulting part-count model is M a F F i i (3.21) i=1 31

43 System Development CHAPTER 4. RESEARCH AGENDA Chapter 4 Research Agenda With an increasing use of CBSE, there is a growing need for tools to support the componentbased development process [17]. CBSE aims to reduce time-to-market by simply and efficiently build systems from components, but it can only be achieved with extensive tool support [17] [54]. Tools are necessary to help maintaining artifacts such as system and software architectures, code libraries, etc, as well as help making them retrievable [54]. Examples of existing tools are component selection and evaluation tools, tools for managing the repositories, component test tools, component-based design tools, run-time analysis tools, component configuration tools, etc [17]. We have studied a selection of component selection tools, which are presented in section 3.6. To our knowledge, there does not exist any tools that help in the trade-off analysis about deciding which components that should be selected for a new application to best satisfy the customer in regard to the customer s requirements, the development costs, time-to-market and quality. And in addition, support the decision by providing earlier experience with the component. 4.1 Goal and Research Questions The main goal of this project is: to create a tool that helps the developer with selecting components for new component-based software systems, by providing suitable component information and supporting the trade-off analysis between functionality, costs, reliability and time-to-market. Important research questions when developing such a CBS development tool are: How do we efficiently identify implementation requirements from customer requirements? How can we represent the implementation requirements? What information about the components does the tool-user need and how can this be represented? How do we estimate time-to-market, cost and reliability for component-based software? 4.2 Research Methods The main goal of this project was to find out how to create a tool that will be useful in the component selection phase of CBSE. Hence, a brainstorming for coming up with ideas for functionality and design, was mandatory. The ideas was presented to our supervisor, which gave us feedback. 32

44 CHAPTER 4. RESEARCH AGENDA System Development A literature study was performed in order to gain knowledge about component-based software engineering (CBSE) and how to calculate time-to-market, cost and reliability in CBSE. Exploring methods and processes where done with the purpose of transforming customer requirements to system requirements, and to find a suitable way to represent the implementation requirements. A paper prototype model in the form of low tech sketches, was designed to examine the final design and functionality of the tool. A prototype was chosen because it would give us an intuitive and easy model to manipulate [65]. The model could be tested in situations where the user could touch and see the limited working model. An advantage of prototypes is that the user can give evaluative response on the model, which can be used to modify the model [65]. Other advantages is that the user has seen the system and will know what to expect. This results in higher user satisfaction [65]. Disadvantages to be aware of is that prototyping can lead to an insufficient analysis and to incomplete documentation [65]. Our prototype was tested on a relevant end user of our resulting tool. Based on the user feedback, the requirements and design was discussed. The prototype of the tool is planned to be implemented during the spring of Overall Work Plan This work plan is an approximation to the chronological order of our work. Our project started by coming up with ideas to what our tool should include of main functionality and what identifying relevant topics for a literature. Then the project followed to parallel paths, shown in figure 4.1. Figure 4.1: Overall Work Plan The first path was a literature study about CBSE, which included processes, technologies, and how to estimate time-to-market, cost and reliability. The second path involved creating the system. Brainstorming, which included coming up with many ideas and taking the best ones with us to the next step. Design, which included finding the main functionality of the system and functional requirements. The design also included making a prototype model of the system. Prototype-testing included testing the prototype on an extern person and receiving feedback on the functionality. Then an evaluation was performed, which included discussing the results of the test. 33

45 System Development CHAPTER 5. THE COEXSEL TOOL Chapter 5 The CoExSel Tool This section first gives an introduction to the CoExSel tool and identifies the role of the user in the usage of the tool. The last section presents the requirement specification of the CoExSel tool. 5.1 Tool introduction As stated in 4.1, the purpose of the CoExSel tool, is to support the selection of components by providing proper component information and by supporting the possibility of doing trade-off analysis between time-to-market, reliability, functionality and costs during component based software engineering (CBSE). To reduce the scope of our project, we define a component as a Java class or package that can be used as a stand-alone black-box component. However, we do not think that the tool is restricted to only be used with this definition of a component. The tool is meant to be useful for small to medium size companies that develop Java applications and want to be able to reuse classes and packages in new development projects. The CoExSel tool will help in the selection process by managing the implementation requirements. The tool will support deriving the implementation requirements from customer requirements in two different ways, as shown in figure 5.1. One solution is to create system requirements that cover all the customer requirements, and later convert them into implementation requirements. This will create a hierarchy of connections between the system requirements and their related implementation requirements. If the tool-user wants to connect an implementation requirement to more than one system requirement, this is also possible. Another solution is to create use cases that will cover all the customer requirements, and later specify the actions performed by the system into implementation requirements. Here, implementation requirements can also be connected to more than one step in the use cases. These connections provides traceability between use cases and implementation requirements. The tool support both of these techniques. The tool will manage the component library and provide searches for components that have a particular functionality and/or has been used in a particular architecture. The search result is a list of references to the description of the matching components. The component description includes information concerning if the components are used elsewhere in the application and ranking given by earlier users about the quality and trust-worthiness of each component. The tool supports the selection process by allowing a user to connect an implementation requirement to a component. The tool also supports the selection process by keeping track of which implementation requirements that are fulfilled, which are not fulfilled, and which requirements that the tool-user have unsuccessfully tried to fulfill by searching for a component. 34

46 CHAPTER 5. THE COEXSEL TOOL System Development Figure 5.1: Connection between Use Cases and Requirements When the components for the new application have been selected, the tool will perform estimations of time-to-market, cost-benefit and reliability. This will allow users to compare the effect of reuse of different possible sets of components. In summary, the CoExSel Tool will have the following main functionality: Let the user connect the use cases/system requirements to implementation requirements and vice versa. Provide the user with information about the components, including earlier experience with the component. Provide the user with search for components -functionality. Allow the user to select components. Estimate time-to-market, cost and reliability. 5.2 The Role of the Tool-user The following tasks can be carried out on the CoExSel Tool: Creating use cases/system requirements. Creating implementation requirements from the system requirements. Creating implementation requirements from actions performed by the system as described in the use cases. Group use cases, system requirements and implementation requirements into categories based on key words. Connecting implementation requirements to system requirement/use cases. Connecting implementation requirements to components and components to implementation requirements. Search for components. Search for implementation requirements. 35

47 System Development CHAPTER 5. THE COEXSEL TOOL Figure 5.2: The Role of the User Inserting experience related to a component. In difference to other tools discussed in section 3.6, there is no automatic selection process performed by artificial intelligence in this tool. The tool-user is the central actor in the use of the tool, as seen in figure 5.2. It is the tool-user that after creating implementation requirements from use cases or system requirements, is responsible for finding the most suitable component to match the implementation requirements. It is his experience and the support from the tool with information about others experiences with the components, that enables the tool-user to make a good decision. An advantage of this is that there are less constraints on the components put into the component library. I.e. it is not necessary for a component to be created for a particular component model such as CORBA. The tool is therefore more applicable to the CBSE process. Fewer constraints on the components will most likely result in that the component library consists of a larger amount of components, which will increase the probability of finding a component with the needed functionality. However, a disadvantage is that architectural mismatch between components are more likely to happen when the components do not support one common component model. It is not given that components with different component models can be modified and tailored into one software system. 5.3 Requirements Specification The requirements specification presents the requirements for the CoExSel tool, which includes the functional requirements. Functional requirements describe the functionality or services the system is expected to provide. This chapter gives an overview of the functional requirements of the software system Open Project Requirements FR.1 New Use Case Project The user must be able to create a new project, which allows the creation of use cases to help deriving the implementation requirements. FR.2 New System Requirements Project The user must be able to create a new project, which allows the creation of system requirements to help deriving the implementation requirements. 36

48 CHAPTER 5. THE COEXSEL TOOL System Development FR.3 Open Existing Project The user must be able to open an existing project Use Case Projects FR.4 New Use Case The user must be able to insert a new use case. FR.5 Categorize Use Cases The user must be able to group the use cases into categories based on key words, which the user can define based on preferences. FR.6 Insert Into Use Cases The user must be able to insert name, number, actor, pre-condition, post-condition, basic path and alternative path, into the use case template. FR.7 New Use Case Template The system must be able to open a new use case template. FR.8 Store Use Case Template The system must be able to store and retrieve the use case template with the inserted information System Requirements Projects FR.9 Insert Requirements and requirement description. The user must be able create a system requirement with id, name FR.10 Categorize System Requirements The user must be able to group the system requirements into categories based on key word, which the user can define based on preferences. FR.11 New System Requirements Template requirement template. The system must be able to open a new system FR.12 Store System Requirement The system must be able to store and retrieve a system requirement s id, name and requirement inserted in the system requirement template Implementation Requirements FR.13 Categorize Implementation Requirements The user must be able to group the implementation requirements into categories based on key word, which the user defines based on preferences. FR.14 New Implementation Requirement from Use Cases The user must be able to create new implementation requirements connected to each step in the use cases. FR.15 New Implementation Requirement from System Requirements The user must be able to create a new implementation requirements connected to a system requirement. FR.16 Select Component from Implementation Requirement component and connect it to the implementation requirement. The user must be able to select a FR.17 New Implementation Requirements Template implementation requirement template. The system must be able to open a new 37

49 System Development CHAPTER 5. THE COEXSEL TOOL FR.18 Implementation Requirements The system must be able to store and retrieve the implementation requirement template with id, name and requirement description Component Selection FR.19 Component Information The system must be able to store component information such as input/output, category, functional description, and exception handling information. FR.20 Component Experience The system must be able to store experience inserted by users such as used in architecture/pattern, number of times used before, number of times used in the application to be developed, description of use in other projects, and ranking of non-functional attributes FR.21 Search for Components and/or used in architecture. The user must be able to search for components by category FR.22 Result List criteria. The system must be able to return a list of components that match the search FR.23 Components Result List The user must be able to retrieve all information about a component from the result list returned in FR.22. FR.24 Select Implementation Requirement from Component a chosen component to an implementation requirement. The user must be able to connect FR.25 Overview of components belonging to an application components selected for the application. The user must be able to view the FR.26 Appear Once list. The system must be able to show each component only once in the result Calculations FR.27 Time-To-Market The system must be able to do a time-to-market estimation. FR.28 Cost-Benefit The system must be able to do a cost-benefit estimation. FR.29 Reliability The system must be able to estimate the reliability of the system. 38

50 CHAPTER 6. RESEARCH QUESTIONS System Development Chapter 6 Research Questions With basis in the research questions defined in chapter 4.1, this chapter presents the different ideas and solutions we discussed concerning the requirements and design of the CoExSel Tool. We outline the contribution of our work and argue for the decisions we took to reach the final solution. We created a paper prototype to evaluate the choice of the tool-design and the decisions we took, which are presented in section 7. The evaluation is presented in section How do we efficiently identify implementation requirements from customer requirements? Deriving implementation requirements direct from the customer requirements can be difficult due to the gap in the level of details between them. The usual solution to this problem is to insert system requirements as a stage in between. Our initial idea was therefore to allow the tool-user to insert system requirements and then allow him to specify them further into implementation requirements. The other solution we came up with were that the tool-user could write textual use cases for scenarios such that all customer requirements were fulfilled. The tool-user could then specify steps in the use cases into implementation requirements, and hence, would not need to write a complete system requirements specification. The idea was that the tool-user would specify each step performed by the system into implementation requirements. However, it would be difficult for the system to check whether a use case step is preformed by the system or by another actor such as a user. Hence, it would be up to the tool-user to use the tool correctly. We believe that an advantage of basing our tool on use cases is that they are a well known and frequently used when developing new software. We therefore think that the usability of the tool would be good. The properties of textual use cases supports the identification of context information, such as identifying actor(s) involved in the use case, as well as preconditions and post-conditions of the use case. We believe that this is an advantages with use cases that enables the tool-user to understand the context in the use cases in the tool. This would give him an idea of the context of the implementation requirements. To describe a use case, the tool-user would be able to fill in a basic path and alternative paths. The tool-user could then derive implementation requirements from both these paths. The basic path would put the implementation requirements in a clear and structured order which would provide the tool-user with good overview of the basic course. The alternative path would enable the tool-user to think of implementation requirements which might have been forgotten if only system requirements were created for the basic scenario. If the customer requirements change and the tool-user wants to delete a use case or a step in the use case, all implementation requirements connected to that use case or step, would also be deleted if they are not connected to a step in another use case as well. 39

51 System Development CHAPTER 6. RESEARCH QUESTIONS We think that an advantage of using the system requirements -approach instead of the use case - approach, is that they are easier to write and therefore less time-consuming. The tool is meant to allow the tool-user to categorize and sort the system requirements according to his preferences. However, categorizing system requirements would not give the user the course-oriented view and context information, as we believe would be provided in the use case -approach. We wanted to take advantage of the features we believe would be provided in the use case -approach and decided to support writing use cases in the CoExSel tool. However, because of the disadvantage that it may be time-consuming to write use cases, we also decided upon supporting writing system requirements into the tool. 6.2 How can we represent the implementation requirements? The question of how to represent the implementation requirements, is important because, as discussed in chapter 2, the level of details in the implementation requirements must match the level of details in the component description. We saw no other possibility than that an implementation requirement could be added through a text field. To be able to manage the requirements, we thought that a requirement should consist of a name, an id and the textual requirement description. However, because it is important that a tool-user is able to categorize the implementation requirements, we also included a category. The category would represent a catalogue under which the implementation requirement would be found in the implementation requirements tree-menu. A catalogue is meant to be created after preferences by the tool-user. 6.3 What information about the component does the tool-user need and how can this be represented? In our opinion, the tool-user needs at least component information such as id, domain and written description about the component s functionality. However, the quality of the written information would depend on the tool-user that insert the information. To make sure that the tool-user has a certain amount of information to base the component selection decision on, we explored how we could provide the tool-user with more information about the functionality and quality. Since the components in this tool, for now, are restricted to Java classes and packages, the tool will provide a link to the Java API. An Application Program Interface (API) is documentation of functionality of a component and includes exception handling of that component. Therefore, the tool-user should be able to access the components API to learn more about its properties. Other information that could be useful is which architecture the component is designed for. With this information, the tool-user could choose components that fit to the same architecture. Even if the tool-user did not choose components that was created for one common architecture, we believe it would be useful to know which architecture the component is designed for to understand more about the component. A disadvantage, however, could be that tool-users can have doubts about a component that is very suitable for his application since it is designed for another architecture than the one he wanted to use. Therefore, he might drift towards other, maybe not suitable, components. It is claimed that developers do not use formal component selection processes, but base their component selection upon their experience with the components [62]. Thus, another idea we had were to allow inserting experience from using the components, and this information would be provided to all the tool-users. Tool-users would be able to insert experience such as their ranking of the reliability and the quality attributes of the component, textual description of the use of a component and general experiences gained, the architecture of the project the component was used in, etc. The purpose is to give the tool-user a broader perspective of the components, which is used to drive the component selection decision. A disadvantage is that tool-users could insert unreliable and error prone experience, which could misguide other tool-users. To try and reduce this problem, experience would be inserted together with details of both the author and the project 40

52 CHAPTER 6. RESEARCH QUESTIONS System Development in which the component was used. 6.4 How do we estimate time-to-market, cost and reliability for componentbased software? It is important that the estimation methods used in this tool, give reasonable values. The preference of estimation methods can differ among companies. Therefore, to try and satisfy most users, we decided that estimation methods would be created as plug-in to the tool. When programming a complete prototype of this tool, it is important to that the plug-ins are easy to create and add to the tool. For our simple paper prototype, the decision of which estimation methods the tool should use for estimating time-to-market, costs and reliability, was not important when the tool would support plug-ins. It was, however, important the methods chosen would be a good example of the information these estimates would provide. We therefore decided to select estimation methods for time-to-market, cost and reliability, that were simple, but still representative for a possible estimation method. The final decision of which estimation methods we used, are presented in chapter Our Contribution Experience We believe that earlier experience with the component would be useful information in the selection process. An advantage of including experience in the tool, could be that seeing earlier use of the component can provide information such as what functionality the component has been successfully used to fulfill and which architecture or pattern it has been successfully used in. We believe that reliable information can reduce the risk of selecting an inappropriate component due to the lack of information about the functionality. In addition, we believe it can reduce the risk of architectural mismatch. We also believed that experience such as the quality of earlier developed systems using that component, and a ranking of the quality of the component, could reduce the risk of bad quality in new systems to be developed. We also thought that experience could give the developer an impression of the ease of integrating the component, and therefore give an impression of the cost of developing with that component. The use of an experience databases is a well known concept. However, to our knowledge, there does not exist any component-based software development tools that include an experience database to support the component selection process. By integrating the experience database with the development tool, we think that it will be easier to use. Looking up experience in a separate tool can be time-consuming. Therefore, integrating this functionality in the tool could be an advantage and lead to more frequently use. More frequently use of the experience database, can motivate the tool-users to insert reliable information, which again can increase the use of the experience in the selection decision The CoExSel Tool Constructs an Important Connection By supporting the phases from converting customer requirements into system requirements/use cases, and further specify them into implementation requirements before selecting appropriate components, the tool is meant to construct an important connection between the use cases/system requirements, the implementation requirements and the components. We argue that these relations are important when the customer requirements change, when substituting or updating one or more components, when there are errors in the component, and when evaluating the effect of the reliability of the components. 41

53 System Development CHAPTER 6. RESEARCH QUESTIONS Customer requirements often change because the requirement specification is unclear or because of changes in what the customer wants. If this occurs, it is important to minimize the cost and effort required to implement these changes in the system. We believe that knowing exactly which parts of the system, i.e. which components, that are affected by the change in the customer requirements, will minimize the scope of changes in the system and the effort needed to retest the system. Which parts of the system that are affected and must be changed, could be identified by looking at the use case(s) which the customer wants to change, and then follow the connection from the use case to the implementation requirements. If system requirements were written instead of use cases, then the implementation requirements could be traced by finding the system requirements written to fulfill the customer requirement. However, finding the system requirements affected by the change in one or more customer requirements, might be a more time-consuming task. This because textual use cases give a more course-oriented view of the system where the effect of changes are easier to discover. If errors are discovered in the system due to errors in one or more components, it is important to find out where the error is located. We believe that knowing which functionality that is affected by the error, makes it possible to trace the error from the customer requirement(s) that concerns that particular functionality, to the component(s) that implements the functionality. I.e. the tool-user could find the use case or the system requirement(s) that concerned the functionality the error affects. The tool-user could then easily follow the connection to the implementation requirement(s). These would be further connected to the components that fulfill the implementation requirements. Hence, this relation could help minimizing the scope of changes in the system and the effort needed to retest it. Only the components affected would need to be retested. However, it would be important to identify if the error is in the affected functionality, or if it is a symptom from an error that arose as a result from another functionality. This process could therefore only be used as a guidance to where in the system, i.e. which components, it is most likely that contain the error. Another scenario where we believe the relations could be important, is when evaluating the effect of the components quality on the application under development. I.e. if there is a component with more of the needed functionality but less reliable, then it is important to know which parts of the system s functionality that can be affected if the component does not work. This could be found by following the connections from the component to the implementation requirements, and further to the customer requirements. Hence, the tool would give the tool-user important information in the trade-off analysis between reliability and costs when building the system Enables Trade-off Analysis between Functionality, Costs, Time-To-Market and Reliability When selecting components to develop new component-based software systems, there is often a need for trade-off analysis. Trade-offs can arise between different combinations of functional and non-functional requirements such as functionality, costs, time-to-market and quality. As mention in chapter 2, a reason for trade-off is that it does not exist any combination of components that fulfill all the requirements. We believe that trade-off analysis is supported in the tool by allowing the tool-user to connect the implementation requirements to a set of components and then automatically estimate costs. When this is done, the tool would give the tool-user an overview of which implementation requirements that are not fulfilled. This to make it easier to see if there are important requirements that are not fulfilled. The tool is meant to estimate the cost of developing the application with the chosen components, which would include the estimate of the amount of effort required to develop the unfulfilled requirements by traditional development. This could be done with several different sets of components, and trade-off analysis could be done between the different solutions. Another important issue in the trade-off analysis, is the possibility to study the consequences of 42

54 CHAPTER 6. RESEARCH QUESTIONS System Development changing one or more of the customer requirements. The customer requirements are rarely so fixed that the customer is not interested in making small changes to save money, shorten time-to-market or increase reliability. We believe that this is supported in the tool by letting the tool-user select or deselect one or more components, and perform the estimations on different solutions. The results could then be studied and give the tool-user information about i.e. how much the cost changed when a requirement was removed. The tool is also meant to estimate the cost of developing with traditional software engineering, which could be compared to the cost of developing with CBSE. The CoExSel tool is also meant to give he tool-user an estimation on the reliability of the selected components, which could be used in comparison with costs and other solutions. 43

55 System Development CHAPTER 7. TESTING AND RESULTS Chapter 7 Testing and Results We created a paper mock-up model of the tool to test its utility. The model was tested on a fictitious scenario created in cooperation with a system developer from Edvantage Group AS, from now called the test-person. Edvantage Group is a firm which creates portals and hosts web-based courses for e-learning, which they sell to customers. The test scenario is based on a possible extension of their system. This chapter will present our tool in further details by presenting the test scenario, which includes the testing process, the goals and the results. The succeeding chapters will discuss and evaluate the results in further detail, as well as suggest improvements and further work. 7.1 Goals The main purpose of the test was to investigate if the tool can help developers in the component selection process. A problem in the component selection process is, as discussed in section 2, to select the set of components that best fit in the new application in regard to functionality, costs, time-to-market and quality. The main goals of the test were therefore to check if the tool could be used for: Giving helpful information to the developer when choosing modules/components from a database and integrating them into a system or part of a system. Analyzing trade-offs between several solutions. Analyze the consequences of changing one or more requirements. The sub-goals identified were: 1. Identify if the information given about a component gives appropriate and significant information to the user, so he can match the component against the implementation requirements. 2. Identify any missing functionality. 3. Test if the preserved relations between the component and the customer requirements serve any purpose. 4. Test the usability of the tool. 5. Test the utility of the tool. 44

56 CHAPTER 7. TESTING AND RESULTS System Development In sub-goal 1, we wanted to test the level of details in the component description compared to the details of the implementation requirement. The user must have enough detailed information about the component to be able to match it with an implementation requirement. In sub-goal 2, missing functionality refers to any functionality that by not being supported, prevents the tool from being used as stated in the goal in section The Testing Process The mock-up model was created on paper and consisted of all screen shots that can occur when using the tool. New screen shots were presented as the test-person preformed actions on the system. The actions were the result of tasks given by us. The following tasks were given to the test-person: 1. Create a new project based on the test scenario. 2. Write Use Cases from the customer requirements. 3. Write implementation requirements from the use cases. 4. Select suitable components to achieve the implementation requirements. 5. Estimate time-to-market, cost and reliability. 6. Is this the best set of components to achieve the implementation requirements considering time-to-market, cost and reliability? 7. Can any requirements be changed to achieve better time-to-market, cost and reliability? A customer requirement is changed: 1. Do the necessary changes to the project. 2. Do the estimations of time-to-market, cost and reliability. Only the coarse features of this procedure were followed. Instead, a more informal discussion of the usefulness of the tool was carried out. The tasks were hard to follow because of the limited functionality of the mock-up model and the lack of experience inserted with information about earlier reuse of the components. 7.3 Fictitious Scenario The fictitious scenario, developed in collaboration with Edvantage Group, was based on a possible extension of their system. The scenario was to create a system that would handle the billing of customers for their use of e-learning courses. A customer is a company that buys access to a package of e-learning courses which is hosted by Edvantage Group. In this system, the customer could either be charged based on license or per usage. When billing a customer per license there is a fixed price. Billing the customer per usage requires that the system calculates the number of users that use a course. This is done for each organizational unit in the customer s organization. The type of billing would be defined in the contract when the customer buys a package of courses. 45

57 System Development CHAPTER 7. TESTING AND RESULTS Create a New Project The test-person could create a project based on either use cases (Use Case Project) or system requirements (System Requirement Project). As explained in section 5.1, a Use Case Project entails that the test-person must create use cases from the customer requirements. The steps in the use cases which are preformed by the system, were transformed into implementation requirements. A System Requirements Project is similar, but the system requirements are then specified into implementation requirements. The test scenario only includes a Use Case Project, while a System Requirements Project will be explained in section A Use Case project is created by selecting Create New Use Case Project on the File menu, shown in A.1.1. This will result in the appearance of a use case tree-menu -view on the left side on the screen, as seen in figure Use Case of Billing a Customer The root node in the tree-menu consists of the project name, which in this scenario is called Invoice System. With the Invoice System -root node marked, clicking on the right mouse button will result in the appearance of a pop up menu. Selecting Create New Use Case will result in that a reference to a new use case is added as a child node of the marked node, in the tree-menu. It also result in that a Use Case template appears in the right view, as seen in appendix A.3. In this scenario, the test-person created a use case called Generate invoice. This use case is shown in figure 7.1. Adding several use cases is done by repeating this procedure. However, in this scenario only one was needed. Another possibility is to create catalogues as child nodes of the root node. Catalogues are meant to be used for organizing use cases into groups. Appendix A.3 shows examples of tree-structures the tool supports. Figure 7.1: Use Case for Generating Invoice 46

58 CHAPTER 7. TESTING AND RESULTS System Development The Implementation Requirements Implementation requirements could be created for each step in the basic path of a use case, as well as in the alternative path. In this scenario only the basic path was needed. An implementation requirement is created by marking the step where the new requirement should be added, and right clicking on the mouse button. A pop-up menu appears, and selecting Create New Impl Req creates a new implementation requirement as a child node of the selected use case step, as will be seen in the use case tree-menu. This procedure therefore creates a connection from the use case to the implementation requirements. An example is given in the appendix, section A.3. The connection is preserved for reasons discussed in section When selecting Create New Impl Req, in addition to creating a new implementation requirement reference in the implementation requirement tree-menu, the tool opens an implementation requirement template in the right view. This is shown in the implementation requirement template in appendix A.3. An implementation requirement created by the test-person from the Generate invoice use case, is shown in figure 7.2. A list of all implementation requirements created from the use case, is shown in appendix B. The implementation requirement -view that appeared, contains options for the tool-user to either cancel the action, save the implementation requirement or choose a component to fulfill the requirement. How to select a component is explained in section Figure 7.2: Implement requirement The tree-menu -view shown on the left side in figure 7.2, can be switched, i.e. from use case view to implementation requirements view, by using the tabs at the top of the menu. 47

59 System Development CHAPTER 7. TESTING AND RESULTS Connecting Implementation Requirements to Components A search for component -view is opened when clicking on the choose component -button, shown in figure 7.2. A search for component -view can be seen in appendix A.4. The search can be based upon the category of a component or the architecture the component successfully used in. A result list with components matching the search appears in the same view, as a list under the search criteria. Double-clicking on a component name, results in the component description -view appearing. The description of a component used in this scenario is shown in figure 7.3. Selecting the search tab on the top of the view brings the tool-user back to the search for component -view. Figure 7.3: Component Description Select As seen in figure 7.3, the component description -view contains information about the name of the component, the domain the component belongs to, a description of the functionality of the component, the number of projects which have used it before, the number of times it is used in this project, which architecture it is designed for, and a link to the java API for that component. The view also shows a text-box where earlier experience with the component is written. Adding experience is done by pressing the Add experience -button. This is further explained in section Clicking on the select -button as seen in figure 7.3, resulted in the search for component -view. Search were performed and a search result retrieved as seen in A.4. A component was selected and the implementation requirement were saved by pressing the save button. Then, the tool marked the implementation requirements with a green color. Not covered implementation requirements are marked with a red color. If a search is preformed, but no component is selected due to i.e. no suitable component found, then the requirement is marked with a yellow color. This procedure was repeated and a set of components were selected based on the component information and earlier experiences with the use of the component. Implementation requirements IR1.1 and IR1.2 were 48

60 CHAPTER 7. TESTING AND RESULTS System Development covered by the component AuthorizationManager.java, and IR2.1 was covered by the component Orgunit.java, as seen as child nodes of the implementation requirements in A Estimations When the suitable set of components was chosen, it was possible to perform an estimation analysis. From the menu Action, shown in appendix A.1.4, the test-person clicked on the Perform Estimation Analysis -item. This resulted in an estimation -view on the left side, shown in figure 7.4. The view includes the number of implementation requirements that was and was not covered by components. Figure 7.4: Estimation Analysis The CoExSel tool shall perform cost estimations both for CBSE and traditional SE, to estimate the benefit of using CBSE instead of traditional SE. In this simple prototype we continued our test scenario by calculating the estimations by hand. To estimate the cost of developing the Invoice System with CBSE, we used COCOTS [1]. To estimate the costs of developing the system with traditional SE, we used the Use Case Point method [55]. Both cost and effort are terms that refer to the cost of creating a new software system. Since COCOTS use effort as the unit of measure, we transformed the Use Case Points estimated into effort. The results of the estimations are shown below. The detailed estimation with the COCOTS method and the Use Case Point method, are presented in appendix C.2 and appendix C.1.2, respectively. For our test scenario, the total effort is represented by: component integration effort = = (person-hours) (7.1) 49

61 System Development CHAPTER 7. TESTING AND RESULTS The total effort for developing with traditional SE was: Effort = AUCP Person/Hours/AUCP = = (7.2) The probability that there will be no failure when running for task k is given by R(k) = Π M i=1[r i (k)] ai(k) (7.3) and the system failure rate becomes λ s = K k=1 r k[1 R(k)], where r k is the arrival of task k. The reliability is estimated by using the reliability of the individual components. In this scenario the system logic is thin and hence the a i 1, while in systems with thicker logic the a i 1. The probability that no failure occurs in the system (simplified) : R = Π M i=1[r i ] ai = Π 2 i=1[0.993, 0.995] = (7.4) Estimations on Time-To-Market is expressed in person-months as: T dev = c Cost a (7.5) where c and a are constants, that will depend on development mode. The effort was expressed in person-hours and hence, Time-to-Market is also expressed in personhours: T dev = c Effort a = = (person-hours) (7.6) where c is estimated in appendix C.2 and a is based on the COCOMO model [13] Change in a Customer Requirement When a customer requirement is changed, this can lead to changes in the use cases, which again can lead to changes in the implementation requirements. In this scenario the change in the customer requirements led to that IR1.1 and IR1.2 was not needed. The component that covered these implementation requirements was removed from the set of components. If the set of components is changed then a new estimate must be performed. The new estimate are calculated below. The total component integration effort = = = (person-hours) (7.7) The estimation of the use case points in effort for traditional SE was: Effort = AUCP P erson/hours/aucp = = (7.8) The probability that there will be no failure when running for task k is given by R(k) = Π M i=1[r i (k)] ai(k) (7.9) and the system failure rate becomes λ s = K k=1 r k[1 R(k)], where r k is the arrival of task k. The estimations that no failure occurs in our components (simplified) : R = Π M i=1[r i ] ai = Π 1 i=1[0.995] = (7.10) Estimations on Time-to-Market is expressed in person-months: T dev = c Cost a (7.11) where c and a are constants, that will depend on development mode. Time-to-Market expressed in person-hours: T dev = c Effort a = = (person-hours) (7.12) where again, c is estimated in appendix C.2 and a is based on the COCOMO model [13]. 50

62 CHAPTER 7. TESTING AND RESULTS System Development 7.4 Remaining Functionality The CoExSel tool has more functionality than was shown in the test-scenario. The remaining functionality will be explained in this section System Requirements A tool-user can, instead of creating a Use Case Project, create a project based on system requirements (System Requirements Project). A System Requirement Project is created by selecting the Create New System Requirements Project -item on the File -menu, shown in appendix A.1.1. This results in that a system requirements tree-menu -view appears on the left side of the application window. This view will be similar to the use case tree-menu in Use Case Projects. With the project name marked the tool-user can click on the right mouse-button, which will result in that a pop up menu appears. Selecting Create New System Requirement in the pop up menu, will result in that a reference to the new system requirements is added as a child node of the marked node. The system requirements -view on the right hand side of the screen will be similar to the implementation requirement -view. A button in the system requirement -view can be pressed to create a new implementation requirement. When pressing this button, a implementation requirement -view appears on the right side of the application window, as it did when creating an implementation requirement in the Use Case Project. Tool-user can then follow the same procedure of filling in the implementation requirement and selecting components to fulfill it Catalogues System requirements can be categorized into catalogues. The purpose is to make the system requirements more organized and manageable. Creating a catalogue is done by right-clicking on a system requirement in the system requirement tree-menu, and selecting create catalogue in the menu that appears. Catalogues can only be created from the root node or other catalogue nodes Connecting Components to Implementation Requirements As shown in the scenario, components are selected by pressing select component in an implementation requirement -view. The selected component will then become connected to the implementation requirement where the search for a component was started. There is, however, another way of selecting components. The tool-user can select a component, i.e. by searching for a component, and then connect it to a suitable implementation requirement. This can be done by selecting search for component in the Component menu, shown in appendix A.1.5. This results in that the view for searching for components appears on the right side of the application window, shown in the figure in appendix A.4. As stated in section 5.3, the search can be based upon a category or which architecture the component have been used in. Selecting one component from the search result will result in a component description view appearing, as shown in figure 7.5. This component description -view is similar to the one that appears in the Use Case Project except that there exists a search for implementation requirement -button. The reason for this is that the tool-user did not have a starting point in the implementation requirement. When a tool-user presses the search for implementation requirement -button, a search for implementation requirement -view appears as shown in appendix A.4. The implementation requirements can be search for based on catalogue in which they are placed. The search results is a list of implementation requirements. By double-clicking on the implementation requirement name, the implementation requirement -view will be shown, which will be the same as figure 7.2. Selecting the Search for impl req -tab on the top of the view, brings the tool-user back to the search for implementation requirement -view. By clicking on the save -button in this view, the implementation requirement will be saved and 51

63 System Development CHAPTER 7. TESTING AND RESULTS the connection between the component and the implementation requirement, is preserved. This results in that the implementation requirement is marked with a green square. Figure 7.5: Component Description View, Connect to Implementation Requirement Adding Experience to Components Experience can be added by pressing the Add Experience button in the component description - view, as seen in figure 7.5. Pressing this button results in that a add experience -view appears on the right side of the application window, as seen in figure 7.6. The component, to which the experience will be added, is automatically identified by name at the top of the view. To insure accountability, the tool-user s name will automatically be inserted as the author of the experience. This requires that a log-in functionality is provided by the tool. This, however, is not taken into account in the specification of the CoExSel tool written in this report, and must be included before a complete prototype is developed. The view also allows the tool-user to insert the name of the project in which the experience of using the component is gained. The main goal of adding experience is as stated in 6.5.1, to increase the knowledge of the components. In the add experience view, the tool-user can rank the following experience attributes as high, medium or low, based on the the ISO/IEC [35] quality standard: Integration complexity: Represents a value of how difficult it was, or how much effort that was needed, to integrate this component with the other components in the project. Adaptation complexity: Indicates how hard it was to adapt the component. Reliability: The capability of the software to maintain the level of performance of the system when used under specified conditions. This attribute will also be estimated by the tool, but is added to validate the estimated value. 52

64 CHAPTER 7. TESTING AND RESULTS System Development Figure 7.6: Add Experience to a Component Modifiability: Indicates the degree to which a component can be modified when the desired change has been determined Testability: The capability of the software product to enable modified software to be validated. Usability: The capability of the software to be understood, learned, used and liked by the user, when used under specified conditions. Performance: Indicates the degree of response time and throughput behavior of the system. An example of how a tool-user can add an experience, is shown in figure 7.6. In addition to the ranking of attributes, the view contains a text-area where the tool-user can insert a description of the use of the component. The quality of the information inserted depends on the tool-users as stated in 6.5.1, but the intention is that the tool-user inserts a detailed description of his use of the functionality the component provided. The experience inserted in this view will be visible in the component description view. A text field will provide the tool-user with all experience added to a component, as can be seen in figurefigure 7.5. The view also contains an overview of the mean value of the values inserted by the tool-users, for each of these attributes View Selected Components All components selected for the application being developed in the current project, will be shown if selecting the View all components -item in the Component -menu, see appendix A.1.5. This will 53

65 System Development CHAPTER 7. TESTING AND RESULTS result in the appearance of a view that contains a list of the name and id of the selected components. A selected component is a component that is connected to at least one implementation requirement in that project. 54

66 CHAPTER 8. DISCUSSION System Development Chapter 8 Discussion Only a paper prototype of the CoExSel tool is developed. Hence, it is difficult to base the validation of the tool on results of testing. However, we will in this chapter state pros and cons pertaining the tool to highlight its value. The arguments are based on feedback received when carrying out the prototype-test, feedback from our supervisor and our own opinions on the tool. Issues that are important to discuss are maintenance of the component library, the feature of use cases, the value of the estimations, etc. 8.1 Maintenance The component library will evolve during use, due to insertion of new components, component adaptation and component updates. Updates can be the result of adding new functionality or correcting errors, and raises two important issues. First, it is important to investigate the effect updates of components have on systems that already included the component. Second, it is important to specify what will happen to the experience in the database when components are updated. When investigating the effect update of components have on systems that have already reuse the component, it is important to distinguish between two reuse solutions; (1) separate copies of components are distributed and used, or (2) components are reused by referencing to one common copy of the component. If each software system reuse a particular component by referencing to one common component, then changes in the component can result in errors in the systems where the component is already in use. Errors can either arise if the component s functionality is changed and the component does no longer provide the needed functionality. Another error arise if the interface of the component is changed, which means that the system can no longer use the component. Errors can also arise if the updated component contains faults. These problems will not arise if each software system has its own version of the reused component. When a component is updated there are no guarantees that the experience written about the use of a component, is still valid. Updating a component can, as mentioned, result in errors in the systems that use the component. If that is the case, then it is clear that the component experience is not valid any longer. Deciding what to do with the experience is important. One possibility is to delete all experience in the component information. The advantage of this is that no invalid experience will be read by tool-users. A disadvantage is that the valid information, if any, will also be deleted. This can result in unnecessary loss of useful information. Deciding what information that are still valid, is a challenge which can be difficult to solve. Keeping all the experience related to a component is not recommended if there is a possibility that the tool can provide invalid experience. 55

67 System Development CHAPTER 8. DISCUSSION Deleting all experience related to a component when errors are discovered in systems that use the component, is another solution. However, if the error have not yet occurred, or if each system uses its own version of the component such that errors from upgrading a to a new version could not possibly occur, then the decision is more difficult. This means that the experience could still be invalid, but it is not yet proven. New versions of a component can also result in that the experience is invalid even if no error would occur, i.e. as a result of changes in the modifiability or usability. Treating the two versions of a component as two separatecomponents in the component library, can result in a huge amount of redundancy. In The CoExSel tool, we use components as black-box components. The problems with maintenance are therefore limited. However, if the problems raised here can be avoided, then white-box components can successfully be used with this tool. 8.2 Categorization The CoExSel tool allows searching for components that match a category given as search criteria. Categories can be created by the tool-user when a component is inserted into the component library, and a component can be connected to several categories. This means that the type of categories is flexible and can be customized to suite the tool-users. In addition, a component can belong to several categories, and therefore be included in several search results. This makes the search functionality more useful. Searching by category is a simple and easy solution to allow searching for components. Categories are usually covering a larger functional aspect such as security, which means that detailed search for a particular functionality is not possible. If categories are made small and specific, a large number of categories might become a problem. The search is based on selecting a category from a drop-down menu, which might be inefficient if a large amount of choices can be selected. It can be time-consuming and difficult for the tool-user to get an overview of the categories such that he can select an appropriate search criteria. For example, a category named security can be divided into authorization, authentication, etc., which might not be intuitive knowledge for the tool-user. If it is difficult to get an overview of all categories, due to the large amount, then the search criteria he is looking for can be difficult to find. In such cases, free textual search might be better suited. However, textual search would make the tool more complex and difficult to build. The search functionality was difficult to test on a paper prototype and with a small number of components. However, be believe, based on the arguments in this section, that the search functionality in this tool is sufficient for use in small to medium size companies. In small to medium size companies, the number of components in the component library is most likely not enormous, hence, the disadvantages are limited. 8.3 Non-Functional Requirements As the CoExSel tool is presented in this document, it does not provide any support for defining non-functional requirements. This is an important feature which needs to be included in the tool. The tool supports no automatic component selection process, which means that it is sufficient to provide a text-box where the non-functional requirements can be inserted. It is, however, important that the non-functional requirements are visible and lucid. This can be achieved by inserting a text-box with a given framework where non-functional requirements can be inserted. 8.4 The Value of Experience Providing experience about earlier use of the component, is meant to reduce the risks that can occur as a result of lack of necessary component information, see chapter 2. The usefulness of the experience was difficult to test with the prototype, since we had no available experience with reuse 56

68 CHAPTER 8. DISCUSSION System Development of our components. However, we gained valuable feedback from our test-person about the value of the experience included in the component information, which we will present in this discussion. The test-person pointed out that it was easy to use the tool as an experience-database, because of the few restrictions on how to insert experiences. An advantage with few restrictions is that the tool-users can choose how to insert an experience and what experiences to insert. This means that the tool-users have more control over the process of adding experience, and that it is up to him to add informative, useful and valid experience into the database. As a result, the tool-users may feel more responsible for the quality of the experience that they add. A disadvantage with less restrictions is that the experience can be less structured, and it is therefore more difficult to retrieve the wanted experience. Finding information in a textual description of an experience can be time-consuming and difficult. This, if the amount of text in a description is large, or if the number of inserted experiences is large. The tool-user pointed out that a search among experiences would be useful. In particular, he meant it would be useful to have the possibility to search for information that were more positive or more negative than the main part of the inserted experience. This information, if it is valid, would tell the tool-user other aspects of the component that the main group of users have not experienced. Another problem is that if a large amount of inserted experiences differ in opinion, then they are more difficult to evaluate than if they all agree. However, to decrease these problems and make the experiences inserted more useful, the test-person pointed out that strict quidelines for how to insert and format the experiences would be necessary. Strict guidelines can lead to the disadvantage that it becomes a more bothersome task to add experiences. Two general problems with databases that contain experiences, is that (1) it can be difficult to reach a critical mass of users, and (2) users with great knowledge in an area do not necessarily see the need for using the database. A database must consist of a critical number of experiences before it can be useful. To overcome this problem, the users must understand the value of adding their experiences. In addition, the experiences must be easy to insert. However, users of experience databases may not see the value of the database, before the information has been useful for them. Easier access to the information they are looking for, and structured information which is lucid, can result in more users. The solution to the second problem, is to provide the users that has great knowledge in an area, a reason to use the database. An evident reason is that their knowledge can be very valuable and useful for others with little knowledge. Other reasons could be motivation from seeing that the tool was being used, or motivation from receiving acknowledgement for their work of adding valuable experience. The test-person highlighted that providing experiences with earlier use of components, was useful. An advantage was that the experiences explained how it was to work with the components. The tool-user could then learn and extract information from the experiences about working with the component that was useful to him. This way, the tool-user has a better foundation when selecting components, and hence, increasing chance of finding a suitable component. A disadvantage of describing how to work with a component, is that it could give too much information that may not be relevant to the tool-user. Then the tool-user might need to look through many experiences before he finds the information that is relevant to him. The disadvantage that it is time-consuming to look through experiences, could result in that the advantage of finding useful and valuable information, decreases. It could therefore, as mentioned, be useful to allow the tool-user to search among the experiences. To provide the tool-user with more information, the project name is included. With the project name related to the experience, the tool-user can look at the use cases and implementation requirements used in that project. In addition, the tool-user can look at the implementation requirements that are connected to a particular component. An advantage of looking at these connections, is that they give more information about the context the component has been used in before. 57

69 System Development CHAPTER 8. DISCUSSION When experiences are added to our tool, the author is added automatically to insure accountability, as discussed in section This advantage could increase the validity of the inserted experience. Another advantage, pointed out by the test-person, is the possibility of contacting the author of the experience. The test-person also pointed out that knowing which person that has inserted an experience, makes it possible to use knowledge about the skills of the author when evaluating the information. 8.5 The Features of Use Cases A disadvantage with the textual use cases in our tool, is that it is not possible to create a hierarchy of use cases that are connected. Supporting complex use cases were not regarded as important in our prototype, since we wanted a simple way of representing customer requirements. However, as pointed out by the test-person, complex use cases are a reoccurring phenomenon in companies. This is, therefore, an unsupported feature which should be explored in further work. An advantage of not having different levels of use cases, is that the tree-menus in the tool will be more lucid and less complex. Implementation requirements can be directly derived from the steps in a use case. This results in that the implementation requirements can be put into the context with a use case, which can give a better understanding of the surroundings of the implementation requirements, as discussed in section 6.1. The test-person expressed that the use case gave him an impression of where the implementation requirements belonged in the system. It gave context information, such as preconditions and post-conditions. He also thought they were useful when looking at how much of the use case that were covered by components and not covered by components. This because it would make it easier to estimate the work that remained to be done, because he had a complete overview over which implement requirements that were not fulfilled. Use cases describe scenarios and it is possible to have the same scenario in two different projects. The test-person stated that use cases were often reused from other projects. This would be an advantage for the tool-user, because then he could copy the use case from one project to another. It is also a possibility that the implementation requirements in a reused use case, are reusable. Then the tool-user can copy these implementation requirements and the connected components as well. This advantage saves the tool-user time he would have spent coming up with new requirements. If the use case can be reused, but not the implementation requirements, then the tool-user can use the implementation requirements as guidelines for creating new requirements. A disadvantage of reusing the use cases and implementation requirements, is that possible mistakes in the use case are also adopted. These mistakes should be discovered and corrected. Even if it is not possible to reuse anything from other projects in a new software system, it is still possible to learn from them by looking at use cases, the implementation requirements which were derived from the use cases, and the components that were connected to the implementation requirements. 8.6 The Value of Trade-off and Cost Estimation Trade-off analyses are important when all the requirements cannot be fulfilled and when the goal is to minimize costs and time-to-market, and maximize reliability. The CoExSel tool supports the tool-user when performing trade-off analysis. This could also be done manually. However, providing it automatically in the tool, saves the tool-user time and effort. Therefore, is it easier for the tool-user to perform several succeeding estimations on different sets of components, by changing the connections between the implementation requirements and the components. When the estimations are done automatically in our tool, it is important that they are based on sensible 58

70 CHAPTER 8. DISCUSSION System Development data from the development project. However, as pointed out by our test-person, a disadvantage of an automated process of estimating costs, time-to-market and reliability, is that a tool-user can be sceptical to the results. This because there are many other factors that depend on for example time-to-market. Time-to-market depends on i.e. which persons that develops which part of the system and their experience on the area. This information can be hard to quantify, and therefore affect the estimations. A different way to use the estimations, is to look at the relative difference between the value of two estimations. If the tool-user finds a project with higher estimated values compared to another project, he could choose the one with the highest value. This results in an advantage that it is not longer the value that is important, but the difference. Then it is not that important that a relative value is correct. A disadvantage, however, is that it is difficult to know if the proportion between these numbers are reflected in the difference. I.e. if a difference of twenty in effort is marginal or crucial. The tool-user may also wish to find a set of components that have high value of, for example, reliability. The test-person confirmed that this form of analysis was useful. In our discussion, the test-person expressed that the developer needs to provide many input values before the estimation could be performed. He stated that it would be better if these values could automatically be collected from the use case projects. A problem with that the input is provided by the developer, is that all inputs depends on a subjective opinion. It can be more reliable on the eyes of others if the estimation is more objective. Automatically collecting the input values, is also less time-consuming for the developer. However, it is difficult to build a tool that can collect input values automatically. In our opinion, it is important that the estimation methods are plug-ins. This means that tool-users could change the estimation method to the ones that fit their company, and/or that collect input from i.e. the use cases in the development project. 8.7 Usefulness of the preserved connection Testing the usefulness of the preserved connection was difficult on a paper prototype. The test scenario resulted in only one use case, which was to small to test all the functionality of the tool. The reasons implied in section 6.5.2, which included easier error correction, etc., were not tested. This is a task for future work. The test-person did not see the usefulness of using the connections for the purposes we had suggested. However, he thought that the connections were useful for setting the implementation requirements into a context, and useful if reusing use cases or implementation requirements, both discussed previously in this chapter. 8.8 Usability The overall feedback on the usefulness of the CoExSel tool, was that it was easy to use since it is based on well known software development methodologies. The tool was said to be flexible and therefore easy to deploy. The test-person did not have trouble understanding how to perform the tasks he was given, in the test scenario. The colouring of the nodes in the tree-menu with green, yellow or red, respectively, implies that: 1. The requirement is covered by a component. 2. An attempt has been made to cover the requirement with a component, but not succeeded. 3. The requirement is not covered with a component. This way of visualizing the coverage of implementation requirement, was seen as useful by the test-person. 59

71 System Development CHAPTER 8. DISCUSSION The test-person expressed that a possible disadvantage with the CoExSel tool that could affect the usability, was that it might be time-consuming to insert experience. If there, for experienced users, are more overhead with inserting experience than utility gained from using it, then that would be a critical fact. A detailed evaluation of usability is difficult to perform on a paper prototype. Hence, a more thorough prototype and test is needed. 60

72 CHAPTER 9. EVALUATION System Development Chapter 9 Evaluation This section presents and evaluates the answers we have found on the research questions stated in section 4.1. The answers are evaluated based on the test-results, feedback gained from developing and testing the paper prototype of the CoExSel tool, and the discussion in the previous section. 9.1 How do we efficiently identify implementation requirements from customer requirements? We have presented two procedures in section 5.1, for how to identify and derive implementation requirements from customer requirements in the CoExSel tool. The first procedure is to derive use cases to cover all customer requirements, and then further derive implementation requirements to cover all steps in the use case that are performed by the system. The second procedure is to derive system requirements to cover all customer requirements, and then further derive implementation requirements to cover all the system requirements. As discussed in chapter 8.8, use cases provide context information which were proven to be useful when deriving implementation requirements. This because it can be difficult to create implementation requirements, which can be an easier task with more knowledge about the surroundings of the implementation requirements. Only the use case approach has been tested and proven to be efficient in the prototype-test of the CoExSel tool. However, because both procedures are based on well-known requirements engineering concepts and easy to use, we conclude that both procedures are efficient to use when deriving implementation requirements. 9.2 How can we represent the implementation requirements? We believed when designing the CoExSel tool, based on the discussion presented in chapter 6, that an implementation requirement would be sufficiently represented by name, id, category and the requirement description. We have already concluded, in section 8.2, that including a category is sufficient when searches are performed. The prototype-test proved that name and id was sufficient information to manage, i.e. store and retrieve, implementation requirements. The representation of requirements, does not place any restrictions on how the implementation requirements are written. Hence, it is the tool-user s responsibility to write good implementation requirements. The tool is meant to be used by developers with experience in software engineering, hence, it is a valid assumption that the tool-user is able to write clear and unambiguous implementation requirements. This assumption was also supported by the test-person. Our definition of a component includes only Java classes and packages, hence, the level of details in a component description is at least as detailed as the Java API. The similarity in the level 61

73 System Development CHAPTER 9. EVALUATION of details in the component description between components in the component library, makes it easier for the developer to create implementation requirements that match the component description. For this reason, it is also a valid assumption that the tool-user is able to take into account the level of details in the component description, and write implementation requirements that can be matched to the component description. The results from the prototype-test supports both assumptions. The test-results showed that our test-person was able to represent clear and unambiguous implementation requirements in the CoExSel tool, which could be matched to the components description. Therefore, even if the quality of the implementation requirement depends on the tool-user, we conclude that our choice of representing implementation requirements is satisfactory. 9.3 What information about the component does the tool-user need and how can this be represented? In the CoExSel tool, we provided the tool-user with the following information about a component: Component name and id. Domain. Textual description of the component. Number of projects that have used the component before. Number of times the component is used in the current project. The architecture or pattern the component is designed for. Link to the Java API. Information inserted by tool-users containing their experiences with the use of the component in earlier projects. The information includes: A ranking of the attributes: integration complexity, adaptation complexity, modifiability, testability, reliability, usability. performance, to the values low, medium or high. A textual description with the experiences from the tool-user s use of the components. The prototype-test showed that all information we had included about a component was necessary. Component name, id and domain are used for storing, retrieving and searching for components. The test showed that the textual description of a component was useful to get an overview of the component s functionality. It could, however, not be used for matching a component with implementation requirements, since the level of details in the description were too low. The link to the Java API was useful for getting the right degree of details about the component. The Java API also provided the tool-user with information about exception handling, which was identified as important in chapter 2. When the tool-user had a several qualified component to select between, then the number of times the component had been used in the current project, was used in the selection decision. The test-person stated that the experiences the tool provided with earlier use of a component, were useful information in the component selection process, see discussion in section 8.4. The main reason was that it gave an impression of how it would be to work with the component, i.e. the ease of modifying or integrating it. Adding experience in the tool had some disadvantages, such as the degree of validity, and ease of extracting needed information. However, the test-person believed that these disadvantages could be decreased by providing guidelines saying i.e. how to 62

74 CHAPTER 9. EVALUATION System Development insert information. It can be difficult to get an overview of the quality of a component in a textual description. It was therefore highlighted that giving an average value of each of the ranked quality attributes, was useful. The test-person said that it should be possible to customize the values which are used for ranking. This because a company can have a familiar way of ranking, for example, integration complexity. Instead of using low, high and medium, they could prefer using quantitative values. Section 8.4 discusses the need for looking at the connection between use cases, implementation requirements and components in earlier projects. To make this process less time-consuming, it would be useful to include a link to earlier projects in the experiences inserted into the tool. The test-person also expressed a need for being able too look at and reuse use cases from earlier projects. He stated that a considerable amount of use cases could be reused in new projects. An idea could be that the tool supports the tool-user when a component is found and the tool-user want to see which implementation requirements it has covered in earlier projects. This can be done by letting the tool-user trace back to implementation requirements and use cases in earlier projects from a component. 9.4 How do we estimate time-to-market, cost and reliability for componentbased software? In our paper prototype, we used COCOTS [1] and Use Case Points [55] to estimate the effort of developing the test scenario with CBSE and traditionally software engineering, respectively. These estimation methods use constants that should reflect the company where the new software system is going to be built. Without the constants, the estimations are worthless. It is therefore important that companies gather experience to find valid constant values. We based the estimation of timeto-market on a cost estimate, and used a model presented in [36]. For estimating reliability in our paper prototype, we used a simplified version of the Kubat model [38]. In our test we used standard values for all constants in all methods, and assumed sensible input values where that was necessary. The test of the prototype showed, as discussed in section 8.6, that it was easy to perform two succeeding estimations on different sets of components. This showed that the effort of estimating different sets of components is small and that the user saves time, as apposed to doing the estimations manually. As the test-person expressed, he would not have done the estimations manually for different sets of components. However, he also expressed that he did not trust the estimated values, since they were automatically performed with subjective input. The test-person stated that in his company other factors could influence the estimations, such as who develops the system and the experience of the developers, which would result in changes of the estimates. However, these factors are included in both Use Case Points and COCOTS. We therefore argue that these estimations are useful. The test-person said that the relative values of different estimations would be a remedy for choosing a component set as suggested in section 8.8. The comparison of the values of the estimations, could be used to decide which component set to implement. Even if the test-person did not know the proportion between the values, he could make a logical assumption that the component set with the highest value of reliability and the lowest values of costs and time-to-market, would be the best solution. From the estimations, the test-person selected that he would weight reliability more than time-to-market. Then it was possible to use the estimations to get the highest possible value of reliability from the components. If including an additional component would result in a reduced reliability value, then the tool-user must decide if he wants to use the component or develop a 63

75 System Development CHAPTER 9. EVALUATION more reliable component from scratch. 64

76 CHAPTER 10. CONCLUSION AND FURTHER WORK System Development Chapter 10 Conclusion and Further Work 10.1 Conclusion The CoExSel tool presented in this report, has been proven to be helpful in the component selection process in CBSE. The tool provides the necessary functionality for supporting all stages in the component selection process, including requirement management, component library, connecting a component to a requirement, and performing cost, reliability and time-to-market estimations. To provide a better and more extensive description of the components, we have successfully been able to add experiences with earlier use of components, into the tool. The component description includes an average value, based on experiences, of each attribute, such as modifiability, reliability, usability, etc. This can give a good overview of the quality of the component if the experience is reliable. It has been proven that the experience provided in this tool, reduces the risk of selecting a set of components that lack functionality and includes low quality components. However, results show several possible extensions of our tool, which will provide the tool-user with more experience. For example, a link to earlier projects is concluded to be useful. The CoExSel tool has successfully provided estimations of time-to-market, cost and reliability. Feedback showed that the value of the estimations were not seen as useful. However, utility was gained from looking at the relative difference between two different sets of components. This made it possible to select the set with the best overall score on the estimations. In a particular set of components, it was possible to analyze the consequences of adding a new component with respect to reliability, time-to-market and costs. Trade-off analysis can be done between these attributes and the value of the functionality the component will add. Trade-off analysis can also be done between different sets of components. A challenge when a company adopts a tool like the CoExSel tool, is to reach a critical number of users. The tool is not useful before the sum of experiences provides valuable information for the tool-user. We can increase the probability of success if key-persons with valuable experiences, take the tool into use. We have designed a prototype and suggested improvements. If these improvements are implemented and the tool is taken into use, we believe that it can contribute to the component selection process Further Work To reduce the scope of the project, we decided to define a component as a black-box Java class or package. Further work should therefore investigate the use of the CoExSel tool with a more general component definition. In this project, we also decided to focus on reliability instead of 65

77 System Development CHAPTER 10. CONCLUSION AND FURTHER WORK including all attributes concerning quality. This to decrease the scope of the project. However, including other quality attributes can be done by including metrics which will estimate them. In the component description, we have included quality attribute values, such as ranking of performance, usability, etc., which are inserted by the tool-users based on his experiences from earlier use of that component. An idea is that quality estimates of an application designed with a set of components, can use these values to estimate the quality of the application if it is developed with that set of components. I.e. the mean of the experienced value of the performance attribute for each component in the selected set, can be used for estimating the performance of the total application. The CoExSel tool supports the reuse of components. The results from the prototype test implied that there were other artifacts that it could be useful to reuse, such as adapters, use cases and implementation requirements. Adapters are often developed to enable components to work together. It is likely that these adapters can be useful in new applications where a similar set of components are used. We therefore think that this issue should be investigated in further work. Our discussion in section 8.8, implies a need for supporting reuse of use cases and implementation requirements. The CoExSel tool can be expanded to include links from a component in a project, to other projects that have used that components. This would give the tool-user easy access to implementation requirements and use cases that the component have been used to fulfill in earlier projects. This would give the tool-user more information about the functionality of the component, and is therefore stated as useful information in this document. If a more functional prototype of the CoExSel tool are going to be developed in the future, the support of hierarchical use cases should be added, see discussion in section 8.8. Creating hierarchical use cases in the use case tree-menu, will make the menu more complex. However, will not be a difficult task to include this functionality. The only issue is to make sure that use case tree-menu hierarchy consist of legal child nodes, i.e. a use case node shall not be the child of a implementation requirements node. As stated, a challenge when a company adopts a tool like the CoExSel tool, is to reach a critical number of users. It could therefore be a good idea to expand the too to support importing and exporting inserted experiences. By providing this feature, experiences with components could be exchanged with other similar companies, that use the same components. A result of this feature will be more experiences inserted of the components, which will increase the credibility of the experience. Experience could then reflect different use the components. It will also be easier to reach the critical user mass since this will increase the number of users. 66

78 APPENDIX A. PICTURES OF THE PROTOTYPE System Development Appendix A Pictures of the Prototype A.1 Menus These are the top menus in the CoExSel tool. A.1.1 Menu Item: File Figure A.1: File Menu Item A.1.2 Menu Item: Use Case Figure A.2: Use Case Menu Item A.1.3 Menu Item: System Requirements Figure A.3: System Requirements Menu Item 67

79 System Development APPENDIX A. PICTURES OF THE PROTOTYPE A.1.4 Menu Item: Action Figure A.4: Action Menu Item A.1.5 Menu Item: Components Figure A.5: Components Menu Item A.1.6 Menu Item: Help The functionality of the help menu item is not yet defined. A.2 Tree-Menus A.2.1 Left Menu Implementation Requirements Figure A.6: Left Menu: Implementation Requirements 68

80 APPENDIX A. PICTURES OF THE PROTOTYPE System Development A.2.2 Left Menu Use Cases Figure A.7: Left Menu: Use Cases A.3 Templates The Use Case template used in the CoExSel tool, shown in figure A.8. Figure A.8: Use Case Template The Implementation Requirement template used in the CoExSel tool, shown in figure A.9. The possible tree structures in the CoExSel tool is shown as templates in figure A

81 System Development APPENDIX A. PICTURES OF THE PROTOTYPE Figure A.9: Implementation Requirement Template Figure A.10: Tree Structures Template 70

82 APPENDIX A. PICTURES OF THE PROTOTYPE System Development A.4 Searching The figure A.11 shows that a search for components can be based upon category, used in architecture before, or both. Figure A.11: Search For Component The figure A.12 shows the result after the search. Figure A.12: Search For Component Result 71

83 System Development APPENDIX A. PICTURES OF THE PROTOTYPE The figure category. A.13 shows that a search for implementation requirements can be based upon a Figure A.13: Search For Implementation Requirement 72