复制成功
  • 图案背景
  • 纯色背景

笔记

  • 2019-11-16
    为大人带来形象的羊生肖故事来历 为孩子带去快乐的生肖图画故事阅读
    谈谈怎样学好数学_苏步青-中学生文库
网上数字图..

上传于:2015-05-31

粉丝量:1039

所发布文档来源于互联网和个人收集,仅用于分享交流和学习使用,请下载后于24小时内删除,版权为原作者所有,请支持购买原版。因上传文档受大小限制,部分文档拆分上传,请浏览确认后下载。如有侵犯您的版权,请通过站内信息告知,将立即删除相关资料.如有其它问题也欢迎联系,谢谢!



计算机书籍 计算机书籍 Testing.And.Quality.Assurance.For.Component.Based.Software

下载积分:600

内容提示: Testing and Quality Assurance forComponent-Based Software For a listing of recent titles in the Artech House Computing Library,turn to the back of this book. Testing and Quality Assurance forComponent-Based SoftwareJerry Zeyu GaoH.-S. Jacob TsaoYe WuArtech HouseBoston • Londonwww.artechhouse.com Library of Congress Cataloging-in-Publication DataGao, Jerry.Testing and quality assurance for component-based software / Jerry Zeyu Gao, H. -S.Jacob Tsao, Ye Wu.p.cm. — (Artech House computing library)Inc...

