OntoArch Approach for Reliability-Aware Software ... - Semantic Scholar

3 downloads 785 Views 337KB Size Report
Oct 14, 2008 - creating a reliability-aware software architecture ontology, i.e., the OntoArch .... PIR Mailer, and identification through the NetBank component. It is extremely .... mm.gforge.enseeiht.fr/website/index.html, 2007. 20. June, 2007.
Annual IEEE International Computer Software and Applications Conference

OntoArch Approach for Reliability-aware Software Architecture Development

Jiehan Zhou1, Eila Niemelä2, Antti Evesti2, Anne Immonen2, Pekka Savolainen2 1 MediaTeam, Information processing laboratory, Department of Electrical and Information Engineering, University of Oulu [email protected] 2 VTT Technical Research Centre of Finland,Kaitoväylä 1, 90571 Oulu, Finland {Firstname.Surname}@vtt.fi Reliability evaluation taking place prior to software development has been attracting a growing attention among software architects and reliability experts. In particular, software architecture design has been regarded as the first phase of evaluating reliability in the development of software systems. Software architectural decisions (i.e. architecture design) have a direct impact on such system aspects as cost, time-to-market, and quality. This consideration results in software reliability evaluation in the phase of software architecture development (i.e. software architecture-based reliability evaluation or reliability evaluation at software architecture level) [12-16]. We use the term ‘software architecture development’ in the context of architecture design and evaluation. Our contribution is an ontology-based reliabilityaware software architecture development approach, i.e., OntoArch. The OntoArch approach integrates software reliability engineering, quality driven software architecture design and quality evaluation approaches. The method embodies reliability engineering in the OntoArch ontology, which is used and exploited in software architecture design and evaluation that is carried out from the architectural models. The remainder of the paper is organized as follows. Section 2 addresses the motivations of creating a reliability-aware software architecture ontology, i.e., the OntoArch ontology. Section 3 presents a guideline for creating the OntoArch ontology. Section 4 examines knowledge domains and designs the OntoArch ontology. Section 5 presents the experiment and validates the OntoArch approach with the case study of PIR architecture design and evaluation. Section 6 concludes the paper.

Abstract Reliability-aware software architecture development has recently been gaining growing attention among software architects. This paper tackles the issue by introducing an ontology-based approach, called OntoArch, which is characterized by: 1) integration of software reliability engineering and software architecture design; 2) targeting reliability-aware software architecture development; and 3) OntoArch ontology in the context of software architecture design and software reliability engineering. The OntoArch approach is validated by applying the OntoArch approach to the development of a PIR (Personal Information Repository) system architecture. Keywords: software architecture, software reliability, reliability-aware software architecture design

1. Introduction Today, software-intensive systems permeate our modern society; they can be found in, e.g., consumer electronics, buildings, automobiles, and aircraft. The size and complexity of software-intensive systems have been growing dramatically during the past decade, and the trend is certain to continue with the emerging service-oriented architectures [1-3]. Thus, the reliability evaluation of software and services has become a major concern in software communities. Software reliability is the probability of failurefree operation of a computer program in a specified environment for a specified time [4-6]. Software reliability has been discussed, e.g., in a number of studies on software reliability evaluation focusing on post-software development, including reliability modeling [7, 8], and reliability estimation and prediction tools development [9, 10]. In addition, a few books [5, 6, 11] have been published in the field of reliability education and training.

0730-3157/08 $25.00 © 2008 IEEE DOI 10.1109/COMPSAC.2008.91

2. Motivations Several proposals have been made to predict reliability at the architecture level. Most promising

1229 1228

Authorized licensed use limited to: Oulu University. Downloaded on October 14, 2008 at 06:06 from IEEE Xplore. Restrictions apply.

