2.1. Software Paradigms

Today, most organizations will find their technology skill base engaged in one of the three major paradigms: procedural, object oriented, or component oriented. Where you are today is highly specific to your organization and your staff skills. Procedural and object paradigms are closely tied to programming-language choice, but you will find that component orientation is different in that it is more closely associated with the selection of an infrastructure.

Procedural programming languages include FORTRAN, COBOL, Pascal, BASIC, and many others. In procedural technology, the program comprises the process for executing various algorithms. The process is separated from the data in the system, and the process manipulates the data through direct access operations. This is a direct outcome of the stored-procedure programming systems from which computer technology originates. When the program and data are separated, there are many potential interdependencies between parts of the program. If the data representation is modified, there can be substantial impacts on the program in multiple places.

An example of data–process separation is the year 2000 problem, in which simply adding some additional digits to the date representation has catastrophic consequences for procedural software. Unfortunately, because the majority of systems are built with procedural technology, the dependencies upon these data representations can cause systemwide program errors and the necessity for line-by-line program review and modification.

Object-Oriented Paradigm

Object-oriented programming languages include Smalltalk, C++, and the Java programming language ("the Java language"). These languages support the encapsulation of data with accessor code in terms of abstract data types (commonly called classes). In object-oriented programming languages, the encapsulation capabilities are sufficient for reasonably sized programs. As long as software modules are maintained by individual programmers, encapsulation is sufficiently robust to provide some intrinsic benefits. However, we shall see that language-specific encapsulation is insufficient to support software reuse and distributed systems.

In object-oriented technology, the basic paradigm is changed to enable a separation of concerns. Figure 2.1 shows the object-oriented technology paradigm in which the program is broken up into smaller pieces called objects. Each object contains some of the data of the system, and the program encapsulates that data. In other words, access to the data is only available through using the program through which it is directly associated. In this way, the system is partitioned into modules which isolate changes. Changes in data representation usually only impact the immediate object which encapsulates that data.

Objects communicate with each other through messages. Messages can have an impact upon state—in other words, changing the data—but only through the encapsulated procedures which have an intimate relationship to the local data. For small-scale programs, the object paradigm is effective in its isolation of change. However, the paradigm is not perfect for all of its potential uses.

Technology and System Scale

When the size of the system is scaled so that many programmers are involved, the encapsulations have been found to be insufficient to isolate change across systems. In this case, additional component-oriented infrastructures are needed to provide industrial-strength encapsulations of the data and associated programs.

One example is the CORBA interface definition language, which defines object-oriented interfaces that are sufficiently opaque to support the integration of large-scale distributed systems. In fact, the encapsulation mechanism, or IDL, is powerful enough to enable the transparent integration of multiple programming languages such as Smalltalk and the Java language as well as the object-oriented communication across heterogeneous systems which may involve multiple operation systems and protocol stacks.

Objects Are the Commercial Baseline

Object-oriented technology is in widespread use today. It has been said that the procedural technologies originated from academia but the object-oriented technologies originated from commercial organizations. In fact, object-oriented technologies have many interesting origins which go back virtually to the beginning of computer science. Today, object technology is the dominant paradigm for commercial software. Virtually every vendor in the software business is providing object-technology solutions which, together with component infrastructures, can enable interoperability between software vendors in various software environments.

For example, corporate development organizations today are migrating from procedural languages such as C and COBOL to object-oriented languages which have gained substantial popularity in recent years. Languages such as the Java language have made a dramatic impression on society as a whole. An awareness of the Java language is so commonplace that even the man on the street is familiar with the terminology for this tool of software developers.

Object-Oriented Architecture: An Oxymoron For the majority of practitioners, object orientation is devoid of a software architecture approach. This is manifested in multiple ways in object-oriented methods and culture. Starting with what is generally regarded as the original source for OO thinking, Wirfs-Brock's 1990 book, Designing Object-Oriented Software, there was a notion of software architecture, including the discovery of subsystems through inspection of collaboration diagrams. It merited an entire chapter of Wirfs-Brock's method in 1990. In the next decade, little was written about architecture in the OO methodology community. Major OO methodology books had at most a few paragraphs concerning architecture, which were a faint reflection of Wirf-Brock's architecture notions. Since virtually nothing was written about architecture in the literature, most OO practitioners had no architecture guidance. There was no reason to consider architecture important. This has led to great confusion on OO projects, as team members struggle to manage complexity and scalability with OO methods not designed to address them. In general, OO methods involve successive refinement of object models, where most analysis objects are eventually transformed into programming objects. In our terminology, we called these approaches model-based methods. The assumption that each analysis object will inevitably become a programming object is a major obstacle for OO thinkers to overcome in order to understand architecture. In architectural models, specification objects represent constraints, not programming objects. They may or may not be transformed into programming objects; that is an independent decision of the developer. OO also opposes architecture in other subtle ways, related to project culture. OO encourages project teams to be egalitarian (e.g., CRC cards), where all decisions are democratic. On such a project, there is no architect role, because there is little separation of decision making between members of the development team. OO encouraged "bad-is-better" thinking in development, a philosophy which is virtually the opposite of architectural thinking. Using "bad is better," the external appearance of a working implementation greatly outweighs any requirement for maintainable internal structure. In other words, rapid iterative prototyping, with ruthless disregard for architectural principles, is a normal, healthy environment for OO development. The topic of architecture has resurfaced only recently in OO literature, with the newfound popularity of componentware. Now it is customary to include a token chapter on architecture in most methodology books, whereas in the heyday of OO, architecture was virtually taboo. In one sense, componentware is a response to the shortcomings of OO. Componentware, with its emphasis on larger-variable-grained software modules, is a clear step toward an architectural mindset.

