Graduate Theses, Dissertations, and Problem Reports 2003 Architecture-level risk assessment tool based on UML specification Tianjian Wang West Virginia University Follow this and additional works at: https://researchrepository.edu/etd Recommended Citation Wang, Tianjian, "Architecture-level risk assessment tool based on UML specification" (2003). Graduate Theses, Dissertations, and Problem Reports.edu/etd/1404 This Thesis is protected by copyright and/or related rights. It has been brought to you by the The Research Repository @ WVU with permission from the rights-holder(s). You are free to use this Thesis in any way that is permitted by the copyright and related rights legislation that applies to your use.
For other uses you must obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/ or on the work itself. This Thesis has been accepted for inclusion in WVU Graduate Theses, Dissertations, and Problem Reports collection by an authorized administrator of The Research Repository @ WVU. For more information, please contact researchrepository@mail. Architecture-level Risk Assessment Tool Based on UML Specification Tianjian Wang Thesis submitted to the College of Engineering and Mineral Resources at West Virginia University in partial fulfillment of the requirements for the degree of Master of Science in Computer Science Hany Ammar , Ph.
Goseva-Popstojanova, Ph. Gamal Fahmy, Ph. Lane Department of Computer Science & Electrical Engineering Morgantown, West Virginia University 2003 Keywords: Risk Assessment, Dynamic Matrix, Software Engineering Copyright 2003 Tianjian Wang ABSTRACT Architecture-level Risk Assessment Tool Based on UML Specification Tianjian Wang Most faults in software systems are likely to be found in only a few of components [1]. The early identification of these components allows the project management to focus on remedial actions, such as redesigning the critical components that are likely to cause field failures or optimally allocating resources on implementation and testing [2].
This thesis presents a prototype tool called Architecture-level Risk Assessment Tool (ARAT) to demonstrate the process of risk assessment. The final result of this process is to distinguish those potentially high risk components in the software system. ARAT is built on the risk assessment methodology [3]. By manipulating the data acquired from domain expert and measures obtained from Unified Modeling Language (UML) artifacts [4], ARAT can be used in the design phase of the software development process to improve the quality of the software product.
A paper which demonstrates this tool is also published [19]. Dedication I am honored to dedicate this paper to all the members of my family, who have encouraged me, and supported me throughout my life. I want to specifically express my love and appreciation to my lovely and beautiful sister, the one who shares my burden and dream, stress and joy. iii Acknowledgements First, I would like to express my deepest gratitude and appreciation to my research advisor, Dr.
Hany Ammar, for this opportunity he gave me to conduct research under his supervision, for his ever presence guidance during this research effort and the freedom he give me to learn and explore. I would like to thank Dr. Katerina Goseva-Popstojanova for her support and review and for serving as a member of my graduate committee. I would like to thank my research colleagues, especially Ahmad Hassan, for the expertise he provided through out this research effort.
I would also like to thank Dr. Gamal Fahmy for taking time to be a member of my graduate committee and review this document. This work is funded in part by grants to West Virginia University Research Corp. from the National Science Foundation Information Technology Research (ITR) Program grant number CCR-0082574 and from the NASA Office of Safety and Mission Assurance (OSMA) Software Assurance Research Program (SARP) managed through the NASA Independent Verification and Validation (IV&V) Facility, Fairmont, West Virginia.
iv TABLE OF CONTENTS Abstract.iv Table of contents .v List of Figures .1 What is ARAT……………………………………………………….2 Problems and Solutions…………………………………………….3 Objective and related work…………………………………………2 1.4 Preview of the chapters…………………………………………….1 Basics of Metrics.1 Connector and component…………………………………….2 Dynamic Specifications Metrics using UML………………….2 Basics of risk assessment.1 Risk defined in methodology……………………….2 Performing risk assessment……………………………………6 2.1 Overview of the methodology………………………………….2 Risk analysis process………………….2 Overall system requirement………………………………………….3 User interface requirement ……………………………….4 Hardware and software requirement………………………….1 Structure of ARAT…………………………………………………….3 Calculation Module Design…………………………………………….4 GUI module Design…………………………………………………….1 Presentation Component Design…………………………….2 Interactive Component Design…………………………………24 4.5 Extensibility and Compatibility………………………………………….2 Instruction of Rose RT extensibility interface………………………….1 JDBC-ODBC Bridge and SQL Command Handler………….4 Integrating EspressChart Package……………………………….1 Functionality testing and integration testing…………….2 User interface testing………………………………………………. Analysis and Conclusion ………………………………………………….1 Analysis and conclusion………………………………………………. 40 Appendix A Rose Real Time Script for model conversion………………….42 Appendix B ARAT overall control flow chart….45 Appendix C ARAT Sequence diagram…….46 vi Lists of Figures Figure 1: The Risk Analysis Process…………………………………………. 8 Figure 2: Overall Process Flow chart of ARAT………………………………10 Figure 3: Complexity Calculation Module Control Flow Chart………….11 Figure 4: The console GUI of ARAT system…………………………………12 Figure 5: Use Case Diagram of ARAT……………………………………….15 Figure 6: Component diagram for ARAT…………………………………….17 Figure 7: Class diagram of ARAT…………………………………………….18 Figure 8: ER diagram for ARAT database…………………………………….20 Figure 9: Maximized Tabular Frame………………………………………….22 Figure 10: Maximized 3D Chart Frame……………………………………….23 Figure 11: GUI component Overview………………………………………….24 Figure 12: Severity Weight Option Frame ………………………………….
25 Figure 13: Eclipse IDE platform ……………………………………………….28 Figure 14 Information captured from use case diagram ………………….30 Figure 15 Example use case diagram of target software system……….30 Figure 16 Rational rose script module for use case diagram…………….…31 Figure 17 Textual data presentation of sequence diagram…….……………32 Figure 18 Sequence Diagram Example………….32 Figure 19 Rational rose script module to capture sequence diagram………33 vii CHAPTER 1: INTRODUCTION 1.1 What is ARAT This tool (ARAT) is an implementation of the methodology presented in publication [3]. It uses quantitative metrics to systematically evaluate the quality of the software architecture. It also integrates the real time failure probability estimation, and the severity metrics calculation into the risk assessment model.2 Problems and Solutions Problems exist in current software engineering quality assurance applications. Many quality assurance methods or tools are applied in the late phase of the software life cycle.
Due to some important product quality characteristics, like performance, reliability, maintainability, which can not be added in the late phase of the software lifecycle, any corrections made in the earlier phases on defect would be cost-effective. Otherwise, the failure would be expected when the requirement must be satisfied. Hence, early warnings and corrective activities of poor quality software product would be strongly desired for effective quality assurance. In addition, software architecture describes both the static structure and the dynamic behavior of the software.
It is the key in software design and software quality analysis. As a solution to the problems, our Architecture-level Risk Assessment Tool (ARAT) is created to track the quality of software product. Because the risk analysis is based on measurements and calculations of the high- level design diagrams, ARAT can be used as early as in the design phase of the software development process. It measures dynamic metrics proposed in [2] and further analyzes the quality of the architecture to produce architectural-level software risk assessment [3].3 Related work and Objectives 1 Some current tools in the market doing the risk assessment are based on the source code of the software, [8] they first obtain the static metrics from source code, and then go on carrying out risk analysis on these metrics.
But source code metrics are affected by the programming style of the programmer, as well as the programming language itself with its structures affecting the metrics results. When calculating the metrics from architectural descriptions like UML, we achieve independence of languages and human factors [9]. What is more, it is strongly desired by the project management to acquire the result of the risk assessment for the target system as early as possible. It would be impossible or resource wasteful to correct the error if we have to wait to get the result after part or full implementation is finished during the lifecycle of the software development.
ARAT that examines UML at design phase has obvious advantages over those tools built on source code. On the other hand, some tools [10] do get description from intermediate file by using certain CASE tools; they can be used in design phase as well, but they only produce static metrics to describe the model with limited capability, which is not enough to accurately represent the dynamic behavior of the architecture. They even require the output of result in a specific chosen format which is not convenient for popular use, some tools require extra information saved in a file which is not directly acquired from the model to describe the target software system model, then measurement and analysis based on the information would not be precise. As a result, it is not suggested to be adopted widely.
Under this circumstance, we simply access the result of a CASE tool to carry on the risk analysis. The result is in general textual format and obtained directly from UML model diagrams of the target software system by running a very simple script. All further steps of analysis are based on this result. Thus, we not only achieve the accuracy and performance of the analysis, but also have the very straightforward 2 way to do the analysis.
The simple, effective and practicable method with high performance is the contribution of this tool. In summary, the main objectives of this tool are listed below: 1. It can carry on the risk assessment as early as the design phase in the lifecycle of the software development. It can be compatible with popular design/modeling tools.
It is able to precisely compute the scenarios/use cases/system risk factors. It is able to determine the distribution of the scenario/use case/system risk factors over different severity classes. It is able to identify critical components based on the risk estimation. It has user interface with less training and learning.
It contains high flexibility and extensibility to wrap more functional modules which will be developed in the future like performance analysis module, reliability analysis module, hazard analysis module etc. The tool is portable and scalable. Popular adoption and usage is feasible.4 Preview of the chapters The rest of this document is organized as follows: Chapter 2: describes the background to produce ARAT including a brief introduction on metrics, risk assessment as well as the methodology used by ARAT. Chapter 3: gives an overview of the whole system.
Chapter 4: describes the design issue of the main ARAT components. Chapter 5: describes the implementation of various components in ARAT. Chapter 6: discuss the module verification and integration testing. Chapter 7: brings up a brief summary about this tool and discusses some future work on ARAT.
3 CHAPTER 2: BACKGROUND The fundamental knowledge of metrics is necessary to understand risk assessment process. This chapter provides a brief introduction about metrics, risk assessment, and how to perform risk assessment based on the proposed methodology [3]. The benefit of adopting this methodology is also included.1 The basic of metrics Software metrics is any type of measurement which is related to a software system, process or related documentation [12]. Specifically, dynamic metrics are collected by measurements made of a program in execution while static metrics are collected by measurements made of the system representations such as the design, program or documentation.
Dynamic metrics are fairly closely related to software quality attributes like the efficiency and the reliability of a program whereas static metrics help to assess the complexity, maintainability and other attributes of a program.1 Connector and Component A component can be as simple as an object, a class, or a procedure, and as elaborate as a package of classes or procedures. Connectors can be as simple as procedure calls; they can also be as elaborate as client-server protocols, links between distributed databases, or middleware.2 Dynamic Specifications Metrics In order to estimate the fault proneness of software components and connectors, a dynamic metric for components is computed based on the dynamic complexity of 4 state chart [13]. The normalized dynamic complexity DOCix of a component is calculated based on the following formula: docix DOCix = .