reliability evaluation methods, i.e. the methods from Cortellessa et al. [17], Rodrigues et al. [18], Yacoub et al. [19], Reussneer et al. [20], and Grassi [21] have been compared in [22] from the viewpoint of software architecture. The Reliability and Availability Prediction (RAP) method [23] and the Quality Requirements of a software Family (QRF) method [24] highlight how quality requirements have to be defined, represented and transformed to architectural models. However, the existing proposals do not consider the system reliability and architecture modeling systematically. Most of them lack tool support for reliability evaluation. Moreover, it is also common to these methods that traceability of reliability requirements to software architecture is missing. Due to the complicated nature of today’s systems and the shortcomings of the existing reliability prediction methods, an ontology-based method is required to support reliability-aware architecture development. With the core element of the OntoArch ontology, the OntoArch approach takes the advantages of RAP and QRF and integrates architecture design and reliability engineering. The OntoArch ontology is intended to be used in the following aspects: Management and development of reliabilityaware software architecture knowledge in the software architect community. The reliability-aware architecture ontology allows developers and users to better understand software architecture and reliability terminologies, assess software reliability, and communicate effectively with the architect. The ontology further allows the architect to make appropriate decisions in the context of architecture modelling, resource usage and schedules through monitoring the reliability-aware architecture design process. Support computer-aided reliability-aware architecture development. Once the OntoArch ontology is built into the traditional computer-aided architecture design and reliability evaluation programs, the programs will be enhanced in terms of ontology-guided architecture design and reliability evaluation. To our knowledge, there exits no such kind of tooling so far. Support for service-oriented architecture design in the foreseeable service-intensive business. The service-oriented software development has already emerged for SOA (Service-Oriented Architecture) based applications integration [25,26]. Nonfunctional requirements of services, including reliability, are playing an important role in quantitative architecture reliability evaluation. Research [27,28] on QoS (Quality of Service) -aware Web service architectures tries to extend the W3Cdefined SOA model by integrating QoS in Web services. The OntoArch ontology purposes to

facilitate reliability-aware discoveries and compositions.

component/service

3. The ArchOnto engineering process Ontology engineering aims to design a subject ontology in order to facilitate knowledge management within internal and external communities and support computer-aided knowledge management and automation of networked knowledge management, e.g. knowledge acquisition, knowledge storage, and knowledge exchange. Based on the summary of ontology engineering methods [38] and a typical process of ontology engineering given in [29], we refine the ontology engineering steps for creating the OntoArch ontology as follows: Step 1. Determine the domain for the OntoArch ontology. The OntoArch ontology covers concepts from the areas of software architecture and software reliability, and the aspects of process, methods, models, specifications, tools, and organizations. The OntoArch ontology is designed for the purposes of architecture design, failure data collection, architecture reliability modelling, reliability-aware architecture evaluation, decision guidance, and architecture transformations. The domain in the aspect of organization is not taken into account in the current version of the OntoArch ontology (Figure 1). Step 2. Consider reusing existing reliability-aware architecture ontologies. Unfortunately, there are no existing ontologies reported for software architecture or software reliability so far. The knowledge body for reliability-aware architecture design has been distributed in textbooks and research publications in terms of software architecture design and reliability engineering. Step 3. Determine the key concepts related to reliability-aware architecture design. It is advisable to start with classic textbooks in the fields of software architecture and reliability engineering, and to compile a list of all the concepts that the reliability-aware architect community is likely to need. Further, we need to examine the meaning of these concepts and their properties. Step 4. Define an OntoArch concept hierarchy. A top-down development process can be used in this step. First we define the most general reliabilityaware architecture concepts (e.g. process, method, and specification) and subsequent specialization of these concepts (e.g. reliability definition and usage profile development). Step 5. Define the properties of the OntoArch concepts. The OntoArch properties represent the relationships between the OntoArch concepts. In general, there are two types of OntoArch properties: internal and external. The internal properties indicate properties owned by the concepts themselves, such as the name of a process. The external properties

1229 1230

Authorized licensed use limited to: Oulu University. Downloaded on October 14, 2008 at 06:06 from IEEE Xplore. Restrictions apply.

indicate the relationships between concepts, such as the method of a process. Step 6. Define additional OntoArch properties (e.g., cardinality, bidirectional/inverse, etc.). As an example of fine tuned properties, it is possible for a reliability-aware architecture design process to involve one or several methods; and, conversely, a method must be associated with a process. Step 7: Create OntoArch axioms/rules. OntoArch axioms/rules are a kind of special properties. Defining rule types helps us reduce the workload of formalizing the OntoArch ontology. For example, we define the rule of subProcessTransitivity to denote that the process ‘failure severity definition’ is a subprocess of the reliability definition process. Step 8. Create OntoArch instances. We define specific OntoArch instances in terms of its concepts and its properties. For example, we can build the PIR architecture instance to represent a specific application architecture.

