SUMMARY Component-based software engineering offers inherent benefits in software quality,
27.7 SUMMARY Component-based software engineering offers inherent benefits in software quality,
developer productivity, and overall system cost. And yet, many roadblocks remain to
be overcome before the CBSE process model is widely used throughout the industry. In addition to software components, a variety of reusable artifacts can be acquired by a software engineer. These include technical representations of the software (e.g., specifications, architectural models, designs), documents, test data, and even process- related tasks (e.g., inspection techniques).
The CBSE process encompasses two concurrent subprocesses—domain engi- neering and component-based development. The intent of domain engineering is to identify, construct, catalog, and disseminate a set of software components in a par- ticular application domain. Component-based development then qualifies, adapts, and integrates these components for use in a new system. In addition, component- based development engineers new components that are based on the custom require- ments of a new system,
Analysis and design techniques for reusable components draw on the same prin- ciples and concepts that are part of good software engineering practice. Reusable components should be designed within an environment that establishes standard data structures, interface protocols, and program architectures for each application domain.
Component-based software engineering uses a data exchange model, tools, struc- tured storage, and an underlying object model to construct applications. The object
CHAPTER 27 C O M P O N E N T - B A S E D S O F T WA R E E N G I N E E R I N G
743
model generally conforms to one or more component standards (e.g., OMG/CORBA) that define the manner in which an application can access reusable objects. Classi- fication schemes enable a developer to find and retrieve reusable components and conform to a model that identifies concept, content, and context. Enumerated clas- sification, faceted classification, and attribute-value classification are representative of many component classification schemes.
The economics of software reuse are addressed by a single question: Is it cost effective to build less and reuse more? In general, the answer is, “Yes,” but a soft- ware project planner must consider the nontrivial costs associated with the qualifi- cation, adaptation, and integration of reusable components.
REFERENCES [ADL95] Adler, R.M., “Emerging Standards for Component Software, Computer, vol.
28, no. 3, March 1995, pp. 68–77. [BAS94] Basili, V.R., L.C. Briand, and W.M. Thomas, “Domain Analysis for the Reuse of Software Development Experiences,” Proc. of the 19th Annual Software Engineer- ing Workshop, NASA/GSFC, Greenbelt, MD, December 1994. [BEL95] Bellinzona R., M.G. Gugini, and B. Pernici, “Reusing Specifications in OO Applications,” IEEE Software, March 1995, pp. 65–75. [BIN93] Binder, R., “Design for Reuse Is for Real,” American Programmer, vol. 6, no.
8, August 1993, pp. 30–37. [BRO96] Brown, A.W. and K.C. Wallnau, “Engineering of Component Based Systems,” Component-Based Software Engineering, IEEE Computer Society Press, 1996, pp. 7–15. [CHR95] Christensen, S.R., “Software Reuse Initiatives at Lockheed,” CrossTalk, vol.
8, no. 5, May 1995, pp. 26–31. [CLE95] Clements, P.C., “From Subroutines to Subsystems: Component Based Soft- ware Development,” American Programmer, vol. 8, No. 11, November 1995. [DEV95] Devanbu, P., et al., “Analytical and Empirical Evaluation of Software Reuse Metrics,” Technical Report, Computer Science Department, University of Maryland, August 1995. [FRA94] Frakes, W.B. and T.P. Pole, “An Empirical Study of Representation Methods for Reusable Software Components,” IEEE Trans. Software Engineering, vol. SE-20, no.
8, August 1994, pp. 617–630. [HAR98] Harmon, P., “Navigating the Distributed Components Landscape,” Cutter IT Journal, vol. 11, no. 2, December 1998, pp. 4–11. [HEN95] Henry, E. and B. Faller, “Large Scale Industrial Reuse to Reduce Cost and Cycle Time,” IEEE Software, September 1995, pp. 47–53. [HOO91] Hooper, J.W. and R.O. Chester, Software Reuse: Guidelines and Methods, Plenum Press, 1991. [HUT88] Hutchinson, J.W. and P.G. Hindley, “A Preliminary Study of Large Scale Soft- ware Reuse,” Software Engineering Journal, vol. 3, no. 5, 1988, pp. 208–212.
[LIA93] Liao, H. and Wang, F., “Software Reuse Based on a Large Object-Oriented Library,” ACM Software Engineering Notes, vol. 18, no. 1, January 1993, pp. 74–80. [LIM94] Lim, W.C., “Effects of Reuse on Quality, Productivity, and Economics,” IEEE Software, September 1994, pp. 23–30. [LIN95] Linthicum, D.S., “Component Development (a Special Feature),” Application Development Trends, June 1995, pp. 57–78. [MCM95] McMahon, P.E., “Pattern-Based Architecture: Bridging Software Reuse and Cost Management,” Crosstalk, vol. 8, no. 3, March 1995, pp. 10–16. [ORF96] Orfali, R., D. Harkey, and J. Edwards, The Essential Distributed Objects Sur- vival Guide, Wiley, 1996. [PRI87] Prieto-Diaz, R., “Domain Analysis for Reusability,” Proc. COMPSAC ’87, Tokyo, October 1987, pp. 23–29. [PRI93] Prieto-Diaz, R., “Issues and Experiences in Software Reuse,” American Pro- grammer, vol. 6, no. 8, August 1993, pp. 10–18. [POL94] Pollak, W. and M. Rissman, “Structural Models and Patterned Architectures,” Computer, vol. 27, no. 8, August 1994, pp. 67–68. [STA94] Staringer, W., “Constructing Applications from Reusable Components,” IEEE Software, September 1994, pp. 61–68. [TRA90] Tracz, W., “Where Does Reuse Start?” Proc. Realities of Reuse Workshop, Syracuse University CASE Center, January 1990. [TRA95] Tracz, W., “Third International Conference on Software Reuse—Summary,” ACM Software Engineering Notes, vol. 20, no. 2, April 1995, pp. 21–22. [WHI95] Whittle, B., “Models and Languages for Component Description and Reuse,” ACM Software Engineering Notes, vol. 20, no. 2, April 1995, pp. 76–89. [YOU98] Yourdon, E. (ed.), “Distributed Objects,” Cutter IT Journal, vol. 11, no. 12, December 1998.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more