Databases and Objects

Database technologies are also evolving toward objects. The database technologies originated with several different models. In recent years, the relational model of databases has been predominant. More recently, object-oriented databases have become a substantial technology market, and databases which combine object orientation and relational concepts are becoming prevalent.

Database query languages, such as Structured Query Language (SQL), are being extended in standards work to support object-oriented concepts. One reason why this is occurring is that the kinds of applications people are creating require substantially more sophisticated types of data representations and types of query algorithms for searching and manipulating the information.

Object in the Mainstream

Object technology is used today in most application areas and vertical markets. Dozens of projects are being pursued by government organizations in object technology as well as commercial industry. A principal advantage of technology is that it enables the implementation of new business processes which provide competitive advantage to organizations. Society is changing toward increasing dependence upon information technology. The use of object technology enables rapid system implementation and various forms of labor saving through software reuse mechanisms. Even though the largest number of lines of software are still written in procedural languages such as COBOL, it is becoming clear that this paradigm is changing.

Toward Components: Scripting Languages

Proponents of scripting languages claim that there are a larger number of scripting language programmers than there are of any other kind [Ousterhout 98]. Scripting languages such as the JavaScript language, TCL shell programming languages, and Visual Basic enable pre-existing software (e.g., components) to be easily integrated into application configurations.

Since object-oriented software and object technology is the dominant commercial paradigm, it is important to understand the major flavors of commercial technologies which are available for the architecture of software systems. The two major categories include commercial off-the-shelf proprietary software and commercial off-the-shelf open systems software (see Section 2.2).

Componentware: The Component Orientation Paradigm

Moving to the next level of software sophistication requires fundamental changes in systems thinking, software processes, and technology utilization. The next major area of technology, componentware (or component orientation), contains key elements of the solution to today's critical software problems.

The componentware approach introduces a set of closely interrelated techniques and technologies. Componentware introduces a sophisticated mindset for generating business results. These componentware elements include:

• Component Infrastructures

• Software Patterns

• Software Architecture

• Component-Based Development

Componentware technologies provide sophisticated approaches to software development that challenge outdated assumptions. Together these elements create a major new technology trend. Componentware represents as fundamental a change in technology as object orientation did in previous generations. We will discuss these componentware technologies after a brief introduction to componentware's unique principles.

Components versus Objects

Componentware can be understood as a reincarnation of object orientation and other software technologies. Distinguishing componentware from previous generations of technology are four principles: encapsulation, polymorphism, late binding, and safety. This list overlaps with object orientation, except that it eliminates the emphasis on inheritance. In component thinking, inheritance is a tightly coupled, white-box relationship that is unsuitable for most forms of packaging and reuse. Instead, components reuse functionality by invoking other objects and components instead of inheriting from them. In component terminology, these invocations are called delegations.

"One person's architecture is another person's detail. One person's system is another person's component" [Rechtin 97].

By convention, all components have specifications corresponding to their implementations. The specification defines the component encapsulation (i.e., its public interfaces to other components). Reuse of component specifications is a form of polymorphism which is strongly encouraged. Ideally, component specifications are local or global standards that are widely reused throughout a system, an enterprise, or an industry.

Componentware utilizes composition for building systems. In composition, we integrate two or more components to create a larger entity, which could be a new component, a component framework, or an entire system. Composition is the integration of components. The combined component acquires joint specifications from the constituent component.

If the components have matching specifications for client calls and services, then they can interoperate with no extra coding. This is often called plug and play integration. When executed at runtime, this is a form of late binding. For example, a client component can discover a component server through an on-line directory, such as the CORBA Trader Service. With matching client and service interface specifications, the components can establish a run-time binding to each other and interact seamlessly through the component infrastructure.