and purpose-specification. For example, in the failure data interpretation process, there are such methods as reliability trend estimation and reliability chart demonstration. The architect can choose either or both of them for interpreting the architecture reliability. The OntoArch models are chosen and used in any given applications depending on the specific application purposes or requirements. A software reliability model usually takes the form of a random process that describes the behaviour of failures over a period of time. For example, the first-order Markov chain model [6] assumes that the next component to be executed will probabilistically depend on the present component only and will thus be independent of the past history. The OntoArch tools refer to computer programs used for software architecture design and/or reliability evaluation. Examples of this kind of software reliability tools are CASRE [9] and SMERFS [30]. Among the tools for architecture modelling are ADLs [31], and Stylebase [32]. The OntoArch specifications refer to the input and output of the OntoArch processes. This data may take the form of tables, files, and graphics.

4. OntoArch design 4.1. OntoArch domains We describe reliability-aware architecture design as a series of interrelated architecture design and reliability prediction processes, through which the reliability-aware architecture knowledge body is organized in terms of methods, tools, models, and the specifications of input and output (Figure 1).

4.2. OntoArch Concept hierarchy The OntoArch concept hierarchy (Figure 2) is a hierarchical concept classification showing the concept relationships between the knowledge domains of reliability-aware architecture design. The details about the descriptions of these concepts are out of the scope of this paper.

4.3. OntoArch Properties We divide the OntoArch properties into internal and external properties. An internal property describes the internal structure and the attributes of concepts, whereas an external property describes the relationships between concepts. For an internal property, we must determine which concept it describes; for instance, specificationName is one of the internal properties of the concept Specification. For an external property, we must determine the class(es) which the values of the property will be members of and the class(es) that will have the property as a member; for instance hasMethod is an internal property between concepts of Method and Process. The initial OntoArch properties are defined in Figure 3.

Figure 1. Domains in reliability-aware architecture design The OntoArch processes refer to reliability-aware architecture design and evaluation processes, consisting of five main activities, which are functional-based architecture design, reliability definition, usage profile development, reliability modelling, and failure data interpretation. The OntoArch approach identifies a way for the organization to conduct reliability-aware architecture design processes paying attention to cost-efficiency

1230 1231

Authorized licensed use limited to: Oulu University. Downloaded on October 14, 2008 at 06:06 from IEEE Xplore. Restrictions apply.

Figure 2. OntoArch Concept hierarchy 5.1. OntoArch implementation 5. Experience on OntoArch approach In the implementation of the OntoArch platform, we explored and adopted the following techniques as part of the OntoArch ontology design; Eclipse as a integration platform of the architecture development environment, Eclipse UML2 as an architecture modeling language, TOPCASED [33] as an Eclipse plug-in for visualizing UML models, OWL [34] for

In this section, we present our experiences gained in implementing the OntoArch approach, including the technical implementation of the OntoArch approach and utilization of OntoArch to the PIR architecture development.

1231 1232

Authorized licensed use limited to: Oulu University. Downloaded on October 14, 2008 at 06:06 from IEEE Xplore. Restrictions apply.

modeling the OntoArch ontology, Protégé [35] for managing the OntoArch ontology, and the RAP tool [36] for reliability evaluation from the architecture models.

important components of the PIR system are Document Service for Customer, PIR Case, Browser, PIR Mailer, and identification through the NetBank component. It is extremely important that PIR system is of high reliability. The identified reliability requirements are: the system probability of failure must be 0; the system availability should be 100%; data can not be lost in error situations or must be restored after the errors; if breakdown occurs, mean down time should less than a minute; system data must always be correct; and system must detect and handle errors.

5.2. Utilizing OntoArch 5.2.1. PIR case study. Personal Information Repository (PIR) [83] is used for a reliable document delivery between patient clients and hospitals. The main function of the PIR system is to transmit health care information between hospitals (service providers) and customers (patients). The most

