Benefits and Challenges of System Integration/Reuse
In engineering circles advances in computer hardware and engineering applications software are driven by market competition, and the desire to design, analyze, and manufacture increasingly complex engineering systems. Complexity can be due to the mere size (or number of parts) of the system, or perhaps due to enhanced performance specifications achieved through the use of new materials, and novel combinations of disciplines (e.g., design and optimal control of electro-mechanical systems).
For organizations that have made large investments in hardware/software technology, there is great reluctance to discard it simply because a new technology has come along. What management would like to see instead, is the benefits of improved communications without having to reinvest in the basic application-specific software. The objectives of systems integration are to try to bring this situation under control, to ensure that the pathway forward maximizes return for the organization, and protects a companies past investments in software and hardware (East, 1994).
What is Reuse?
If systems engineering developments for multidisciplinary engineering and business applications are to have any chance of keeping up with advances in computer hardware and networking, while also achieving significant improvements in system development productivity, one of the most important catalysts is to stop developing system components from scratch for each new project.
Instead, engineering systems should be built from existing application-area components by assembling and replacing inter-operable parts. What is needed are ensembles of business components/objects that provide major chunks of engineering/business functionality, which can be snapped together to create complete business applications.
The simplest form of (software) reuse is "cut-and-paste," where chunks of code are cut from an existing work and pasted into a new development. While this form of reuse accelerates the initial design, there are serious problems and limitations in its use. First, adapting a component via cut-and-paste is difficult because you must first look inside (and understand) the component's inner workings before making the modifications. Over time, a library of reusable components can be constructed.
For this approach to development to work(i.e., use of unaltered components applied across many contexts). systems must be sufficiently decoupled so that they can be easily pulled apart, reconfigured, and maintained. Every component should be open to extension, but closed to modification. This is design for reuse in action.
This style of design requires extra decisions on how functionality should be distributed among the system components -- in return, and if this is done well, enhanced flexibility can result from the application of object-oriented principles (D'Souza et al., 1998).
Experience. Decades of experience from the software industry indicate, that this goal is much easier stated than achieved. The main criticism of the the modularity practice to date is due to the narrowness of the domain, which can be largely attributed to:
It takes effort to work out how to make a component more generic. Perhaps the generic component will run more slowly than an application-specific component. The benefit lies in cost savings through increase reuse, reduced maintenance, improved quality and extended working lifetime. The extent to which these benefits will occur, in practice, may be quite uncertain, so generalizing components for reuse is a calculated risk.
Well-defined interfaces are an essential component of system-level design. Interface-based design is a methodology that employs component interfaces as the key design abstraction, separates system interfaces from the internal details of implementation for virtual components (VCs), and shows how the interfaces at various levels of abstraction relate to each other.
This approach to development encourages designers to:
The advantages of this methodology include:
Interfaces can be defined through port definitions (a port is simply a connection point into a virtual component), interface behavior (a description of allowable activity/transactions through a port), attributes (i.e., data attributes; flow of control) and transactions and messages.
Components, Connections and Pluggable Reuse
We define a component as (Brown, 2000):
Components are self-contained packages of functionality that have clearly defined open interfaces that offer "plug-and-play" high-level application services, a specification of external behavior provided and required, plus the documents and source code associated with satisfying the specification (of course, the latter may be withheld from the customers). The elements of a component are (pg. 82; Brown, 2000):
The specification is an abstract description of the services offered by the component. This description may include the expected behavior of the system for specific situations.
Multiple implementations can improve the flexibility for when the component can be used (e.g., across operating systems).
A component model is a set of services that support the system operation, plus a "set of rules" that must be obeyed by an external component for it to take advantage of the services (e.g., CORBA component standard; Javabeans)
Components can be grouped in different ways to provide a replaceable set of services. This grouping is called a package.
Once a package of components is installed in an operational environment, they will be deployed.
Using formal specifications to represent hardware/software components facilitates the determination of reusability because they more precisely characterize the functionality of the hardware/software, and the well defined syntax makes processing amenable to automation.
The component approach to development mandates that there is no need to modify a component when it is connected to other components. Generic components have plug-in points (parameterized aspects that can be filled in appropriately in a given context) for implementation of components and for generic model components that are build to be adapted and reused.
Reuse requires that components be built to serve dual purposes. First, they need to be generic -- that is, their properties are not overly tied to a specific application. And second, they must be capable of being easily adapted and customized to the needs of a specific application. So how to:
The first item says that we need to apply reuse at all levels of abstraction in the development process, from high-level specifications down to low-level details (see the adjacent figure). The second item says that we need easy to use mechanisms for extending and customizing system modules/components.
Use of Upper and Lower Interfaces
Through the use of well-defined interfaces, components should simply plug together. (insert material from pages ....395.)
Let's look at the problem of plugging components together in a little more detail. In the construction of an engineering system from components, it is useful to partition the component interfaces into two types: (1) those that are designed to support component assembly, and (2) those that are designed for extension and specialization.
Examples of upper interfaces (from the software world) include public operations of a class, APIs of databases, and primary application-specific services. Examples of lower interfaces (from the software world) can be found in web browsers, spreadsheets, graphics packages, .... etc.
Design and Implementation of Generic Components
Development of reusable system components doesn't occur by itself -- it requires effort. From an organizational perspective, resources must be assigned to the development of reusable assets. Along the way, key questions to be addressed include:
A fundamental tenet of component design is complete separation of the interface specifications (i.e., what a component will provide and expect when used) from implementation. By encapsulating application components/objects with well-defined open interfaces, complexity of system development is held in check because developers only need to know what the object is and the services it provides (i.e., they do not need to understand the internal workings).
The adjacent diagram shows the pathway of development for creation and use of reusable components. There is no magic formula for reuse. If you notice that a large block of system code is being used across a family of applications, it is clearly a candidate for packaging and reuse. This requires careful analysis of the problem domain. There is also a danger of carrying generalization and reuse too far, producing generic components containing many features that are rarely used.
On a larger scale, reuse of components occurring among individuals, design teams and organizations requires coordination. Someone needs to be responsible for the component storage, management and distribution.
To assemble a larger component (or application) from a smaller component, the basic idea in component-based design is to:
Component-Based Design versus Object-Oriented Design
The differences between component-based design and object-oriented design have less to do with either style of design, and more to do with factors of degree and scale. For example:
Compared to objects, components offer the following benefits:
Components need not be assembled from objects. For example, a benefit of component-based technology is that they can be assembled as wrappers around legacy systems. For more information, see "components and connectors, pg. 397."
Component specifications contain the following information:
Together these mechanisms enable communication, which is the key to system interoperability. In present day terms, the telephone is perhaps the best example of a system once dominated by company-specific proprietary standards, now replaced by a common global standard. The result -- anyone can phone anywhere, anytime.
Connector Standards
To facilitate communication among components we define standard kinds of connectors between components:
For more information, see "components and connectors" page 397.
The essential elements of component-based design are (see Brown, 2000, pg. 110):
Systems are modeled as collections of interacting components. System behavior is defined and analyzed in terms of component interfaces.
Component functionality should have high cohesion.
It must be possible to specify and build components independently from one another.
To achieve system-level application assembly from components, we need:
This principle allows for orthogonalization of design concerns (e.g., separation of models of behavior from models of system structure).
System components are defined by encapsulated behavior accessible through well-defined interfaces. Interfaces define the services that can be provided by the component, and the rules under which these services can be provided.
Informal descriptions of component behavior can be provided by way of operation signatures and informal text. However, detailed descriptions of operational semantics require formal, verifiable descriptions using pre- and post-conditions attached to each operation (sounds like UML might be useful here, huh?).
This process records the history of development for the component, and includes information to assure quality and aspects of the designer's rationale.
These practices are supported by the principles of orthogonalization of concerns, effective use of languages for system modeling, and formal models for system verification.
Supporting Component Modeling with UML
When designing a system, many of the system's inherent qualities are determined by decisions that lead to what the main functional pieces of the system are (see Brown, pg. 133).
UML diagrams can be used to capture and record the static and dynamic behavior (e.g., activity diagrams, sequence diagrams, statechart diagrams) of a component system.
Specifying Interfaces with Class Diagrams.
See Brown pg's 163-165.
Developed in February 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin, University of Maryland