In a perfect world, all components would be fully conformant with their specifications and free from all defects. Successful operation and interoperation of components depend on many internal and external factors. Safety properties can help because they can minimize entire classes of defects in a component environment. As society becomes increasingly dependent upon software technology, safety has become a serious legal concern and one of the most important areas of computer science research.

For example, Java's garbage collection feature guarantees memory safety, or freedom from memory deallocation defects (which are problematic in C++ programs). Other kinds of safety include type safety (guaranteed data type compatibility) and module safety, which controls the effects of software extension and component composition.

Component Infrastructures

The componentware revolution has already arrived in the form of component infrastructures. Major platform vendors have bet their futures on componentware product lines. In particular, Microsoft, Sun Microsystems, IBM, and the CORBA consortia have established significant componentware infrastructures through massive technology and marketing investments.

These component infrastructures (Microsoft COM, Sun Enterprise JavaBeans, and CORBA request brokers) are dominant infrastructures for overlapping industry segments—Microsoft COM+ on the desktop; the Java language for cross platform applications; and CORBA for corporate networks and the Internet. Interestingly, these technologies are also mutually interoperable, with Microsoft, Sun, IBM, and others supporting the CORBA Internet Inter-ORB Protocol (IIOP) for Microsoft COM and Java Remote Method Invocation (although the Java language works equally well with CORBA). In the following paragraphs, we'll compare these infrastructures briefly.

Microsoft has been promoting the Component Object Model (COM) and follow-on products for several years. COM is a single-computer component infrastructure. OLE and ActiveX define componentware interfaces based upon COM. In theory, the Distributed Component Object Model (DCOM), now called COM+, extends the capabilities of COM over networks and the Internet. With these technologies, Microsoft has funded a major corporate strategy promoting a worldwide migration to componentware over the past five years. Future Microsoft plans indicate that it will continue its componentware initiative for the forseeable future.

Sun Microsystems' invention of the Java language is a continuing evolution of programming-language features, infrastructures, and related class libraries. The Java language technology has created tremendous industry excitement and support from independent developers. The extensions for JavaBeans and Enterprise JavaBeans establish an evolving component model that rivals COM and ActiveX in the cross-platform application space. Enterprise JavaBeans and the IBM San Francisco project are using Java Remote Method Invocation (RMI) for distributed computing, one of several proprietary infrastructures available to Java language programmers. While proprietary Java language infrastructures do provide convenience for programmers, they lack one key capability: ease of interoperability with other programming languages. This may be a serious limitation for corporate projects because it hampers legacy integration and cross-language development which is commonplace for server applications. Another, more subtle, issue is that Java application programming interfaces (APIs) are not standard. For popular technologies like JDBC, vendors often customize the APIs as they create their value-added versions of the Sun reference technologies.

The Common Object Request Broker Architecture (CORBA) is an open systems standard for distributed infrastructure supported by multiple vendors, industry consortia, and formal standards bodies. Recently there has been a surge in CORBA licensing in corporate development organizations, with a surprising array of Fortune 500 companies adopting CORBA for enterprise projects, including banks and manufacturers. From its inception CORBA has supported both object and componentware models. With today's CORBA products supporting multiple component interfaces in a single encapsulated servlet, CORBA is an ideal infrastructure for componentware development involving heterogeneous hardware/software, multiple programming languages, or distributed computing. Recently, CORBA has been extended to support the capabilities of message-oriented middleware and domain-specific API standards (health care, manufacturing, financial services, and so forth). Just like any other technology, CORBA products do have limitations (e.g., memory leaks, conformance, performance). However, for a standard established in 1991, it is amazing how well the CORBA architecture has weathered cataclysmic innovations in other technologies and emerged ever stronger (e.g., the Java language and the Internet).

Java application servers have overtaken CORBA's role in many Internet-savvy organizations. What CORBA lacks is direct support for scalability, reliability, and maintainability. These capabilities are standard features supported by most Java application servers today.

Componentware infrastructures are having a significant impact on software development. In many respects, these infrastructures are well on their way to becoming mainstream development platforms. Because all of them are becoming interoperable (through CORBA IIOP), there is a well-understood relationship between infrastructure models. Their similarities are much greater than their proprietary differences might imply.

Infrastructure selection is one of the most discussed, but least important, aspects of implementing componentware. For corporate developers, the most critical issues are confronted well after infrastructure selection. These issues include: how to master designing with the technology, how to architect systems, and how to coordinate one's development efforts. These areas are covered in the next three sections.

Component Software Patterns

Software patterns comprise a common body of software knowledge which can be applied across all component infrastructures (see Section 1.3). The most famous category of software patterns, called design patterns, comprises proven software design ideas which are reused by developers. Other important categories of patterns include analysis patterns and antipatterns. Analysis patterns define proven ways of modeling business information that can be directly applied to the modeling of new software systems and databases.