Figure 3. OntoArch property definition the software architecture level. In order to achieve this goal, we introduce the OntoArch, an ontologybased reliability-aware architecture development approach, along with the OntoArch platform implementation. Making use of the OntoArch ontology, the OntoArch platform enables software architects and reliability experts to formally, explicitly, and coherently conduct architecture modelling and reliability modelling in a unified computer-aided environment.

5.2.2. OntoArch-based PIR design. First, the OntoArch guides the architect through a number of selections concerning PIR system architecture styles and views which have to be made with respect to the PIR requirement specification. Then the OntoArch guides the reliability experts through collecting failure data based on architecture views and legacy failure data, and estimating the reliabilities of the system components, interfaces and the probabilities of the component transitions. Further, the OntoArch guides the architect in the tasks of selecting software reliability prediction models, and interpreting the simulation results. The main functional features are specified and developed in the OntoArch platform as follows: OntoArchaided architecture knowledge management, OntoArch-aided reliability profiling, OntoArch-aided architecture design, and OntoArch-aided architecture evaluation. The detail about these functions is omitted due to the limited space.

Acknowledgement This work was funded by Tekes, the Finnish Funding Agency for Technology and Innovation (Tekes), and VTT Technical Research Centre of Finland.

References [1] D. Hinchcliffe, "Is Web 2.0 The Global SOA?," SOA Web Services Journal, 2005. [2] K. Channabasavaiah, K. Holley, and E. Tuggle, "Migrating to a service-oriented architecture," IBM DeveloperWorks, 2003. [3] P. Avgeriou, "Run-time Reconfiguration of ServiceCentric Systems," proceeding of the European Pattern

6. Conclusion Reliability-aware software architecture development aims to measure software reliability at

1232 1233

Authorized licensed use limited to: Oulu University. Downloaded on October 14, 2008 at 06:06 from IEEE Xplore. Restrictions apply.

