1 / 34

Component-Based Software Development: Technologies, QA Schemes, and Risk Analysis Tools

This presentation discusses the current technologies in component-based software development, quality assurance models, and a risk analysis tool. It also covers the advantages of component-based software development and the life cycle of CBSD. The presentation concludes with future work in this field.

lindajjones
Download Presentation

Component-Based Software Development: Technologies, QA Schemes, and Risk Analysis Tools

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Component-Based Software Development: Technologies, Quality Assurance Schemes, and Risk Analysis Tools Cai Xia Supervisor: Prof. Michael R. Lyu Markers: Prof. Kam-Fai Wong Prof. Ada Fu December 18, 2000

  2. Presentation Outline  Introduction  Current component technologies  Quality assuranceissues and a QA model for Component-Based Software Development (CBSD)  A risk analysis tool: ARMOR  Expected new features of our risk analysis tool  Demonstration of ARMOR  Conclusion and future work

  3. Introduction Software systems become more and more large-scale, complex and uneasily controlled One of the most promising solution now is component-based software development approach  The process of CBSD is totally different from traditional systems  Quality Assurance is very important for component-based software systems

  4. Component 1 Software systems Component 2 ... Component n assemble select Commercial Off-the-shelf (COTS) components What is Component-Based Software Development? Software systems can be developed by selecting appropriate off-the-shelf components and then assembling them with a well-defined software architecture. Component repository

  5. Advantages of CBSD Reduce • Development cost • Time-to-market Improve • Maintainability • Reliability • Overall quality of software systems

  6. What is A Component? A component is an independent and replaceable part of a system that fulfills a clear function  A component works in the context of a well-defined architecture  It communicates with other components by the interfaces

  7. Application Layer App3 App2 App1 Special business components Components Layer Common components Basic components System Architecture  Layered  Modular

  8. Current Component Technologies  Common Object Request Broker Architecture (CORBA) from Object Management Group (OMG)  Component Object Model (COM) and Distributed COM (DCOM) from Microsoft  JavaBeans and Enterprise JavaBeans (EJB) from Sun Microsystems

  9. CORBA CORBA is an open standard for application interoperability  Allows applications/components to communicate with one another despite of different locations and designers.  The interface is the only way that applications/ components communicate with each other. Object Request Broker (ORB) is the middleware that establishes the client-server relationships between components.  CORBA is widely used in OO distributed systems including component-based software systems

  10. COM/DCOM • COM is a general architecture for component software • Defines how components and their clients interact directly and dynamically •  DCOM is a protocol that enables software components to communicate directly over a network •  Designed for use across multiple network transports, including Internet protocols such as HTTP

  11. JavaBeans/EJB  JavaBeans for client-side component development, while Enterprise JavaBeans for server-side component development  Offers an efficient solution to the portability, security and reliability of component-based development.  The features are well suited for developing robust server objects independent of OS, Web servers and database management server.

  12. CORBA EJB COM/DCOM Development environment Underdeveloped Emerging Supported by a wide range of strong development environments Binary interfacing standard Not binary standards Based on COM; Java specific A binary standard for component interaction is the heart of COM Compatibility & portability Strong in standardizing language bindings; but not so portable Portable by Java language spec; but not very compatible. Not having any concept of source-level standard of standard language binding. Modification & maintenance CORBA IDL for defining component interfaces Not involving IDL files Microsoft IDL for defining component interfaces Services provided A full set of standardized services; lack of implementations Neither standardized nor implemented Recently supplemented by a number of key services Platform dependency Platform independent Platform independent Platform dependent Language dependency Language independent Language dependent Language independent Implementation Strongest for traditional enterprise computing Strongest on general Web clients. Strongest on the traditional desktop applications Comparison of Current Component Technologies

  13. Life Cycle of CBSD  Requirements analysis  Software architecture selection, creation, analysis and evaluation  Component evaluation, selection and customization  Integration  Component-based system testing  Software maintenance

  14. QA for Component-Based Software Two inseparable parts: How to certify quality of a component?  How to certify quality of a component-based software system? Metrics for components: Size Complexity  Reuse frequency  Reliability

  15. A Quality Assurance Model for CBSD  Component  System

  16. Hong Kong SQA Model • Proposed by Hong Kong Productivity Council • Provides the standard for local software organizations • Meet basic software quality requirements; • Improve on software quality practices; • Use as a bridge to achieve other international standards; • Assess and certify them to a specific level of software quality conformance

  17. Component Development Component Certification Component Customization System Integration System Testing System Maintenance Main Practices Requirement Analysis Component Architecture Design System

  18. Process Overview  Component Requirement Analysis

  19. Process Overview  Component Development

  20. Process Overview  Component Certification

  21. Process Overview  Component Customization

  22. Process Overview  System Architecture Design

  23. Process Overview  System Integration

  24. Process Overview  System Testing

  25. Process Overview  System Maintenance

  26. The Feature of Our QA Model Compared with other existing models:  Simple, easy to apply  Design for local component vendors (small to medium size)  Focused on development process, according to the life cycle of CBSD  Not focused on the measure/predict the quality of components/systems

  27. ARMOR: Analyzer for Reducing Module Operation Risk  The prototype was developed at Bell Lab in 1995.  A software risk analysis tool which automatically identifies the operational risks of software program modules.  Take data directly from project database, failure database and program development database.  Collect software metrics, select risk models, and validate the established models.

  28. ARMOR Objectives To access and compute software data deemed pertinent to software characteristics. To compute product metrics automatically whenever possible To evaluate software metrics systematically  To perform risk modeling in a user-friendly and user-flexible fashion  To display risks of software modules  To validate risk models against actual failure data and compare model performance  To identify risky modules and to indicate ways for reducing software risks

  29. High Level Architecture for ARMOR

  30. Component Evaluation and Risk Analysis Tool  Based on ARMOR  Add some Java feasure on it: • Java Classes • Program Coupling • Java Methods • Hierarchical Structure • Clone Detection

  31. Existing Metrics on Java  Metamata  Jprobe  Both base on Java language  Adopted in current component market

  32. Metric Measures Description Cyclomatic Complexity Complexity The amount of decision logic in the code Lines of Code Understandability, maintainability The length of the code; related metrics measure lines of comments, effective lines of code, etc. Weighted Methods per Class Complexity, understandability, reusability The number of methods in a class Response for a Class Design, usability, testability The number of methods that can be invoked from a class through messages Coupling Between Objects Design, reusability, maintainability The number of other classes to which a class is coupled Depth of Inheritance Tree Reusability, testability The depth of a class within the inheritance hierarchy Number of Attributes Complexity, maintainability The amount of state a class maintains as represented by the number of fields declared in the class Examples of Metamata Metrics

  33. Conclusion and Future Work  We look at the current technologies, quality assurance schemes for component-based software development.  Our work is to implement a component evaluation and risk analysis tool  The tool will make use of the well-adopted metrics  It is Java language oriented.

  34. Q & A

More Related