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
Presentation Outline
Introduction
Current component technologies
Quality assurance issues 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
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
What is Component-Based Software Development?
Component repository
Software systems
select assemble
Component 1
Component 2
Component n...
Commercial Off-the-shelf (COTS) components
Software systems can be developed by selecting appropriate off-the-shelf components and then assembling them with a well-defined software architecture.
Advantages of CBSD
Reduce
• Development cost
• Time-to-market
Improve
• Maintainability
• Reliability
• Overall quality of software systems
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
System Architecture
Layered Modular
Special business components
Common components
Basic components
App2App1
App3Application
Layer
Components Layer
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
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
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
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.
JavaBeans/EJB
Comparison of Current Component Technologies
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
Requirements analysis
Software architecture selection, creation, analysis and evaluation
Component evaluation, selection and customization
Integration
Component-based system testing
Software maintenance
Life Cycle of CBSD
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
A Quality Assurance Model for CBSD
Component
System
QualityAssuranceModel
ComponentSystem
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
Main Practices
Requirement Analysis
Component
Architecture Design
System
Component Development
Component Certification
Component Customization
System Integration
System Testing
System Maintenance
Process Overview Component Requirement Analysis
RequirementsGathering andDefinition
RequirementAnalysis
ComponentModeling
RequirementValidation
ComponentDevelopment
SystemMaintenance
Draft User Requirement Documentation (URD)
Format &Structure
Component Requirement Document (CRD)
Updated CRD with model included
Current URD User Requirement Changes
DataDictionary
Structure fornaming &Describing
CurrentURD
RequirementDocumentTemplate
Request for new development or change
Initiators (Users, Customers,Manager etc.)
Process Overview Component Development
Developers
Implementation
Self-Testing (Function)
Self-Testing ( Reliability)
Development Document
Component Certification
System Maintenance
Techniques required
Draft Component
Requirements
Well-Functional Component
Reliable Component
Submit For Reference
ExistingFault
Component Requirement
Document
Process Overview Component Certification
System Requirements
Component Outsourcing
Component Testing
Component Selecting
Acceptance System Maintenance
Specific Component Requirements
Component Released
Component Functions
Well-Functional Component
Component fit for the special requirements
Contract Signoffs, Payments
Reject
Component Development
Document
Process Overview Component Customization
System Requirements & Other Component Requirements
Component Customization
Component Document
Component Testing
Acceptance System Maintenance
on
Specific System & Other Component Requirements
Component Changed
Component Document
New Component Document
Component fit for the special requirements
Component Document
Reject
Component Development
Document
System Integration Assemble
Process Overview System Architecture Design
Initiators
System Requirement Gathering
System Requirement Analysis
System Architecture Design
System Specification
System Integration
Requests for New Systems
Draft System Requirements Document
Format & Structure Document
System Requirement Document
System Architecure
System Specification Document
Current Document
Requirement Document Template
System Testing System
Requirement
System Maintenance
Process Overview System Integration
System Requirement
System Integration
Self-Testing
Component Changing
Final System
System Maintenance
Requirements for New Systems
Draft System
Architecture
Fault Component
Selecting New Component
System Integration Document
Current Component
System Architecture
System Testing Final System
Component Certification
Component Requirement
Process Overview System Testing
System Design Document
Testing Strategy
System Testing
User Acceptance Testing
Test Completion Activities
System Maintenance
Testing Requirements
System Testing Plan
Test Dependencies
System Tested
User Accepted System
System Integration Document
System Maintenance
(Previous Software Life
Cycle)
Component Development
Component Document
System Integration
Component Document
System Test Spec.
User Acceptance Test Spec.
Process Overview System Maintenance
Users
Support Strategy
Problem Management
System Maintenance
Request and Problem Reports
User Support Agreement
Documents, Strategies
Change Requests
All Previous Phases
System Testing
New Version
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
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.
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
High Level Architecture for ARMOR
Component Evaluation and Risk Analysis Tool
Based on ARMOR
Add some Java feasure on it:
o Java Classes
o Program Coupling
o Java Methods
o Hierarchical Structure
o Clone Detection
Existing Metrics on Java
Metamata
Jprobe
Both base on Java language
Adopted in current component market
Examples of Metamata MetricsMetric 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
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.
Q & A
Top Related