文档格式:PDF| 浏览次数:1| 上传日期:2015-05-31 08:31:36| 文档星级:
Testing and Quality Assurance forComponent-Based Software For a listing of recent titles in the Artech House Computing Library,turn to the back of this book. Testing and Quality Assurance forComponent-Based SoftwareJerry Zeyu GaoH.-S. Jacob TsaoYe WuArtech HouseBoston • Londonwww.artechhouse.com Library of Congress Cataloging-in-Publication DataGao, Jerry.Testing and quality assurance for component-based software / Jerry Zeyu Gao, H. -S.Jacob Tsao, Ye Wu.p.cm. — (Artech House computing library)Includes bibliographical references and index.ISBN 1-58053-480-5(alk. paper)1. Computer software—Quality control.Title.IV. Artech House computer library.2. Computer software—Testing.I. Tsao, H.-S. J.II. Wu, Ye.III.QA76.76.Q35G38 2033005.1’4—dc222003057725British Library Cataloguing in Publication DataGao, Jerry.Testing and quality assurance for component-based software.— (Artech House computing library)1. Component software—TestingI. TitleII. Tsao, H.-S. J. (H.-S. Jacob)005.3’02872. Computer software industry—Quality controlIII. Wu, YeISBN 1-58053-480-5Cover design by Igor Veldman© 2003 ARTECH HOUSE, INC.685 Canton StreetNorwood, MA 02062The following are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University: CapabilityMaturity ModelTechnology.and CMM. Testing Maturity ModelSMand TMMSMare service marks of the Illinois Institute ofAll rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced orutilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any infor-mation storage and retrieval system, without permission in writing from the publisher.All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capi-talized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not beregarded as affecting the validity of any trademark or service mark.International Standard Book Number: 1-58053-480-5Library of Congress Catalog Card Number: 200305772510 9 8 7 6 5 4 3 2 1 To my wife Tracey and my lovely son KevinTo my parents Ming Gao and YeFang Qin—Jerry Zeyu GaoTo my mother Shu-Wen Pao, my brother Hsiao-Tzu Tsao,my wife Hueylian, and my children Allison and Jason—H.-S. Jacob TsaoTo my wife Wanjie and to my lovely daughter Ya Ya—Ye Wu . ContentsPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiWhat is this book about?Why has reuse of third-party software components becomepopular recently?Why is testing software components and component-basedsoftware important?Book organizationIs this book for you?xviixviiixviiixixxxAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . xxiIIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Introduction to software components . . . . . . . . . . . . . . 31.11.21.31.41.51.61.7The evolution of software componentsWhy is software component reuse important?What is a software component?Properties of software components in CBSEBasic elements of software componentsSoftware modules versus software components in CBSEAn engineering process for software components3568111317vii 1.8Questions, concerns, and needs in component validationand quality controlSummary19211.9References222Software component testing . . . . . . . . . . . . . . . . . . 252.12.2Component testing backgroundComponent testing in CBSE26282.2.12.2.2Issues and challenges of component testing in CBSEVendor-oriented component testingUser-oriented component testing2930342.32.3.12.3.2Component testing myths and other needsSummaryIssues and challenges in user-oriented component validationIssues and challenges in vendor-oriented component testing353841442.42.5References443Introduction to component-based software . . . . . . . . . . 473.13.2IntroductionComponent-based software versus traditional programs47493.2.13.2.2Component-based software infrastructure: component modelEngineering process for component-based softwareProperties of component-based softwareComponent-based software versus traditional programs495355583.33.43.4.13.4.2ReferencesProcess models for traditional softwareA process model for component-based software5860654Testing component-based software . . . . . . . . . . . . . . 674.14.2IntroductionIssues and challenges of testing and maintainingcomponent-based software68694.2.1Why is adequate testing for component-based softwarenecessary?69viiiContents 4.2.2Difficulties in adequate testing and maintenance forcomponent-based softwareTesting model for component-based software71754.34.3.14.3.2Testing and maintenance methodologiesEnterprise-based test process for component-based softwareSummaryInteraction modelBehavior model75777980814.44.54.6References825Testability of software components . . . . . . . . . . . . . . 855.15.2Basic concepts of software testabilityUnderstanding component testability86905.2.15.2.25.2.35.2.45.2.5Design for testability of software componentsComponent understandabilityComponent observabilityComponent traceabilityComponent controllabilityTest support capability9191929596985.35.3.15.3.25.3.3Verification and evaluation of component testabilityUnderstanding of testable software componentsMethods to increase component testabilityCurrent research efforts on building testable components981001021055.45.4.15.4.2Software testability measurementStatic verification approachStatistic verification approach1071071095.55.5.15.5.2SummaryWhat is software testability measurement?How to measure software testability1091101135.6References114IIValidation methods for software components . . . . . . . . 1176Black-box testing methods for software components. . . . 1196.16.2IntroductionBlack-box testing foundations119122Contentsix 6.2.16.2.26.2.3Black box–based testing techniquesComponent specificationComponent verification historyComponent customization1221231251266.36.3.16.3.26.3.36.3.46.3.5SummaryRandom testingPartition testingBoundary value testingDecision tables–based testingMutation testing1261271301331341376.4References1387White-box testing methods for software components . . . 1417.17.2Flow graph notationPath testing1421427.2.17.2.27.2.37.2.47.2.5Data-flow testingObject-oriented testingStatement coverageBranch coverageMultiple-condition coveragePath coverageLoop coverage1431441441451461471497.37.47.4.17.4.27.4.37.4.47.4.5Issues in testing software componentsConclusionInheritancePolymorphismGUIBinding coverageState-based testing1491501511511521531547.57.6References1548Test automation and tools for software components . . . . 1578.1Software test automation1588.1.18.1.28.1.3Component-oriented software test toolsBasics of software test automationSoftware test automation processDifferent types of test automation tools1601641661708.2xContents 8.2.18.2.2ADLscope: a specification-based test tool for componentsThe Java Compatibility Test Tools and technologycompatibility kitComponent test automation in CBSE1701711748.38.3.18.3.28.3.38.3.48.3.5SummarySystematic management of component testing informationAutomatic test execution for software componentsAutomatic test generation for co1mponentsSystematic performance testing for componentsSystematic regression testing for software components1741761791811831858.4References186IIIValidation methods for component-based software . . . . 1899Integration testing for component-based software . . . . . 1919.1Introduction1919.1.19.1.29.1.3Traditional integration-testing methodologiesType I: Intercomponent faultsType II: Interoperability faultsType III: Traditional faults and other faults1921921931939.29.2.19.2.2A test model for integration testing of component-based softwareFunction decomposition–based integration testingCall graph–based integration testing1931951969.39.3.19.3.29.3.3Black box–based integration-testing approachesTest elementsComponent interaction graphTest-adequacy criteria1971981992009.49.4.19.4.29.4.3UML-based integration-testing approachesInterface nodesEvent nodesContext-dependence and content-dependence relationships2012012022029.59.5.19.5.2SummaryContext-dependence relationshipsContent-dependence relationships2032072089.6References209Contentsxi 10Regression testing for component-based software . . . . . 21110.110.2IntroductionRegression testing for corrective-maintenance activities21221510.2.110.2.2Regression testing for perfective and adaptive maintenanceRepresenting modifications with UML diagramsRegression testing for corrective maintenance21621822110.310.3.110.3.2SummaryControl similarity evaluationData dependence similarity evaluation22122422510.4References22511Performance testing and measurement . . . . . . . . . . . 22911.1Basics of software performance testing and measurement23011.1.1Major focuses in software performance testingand evaluationPerformance test processPerformance testing and evaluation challengesand needs in CBSEPerformance evaluation metrics23123411.1.211.1.323623811.211.2.111.2.211.2.311.2.411.2.511.2.6Performance evaluation approachesUtilization metricsSpeed-related metricsAvailability metricsReliability metricsThroughput metricsScalability metrics23823924024324524624811.311.3.111.3.2Performance testing and evaluation tools and techniquesClassification of performance evalution approachesComponent-based performance evaluation models24825125411.411.4.1SummaryPerformance tracking and monitoring techniques25625711.5References25712Frameworks for testing component-based software . . . . 26112.1BIT components and wrappers26212.1.1BIT components262xiiContents 12.1.2A framework and distributed environment for testingtestable componentsBIT component wrappers26312.226612.2.112.2.212.2.312.2.4A framework for tracking component behaviorsTestable component structureComponent test frameworkGenerating component test driversA distributed component testing environment26626826926927212.312.3.112.3.212.3.3A framework for component performance measurementSystematic event-based component tracking modelJava component tracking packageDistributed tracking environment for component software27327427527712.412.4.1A distributed performance measurement environmentfor componentsComponent performance libraryPerformance tracking techniquesIBM’s solution for test tool collaboration27828028028212.4.212.4.312.512.5.112.5.2SummaryThe STCL architecture requirementsThe STCL architecture28228428612.6References288IVQuality assurance for software componentsand component-based software . . . . . . . . . . . . . . . 28913Quality assurance for software components. . . . . . . . . 29313.1The main differences between hardware and softwarequality assurance29513.1.113.1.2Modern methodology for assuring quality of hardwareMajor differences between hardware and softwarequality assuranceSoftware quality assurance29529830013.213.2.1The essence of software quality assurance: processand disciplineMajor software quality assurance tasksMain issues involved in QA for software componentsIntegrated development and QA process for softwarecomponents30030130313.2.213.313.4304Contentsxiii 13.4.113.4.2Prerequirements (study) phaseExternal-requirements phase (including user andcertifier requirements)Internal-requirements phaseDesign phaseImplementation phase (or coding phase)Test, evaluation, and validation phaseDeployment phasePostdeployment phaseSummary30730931331531731831931932013.4.313.4.413.4.513.4.613.4.713.4.813.5References32114Quality assurance for component-basedsoftware systems . . . . . . . . . . . . . . . . . . . . . . . . 32314.1Main issues in quality assurance for component-basedsoftware systems32414.1.1Salient features of the development of component-basedsoftware systemsThe main differences between SQA for conventional softwaresystems and SQA for component-based software systemsEvaluation of software components32414.1.232632714.214.2.114.2.214.2.3Component evaluation criteriaMulticriteria selectionA specific process and technique for evaluatingsoftware componentsA general process for evaluating software componentsEnsuring a quality adaptation and integration processValidation of the quality of software componentsSeveral major limitations of the conventional SQA processA complementary bottom-up approach for softwarequality assurance32732732832933033133214.2.414.314.414.514.633314.6.114.6.2Building quality into software: the case of object-oriented designAn integrated process for development and QA of CBSSDromey’s method of quality-carrying propertiesTervonen’s goal-rule-checklist-metric model33534034034314.714.814.8.114.8.214.8.3ITSEPRational unified processRUP/ITSEP with SQA343344345xivContents 14.9Summary346References34615Standards and certification for components andcomponent-based software . . . . . . . . . . . . . . . . . . 34915.1Standards for software processes and products35115.1.115.1.2On standards for software testingStandards for software components and component-basedsoftware systemsOrganizing software standardsStandards for software processesStandards for software products35235535615.215.335736215.415.4.115.4.2Certification of software processes, products, and developersCertification of a software componentISO/IEC 12207 or IEEE/EIA 12207IEEE SESC Vision 2000 Architecture36236336436515.515.615.6.115.6.2Liability aspects of producing software components andtheir certificationThe benefits of certification of software componentsResearch into certification of software components36536615.736715.7.115.7.215.7.3A “big picture”Software component: a product, not a serviceLiability lawsuits against product defects: contract, tort,and product (“no-fault”) liabilityDisclaimer as a liability defenseThe roles of standards and certification in liability defenseSummary36836936937037137215.7.415.7.515.8References37316Component quality verification and measurement . . . . . 37516.1The classical approach to verification, validation, and testing37616.1.116.1.2Terminology and tasksStandards for specification of requirements, design,implementation, and testingReviews, audits, walk-throughs, and inspections forverification of adherence to standardsTesting standards for software components37737816.1.337938016.1.4Contentsxv 16.2Recent approaches and their integration with theclassical approach38216.2.116.2.216.2.3A framework for software quality measurementPractical quality measures for software componentsTechnical approachesOrganizational approachesIntegration of the classical and recent approaches38238338438639016.316.416.4.116.4.2Predictive models regarding defect numbers and guidelinesPractical measures for software qualityPractical measures for software components39139339516.516.5.1Prerelease defect number as a predictor for postreleasedefect number: a need for cautionQuality guidelines for software design and implementationSome problems with predictive models for defectsOther practical software measures and metricsSummary39539740240340416.5.216.5.316.616.7References40517Verification of quality for component-based software . . . 40917.117.2Some skepticisms and the companion constructive suggestionsMinimum requirements for the life cycle ofcomponent-based software41141517.2.117.2.2Areas for component standardizationSuccess and failure factors for reuse of in-house developedcomponentsFailure modes and failure causesSummaryOverview of IEEE 1517IEEE 1517 processes, activities, and tasks41541641817.317.442042442717.517.6References429About the authors . . . . . . . . . . . . . . . . . . . . . . . 431Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433xviContents PrefaceWhat is this book about?The widespread development and reuse of software components is regardedby many as one of the next biggest phenomena for software. Reusinghigh-quality software components in software development has the poten-tial for drastically improving the quality and development productivity ofcomponent-based software. However, the widespread reuse of a softwarecomponent with poor quality may literally lead to disasters. Component-based software engineering involves many unique characteristics, some ofwhich have unintended consequences and side effects. The primary goal ofthis book is to elaborate on these characteristics, point out possible strengthsand weaknesses, and develop methodologies to maximize the quality and pro-ductivity potentials associated with development and reuse of software com-ponents. Software testing is one of the most important phases in softwareengineering, and it plays a pivotal role in software quality assurance. Thisbook focuses on testing and the larger context of quality assurance.Part I provides a general discussion of software components, component-based software systems, the concomitant testing challenges, and the importantissue of testability. Part II focuses on validation methods for software com-ponents. Part III covers the testing of component-based software systems,including integration testing, regression testing, and performance measure-ment. Part IV is devoted to quality assurance for software components andcomputer-based software systems.xvii Why has reuse of third-party software componentsbecome popular recently?Building systems based on reusable components is not a new idea. It has beenproven to be a very effective cost-reduction approach in the computer hard-ware industry. Today, that industry is able to build computer systems based onstandardized high-quality hardware parts and devices reliably and quickly.Software engineers learned the value of this idea many years ago. They devel-oped reusable software modules as internally shared building blocks for con-structing different software systems, and they established repositories of suchmodules, but in an ad hoc manner. Many years of trial and error proved tomany software developers that it was not easy to build software systems basedon reusable software components. The major reasons include the lack of awell-defined discipline for component-based software engineering and theabsence of a comprehensive collection of standardized high-quality softwarecomponents within the company or on the market.Recently, the increasing complexity of information technology (IT)-basedsoftware application systems and intensive competition in the marketplaceforced software vendors and researchers to look for a cost-effective approachto constructing software systems based on third-party components. The majorgoal is to shorten the software development cycle and thereby reduce cost.Hence, component-based software engineering becomes a popular subdisci-pline within software engineering because of its promising potential for costand cycle-time reductions.Why is testing software components andcomponent-based software important?As mentioned earlier, widespread reuse of a software component with poorquality may wreak havoc. Improper reuse of software components of goodquality may also be disastrous. Testing and quality assurance is therefore criti-cal for both software components and component-based software systems. Anumber of recent books address the overall process of component-based soft-ware engineering or specific methods for requirements engineering, design,and evaluation of software components or component-based software. We arenot aware of any books focusing on testing, validation, certification, or qualityassurance in general for reusable software components and component-basedsoftware systems.xviiiPreface Book organizationThe book consists of four parts. We briefly describe their contents here.Part I: Introduction provides background on software components,component-based software, as well as component-based software engineer-ing. Moreover, it explains the importance of testing software components andcomponent-based software. It consists of five chapters. Chapter 1 explains thebasic concept of a software component, its main features, its classification, andthe engineering process. It helps the reader understand the concept by com-paring software components with traditional software modules. Chapter 2 dis-cusses software component testing, including its problems and challenges, aswell as its differences from traditional module testing. Chapter 3 provides anoverview for component-based software, including its features, the engineer-ing process, and different construction approaches, while Chapter 4 focuseson its testing. Chapter 5 is dedicated to the important issue of componenttestability.Part II: Validation methods for software components consists of three chapters.They focus on validation techniques for software components. Chapters 6 and7 review the applicable black-box and white-box testing methods for softwarecomponents, respectively. Chapter 8 discusses test automation and automatedtools for testing software components.Part III: Validation methods for component-based software consists of four chap-ters, which focus on component-based software and discuss strategies andmethods developed for integration, regression, and performance testing.Chapter 9 reviews the applicable software integration strategies and reports oncurrent research results on component integration strategies and methods.Chapter 10 discusses regression testing of component-based software andrelated recent advances. Chapter 11 focuses on system performance testingand measurement metrics. Chapter 12 addresses system test frameworks forsupporting the validation of reusable software components and component-based software.Part IV: Quality assurance for software components and component-based systemsconsists of five chapters. Quality assurance for software components andcomponent-based software systems is a big subject, and we can only providean overview of the issues and their solutions in Chapters 13 and 14, whichpave the way for the discussion on standards and certification of Chapter 15.Chapters 16 and 17 focus on quality verification and measurement and pro-vide further details for some of the standards discussed in Chapter 15.In our attempt to weave a coherent story about this big subject, we havetried to place a balanced emphasis on the published literature, particularlypeer-reviewed journal articles as well as books written by recognized expertsBook organizationxix in the related fields, rather than relying merely on our personal experience oranecdotes. A common complaint about the current status of software qualityassurance (SQA) is its predominant process orientation. We have attempted toachieve a balance between the process and product orientations.In addition, we have attempted a balance between tailoring generic SQAmethods and describing some recently proposed approaches motivated specifi-cally by the development or reuse of software components. Moreover, in dis-cussing software metrics, we have attempted to strike a balance between theirtheoretical justification and empirical validation.Is this book for you?This book is intended for professionals and students seeking a systematic treat-ment of the subjects of component-based software testing and quality assur-ance. We have attempted to provide a balanced report about the state of thepractice and recent research findings regarding the new issues and their solu-tions. Therefore, researchers should also find this book useful.This book can also be used for training software testing and quality assur-ance engineers because it provides them with a comprehensive understandingof software testing and quality assurance in general. In addition, this book canbe used as a textbook for a software testing and quality assurance course at thegraduate or undergraduate upper-division levels—the instructor may need tosupplement the book with some class projects and/or homework exercises.xxPreface AcknowledgmentsMany people have contributed to the completion of this book through techni-cal discussions or encouragements. We gratefully acknowledge the contribu-tions ofC. S. Ravi, P. Q. Cuong, and H. Q. Duong at Hewlett Packard; Richard Bar-low, Pravin Varaiya, Adib Kanafani, and Mark Hansen of the University ofCalifornia at Berkeley; Randolph Hall of the University of Southern California;Shu-Cherng Fang of North Carolina State University; Yasser Dessouky of SanJose State University; Stephen Chen and Jackie Akinpelu of AT&T Bell Labo-ratories; Mei-hwa Chen of the State University of New York at Albany; andWen-li Wang of Penn State Erie.We also thank Vickie Perrish and Lance Nevard for their editorial assis-tance on Parts I through III.We thank Tiina Ruonamaa of Artech House for her superb management ofthis project every step of the way, which led to the on-time delivery of themanuscript. We also thank Rebecca Allendorf for her meticulous proofreadingand editing. We are indebted to the anonymous reviewers of the originalmanuscript, who offered continuous support throughout the 16-month proj-ect and provided thorough reviews and insightful suggestions, which led tomany improvements in not only the technical contents but also the structureof the book. Finally, all the support provided to the authors throughout thewriting process by Tim Pitts, Commissioning Editor of Artech House, as well ashis excellent selection of the anonymous reviewers made the writing processmore and more enjoyable.xxi . IntroductionTexperts have exerted much effort to study software componentreuse crossing projects, product lines, and organizations. Sincesoftware components are building parts for constructing softwaresystems, creating highly reusable components is one of the impor-tant keys to the success of a software development project. Withthe increase of software component products in today’s commer-cialmarket,manysoftwarevendorsandworkshopshavebeguntouse a new approach, known as component-basedsoftwareengineering(CBSE), to develop large, complicated software application sys-temsbasedonavailableandreusablecomponents.Itsmajorobjec-tive is to reduce software development cost and time by reusingavailable components, including third-party and in-house growncomponents.ThistrenddrivesastrongdemandforCBSEmethod-ology, standards, and guidelines to help engineers and managersin software analysis, design, testing, and maintenance ofcomponent-based software and its components.Recently, a number of books have been published to addresscomponent-based software development processes, analysis anddesign methods, and issues. However, there are no technicalbooks that discuss new issues and challenges in validating soft-ware component quality, addressing solutions and techniques incomponent-based software testing, reporting software compo-nent testing standards and certification, and discussing qualityassurance processes for component-based software. This book iswritten to cover these topics.oday, the concept of software reuse has been widely acceptedby the software industry. In the past two decades, many1IPART The first part of this book is structured to provide the fundamentalconcepts about software components and component-based programs. Itdiscusses testing issues and challenges in component-based software engineer-ing. The objective of this part is to provide readers with answers to the follow-ing questions:◗ What are the major differences between conventional software modulesand modern software components?◗ What are the new issues and challenges in testing software componentsfor component-based software engineering projects?◗ What are the primary differences between conventional software andcomponent-based software?◗ What are the new issues and challenges in testing component-basedsoftware?There are five chapters in Part I. Chapter 1 provides a necessary back-ground and concepts about software components, including definitions, ele-ments, and properties. In addition, the essential differences between softwarecomponents and traditional modules are discussed.Chapter 2 introduces software component testing concepts, and discussesits objectives, processes, issues, and challenges from the perspective ofcomponent-based software engineering.Chapter 3 helps readers learn the essentials of component-based software,including development process and infrastructures. Moreover, the major dif-ferences between conventional software and component-based software areexamined.Chapter 4 focuses on the introduction of testing component-based soft-ware, including its basics, challenges, and issues. Finally, Chapter 5 discussesthe detailed concepts of software testability for components and component-based programs.2Introduction Introduction to softwarecomponentsInent? When we ask people this question, we get different answersbecause they have different understandings about the softwarecomponent concept. In this chapter, we introduce the concept ofsoftware components in component-based software engineeringby comparing them with traditional software modules.We first review the evolution of software components fromsubroutines to reusable software components. Next, we discusssoftware component definitions, basic elements, properties, anddeliverables. We examine the differences between software com-ponents in component-based software engineering (CBSE) and con-ventional modules. Later, an overview of an engineering processfor software components is discussed. Finally, we highlight ques-tions and concerns in component validation and quality assur-ance in component-based software engineering.npastdecades,wehaveusedsoftwarecomponentstorefertothebuilding parts of software programs. What is a software compo-1.1componentsThe evolution of softwareIn the early days of programming, programs were constructed bycreating a main program to control (or invoke) a number of sub-routines. Each subroutine was programmed as a specific part ofthe program based on the given requirements and function parti-tions. To reduce programming efforts, programmers in a projectteam reused subroutines during a project’s implementation [1].31Contents1.1 The evolution of softwarecomponents1.2 Why is softwarecomponent reuseimportant?1.3 What is a softwarecomponent?1.4 Properties of softwarecomponents in CBSE1.5 Basic elements ofsoftware components1.6 Software modules versussoftware components inCBSE1.7 An engineering processfor software components1.8 Questions, concerns, andneeds in componentvalidation and qualitycontrol1.9 SummaryReferencesCHAPTER Hence, subroutine reuse is one of the earliest formats in software reuse. In1968, M. D. Mcilory introduced the concept of software components at theNATO Software Engineering Conference [2]. Since then, the evolutionary his-tory of software component technologies has gone through a number ofstages.From the late 1970s to the 1980s, engineers used the structure-orientedsoftware development methodology to partition an application system into anumber of modules based on its given functional requirements. After the mod-ules were developed, they integrated them to form an application system. Dur-ing that time period, many function libraries were developed in the Fortranprogramming language as reusable software packages to support the develop-ment of scientific applications. These software packages could be considered asthe first generation of software components. Although many programmers hadused these packages to develop various scientific application programs, theydid not know how to practice cost-effective software reuse due to the lack of adisciplined component-based software engineering methodology.In the 1980s, the introduction of object-oriented technology enabled soft-ware reuse in a broader scope, including the reuse of class analysis, design,and implementation. Many object-oriented C++ class libraries were developedas reusable software packages [3]. Thus, object-oriented technology steeredthe evolution of component technology from reusable function libraries toobject-oriented class libraries. In the 1990s, many large corporations, such asGTE, IBM, Lucent Technologies, and Hewlett Packard, launched enterprise-oriented software reuse projects to develop domain-specific business compo-nents for product lines using object-oriented technology [4].In 1989, component technology advanced to its new era—reusable middle-ware—when the Object Management Group (OMG) began to standardize anopen middleware specification for distributed application systems and devel-oped Common Object Request Broker Architecture (CORBA) [5]. Its major goal wasto allow software middleware vendors (like IONA) to provide common reus-able middle-ware to support distributed objects of application software tointeract with each other over a network without concern about object loca-tions, programming languages, operating systems, communication protocols,and hardware platforms. To provide high-level reusable components, theOMG also specified a set of ...

关注我们

关注微信公众号

您选择了以下内容