Languages of Programming (EuroPLOP), Irsee, Germany, 2006. [4] IEEE. IEEE Standard Glossary of Software Engineering Terminology, Institute of Electrical & Electronics Enginee, 1991. [5] M. R. Lyu, "Handbook of software reliability engineering," McGraw-Hill, 1995. [6] J. Musa, Software reliability engineering, more reliable software faster development and testing: McGrawHill, 1998. [7] D. R. Wallace, "Practical software reliability modeling," proceeding of 26th Annual NASA, Software Engineering Workshop, 2001. [8] W.-L. Wang and M.-H. Chen, "Heterogeneous software reliability modeling," proceeding of 13th International Symposium on Software Reliability Engineering, 2002. [9] M. R. Lyu and A. Nikora, "CASRE: a computer-aided software reliability estimation tool," proceeding of Fifth International Workshop on Computer-Aided Software Engineering, 1992. [10] S. Ramani, S. and K. S. Trivedi, "SREPT: software reliability estimation and prediction tool," Computer Performance Evaluation: Modelling Techniques and Tools. LNCS 1786, pp. 358-361, 2000. [11] J. D. Musa, A. Iannino, and K. Okumoto, software reliability: measurement, prediction, application: McGraw-Hill Book Company, 1987. [12] K. Goseva-Popstojanova, A. P. Mathur, and K. S. Trivedi, "Comparison of architecture-based software reliability models," proceeding of 12th International Symposium on Software Reliability Engineering, 2001. [13] W.-L. Wang, D. Pan, and M.-H. Chen, "Architecturebased software reliability modeling," Journal of Systems and Software, 79 (1), 132-146, 2006. [14] R. Roshandel and N. Medvidovic, "Toward Architecture-based Reliability Estimation," proceeding of International Conference on Dependable Systems and Networks, Florence, Italy, 2004. [15] J. Bosch, Design & Use of Software Architectures Adopting and Evolving a Product Line Approach: Addison-Wesley, 2000. [16] S. Gokhale, K.S. Trivedi, Analytical Models for Architecture-Based Software Reliability Prediction: A Unification Framework. IEEE Transaction on Reliability, 55 (4), 578-590, 2006. [17] Cortellessa, V., Singh, H., Cukic, B. Eerly reliability assessment of UML based software models. In: Third International Workshop on Software and Performance, Rome, 2007. [18] Rodrigues, G. N., Rosenblum, D. S., Uchitel. S. Using scenarios to predict the reliability of concurrent component-based software systems. In: 8th International Conference on Fundamental Approaches to Software Engineering, FASE 2005. Springer Lecture Notes in Computer Science, Edinburgh, 2005. [19] S. Yacoub, B. Cukic, and H. Ammar, "Scenario-based reliability analysis of component-based software," proceeding of the 10th International Symposium on Software Reliability Engineering (ISSRE'99), 1999. [20] Reussner, R. H., Schmidt, H. W., Poernomo, I. H. Reliability prediction for component-based software architectures. Journal of Systems and Software, 66(3), 241-252, 2003.

[21]

Grassi, V. Architecture-based dependability prediction for service-oriented computing. In: Proceedings of the Twin Workshops on Architecting Dependable Systems, International Conference on Software Engineering (ICSE 2004), Springer, Edingburgh, 2004. [22]A. Immonen and E. Niemelä, "Survey of reliability and availability prediction methods from the viewpoint of software architecture," Software and Systems Modeling. 7(1), 49-65, 2008. [23] A. Immonen, "A method for predicting reliability and availability at the architectural level.," in Research Issues in Software Product-Lines - Engineering and Managemen, T. Kakola and J. C. Duenas, Eds. Berlin Heidelberg: Springer Verlag, 2006, pp. 373-422. [24] E. Niemelä and A. Immonen, "Capturing quality requirements of product family architecture," Information and Software Technology. 49(11-12), 1107-1120, 2007. [25] E. Marks and B. Michael, Service Oriented Architecture: A Planning and Implementation Guide for Business and Technology.: Hoboken: John Wiley & Sons, 2006. [26] D. K. Barry, Web Services and Service-Oriented Architectures: The Savvy Manager's Guide: San Francisco: Morgan Kaufmann Publishers, 2003. [27] H. Wada and J. Suzuki, "Modeling Non-Functional Aspects in Service Oriented Architecture," proceeding of IEEE International Conference on Service Computing, 2006. [28] A. Keller, and Ludwig, H., "The WSLA Framework: Specifying and Monitoring of Service Level Agreements for Web Services," IBM research report RC22456: IBM, 2002. [29] N. F. Noy and D. L. McGuinness, "Ontology Development 101: A Guide to Creating Your First Ontology," http://ksl.stanford.edu/people/dlm/papers/ontology101 /ontology101-noy-mcguinness.html, 2006. [30] htpp://www.slingcode.com/smerfs/, 28 Jan., 2008. [31] Medvidovic, N., Dashofy, E. M., Taylor, R. N. Moving architectural description from under the technology lamppost. Information and Software Technology, 49 (1), 12-31, 2007.] [32] M. Matinlassi, Quality driven software architecture model transformation. Towards automation, VTT Technical Research Centre of Finland, 2006. [33]"TOPCASED," http://topcasedmm.gforge.enseeiht.fr/website/index.html, 2007. 20 June, 2007. [34] N. L. Sandia, "Java Expert System Shell (Jess)," http://www.jessrules.com/jess/index.shtml, 20 June, 2007. [35] Stanford University, "Protege," 2005. http://protege.stanford.edu/, 20 June, 2007. [36] A. Immonen and A. Niskanen, "A tool for reliability and availability prediction," proceeding of 31st Euromicro Conference on Software Engineering and Advanced Applications, Porto, USA, 2005. [37] A. Evesti, "Quality-oriented software architecture development," VTT Publications 636, 2007, 79 p. [38] J. Zhou, "Knowledge Dichotomy and Semantic Knowledge Management," proceedings of the 1st IFIP WG 12.5 working conference on Industrial Applications of Semantic Web, Jyvaskyla, Finland, 2005.

1233 1234

Authorized licensed use limited to: Oulu University. Downloaded on October 14, 2008 at 06:06 from IEEE Xplore. Restrictions apply.