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