Elements of architecture

Software architecture has become an area of research in its own right. The seminal work of [Shaw96] introduced the notion of software architecture as a means to describe how the various elements of a software system interact to achieve some computational goal. For example, at a high level we can distinguish between a pipe-lined architecture, common to many compilers, and event-driven computation, as it occurs for example in GUI-based systems.

Elements of architecture

[Wolf]

processing elements -- transformation on data
data elements -- contain information
connections -- glue that holds elements together

Models and views

[Kruchten95]

logical -- functional requirements
process -- performance, availability, distribution
physical -- scalability, configuration
development -- organization of software modules
scenarios -- instances of use cases

Definitions

www.sei.cmu.edu/architecture/definitions.html

slide: Elements of architecture -- models and views

In the definition given in [Wolf], a software architecture is described as consisting of processing elements, which operate on data, and data elements, which somehow contain the information being processed. In addition there are connection elements that glue the processing and data elements together. Such an abstract view allows for describing a software system at a high level of abstraction and to indicate choice points and alternatives.

A later definition, given in [Kruchten95], makes a distinction between the levels of abstraction, or points of view, from which a description of a system is possible. It distinguishes between a logical view, which captures the functional requirements, a process view, which indicates non-functional aspects such as performance, availability and distribution, a physical view, which deals with issues such as scalability and configuration, and a development view, which describes the organization of the software modules. In addition, [Kruchten95] distinguishes a scenario view, which may be used for formulating tests based on properly instantiated use cases. The scenario view may be regarded as orthogonal to the logical, process, physical and development models since it does not affect the structure of the system itself, but rather the way the structure is validated against proper usage tests.

An exhaustive list of definitions of the notion of software architecture is given at the Web site of the Software Engineering Institute (SEI), of which the url is given in slide Elements.

At the time of writing, the most comprehensive book concerning software architectures is [Practice]. As a definition it proposes:

The software architecture of a program or computing system is the structure of the system, which comprises software components, the externally visible properties of those components, and their interrelationships.

Note the stress on externally visible properties here. It is meant to express that both components and their relations must be described at a suitable level of abstraction. Also note that the phrase relationships between components may cover quite a lot. For example, when considering the architecture of a Web application, issues such as communication protocols and document standards must be considered as well. In addition, the technological infrastructure, elements of which are given in slide infrastructure, must also be taken into account.

Technological infrastructure

[CS2001]

client-platform -- hardware, OS
presentation services -- windows, multimedia
application software -- code, business logic
network -- communication support
middleware -- distribution, (object) brokers
server platform -- hardware, OS
database -- data management system

slide: Technological infrastucture

One may wonder whether the architecture metaphor, which is derived from the construction of buildings, is really appropriate for software systems. Software systems are much more dynamic than buildings, so it might perhaps be more appropriate to focus on dynamic, behavioral aspects rather than structural aspects. As a metaphor, I would prefer for example one related to an ecological system, to stress the dynamic growth that seems to be characteristic of software systems nowadays.

In the definition or rather collection of definitions, given by the IEEE Architecture Working Group, for the terms architect, architectural description, stakeholder and viewpoint, utmost care is taken to suppress the phrase structure. Instead, the notion of architecting is defined as defining, maintaining, improving and certifying proper implementation of an architecture, and an architecture as a collection of views relevant to the stakeholders of a system.

Distributed object architectures

When considering the architecture of a system, invariably the technological infrastructure plays a role. In particular, when considering client/server or distributed object systems the choice for respectively a particular client and server platform, middleware and communication infrastructure may to a large extent determine the characteristics of the software architecture.

Explicit attention for the architecture of a system becomes increasingly relevant as the complexity of the system grows. As argued in [CorbaPatterns], an architecture is an abstraction that allows for mastering complexity and managing change.

Distributed object patterns

[CorbaPatterns]

Framework

(class hierarchies)

Applications

(wrappers)

System

(horizontal, vertical, metadata)

Enterprise

(reference models, infrastructure, policies)

Intra/Internet

(standards)

slide: Distributed object patterns

[CorbaPatterns] present a number of patterns based on the Common Object Request Broker Architecture (CORBA). The patterns differ in scale, ranging from frameworks and systems to enterprise-level and intra/Internet-level infrastructures. According to [CorbaPatterns], software problems are due to inadequate definition and transfer of software boundaries. They criticize traditional object-oriented analysis and design methods for not paying sufficient attention to the actual interfaces that define these boundaries which may be regarded as a contract between the supplier of a service and its clients. At the higher enterprise and intra/internet levels, policies and standards are perhaps more important than interfaces per se. However, at the framework and system level interface definitions delineate stable boundaries between the components that constitute the system.

In business applications a distinction can be made between horizontal components (covering general functionality, such as GUI-aspects and document interoperability), vertical components (covering domain-specific functionality for one area of business, such as finance), and meta-data, representing the more volatile, knowledge-level aspects of a system. [CorbaPatterns] observe that each of these component types may cover one third of a system. When to consider information or a service as part of the meta-data must be determined by the extent to which that particular information or service may be considered stable. Architectural decisions must strive for an ecology of change, that is a flexible arrangement of components to promote changes in business-logic and adaptiveness to a changing environment.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.