ENGINEERING OF COMPONENT-BASED SYSTEMS On the surface, CBSE seems quite similar to conventional or object-oriented software
27.1 ENGINEERING OF COMPONENT-BASED SYSTEMS On the surface, CBSE seems quite similar to conventional or object-oriented software
engineering. The process begins when a software team establishes requirements for the system to be built using conventional requirements elicitation techniques (Chap- ters 10 and 11). An architectural design (Chapter 14) is established, but rather than moving immediately into more detailed design tasks, the team examines require- ments to determine what subset is directly amenable to composition, rather than con- struction. That is, the team asks the following questions for each system requirement:
• Are commercial off-the-shelf (COTS) components available to implement the requirement?
• Are internally developed reusable components available to implement the requirement?
• Are the interfaces for available components compatible within the architec- ture of the system to be built?
The team attempts to modify or remove those system requirements that can- not be implemented with COTS or in-house components. 1 If the requirement(s) cannot be changed or deleted, conventional or object-oriented software engi- neering methods are applied to develop those new components that must be engi- neered to meet the requirement(s). But for those requirements that are addressed with available components, a different set of software engineering activities commences:
? Component qualification. System requirements and architecture define
What are
the CBSE
the components that will be required. Reusable components (whether COTS
framework
or in-house) are normally identified by the characteristics of their interfaces.
activities?
That is, “the services that are provided, and the means by which consumers access these services” [BRO96] are described as part of the component inter- face. But the interface does not provide a complete picture of the degree to which the component will fit the architecture and requirements. The software engineer must use a process of discovery and analysis to qualify each com- ponent’s fit.
Component adaptation. In Chapter 14, we noted that software architec- ture represents design patterns that are composed of components (units of functionality), connections, and coordination. In essence the architecture
“[I]t seems clear that defines the design rules for all components, identifying modes of connection in the near future
and coordination. In some cases, existing reusable components may be mis- most software
matched to the architecture’s design rules. These components must be applications will be
adapted to meet the needs of the architecture or discarded and replaced by assembled from
other, more suitable components. components rather
than being Component composition. Architectural style again plays a key role in the constructed from
way in which software components are integrated to form a working system. scratch.”
By identifying connection and coordination mechanisms (e.g., run-time prop-
Paul Allen and
erties of the design), the architecture dictates the composition of the end
Stuart Frost
product. Component update. When systems are implemented with COTS compo-
nents, update is complicated by the imposition of a third party (i.e., the orga- nization that developed the reusable component may be outside the immediate control of the software engineering organization).
Each of these CBSE activities is discussed in more detail in Section 27.4.
1 The implication is that the organization adjust its business or product requirements so that component-based implementation can be achieved without the need for custom engineering. This approach reduces system cost and improves time to market but is not always possible.
In the first part of this section, the term component has been used repeatedly, yet
a definitive description of the term is elusive. Brown and Wallnau [BRO96] suggest the following possibilities:
• Component—a nontrivial, nearly independent, and replaceable part of a sys- tem that fulfills a clear function in the context of a well-defined architecture.
• Run-time software component—a dynamic bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered in run time.
• Software component—a unit of composition with contractually specified and explicit context dependencies only.
• Business component—the software implementation of an “autonomous” busi- ness concept or business process.
In addition to these descriptions, software components can also be characterized based on their use in the CBSE process. In addition to COTS components, the CBSE
process yields: Certification of
XRef
software components • Qualified components—assessed by software engineers to ensure that not can be accomplished
only functionality, but performance, reliability, usability, and other quality fac- using cleanroom
tors (Chapter 19) conform to the requirements of the system or product to be methods. See Chapter
26 for details. built. • Adapted components—adapted to modify (also called mask or wrap) [BRO96]
unwanted or undesirable characteristics. • Assembled components—integrated into an architectural style and intercon-
nected with an appropriate infrastructure that allows the components to be coordinated and managed effectively.
• Updated components—replacing existing software as new versions of compo- nents become available.
Because CBSE is an evolving discipline, it is unlikely that a unifying definition will emerge in the near term.
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