Software patterns are a necessary element of componentware. The development of new, reusable components requires expert-level quality of design, specification, and implementation. Proven design solutions are necessary to establish successful component architectures and frameworks for families of applications. Often, there are too many variables to take chances on unproven design concepts.

The popularity of software patterns can be explained as a response to the practical shortcomings of object orientation. Antipatterns explain the common mistakes that people make when developing object oriented software systems (as well as other types of systems). Much more is needed than basic object-oriented principles to build successful systems. Design patterns explain the additional, sophisticated ideas that are required for effective software designs. Analysis patterns present the sophisticated ideas necessary for the effective modeling of concepts and data.

It is still commonplace in software development to reinvent design ideas, incurring the risks and delays of trial-and-error experimentation. If fact, most software methods encourage reinvention as the normal mode of development. Considering the challenging forces of requirements change, technology innovation, and distributed computing, we consider reinvention to be an unnecessary risk in many circumstances. This comment is especially applicable to the development of components, where the costs of defects and redesigns can affect multiple systems.

Altogether, software patterns can be described as knowledge reuse. It is interesting to note that most patterns are considered as simple as common sense by expert-level developers. However, for the majority of developers, patterns are a necessary part of technical training that can help them to achieve world-class results.

Component Software Architecture

Software architecture concerns the planning and maintenance of system structure from earliest system concept through development and operations. Good architectures are stable system structures which can accommodate changes in requirements and technologies. Good architectures ensure the continuous satisfaction of human needs (i.e., quality) throughout system life cycles. Reusable components are examples of good architecture. They support stable interface specifications, which can accommodate changes due to reuse in many system contexts.

Software architecture plays an important role in component design, specification, and use. Software architecture provides the design context within which components are designed and reused. Components have a role in predetermining aspects of software architecture. For example, a component framework may predefine the architecture of a significant portion of a system.

One of the most exciting aspects of software architecture for componentware is supporting distributed project teams. A software architecture comprises a system specification that enables parallel, independent development of the system or its parts. A proper software architecture defines computational boundaries (i.e., API) that divide the system into separate testable subsystems. These subsystems can be outsourced to one or more distributed project teams.

Component-Based Development

Component-based development is software development with a difference. Many process aspects are reused, such as iterative, incremental development. The primary componentware difference is the specialization of technical roles. Three key componentware roles are software architect, component developer, and application developer. These differ from object-oriented approaches, which promoted notions of all-purpose programmers, committee-based design, and architecture after-the-fact.

A typical leadership team for a project comprises a software architect and a project manager. The architect works in conjunction with management to make key technical decisions, those with systemwide impact. The architect is responsible for technical planning of the system and for communicating these plans with developers. Since the architect coordinates systemwide design decisions, many other technical decisions are the responsibility of developers. To be effective, the architect must have the highest levels of experience and technical training, with outstanding skills in design, specification writing, and spoken communication.

The best component developers are also the most talented programmers. They design and program the building blocks from which the application will be constructed. The architect defines the major boundaries behind which component-based services will be provided. Reuse of preexisting components is evaluated with respect to an organizational software repository. For new component requirements, the component developers design and construct new software, updating the organizational repository. Typically, components will implement the horizontal functions and lower-level aspects of the system, reducing the need for application developers to reinvent these capabilities. Component developers make intensive use of software patterns, applying several overlapping patterns to each component design and implementation.

Application developers are responsible for integrating components and implementing the vertical requirements of the system, including user interfaces. They apply preexisting components to the solution of application-specific problems. Application developers must communicate with end users having some domain expertise.

Generally, component developers use systems programming languages, such as the C++ and Java languages, while application developers use scripting languages, such as the JavaScript language, TCL, Python, and Visual Basic. Systems programming languages allow more control of low-level issues but are more difficult to use for application building. Scripting languages provide a higher level of abstraction, with a corresponding reduction of up to 8:1 in lines of code needed to implement a given requirement, compared to systems programming languages.

Componentware is the next major software technology trend. In many ways, it has already arrived and is readily available for commercial exploitation. This revolution is actively supported by major vendors, including Microsoft, Sun, IBM, and the CORBA vendor consortia. The most important aspects of componentware are not the choice of technologies, but how these are applied. Successful adoption of componentware must include the reuse of software patterns, the planning of software architecture, and the establishment of component-based development teams.

The componentware revolution is an exciting opportunity to avoid the inadequacies of outdated software approaches. Componentware enables you to survive and thrive when facing the challenges of requirements change and rapid commercial innovation. Componentware delivers the benefits of software reuse and enables outsourcing to distributed project teams.