Software Architecture: Basic Training
- Object-Oriented Technology
- Component-Oriented Technology
- Technology Ownership
- Client-Server Technology
- Internet Technology
- Architectural Layers and When to Use Them
- Software Application Experience
- Technology and Application Architecture
- Applying Standards to Application Systems
- Distributed Infrastructures
- Conclusions
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter on basic training for software architects presents the fundamental tools required of effective software architects. In the military, basic training is used to challenge and motivate cadets and to demonstrate both the demands and rewards of a military career. Similarly, software architects must be motivated individuals who have the desire to confront the challenges of technical leadership in a software development effort. However, motivation is not enough. A software architect must be equipped with the intellectual tools to realize an architectural vision.
This book takes a hands-on approach that not only presents the best architectural practices in the industry but also provides concrete real-world examples and exercises for applying the presented material to circumstances common throughout the software industry. Basic training will cover the fundamental concepts of software technology, which provide a foundation for software architecture. Software technology has evolved through many trends and alternatives for software development. Currently, mainstream software practice has evolved from procedural to object-oriented to component-oriented development (Figure 3.1). With the increasing adoption of enterprise Java and Microsoft .Net, component orientation is the next major paradigm. In corporate development, most new-start projects are adopting component orientation because it is supported by the majority of commercial development environments. As is discussed in this chapter, object orientation has a very weak notion of software architecture, which leads to serious shortcomings. The emerging trend of component orientation is replacing old approaches with strong elements of architectural design.
)
Figure 3.1. (a) Procedural Paradigm and (b) Object-Oriented Paradigm
Software architects must be able to articulate these development paradigms clearly, along with appropriate uses of enabling technologies. In any given project, an eclectic mixture of development paradigms (including relational database management) can be useful to achieve the best results. Each paradigm has something useful to offer, including mature development tools.
Today, most organizations will find their technology skill base engaged in one of the three major paradigms: procedural, object oriented, or component oriented. Each paradigm is highly specific to the organization and its staff skills. Procedural and object-oriented paradigms are closely tied to programming language choice, but component orientation is different in that it is more closely associated with the selection of an infrastructure.
Procedural programming languages include FORTRAN, COBOL, C, Pascal, and BASIC. 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 had catastrophic consequences for procedural software. Unfortunately, because the majority of systems are built with procedural technology, the dependencies upon these data representations can cause system-wide program errors and the necessity for line-by-line program review and modification.
3.1 Object-Oriented Technology
Object-oriented programming languages include Smalltalk, C++, the Java programming language ("the Java language"), and C#, one of the languages available in the Microsoft .Net development environment. 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, 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 3.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 available only by using the program through which it is directly associated. In this way, the system is partitioned into modules that isolate changes. Any changes in data representation have an impact only on the immediate object that 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 that 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.
Object-oriented technology is in widespread use today. It has been said that the procedural technologies originated from academia, but the object-oriented technologies actually originated from commercial organizations. In fact, object-oriented technologies have many interesting origins that 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 that, together with component infrastructures, can enable interoperability between software vendors in various software environments.
Object-Oriented Architecture
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, Designing Object-Oriented Software [Wirfs-Brock 1990], there was a notion of software architecture, including the discovery of subsystems through inspection of collaboration diagrams, which merited an entire chapter. 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 Wirfs-Brock's architectural notions.
Since virtually nothing was written about architecture in the literature, most OO practitioners had only rudimentary architectural guidance. They had no reason to consider architecture important. This attitude 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 terminology used in this book, these approaches are called 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 on the part 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 role for the architect because there is little separation of decision making between members of the development team.
OO encouraged "bad-is-better" thinking in development, a philosophy that is virtually the opposite of architectural thinking. Using bad-is-better thinking, 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 new-found 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-grained software interfaces and modules, is a progressive 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 significant technology market, and databases that combine object orientation and relational concepts are commonplace. Most of the major industry databases, such as Oracle 9i and IBM's DB2 database, include object-relational capabilities.
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. Government organizations and commercial industry are pursuing dozens of projects in object technology. A principal advantage of technology is that it enables the implementation of new business processes that 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 still exists in procedural languages such as COBOL, it is becoming clear that this paradigm is changing.
Scripting Languages
Proponents of scripting languages claim that there are more scripting language programmers than any other kind [Ousterhout 1998]. Scripting languages such as the JavaScript language, TCL shell programming languages, and Visual Basic enable preexisting software (e.g., components) to be easily integrated into application configurations.