Software Architecture

30.11.2003

Software Architecture

Prof. Dr. Arnd Poetzsch-Heffter

Software Architecture

Chapter Overview

1.

“Software Architecture: An Introduction”

2.

“Software Systems and Architecture”

3.

“Architectural Views and Aspects”

4.

“Architectural Patterns”

5.

“Program Frameworks”

6.

“Architectures for Component Software”

7.

“Description Techniques for Architectures”

8.

“Designing Software Architectures”

Poetzsch-Heffter: Software Architecture 30.11.2003

2

1 Software Architecture: An

Introduction

What this chapter is about

1.1

“Subject Matter and Goals”

1.2

“Architecture of Software Systems”

1.3

“Software Architecture in Relation to other Disciplines”

1.4

“Further Reading”

4

Poetzsch-Heffter: Introduction 30.11.2003

What is Software Architecture ?

No standard, universally-accepted answer to this question.

Software architecture is a subdiscipline of software engineering with at least the following goals:

1. It should provide knowledge about existing, well-designed architectures, frameworks, and architectural patterns.

2. It should develop techniques, methods, models, description languages, and tools to improve understanding, analysis, design, construction, evaluation, and evolution of software systems.

5


1.1 Subject Matter and Goals


6



Scientific or engineering disciplines can be characterized by their subject matter, their goals, and problems.

Subject of software architecture is software systems .

Discipline of software architecture is discussed looking at:

• examples of software systems

• different structuring techniques

• central goals and problems

7



1.1.1 Software Systems

8



A software system is a technical system or subsystem in which software plays a dominant role.

We discuss some examples to illustrate:

• what we regard as software

• how software systems can be classified

• that software systems may have very different characteristics

9



Example (

GNU Chess application ):

System to play chess with a computer.

• installed on a given computer

• interactive

• simple

• single user

• graphical user interface

• runs in one process

• no persistent state between executions


10


Example (

Pascal compiler ):

Takes Pascal programs as input and produces assembler or machine code.


• input/output system,

• batch-oriented

• single user

• performs complex transformation

• runs in one process

11



Example ( operating system ):

Platform system for program execution, for file and network access, and for handling input and output.


• interactive

• nonterminating

• persistent state between executions

• multi process

• provides a rich programming interface

• provides a platform for other systems

12



Example (

World Wide Web ):

A distributed client-server system for making documents accessible over the Internet.

• open

• extensible

• thousands of servers and millions of clients

• distributed all over the world

• provides no central or coordinated activity

13


1.1 Subject Matter and Goals 14

Example ( reservation system of the Deutsche Bahn AG ):

System for reserving seats in trains.

• closed

• dedicated

• distributed

• provides a number of coordinated services

• based on user interaction



Example (

D2 telecommunication network ):

System for keeping track of the location of mobile phones, for connecting the caller to the callee, for maintaining phone connections, and for accounting.

• distributed

• cannot be shut down for maintenance

• fault-tolerant

• highly available



Example ( automatic pilot of am Airbus A 320 ):

System for navigating the aircraft towards a destination.

• nonterminating

• embedded

• realtime

• consists of sensors, computer hardware, and control devices being part of the whole aircraft system

• highly dependable

16


17 1.1 Subject Matter and Goals

Software Systems: Characteristics

Software systems are installed or running on one or several physically identifiable platforms.

Together with their platform(s), they constitute operational systems that provide some tasks/services.

Software systems are built on top of or are subsystems of other systems.



Software Systems: Models

Software systems can be very complex.

The many people involved in a software system need means to communicate about relevant issues:

• Designers: analyze and compare different designs

• Programmers: understand the interfaces and behavior of system components

• Testers, maintenance: overall structure of program modules

• Trainers, users: conceptual characteristics and structures

18



1.1.2 Structures of Software Systems

19



Various models and description techniques are needed to express different structures of a system on different levels of abstraction.

Two of many different ways to abstract a software system are discussed in detail:

1. Conceptual view

◦ shows what a system is supposed to do and how its subtasks are structured

2. Implementation view

◦ explains the structure of the program modules implementing the system

20



Example (Ada / C compiler):

Compiling system that translates Ada and C programs into assembler code.

21



Ada source

program scanner

& parser

Ada syntax tree

C source

program scanner

& parser

C syntax tree name analyzer

& type checker attributed Ada

syntax tree name analyzer

& type checker attributed C

syntax tree translator

to IR translator

to IR program in intermediate representation optimizer1 optimizer2 optimizer3

code generator assembler

program


22



main program attribute evaluator

23


1.1.3 Goals and Problems of Software Architecture

24



• collect, describe, and refine the knowledge about well-designed architectures, frameworks, and architectural patterns.

• improve the support for routine design (reuse of prior solutions)

• develop techniques, methods, models, description languages, and tools to improve understanding, analysis, design, construction, evaluation, and evolution of software systems.

25



Description Techniques

• Define the semantics of the notations for the different structures in such a way that the relationship between the structures is well-defined and that they complement each other to avoid redundancy.

• Software systems have very different characteristics:

◦ simple applications running in one process

◦ Nonterminating systems that are platforms for applications

◦ Systems distributed over large networks with coupled processes

• Description techniques have to cover wide classes of architectures.

26



Foundations

Theoretical foundation is needed to solve these problems:

1. How can interfaces of components and their connections be modeled and specified on an abstract level?

2. How can descriptions of different system structures be embedded into a common formal framework?

3. How can architectural descriptions be combined with formal methods so that system properties can be formally verified?

4. How can efficiency or security analysis be based on architectural descriptions?

27



Reference Architectures

• The study of successful software architectures should provide reusable solutions to specific design problems.

• This can be done at different levels.

• Reference architectures or domain-specific architectures should help in the design of whole systems or large subsystems within specific application domains.

• typical examples:

◦ reference architecture for compilers based on phases scanning, parsing, semantical analysis, optimization, and code generation

◦ domain specific architectures for the realization of Web Services

28



Frameworks

By frameworks we mean generic architectures together with extensible implementations of the kernel functionality for these architectures.

typical examples:

• frameworks for graphical user interfaces

• component software



Patterns

The study of architectures should develop knowledge about reusable patterns that capture the relation between generic program components or objects.

Architectural patterns can guide the design phase of a software system and provide a vocabulary to talk about architectural structures.



Tools and Visualization

• Architectural descriptions can be integrated into the mechanized software development and construction process.

• With an advanced tool support, they can be used to automatically generate communication code and module interfaces.

• They provide the basis for:

◦ system-wide consistency checking

◦ automation of system distribution, installation, and startup

◦ visualization and testing of complex software systems

31


1.2

Architecture of Software Systems

1.2


1.2.1 The Architecture of a Software System

32


1.2

Architecture of Software Systems 33

What is the architecture of a given software system?

To answer this question, we compare the architecture of a software system to the architecture of a skyscraper.


1.2


Software System compared to Skyscraper

An installed software system consists of:

• megabytes of data and binary code

• sitting on some storage media of one or several computers.

• While executing, part of its code is loaded into main memory.

The skyscraper consists of:

• millions of bricks or tons of concrete

• sitting on solid ground

• While functioning, it needs power supply for air conditioning, elevators, etc.


1.2


Architecture is certainly not about the basic concrete elements of the systems like bytes or bricks.

The architecture of the skyscraper is about:

• its form and statics

• the structure of its surface

• the internal structuring of the building into floors and rooms

• the organization of staircases and elevators

• the connection to the outside,

• the structure of the air condition, heating, and power supply, etc.

35


1.2


For all of these aspects, the architects of the skyscraper will produce documents based on different techniques, but closely related.

36


1.2


The architecture of a complex software system is based on the following structures :

37

• Conceptual structure :

◦ components: abstractions of the system’s functional requirements

◦ relation: exchanges-data-with

• Data flow :

◦ system components on different levels of abstraction

◦ relation: send-data-to

• Control flow :

◦ system components on different levels of abstraction

◦ relation: becomes-active-after


1.2


• Hierarchical structure :

◦ hierarchical structuring of the systems in subsystems down to program modules

◦ relation: is-subsystem-of

• Uses/call structure :

◦ components: program modules, classes, and procedures.

◦ relation: import on modules, uses on classes, call on procedures

• Process structure :

◦ components: processes and threads

◦ relations: synchronizes-with, cannot-run-without, starts, stops, ...

• Physical structure :

◦ Describes the distribution of code and data to underlying platforms.


1.2


A short definition of software architecture capturing all its aspects cannot be given.

Three textbook definitions are shortly discussed.

39

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

Listen


1.2


The architecture of a software system defines that system in terms of computational components and interactions among those components.

Components are such things as clients and servers, databases, filters, and layers in a hierarchical system. Interactions among components at this level of design can be simple and familiar, such as procedure call and shared variable access. But they can also be complex and semantically rich, such as client-server protocols, database-accessing protocols, asynchronous event multicast, and piped streams.

In addition to specifying the structure and topology of the system, the architecture shows the correspondence between the system requirements and elements of the constructed system, thereby providing some rationale for the design decisions. At the architectural level, relevant system-level issues typically include properties such as capacity, throughput, consistency, and component compatibility.

Listen


1.2


A software architecture is a description of the subsystems and components of a software system and the relationships between them.

Subsystems and components are typically specified in different views to show relevant functional and non-functional properties of a software system. The software architecture of a system is an artifact. It is the result of the software design activity.

Listen

41


1.2


1.2.2

Generic Architectures and Patterns

42


1.2


• The architecture of single, installed software systems has a concrete counterpart: physical installation on computers.

• The architecture of implemented software systems is used when it is possible to abstract from the installation of the software systems.

• Abstraction from different configurations of software systems and from different versions .

• Product-line architectures describe the architectural structures of a family of software products within a company or organization.


1.2


• A domain-specific architecture captures the architectural abstractions specific to a given problem domain.

• A reference architecture captures some high-level design decisions and standards that a group of people or organizations have agreed on.

• Architectural notions refer to families of whole software systems.

Architectural patterns describe useful organizational schemata to structure software systems.

• An architectural pattern provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.


44

1.3 Software Architecture in Relation to other Disciplines

1.3 Software Architecture in Relation to other

Disciplines

45



Software architecture is a young discipline that can learn from related more mature disciplines.

• Building architecture and city planning: use of patterns and standardized notations for different architectural structures.

• hardware architecture: standardized notations and techniques to handle well-understood design levels, high-level description languages (e.g.

VHDL ).

46



• Computer architecture studies the design and structure of computer systems. The components of such systems are processors, memory chips, harddisks, etc. Typical connectors are buses or networks.

• Network architecture is about network topologies, switching and routing mechanisms, and protocols for network systems.

• Computer, network, and software architecture have different subject matters, but the goals are very similar:

◦ collecting knowledge about good designs

◦ improving the design and construction process

47



As a consequence of the subject matters, different techniques are needed.

• Software architecture has to cope with highly dynamic structures.

• The structures of computer and network architectures are much more static.

48



Software architecture is a subdiscipline of software engineering .

General software engineering principles apply to software architecture as well:

• separation of concerns,

• anticipation of change

• generality

• scalability

• compositionality

• rigor

49



Most architectural issues are related to

• software design

• software construction

• module integration

• NOT to the coding phase

Software engineering distinguishes two important dimensions:

• process qualities

• product qualities


50


The engineering process is about how to build and maintain a software system.

• Steps:

◦ requirements capture and analysis

◦ design

◦ implementation

◦ testing

• It includes:

◦ management issues

◦ timing issues

◦ quality control, etc

51



• The product qualities focus on what is built .

◦ system requirements

◦ test cases

◦ architectural documentation

◦ implementation of the system.

52

Thus, process and product qualities can be considered to be orthogonal.

In this course, we will concentrate on the product dimension.


1.4 Further Reading

1.4 Further Reading

53


1.4 Further Reading

Software architecture is a young discipline and textbooks in a classical sense are still to be written.

The following books give a good insight into the field:

• Software Architecture in Practice . Lenn Bass, Paul

Clements, Rick Kazman

• Software Architecture: Perspective on an Emerging

Discipline . Mary Shaw, David Garlan

• Pattern-Oriented Software Architecture: A System of

Patterns . Frank Buschmann, Regine Meunier, Hans

Rohnert, Peter Sommerlad, Michael Stal

54


1.4 Further Reading

• Applied Software Architecture . Christine Hofmeister,

Robert Nord, Dilip Soni

• Design and Use of Software Architectures: Adopting and

Evolving a Product-Line Approach . Jan Bosch

• Component Software: Beyond Object-Oriented

Programming . Clemens Szyperski

55


2 Software Systems and

Architecture


2.1

“A Closer Look to Software Systems”

2.2

“Examples of Software Systems and Architectures”

57


2.1 A Closer Look to Software Systems


58



Software architecture is about architectural aspects of:

• single software systems

• classes of software systems

• incomplete and extensible software systems and about:

• patterns occurring in software systems

59



2.1.1 Software Systems and their Contexts

60



In order to get a more precise idea of software systems and their basic structures, we first consider only installed or running systems.

This allows us to uniquely identify them, similar to physical objects.

We can identify running software systems by the corresponding processes and the system installation they are executing.

61



Thus, like most collections of physical objects, installed or running software systems have

1. an identity (in particular we can say where the system parts are installed or running);

2. a lifetime (from installation to deinstallation);

3. a state at each point in time (the state of a software system tells us what parts of the system are running and comprises information about variables and the state of execution);

4. a behavior .

62



In order to investigate and describe systems, it is necessary to agree on the interfaces separating the system from the context it is embedded in.

63

We distinguish two interfaces:

• the interface between the system and its platform

• the interface between the system and its environment

System of interest

Platform

System environment

(users, supersystems,

external communication)


2.1 A Closer Look to Software Systems 64

Platform and environment of a software system have different characteristics. That is why they play different roles in architectural descriptions of systems.



Platform

Typically, a platform is a software/hardware system. The platform provides the basic functionality on which a software system is built.

65

Example (platforms):

• operating system: computer hardware

• internet browser: operating and window system, network system providing TCP/IP

• e-business system: includes browsers and web-servers



It depends on the point of view whether system parts are regarded as parts of the platform or as parts of the software system of interest.

In general, we assume that a software system Υ is built on top of its platform Π in a layered way; i.e.

Υ may use

• services from Π (e.g. by calling procedures of Π ) and

• Π ’s general functionality (e.g. executing code).

This implies that Υ cannot be installed or run without its platform.

66



Reasons to make the distinction between a software system and its platform:

1. A platform may be used for several different software systems. Thus, it is reasonable to describe the platform separately and reuse it.

2. Separating the platform and the software system of interest allows one to focus on the relevant system parts.

During runtime, the user only interacts with the system and needs not to be aware of an underlying platform.

Exception: In the case of terminating systems, the user starts the system by interacting with the platform

(e.g. clicking on an icon to start a compiler, ...).


67


System Environment

We speak of the environment of a software system to refer to the outside world it interacts with (human users or technical systems). In particular, a software system can be a subsystem of a larger system.

The interaction includes:

• user inputs (keystrokes, mouse clicks, etc.)

• outputs for users (sound, text, paper, graphics, video, etc.)

• messages, input, or calls from the environment

• messages, output, or calls to software parts in the environment



The communication of a software system with its platform is only needed to understand its implementation.

The interaction with the environment is crucial to understand the behavior of a software system.

Example:

To understand the behavior of a chess game with a graphical user interface, we have to learn how to move the pieces and how to interpret the output from the system, but we do not have to know how it allocates memory or how it uses the window toolkit.



2.1.2

Characteristics of Software Systems

70



Software systems can be very different. The characteristics can be used to classify software systems and they help us to identify the relevant architectural properties of a system.

71



How is the system used?

We can distinguish software systems according to their system environment (users or components they interact with).

• A software system is often called an application if it is more or less directly used by human beings. Usually, an application is started, used, and then exited.

◦ Example: text processing systems

• A system is called embedded if it is used within a mechanical or electronical system.

◦ Example: system in a car or a TV receiver

72



• A software system is often called a platform system if its main purpose is to serve as a platform for other software systems.

◦ Example: Operating, window, and network systems

• Closed systems are used as they are. Typically, they are not modified or extended by users or third party developers.

◦ Example: most text processing systems

• Open systems allow users to extend the system. At design time, the precise context in which they are used is not known.



What is the global behavior of the system?

A system can be termninating or nontermninating .

74

Batch-oriented or transformational systems are terminating:

They receive some input, perform some tasks, produce the corresponding output, and terminate.

A typical transformational system is a compiler taking a source program as input and producing an assembler program as output.



Reactive systems maintain some ongoing interaction with their environment. This implies that reactive systems cannot be specified by a relation between an initial and final state, but rather by describing their ongoing behavior. Reactive systems are often nonterminating.

Reactive systems that need a lot of interaction with human users are often called interactive systems. According to the number of persons that can interact with a system, we speak of singleor multi-user systems.

For terminating systems, it is interesting to know whether they have a persistent state .



Further Characteristics

A system might be

• computation intensive (e.g. a system to compute a video sequence) or communication intensive (e.g. the WWW).

• running in one process on one computer, in several processes , or distributed over several computers.

• designed with weak demands concerning the response time, or it has to meet strong realtime requirements.

In combination, the above characteristics allow for a coarse classification of a software system and thus serve as a basis to describe its architecture.

76



2.1.3 What is Software? What is a Software System?

77



The term ,,software“ is often used with different meanings.

78



Software

Used in a very broad sense, the term “software” comprises programs and data.

Programs are usually descriptions with a formal syntax that specify executions.

Data captures information that can be stored on a computer.

Reasons why we consider programs and data as software:

• Programs can be handled and manipulated like data and certain kinds of data can be interpreted as programs.

• Programs and data can be mixed. E.g. an HTML-page might contain structured texts and a Java Script program.

• The techniques to manage programs and data are similar.



What is the software of a given software system Υ ?

Following items may be candidates:

• the installed object code that allows us to run Υ

• the corresponding source programs

• data that captures Υ ’s configuration and customization information

• software that is used to generate Υ , install, or test it

• grammar from which a parser is generated that is used as part of Υ

• parser generator

• programs describing the installation process, e.g. make-files



To define what is the software of a system, it is important to understand the following points:

• Software systems depend on various kinds of data, descriptions, and programs.

• This software has to be managed in a consistent way.

• Different parts of the software are responsible for different stages in the implementation and use of a system

(generation, configuration, installation, customization, execution, testing).



Software Systems

Software systems have a number of implicit or explicit parameters:

• the platform

• functional properties (e.g. an installation of a text processing system might or might not include a spell checker)

• size of data or number of transactions they can handle

• system environments and users

These parameterizations and variations lead to classes of software systems.

82



In summary:

• A software system is a technical system or subsystem in which software plays a dominant role.

• It should have a fairly clear interface to its platform and to the system environment.

• It may be parameterized for the installation on different platforms, to provide different functionality, and to adapt it to different users and system environments.



A software system can be in different stages . It can be:

• executing, usually in the form of processes on one or several computers/platforms;

• deployed/installed, i.e. stored on the platform and ready for execution;

• configured, i.e. prepared for deployment/installation;

• programmed, i.e. implementation parts of the possibly parametric system are finished;

• designed, i.e. design specification is completed (including the description of the architecture).

84



Whenever software is executed, we can assume that it constitutes a system or is part of a system. This does not mean that software is always written to be part of a specific software system (e.g. library code).

85

A software system is usually built from

• general library software ,

• platform specific software ,

• domain specific software ,

• software that is specifically implemented for the system of interest.


2.2 Examples of Software Systems and Architectures

2.2 Examples of Software Systems and

Architectures

86



• We first describe the GNU compiler collection to illustrate the concepts and notions introduced so far and to provide an example for a software system family.

• Then, we explain a typical three tier architecture.

• As a third example, we refer to the description of the Call

Center Customer Care System.

87


2.2 Examples of Software Systems and Architectures 88

GCC: The GNU Compiler Collection

The GNU Compiler Collection is an integrated compilation system that allows to compile C, C++, Objective C, Fortran, and Java programs.

It is a termninating, non-distributed, transformational system without persistent state.

Interactions with the system are only indirect: On the one hand, it produces error messages for users, on the other hand it generates target code that can later be executed on some platform or debugged using the GNU source-level debugger GDB.


2.2 Examples of Software Systems and Architectures 89

The complexity of GCC has three reasons:

1. The analyses and optimizations performed on the input as well as the translation are complex tasks.

2. It can be configured and installed on a great number of platforms

3. GCC handles five different source languages and can generate code for all platforms it can run on; in addition, it can work as a cross-compiler, i.e. running on one platform producing code for another one.

Precisely speaking, GCC is not one software system, but a family of systems .



A Three Tier Architecture

As an example of a three tier architecture, we consider the

WebAssign system.

WebAssign makes homework assignments for students accessible over the Internet.

Students can work on the assignments either interactively or off-line and then send in the solutions.

WebAssign manages the correction and grading process. In particular, it can distribute the solutions to correctors or interact with tools that automaticly check the solutions.

WebAssign has essentially a three tier architecture.

90



user interaction browser web-pages

...

browser web-pages

...

external servers

WebAssign application

server

WebAssign

WebAssign database user system interface

91 process management database management



user interaction browser web-pages

...

...

browser web-pages

...

internet external servers

WebAssign application

server

webserver

system environment

WebAssign

WebAssign database database management

system platform


92


WebAssign is a distributed, nontermninating, interactive, multi-user platform system with persistent state. It is a communication intensive system with simple computations.

93

The three tier architecture is often used when an effective distributed client/server design is needed that provides good performance, flexibility, maintainability, reusability, and scalability, while hiding the complexity of distributed processing from the user.

The characteristics have made three tier architectures a popular choice for Internet applications and net-centric information systems.


3 Architectural Views and

Aspects

95


3.1

“Architectural Structures and Views”

3.1.1

“An Introduction to Views”

3.1.2

“The Dynamic View of Software Systems”

3.1.3

“The Static View of Software Systems”

3.1.4

“The Relationship between Dynamic and Static

View”

3.1.5

“An Example Based Discussion of Views”

3.2

“Architectural Aspects”


96

Two principles for the presentation and documentation of an architecture:

1. structuring of the behavior or the software of a system

Typical questions are:

◦ What are the states of a system?

◦ What are its components?

2. focusing on different system-wide properties (also called architectural aspects) like performance, availability, scalability, or security.

A typical question is:

◦ How does the interaction of system components guarantee an acceptable response time for the services provided by the system?


3.1 Architectural Structures and Views


97



The architecture of a software system or of a class of systems is described by their relevant structures.

Definition (structure):

A structure identifies important components or entities of a system and explains their relationship and interactions.

Definition (system component):

A system component is a part of the running system (e.g. a process) or a part of the software (module or procedure).

Definition (system entity):

A system entity is an instance of an abstract concept (e.g. a service or a state of a system).

98



Structures are usually represented by diagrams where components/entities are depicted by boxes in different forms

(rectangles, ovals, circles) and relations are represented by and .

Structures can also be described by informal text or defined by mathematical formula .

Structures can have a well-defined semantics .

Common practice is to use only vaguely defined diagrams.

99



Recently, attempts have been made to develop at least a standardized syntax for the diagrams. A typical example is the notation for the diagrams of the U nified M odeling

L anguage UML.

100

Literature

Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified

Modeling Language User Guide. Addison-Weseley, 1999.



For using structures to describe an architecture, the following questions have to be answered:

• What structures should be chosen for the description of the architecture?

• What is the relation between the structures? Are they consistent?

101

Definition (view):

A view combines several structures that share common properties or a common perspective. Thus, views can be regarded as a means to organize architectural descriptions.



3.1.1 An Introduction to Views

102



A software architecture can be described based on a fixed number of different views .

In the literature, there is not yet a general consensus about what views should be used to describe an architecture.

Some examples are presented here.

103

1. Christine Hofmeister, Robert Nord, Dilip Soni.

Applied Software Architecture. Addison-Wesley, 2000.



Their approch is centered around four views:

• conceptual view

◦ describes the system in terms of its major design elements and the relationships among them

• module view

◦ encompasses two orthogonal structures: functional decomposition and layers

• execution view

◦ describes the dynamic structure of a system

• code view

◦ describes how the source code, binaries, and libraries are organized in the development environment.

104



2. Philip Kruchten. The 4+1 view model of architecture.

IEEE Software, 12(6):42-50, 1995.

105

Philip Kruchten presents a ”4+1” view model, i.e. based on four main views plus a distinguished fifth view:

The 4 main views are similar to those presented above, but they are differently tailored.

The distinguished fifth view uses a small subset of important scenarios (similar to use cases) to show how the structures of the four views work together seamlessly.


3.1 Architectural Structures and Views 106

The two sketched approaches are based on practical needs.

For a deeper understanding or a formal analysis, such a heuristic approach imposes some problems:

• “What are the precise borderlines and relationships between the views?”

• “How can we provide a formal underpinning of the views?”

We concentrate on two fundamental views: the dynamic view and the static view of a software system.



• The dynamic view

◦ is concerned with the runtime structures

◦ on the abstract level corresponds to conceptual structure

◦ on the concrete level corresponds to execution structure

• The static view

◦ is concerned with software and code structures.

◦ on the abstract level corresponds to module structure

◦ on the concrete level corresponds to code structure

Altogether, the two views with the different abstraction levels provide a useful method to classify and relate architectural structures.

107



3.1.2 The Dynamic View of Software Systems

108



The dynamic view of a software system comprises its runtime structures.

On a concrete level:

• the components of these structures are e.g.

◦ processes, threads, objects, storage devices

• the connectors are e.g.

◦ procedure calls, event-based communication, stream-based communication, protocols

• relevant resources are

◦ execution time, storage, communication bandwidth

109



On a more abstract level:

• the components are

◦ functional units performing essential tasks of the system

• the corresponding connectors are often

◦ loosely specified communication mechanisms

• Dynamic structures , i.e. structures of the dynamic view, also describe the behavior of systems.

◦ Example: state transition systems

110



Example (Dynamic View of the World Wide Web):

The WWW is a nonterminating system.

At each point in time, it consists of a set of servers and a set of clients. Servers and clients are essentially processes.

Servers run most of the time, have an address, wait for client requests, and can access a file system or database with

Web-pages.

The typical Web-client is a so-called browser. A browser allows one to load and display Web-pages. It is started and terminated during a user session.

Web-server and -clients communicate over the Internet using the http-protocol.


3.1 Architectural Structures and Views browser

A browser

B browser

C

Web-server www.bundestag.de

Internet

Web-server dict.leo.org

file system or database

112



Problems for the description of dynamic structures:

1. The number of dynamic components/entities may be large; e.g. a complete picture of the WWW has to contain thousands of servers and possibly millions of clients.

2. The number, sort, and relation of active components changes over time; e.g. the number of active Web-servers and -clients is continuously changing.

Solution: Concentrate on representative sections of the system at points in time when the system is in characteristic configurations (in the example, we concentrated on two servers and three clients).



3.1.3 The Static View of Software Systems

114



The static view of a software system comprises the structures of the software, the so-called static structures .

On a concrete level,

• The components of the static view have the form of programs, libraries, program modules, procedures, classes, and structured data.

• The architectural description of these components concentrates on their interface properties.

• The static view includes the issues related to the construction of an executable system from its sources

(often expressed by some scripting languages) and to the distribution of the software to different computers.


115


• Simplifying a bit, there are two kinds of relations between the components of the static view.

◦ The generalized uses-relation expresses that one component uses another or depends on another; e.g. one module imports another, one class inherits from another, one procedure calls another, one program or script starts another.

◦ The translational relation expresses that one component is constructed from several others, e.g. by compilation or binding.

116



On a more abstract level,

• The components of the static view are software packages/modules.

• In contrast to a program module, a software package/ module is programming language independent and captures a larger part of the software realizing a system.

• A software package is determined by its name, its contents, its interface, and its relation to other software packages.

• A software package often corresponds to a work package that is assigned to a group of programmers during the implementation phase of a system.



The typical relationship between the abstract structures and the concrete structures in the static view is the implemented-by-relation; e.g. a software package can be implemented by a set of program modules and a particular procedure for startup and initialization.

Relevant properties in the static view are

• program size

• readability of the code

• avoidance of code redundancy

• code reuse in its different forms

• quality of interface design



3.1.4 Relationship between Dynamic and Static View

119



• Each component at runtime is based on one or several pieces of software. E.g. a running application like a browser is based on the program implementing the application.

• We can relate components at runtime to pieces of binary code and data or to program code in high-level programming languages or to more abstract software levels.

• In most cases, one component of the static view corresponds to several instances in the dynamic view.

E.g. several processes may execute the same program; several objects may be instances of the same class.



Less clear is the relationship between the connectors or communication mechanisms of the dynamic view and the elements of the static view.

• Sometimes, the connectors and communication mechanisms appear in the static view as components, or as part of components; often, they do not appear at all, because they are regarded as part of the platform the system is built on.

• On the other hand, certain components and connectors of structures in the static view are not reflected in the dynamic view; e.g. inheritance and the compiling relation between a source and a target program.



Elements of dynamic Elements of static structures structures process object program class procedure incarnation procedure state variables/files/execution points/...

protocol event

??

??

?? (procedure) module/package

122



To illustrate the relationship between the dynamic and static view, we consider the architecture of a simple Web-browser.

We present both views on a fairly abstract level:

• For the dynamic view, we provide a conceptual structure.

• The static view is presented at the module level.

The architecture is designed and presented in such a way that the relation between the views becomes clear.


3.1 Architectural Structures and Views back forward bookmarks edit new

1. Browser

Window back forward edit bookmarks new

2. Browser

Window

Browser Window

Model

Browser Window

Model

History

List

Webpage

Cache

Cache

Manager

Access Manager

Protocol

Manager


Bookmark

Manager conferences searching homepages

frank

miriam bundestag java

Bookmarks

Internet

124


Main Module

Bookmark

Management

Bookmark Window

View & Control

Notification

Module

Browser Window

Module

Browser Window

View & Control

History

Management

Cache

Access

Management

Management

Protocol

Management

Window

Toolkit

Socket

Module


125


On the given abstraction level, the structures essentially differ in four respects:

1. The dynamic structure has to capture replication of components.

2. What occurs as connectors in the dynamic structure, may be realized by software in the static structure (e.g. the event-based communication is implemented by using the notification module).

3. The static structure usually contains components for system startup and initialization.

4. The static structure expresses the multiple use of a software module and issues of software reuse.



In general, we consider it a criterion for good design, if the relation between dynamic and static views and their structures is simple.

However, there are many cases where such a close relationship cannot be attained, like e.g. the WWW.

The WWW is essentially built

• on the http-protocol for communication,

• on HTML to describe Web-pages,

• and on naming and addressing standards.

The architecture of the WWW poses almost no further constraints on Web-servers and -clients.

127



3.1.5 An Example Based Discussion of Views

128



To illustrate the general explanation of views given above, we have a closer look at a simple example system and some of its dynamic and static structures.

The structures are presented as UML diagrams.

We start the presentation with structures of the dynamic view.

The second part discusses structures of the static view.

129



Structures of the Dynamic View

130



A structure naming the basic tasks of a system and its main interactions with the system environment

• is helpful as a general introduction to a system

• links the requirements and architectural description of a system.



The small bank application used as an example here supports three tasks:

• A user can login to the bank system; the bank can validate that a user has the right to access the accounts.

• A user can inquire the balance of an account.

• A user can transfer money from one account to another.

These basic tasks are demonstrated using a so-called use case diagram of UML.


3.1 Architectural Structures and Views 133 user

login/ validate get account

balance transfer

money

bank

system

In use case diagrams, the system environment is depicted by so-called actors . Actors can be human beings or technical systems (e.g. the bank system).



The use case diagram does not tell us how the tasks play together. To describe the conceptual behavior of a system, a state transition system can be helpful.

A state transition system

• names the conceptual states of a system,

• explains when a system changes from one state to another

• and what actions are performed at state changes.

The conceptual behavior of our bank application is described by so-called state machines using UML notation.


3.1 Architectural Structures and Views user login? entered(name,passwd) / isValid(name,passwd) validate?

invalid_1v2 valid invalid_3 exit

select service?

getBalance account number?

entered(accno) / getBalance(accno) display balance ok ok transfer transfer

data?

entered(amount,source,target) / transfer(amount,source,target) display outcome


135


The state transition system does not tell us what components the system has and where they are executed.

This information is captured by the component or process structure where a component is a unit of computation or memory.

We are using UML notation for objects and processes.

136



:BankClient

<<process>> myBankAppl

*

1 connect()

1 bas:BankApplServer

<<process>> createBankAppl()

1 isValid(nm,pw) getBalance(ac) transfer(a,s,t)

1

*

:BankAppl

<<thread>>

-isValidated

-failedAttempts checkNamePwd(n,p) ndb:NameDatabase

<<process>> dbhost:BankHost

<<process>> getBalance(ac) transfer(a,s,t)



The process structure illustrates the dynamic components of the system.

We assume that the name database and the bank host are servers belonging to the system environment

The system of interest consists of

• the bank application server,

• the bank application objects,

• and the bank clients.



The rationale underlying this decomposition is as follows:

1. Clients should run on computers of users, i.e. computers that are outside the control of the bank.

2. The application server provides a uniform service access point for different types of clients, e.g.:

(a) Web-based clients where the user interface on the client side is implemented by active Web-pages and where communication is based on the http-protocol.

(b) Clients that run as interactive programs on the user side and communicate via remote method invocation.

3. The application server should be able to handle many clients at a time.

139



Structures of the Static View

Whereas the structures of the dynamic view explain the behavior of a system, the structures of the static view describe the software.

In the following, we discuss two structures of the static view of the bank application system:

• the package structure

• the class structure of one of the packages.

140

The main purpose of the discussion is to expose the differences between dynamic and static structures.



The bank application system consists of five packages.

The contents of a package may be e.g.

• declarations of classes,

• interfaces, or other types.

141


3.1 Architectural Structures and Views clientPCAppl::util

<<import>> clientPCAppl

+ BankClient

BankClientGui

<<import>> bankApplServer

+BankApplServer

BankApplServerImpl

+BankAppl

BankApplImpl clientWWW

+ BankServlet clientWWW::pages

<<import>> nameServer

+NameDatabase

<<import>> bankHostServer

+BankHost

<<import>>

142



Whereas a package structure essentially provides a hierarchical partitioning of the whole software into smaller parts, a class structure can be helpful to understand the internal parts of a package and their relation to parts of other packages.

143

As an example, we present the class structure of the package

“clientPCAppl” as a UML class diagram.



BankClient myBankAppl main() loginEnteredEvent(name,passwd) getBalanceEvent() transferEvent() accnoEnteredEvent(accno) transferDataEnteredEvent(

accno, source, target) okEvent() exitEvent()

1 boundary to library /platform

1

BankClientGui init()

1

1

SelectFrame

1

MessageDialog

1

TransDataDialog

1

AccountNoDialog

1

LoginDialog

144

Frame Dialog



Whereas dynamic structures describe a running process, static structures refer to texts and documents and their relationships.

Unfortunately, there is no sharp borderline between the dynamic and static view.

Furthermore, it can lead to more compact and expressive structures to mix dynamic and static aspects.

Relations between objects can be defined in a static way, but in general object relations are dynamic properties.


3.2 Architectural Aspects


146



Definition (Aspect of a software system):

An aspect of a software system is a property or a requirement that is related to the system as a whole.

We distinguish functional and non-functional aspects.

Functional aspects deal with the correct behavior of the system; they include e.g.

• partial correctness properties ,

• termination ,

• liveness ,

• deadlock-freedom .

147


3.2 Architectural Aspects 148

Typical non-functional aspects include following properties:

• Performance , referring to the responsiveness of the system to events from the system environment.

• Security , a measure of the system’s ability to resist unauthorized attempts at usage while still providing its services to legitimate users.

• Availability , measuring the proportion of time the system is up and running.

• Reliability , referring to the property that a system behaves according to its specification even if parts of the system function improperly (includes in particular fault tolerance).



• Testability , referring to the ease with which the software

(including data for test cases) can be developed that demonstrate the system’s well-behavior through testing.

• Modifiability , the ability to change the system in a quick, organized, and cost effective way.

• Reusability , meaning that a system is designed in such a way that its architecture and/or components can be reused for the construction of future systems.

• Scalability , the ability to configure or adapt a system for a more demanding performance profile (e.g. larger number of users, higher execution speed, higher bandwidth in connections, higher storage capacity).



• Portability , the ability of the system to run on different platforms, i.e. computing environments.

• Usability : A system is usable if it is easy for a user to learn how to work with the system.



The distinction between functional and non-functional aspects is not sharp; apects on the borderline are e.g.:

• Error handling , strongly related to reliability, but captures functional behavior as well.

• Performance , usually considered as a non-functional aspect; however, in a real-time system, it is a functional aspect.

• Garbage collection of unreferenced persistent objects can be a functional system requirement; it can as well be a technique for an efficient usage of storage.

151



An aspect can be studied

• on the architectural level or

• on the level of system components.

The analysis of an aspect on the architectural level is usually based on one or several architectural structures.

Some aspects are strongly related to structures of the static view (e.g. portability or reusability).

Other aspects can be better analyzed based on structures of the dynamic view (e.g. functional aspects and performance).

As an example, we consider the analysis of availability based on the dynamic view.



3.2.1 Availability

153



Definition (availability of a system):

A system is said to be available at a certain point T in time if all its services are available at T .

Definition (availability of a service):

A service is available at time T if a request of the service at

T can be processed and answered in an acceptable time interval (that may depend on the service).

We say a system, system component, or service is r % of the time available if the probability that it is available at an arbitrary point in time is r/ 100 .



Example (availability of a service):

Compute the availability of a service provided by a simple system.

The system consists of six processes: a port process, two brokers, and three servers.

The port accepts service requests and delegates them to an available broker.

A broker forwards service requests to available servers.

Broker 1 can forward to server A and B, broker 2 to B and C.

The servers process the services; server A and B provide the service we are interested in.


3.2 Architectural Aspects server A broker 1 incoming service requests port broker 2 server B server C

156



We assume that:

• the port is always available

• brokers are 70% available

• servers are 80% available

• the availability of a process is independent of the other processes.

It follows that:

• no broker is available 9% of the time

• broker 1 alone is available 21% ,

• broker 2 alone is available 21% ,

• both brokers are available 49% .

157



As the service of interest is only provided by server A and B, it is not available at 16% :

9% + 21% ∗ 4% + 21% ∗ 20% + 49% ∗ 4% = 16%

I.e. the service of interest is available 84% of the time.


4 Architectural Patterns


4.1

“Introduction”

4.2

“Layered Organization”

4.3

“Repositories”

4.4

“Compound Object Pattern”

4.5

“Pipes and Filters”

4.6

“Process-Control Pattern”


160

In the design and the construction of software systems certain patterns of organization appear again and again.

Patterns

• express fundamental schemas for structuring software systems into components,

• specify the responsibility of the components,

• provide a vocabulary to describe architectures in a generic way,

• are an important means for reusing design knowledge.

161


In the following we explain six architectural patterns.

We use the same diagrammatic notation for each of the patterns to simplify the comparison of patterns.

162


Literature:

Mary Shaw and David Garlan:

Software Architecture: Perspective on an Emerging

Discipline.

Prentice Hall, 1996.

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter

Sommerlad, and Michael Stal:

Pattern-Oriented Software Architecture: A System of

Patterns.

John Wiley & Sons, 1996.

163


164

Remark on Terminology

The terms “architectural pattern”, “architectural style”, and

“architectural idiom” are often used with a similar meaning.

• Architectural patterns refer to patterns on the system level.

• Design patterns are smaller in scale and capture design knowledge about components on a subsystem level.

• Architectural and design patterns are programming language independent.

• Coding patterns describe successful implementation hints for the realization of design patterns or typical coding problems in a specific programming language.


4.1 Introduction

4.1 Introduction

165


4.1 Introduction

Architectural patterns are presented as generic structures of the dynamic view.

For the presentation of patterns, we use the UML notation for the

“process structure” .

Components of the structure are conceptual subsystems of the architecture. They may be active or passive objects.

166


4.1 Introduction 167

We distinguish the following kinds of components:

• Computational component: Its main task is to perform computations; it has no persistent state.

• Memory component: Its main task is to store data and to provide an interface to access the data.

• Sensor component: Its main task is to constantly measure physical properties (like e.g. temperature of a gas) and store the results into variables.

• Process-control : Its main task is to control a physical process or device based on some input variables.



We will consider as well components that are both computational and memory components. In this case we say that the property of the component is arbitrary . E.g. a server in a client-server system may perform computations for its clients or may work as a database.

We do not distinguish between components and connectors, but consider connectors with a non-atomic behavior as components. Connections are expressed as associations between components. Components can only communicate with associated components.


4.1 Introduction

In UML diagrams representing patterns, various notation rules are used to express the following properties:

• kind of the component

• direction and kind of communication (synchronous or asynchronous)

• which components trigger the activity

• roles of objects (active or passive)

As an example, we consider the client-server pattern. Client components are associated with one server component.

Whereas clients are usually assumed to be computational components, the kind of the server may vary.

169


4.1 Introduction

:Client

<<computation>>

* request

1 :Server

<<arbitrary>>

Based on these notations, an architectural pattern

• describes a family of systems sharing a similar structural organization,

• defines a vocabulary for referring to its components (e.g.

client, server) and

• provides a generic model that describes the main tasks of the components and their interaction.


170


Given this conceptual framework, we can investigate different architectural patterns by answering the following questions:

• What is the design vocabulary, i.e. the types of components?

• What are the allowable structural patterns?

• What is the underlying computational model?

• What are the essential invariants of the pattern?

• What are some common examples of its use?

• What are the advantages and disadvantages of using the pattern?

• What are some of the common specializations?


4.1 Introduction

In the following, we present five patterns:

• the pattern for layered system organization

• repository pattern

• compound object pattern

• pipe-and-filter pattern

• process-control pattern

For each pattern, we discuss some of the above questions.

172


4.2

Layered Organization

4.2


173


4.2


A layered architecture is hierarchically structured into layers.

• Each layer provides services to the layer above it and uses services of the layers below it.

• In a strictly layered system, a layer only communicates with the layer directly below it.

• The system environment has only access to the top layer.

• All other layers are hidden from the environment.

• The top layer initiates and controls the activity of the layered system.

174


4.2


:TopLayer

<<arbitrary>>

1 1

1

:Layer3a

<<arbitrary>>

1

1

:Layer2

<<arbitrary>>

1

1

:Layer1

<<arbitrary>>

1

:Layer3b

<<arbitrary>>

1 1

1

1


175

4.2


A layered organization can be used for different kinds of systems.

176

Typical applications of this pattern are:

• operating systems with the layers hardware, system kernel, system services (often known as system calls), application layer;

• file or database systems where each layer corresponds to a different abstraction level of how the data is represented;

• network systems with protocol stacks on each side of the connection.


4.2


Whereas in the first two examples the communication between the layers typically are procedure calls from the upper to the lower layer, the concrete communication between network layers is different, because each network layer is distributed over the nodes of the network.

node M node N

177

Layer K

Layer L


Layer K

Layer L

4.2

Layered Organization 178

Layered systems have several desirable properties:

1. They support designs based on increasing levels of abstractions.

2. They support enhancement. Because each layer only interacts with the layers above and below, changes can affect at most two other layers.

3. Layers support reuse. Because they support clear interfaces between the layers, they allow different implementations of the same layer to be used interchangeably. Thus, they provide the possibility to standardize interfaces that can be implemented by different vendors (e.g. ISO OSI model for network systems).


4.2

Layered Organization 179

Disadvantages of layered systems:

• The strict structuring enforced by a layered organization is not applicable to every system or it might lead to an unnatural and inefficient design.

• In particular, the restriction that a layer should only communicate with direct sublayers can lead to undesirable overhead.


4.2


Layered organization compared to client-server architecture

• Client-server architectures following the structure of the

“bank application system”

are often called three-tiered systems where the term “tier” is often used interchangeably with “layer”.

• The essential difference is that in client-server architectures the server is visible to the system environment and can be used by a number of clients.

• This is not true for a layered architecture where the inner layers are hidden and the system only has one component as a top layer.

180


4.3

Repositories

4.3

Repositories

181


4.3

Repositories

A repository architecture consists of a central memory component that is accessed by different clients.

The memory component – often called repository itself – is used to store common data of the system and as an asynchronous communication facility between clients:

Data stored by one client can later be read by another.

182

The repository pattern does not determine which components trigger and control the activity within the system.


4.3

Repositories

:ATypeClient

<<computation>>

* access

:BTypeClient

<<computation>>

* access trigger access trigger

1 1

:Repository

<<memory>>

1

:CTypeClient

<<computation>>

*

183


4.3

Repositories

Two specializations of the repository pattern play an important role in practice:

184

• Pattern for database system:

The activity within the system is only controlled by the clients. Clients can read and write the data stored in the central memory. Notice that this is as well a specialization of the client-server pattern where the server is a memory component.


4.3

Repositories

:ATypeClient

<<computation>>

* access

:BTypeClient

<<computation>> access

* access

:CTypeClient

<<computation>>

*

1 1

:Database

<<memory>>

1

185


4.3

Repositories

• Pattern of a blackboard architecture:

The central memory component is responsible for the control of the system. Depending on the state of the stored data, the central component triggers activity at different clients to further evolve the state.

The blackboard pattern is appropriate when a central complex data structure is constructed based on input of different sources or transforming computations by specialized clients. It is in particular “useful for problems for which no deterministic solution strategies are known”.

186


4.3

Repositories

:ATypeClient

<<computation>>

* access

:BTypeClient

<<computation>>

* access trigger access trigger

1 1

:Blackboard

<<memory>>

1

:CTypeClient

<<computation>>

*

187


4.3

Repositories 188

Possible applications of the blackboard pattern:

• AI applications where different, independent clients contribute to analyze the data in the central component.

The contributions can mutually support each other.

• Advanced parallel compiler architecture where all intermediate representations of the target program are stored in a central repository and parsing, optimization, and code generation actions are triggered according to the state of the repository.


4.4

Compound Object Pattern

4.4


189


4.4

Compound Object Pattern 190

The compound object pattern is essentially the computation model underlying object-oriented programming.

A compound object is a component that can

• trigger activity,

• perform computations,

• capture part of the system state.

A compound object may be composed of several smaller objects.

The state of a compound object is encapsulated and can only be accessed from other compound objects by sending messages.


4.4


:CompoundObject

<<memory>>

<<computation>> message message

:CompoundObject

<<memory>>

<<computation>> message

:CompoundObject

<<memory>>

<<computation>> message

:CompoundObject

<<memory>>

<<computation>>

:CompoundObject

<<memory>>

<<computation>>

The compound object pattern is very flexible. It does not determine the precise kind of the components, allows an arbitrary topology, and does not restrict communication.


191

4.4

Compound Object Pattern 192

Advantages of the flexibility:

• It prevents from confining oneself to a too specific architecture.

• Useful for the design and description of generic component models and architectures that should apply to a large class of systems like e.g.

◦ the C ommon O bject M odel of Microsoft

◦ the JavaBeans model of Sun Microsystems

On the other hand, using more restricted patterns can simplify the architecture.


4.5

Pipes and Filters

4.5

Pipes and Filters

193


4.5

Pipes and Filters 194

The pipe-and-filter pattern distinguishes two different types of components:

• A pipe is an inactive data queue.

If components and connectors are distinguished, pipes are typically connectors.

• A filter is an active object that reads from input pipes and writes into output pipes.

write a:Filter

<<computation>>

1

1 write p:Pipe

<<memory>> r:Pipe

<<memory>> read

1 b:Filter

<<computation>>

1 write q:Pipe

<<memory>> read

1

1 c:Filter

<<computation>> read


4.5


Specializations:

• pipeline : restricts the topology to a sequence of filters and pipes.

• batch sequential system : the output of each filter only consists of one data item

• pipes between processes in the Unix operating system.

This allows in particular to “pipe” the output stream of one command into the input stream of another command.


4.5


Advantages:

• allows to organize a system into loosely coupled, independent components

• without feedback: system behaviour is determined by the specifications of the filters, the properties of the pipes, and the topology of the system

• reuse of filters is easy

• simple to extend and modify

Disadvantage:

• applies only to a relatively small class of problems


4.6

Process-Control Pattern

4.6


197


4.6

Process-Control Pattern 198

The process-control pattern refers to embedded systems, i.e.

to systems that monitor or control physical processes.

A physical process is typically characterized by a set of so-called process variables the values of which change continuously. They capture the measurements of the relevant properties of the system state.


4.6


We distinguish three sorts of process variables:

• Input variables: They express the properties of the input to the physical process.

• Controlled variables: They hold the values that the system is intended to control.

• Manipulated variables: These are the variables that the controller can change in order to control the process.


4.6


Process Input

:InputVariables

<<sensor>>

1:read

Physical Process

:ManipulatedVariables

<<process control>>

2:command

:Controller

<<computation>>

1:read

:SetPoint

<<memory>>

User Input

1:read

Process Output

:ControlledVariables

<<sensor>>

200


4.6


There are a number of variations of this pattern, e.g.

• Feedforward control system : the controller reads the input variables and not the controlled variables.

• Feedback control system : the controller only relies on the controlled variables.

• Furthermore, the pattern can be specialized according to the timing and the complexity of the control algorithm.


5 Program Frameworks

203


5.1

“Introduction to Program Frameworks”

5.2

“A Program Framework for User Interfaces”

5.2.1

“Architectural Properties of Graphical User

Interfaces”

5.2.2

“The Abstract Window Toolkit of Java”


Many software systems

• have similar subtasks,

• use common communication mechanisms,

• share components,

• are based on the same architectural pattern.

For example, many software systems

• have a graphical user interface,

• communicate via remote procedure call,

• have applications that share components,

• are based on the three-tier architectural pattern.


204

205

If systems share properties, there is a chance to reuse

• architectural and design knowledge,

• implementation techniques,

• implementation parts, and

• communication infrastructure.

An important method to support reuse is the construction of frameworks that capture the shared properties.


5.1 Introduction to Program Frameworks


206


5.1 Introduction to Program Frameworks 207

Program frameworks are an important technique for software reuse .

They are usually developed for certain tasks or domains.

From a static point of view, a program framework is an extensible and adaptable system of modules or classes that implement the core functionality and communication mechanisms of a general task or domain.



Program frameworks are written in some programming language (e.g. C, C++, or Java).

Depending on the language, the elements of a program framework are

• procedures,

• modules,

• classes,

• interfaces,

• or similar programming elements.

208



In the following, we give answers to two questions:

1. What is the distinction between a program framework and an arbitrary set of library classes?

2. What is the distinction between program frameworks and other kinds of frameworks?

Both answers will help to understand the relation between architectural properties and program frameworks.



Program Frameworks and Library Classes

Syntactically, a program framework appears to the programmer as a set of library classes.

But:

Not every set of library classes is a program framework, e.g.:

• a set of independent, unrelated classes like the Java library classes String, Boolean, Long, Float, etc.

• classical application programming interfaces that allow to access services of the operating or network system



A program framework is a system of classes which:

• work together to realize the functionality of more complex parts of software systems

• are extensible and adaptable

• provide the core functionality to implement a number of different concrete systems (generic aspect)

Often, a program framework is based on an architectural pattern. E.g. many GUI toolkits are designed with the

“model-view-controller pattern”

in mind.



More powerful program frameworks are so-called application frameworks . They capture the generic architecture of families of applications. E.g. they support uniform user-guidance and common appearance of different applications in the family (cf. the article “ET++ – a

Portable, Homogeneous Class Library and Application

Framework”).

Other program frameworks are less general and realize generic architectures for certain application domains.



More General Frameworks

Program frameworks capture generic architectures and generic implementations in form of library classes written in some programming language.

This has two disadvantages:

1. Program frameworks rely on whitebox reuse.

2. They are tied to the mechanisms and limitations of the underlying programming language.

In the following, we explain these disadvantages and discuss possible alternatives or extensions.

213



Whitebox Reuse

Applications that are developed with the help of a program framework are often constructed by specializing the library classes.

Whitebox reuse means that the software developer has and needs to have access to the program parts to be reused.

214

Disadvantage:

The provider of the framework cannot change the implementation of the framework without affecting the existing applications developed with it.



Possible solutions:

• Graybox approach (BW97):

◦ develop and use better encapsulation and interface specification techniques.

• Blackbox components:

◦ capture the generic architecture that should be supported

◦ are fully encapsulated and can only be accessed through a well-defined interface

◦ have a hidden implementation

◦ can be given in a binary format (programming language independent)

215



Program Language Limitations

Program frameworks share the inherent limitations of using one fixed language.

The construction of systems running on multiple platforms is limited by:

• Interprocess communication and communication with programs written in different languages.

• Support for configuration and deployment of system parts.

• Component compatibility and versioning.

• Support for persistent data in a programming language independent and portable way.


5.2 A Program Framework for User Interfaces 217

5.2 A Program Framework for User Interfaces



5.2.1

“Architectural Properties of Graphical User Interfaces”

5.2.2

“The Abstract Window Toolkit of Java”



5.2.1 Architectural Properties of Graphical User

Interfaces

219



Graphical User Interfaces

A graphical user interface should enable a user-friendly and flexible interaction between an application and its users.

220

A GUI has three main tasks:

1. It should allow to control the application.

2. It should allow to enter data for the application.

3. It should enable to present the state of the application and the results of operations performed by the application in a graphical way.



A program framework for GUI implementation has to provide:

• GUI components (e.g. buttons, text fields, checkboxes),

• techniques to show and arrange the GUI components on the screen (e.g. to layout several buttons in an area of a window),

• a mechanism to link operations of the application kernel to the actions performed on the GUI (e.g. the mouse click on a button has to be linked to the operation that should be performed in reaction to the click).

• an execution model supporting simultaneous user actions.



MVCPattern

The classical pattern underlying graphical user interfaces is the model-view-controller pattern or MVC-pattern .

It distinguishes three kinds of components:

• The model represents the underlying application kernel and captures the state of the GUI It provides the interface to the core functionality of the application.

• The views display the model or part of it on the screen.

Thereby the model becomes accessible to the user.

• The controllers control the interaction between users and the model.



User

:View

<<computation>>

4:read data

:Controller

<<computation>> system environment system of interest

1:notify about

events

2a:update

3:notify about

state changes

2b:call operations

4:read data

:Model

<<computation>> system of interest system environment

Application

223



The MVC-pattern is not fixed.

Variations can e.g. affect

• the relation between views and controllers:

(a) Is there always a one-to-one mapping?

(b) Can there be a controller that is associated with several views?

• or pertain to the execution model.

224



For the purpose of this chapter, two things are important:

1. The construction of GUIs involves

◦ the management of views,

◦ the management of the consistency between model and views,

◦ and a mechanism to handle the possibly concurrent events.

2. It should have become clear how the pattern structures the core functionality of a GUI into different system components.

225



5.2.2 The Abstract Window Toolkit of Java

226



The Abstract Window Toolkit , AWT for short, is the basic program framework that Java provides for the implementation of GUIs (the Swing toolkit is an extension of it).

It consists of more than a hundred classes.

The following paragraphs give an overview of the AWT and discuss its relation to the MVC-pattern and in what respects it supports reuse.



Overview of the AWT

Like other GUI toolkits, the AWT is organized around a class hierarchy of GUI components .

GUI components are used to

• construct views,

• support event-handling,

• provide a mechanism to register so-called listeners.



Object

Component

Canvas

Label

Button

List

Choice

CheckBox

Scrollbar

TextComponent

Container

ScrollPane Window

Frame Dialog

Panel

Applet

FileDialog

TextArea TextField

229



GUI components that are instances of class container or its subclasses are called container, all others are called elementary components.

230

Characteristics of containers:

• GUI components can be added to and removed from a container.

• If a GUI component CP is contained in a container CT, then the representation of CP on the screen is contained in the representation of CT.

• The containment relation forms a hierarchy.



Characteristics of windows :

• Containers that are not included in other containers are called windows.

• Windows can be handled by the window manager of the platform on which the GUI is running, e.g. they can be moved, resized, and iconified.

• The main window of an application is called a frame ; all other windows have to be registered with this frame to coordinate the event-handling.

231



The programmer has essentially three mechanisms to influence the graphical representation of the GUI components.

1. Depending on the component type, she can customize some of its attributes, e.g. the title of a window or the label on a button.

2. She can override the method that draws the GUI component on the screen (only for special situations).

3. For each container, she can determine a layout manager.

232



The AWT provides a mechanism for event-handling similar to the MVC-pattern:

• Events occur at some GUI component CP.

• To get notified about the events occurring at CP, one has to register a listener object at CP.

• If an event of sort S occurs at CP, CP notifies all listener objects of type S that are registered at CP.

• The listener objects correspond to the controllers.

• The programmer of a GUI can provide the method that is executed when a listener is notified about an event.

233



Part of the flexibility of the AWT event-handling mechanism comes from the fact that

1. a listener object can be registered at more than one GUI component and

2. several listener objects can be registered at the same GUI component.



Shades of Reuse

If a programmer uses the AWT to implement a graphical user interface, he does not have to know

• how to refresh windows,

• how to render GUI components on the screen,

• how to make containers react to resize events,

• how to associate events with GUI components, and

• how to integrate all these features in a smooth way.

The knowledge about these aspects is captured in the architecture and implementation of the AWT.

235



Simple GUIs can be built from the classes of the AWT almost without specialization.

236

Outline:

1. Construct the views from the GUI components.

2. Connect the GUI components to the application kernel by implementing listener classes.

3. Register the listener objects with the GUI components.

In this case, the components, the graphics classes, and the event-handling mechanism are used in a blackbox fashion.



Specialization and inheritance, i.e. techniques based on whitebox reuse, are needed for extending the core functionality of the AWT.

Typical cases are

• the realization of specialized or compound GUI components

• and the refinement the event mechanism.

237



Example (GUI of a calculator):

As an example application, we consider a simple calculator for adding and subtracting integers.

238



In this example, the application and its GUI are implemented within one class mixing aspects of view, controller, and model.

The object of class CalculatorFrame represents the view and is used as a listener for the three buttons.

The method actionPerformed that handles the button events also includes the application code.

package framework; import java.awt.*; import java.awt.event.*; public class CalculatorFrame extends Frame implements ActionListener {

TextField tfop1, tfop2;

Label lbres;



CalculatorFrame(){ setLayout( new GridLayout(4,1) );

// input fields add( tfop1 = new TextField("",15) ); tfop1.setEditable( true ); add( tfop2 = new TextField("",15) );

// buttons to trigger operations

Panel p = new Panel( new GridLayout(1,3) );

Button bt; p.add( bt = new Button("add") ); bt.addActionListener(this); p.add( bt = new Button("sub") ); bt.addActionListener(this); p.add( bt = new Button("close") ); bt.addActionListener(this); add( p );

// label to show the result add( lbres = new Label("") ); setSize( 200, 120 ); setVisible( true );

}


240

5.2 A Program Framework for User Interfaces public void actionPerformed( ActionEvent e ) { try {

String buttonlabel = ((Button) e.getSource()).getLabel(); if( buttonlabel.equals("close") ) System.exit( 0 ); int op1 = Integer.parseInt( tfop1.getText() ); int op2 = Integer.parseInt( tfop2.getText() ); if( buttonlabel.equals("add") ){ lbres.setText( String.valueOf(op1 + op2) );

} else if( buttonlabel.equals("sub") ){ lbres.setText( String.valueOf(op1 - op2) );

}

} catch( NumberFormatException nfe ) {}

}

} public static void main(String argv[]) { new CalculatorFrame(); }

241



The example should show that the AWT does not prescribe the special architecture of the GUIs constructed by it.

The AWT allows to merge application, model, controller, and view into one class.

This flexibility can be misused:

• For small applications, this flexibility can be helpful.

• For larger applications or for applications where an evolution is probable, such unstructured implementations can become unmanageable.

242



In summary, a program framework like the AWT can fix some architectural decisions and leave other aspects of architectural design open.

Several attempts have been made to design frameworks that support more powerful architectural patterns, in particular patterns for whole application systems.

An example is the ET++ application framework. In such frameworks, the architectural reuse can achieve the same importance as the reuse of code.


6 Architectures for Component

Software


6.1

“Component Frameworks: An Introduction”

6.2

“Microsoft’s Component Object Model”

6.2.1

“Component Model”

6.2.2

“Component Infrastructure”

6.2.3

“Further Features of the COM Framework”

6.3

“Enterprise JavaBeans”

6.3.1

“Component Model”

6.3.2

“Component Infrastructure”


245

246

Component frameworks support the composition of software systems from concrete software components.

Software components are well-defined entities of their own that can be provided by other development groups or companies.

In particular, component technology is important to create a market for prefabricated software.

Component frameworks have three main goals:

• Reuse of software components

• Providing the basis for a market of software components

• Role separation


247

Component frameworks enable to separate the responsibility of developing and managing a software system into five roles:

• component provider,

• framework provider,

• application provider

(constructs an application from components),

• application deployer (installs an application on a platform),

• system administrator.

Role separation is important for division of labor, specialization, and better competition in the software market.


6.1 Component Frameworks: An Introduction 248

6.1 Component Frameworks: An Introduction



The

“compound object pattern”

provides the conceptual basis for component frameworks.

249

In this context, the term components refers to software components consisting of concrete

“program parts and data” .

Components are the units of composition in the context of a component framework.

The goal of component frameworks is the blackbox reuse.

Inspection of the component’s implementation by the user should be unnecessary.



Composition Techniques

A component framework provides the mechanisms to stick components together.

We can distinguish three kinds of composition mechanisms :

• Static linking of components, i.e. the components are linked together before they are executed.

• Dynamic linking of components, i.e. some components are linked at runtime into an executing process.

• Connecting of components that run as parts of different processes.



Component Frameworks

The glossary of ”Component Software: Beyond object-Oriented Programming” by Clemens Szyperski gives an explanation of the term “component framework”:

251

“A component framework is a collection of rules and interfaces ( contracts ) that govern the interaction of components plugged into the framework. A component framework typically enforces some of the more vital rules of interaction by encapsulating the required interaction mechanisms.”



As the general goal is to compose software systems from prefabricated components, a component framework has to give answers to the following three questions:

252

• Component model: What is a component?

• Component infrastructure: What are the infrastructure and the technical support for deploying and composing components?

• Further features: How are further requirements supported by the component framework?



The component model essentially consists of rules specifying

• what kinds of components are supported,

• what constitutes a component,

• and what the properties of components are.

Many of the rules are usually syntactic.

But, there may be as well semantic rules.

Components are described with the help of some languages

(e.g. programming or assembly languages).



The component infrastructure

• explains how components are composed and deployed

• describes the rules

◦ how a component finds other components by name,

◦ how components are linked to each other,

◦ and how they can communicate

• specifies interfaces that allow to inspect components at runtime

• may provide mechanisms to startup and initialize remote components

254



• may comprise library code that components need to connect to other components

• may define standardized platform components for composed systems

• may specify tools for composition and deployment

255

Component frameworks often support further features , like:

• support for persistence,

• security mechanisms.



Different Kinds of Frameworks

Component frameworks can be independent of requirements of specific application domains.

They can support general architectural patterns (e.g. the

EJB framework primarily supports the construction of software systems according to the three-tier architectural pattern).

They can be developed for more specific application areas.

In that case, the component model and infrastructure are specialized to that area. Often predefined components are provided.

256



The RMI (remote method invocation) in Java is a communication infrastructure.

257

• It provides library classes, interfaces, and services to connect to remote objects and invoke their methods.

• It can be used to build up a component infrastructure, but it is not a component framework

• A component model is missing.



The AWT is a typical program framework.

The subclasses of class Component can be considered as components.

A component infrastructure providing rules and techniques for composition and deployment is missing.

258

Improvement: the JavaBeans framework building on AWT, which

• defines rules and conventions that specify component interfaces,

• provides an event-based composition mechanism.


6.2 Microsoft’s Component Object Model


259


6.2 Microsoft’s Component Object Model 260

The Component Object Model (COM) is the name of

Microsoft’s basic component framework.

• COM is directly used in many areas.

• It provides the foundation for more specialized frameworks like e.g. Microsoft’s compound document standard OLE.

• COM is available on Windows and other operating systems

(e.g. Mac OS, some UNIX operating systems).

In the following, we will not distinguish between COM and

Distributed COM (DCOM), an extension to COM that allows network-based component interaction.



COM is a framework to compose software systems on a binary level.

In particular, components written in different programming languages can interoperate.

To make this work, the interfaces of components can be described by an interface description language called IDL.

261



6.2.1 Component Model

COM distinguishes between

• COM class : the software that implements a component

• COM object : the instance of a component class

262

A COM class

• can be implemented as a class written in an object-oriented language,

• can consist of many classes or some procedural code,

• provides the implementation for its instances and supports their creation.



A COM object

• is not necessarily a pure object in the sense of an

OO-language, i.e. an object with a fixed number of instance variables and methods,

• can be realized by many pure objects of different types or by other data structures.

• may have state, provides a mechanism to be compared for identity, and is only accessible over well-defined interfaces.

Like in Java, an interface has a name and describes the signature of the procedures/methods provided by (pure) objects implementing the interface.



Example (COM component model):

Let us consider a COM class that provides the interfaces

IOnlyA, IAlsoBC, and IService: interface IOnlyA extends IUnknown { int doOpA( ... );

} interface IAlsoBC extends IOnlyA { int doOpB( ... ); int doOpC( ... );

} interface IService extends IUnknown { int doOpD( ... );

}


264


Client 1 with variable of type

IOnlyA

Client 2 with variables of type

IOnlyA

IOnlyA

IService obj1: ClA obj2: ClA obj3: ClABC obj4: ClAD

COM object obj5: ClImpl obj6: ClOther obj7: ClFoo

265



A COM object is a collection of pure objects.

The pure objects that can be referenced from the outside are called the interface objects of the COM object.

class ClA extends ClUnknown implements IOnlyA { int doOpA( ... ) { ... }

} class ClABC extends ClUnknown implements IAlsoBC { int doOpA( ... ) { ... } int doOpB( ... ) { ... } int doOpC( ... ) { ... }

} class ClAD extends ClA implements IOnlyA, IService { char doOpD( ... ) { ... }

}



This example shows that

• one interface object can be referenced by several clients,

• an interface object can be used to provide the functionality of an interface containing only a subset of the methods

• the same interface can be provided by several interface objects,

• a COM object comprises internal objects to implement the functionality of the interface objects.



The explanations above sketch the conceptual component model of COM.

Technically , to be a binary standard, COM defines a standard binary layout to realize the conceptual model.

In this binary layout, the interface objects are implemented by records that are called interface nodes .

The first entry of these records contains a pointer to a record of function pointers referring to the interface operations.

Whereas Java only allows input parameters, COM supports output parameters as well.



6.2.2 Component Infrastructure

269



In general, the component infrastructure describes the rules and techniques for deploying and composing components.

Here, we focus on the mechanisms that COM provides for composition, i.e. for linking or connecting components.

The basic situation is that a client looks for a service characterized by an interface IF.

There are two alternatives:

1. The client already has a reference to a COM object that provides IF.

2. The client knows a COM class the objects of which provide IF.

270



Querying COM Objects for Interfaces

Supposal: A client has a reference to a COM object X .

Scope: Use this reference to query for other interfaces that

X provides.

Solution: COM supports a naming mechanism for interfaces based on globally unique identifiers (IIDs).

All COM objects have to implement the predefined interface

IUnknown, defined as: interface IUnknown {

HRESULT QueryInterface( IID iid, out IUnknown qif ); long long

AddRef();

Release();

}



The client can use its reference to X to call method

QueryInterface.

Method QueryInterface

• takes an IID as input and checks whether X implements that interface,

• returns a result of type HRESULT indicating whether the check was successful, and if not, why it failed,

• uses the output parameter qif to return the reference to an interface object A that implements the queried interface.

As all COM objects must implement the IUnknown interface, the identity of the corresponding interface object can be used to identify the entire COM object.



Creating COM Objects

We explain the mechanism to create COM objects and to get a reference to one of its interface objects.

This mechanism is based on three different features of the

COM framework:

• Support for unambiguous identifiers of COM classes

(CLSIDs).

• The COM library that is linked to the client code

(procedure CoCreateInstance is called to create a COM object).

• A system registry to find COM classes.

273



Similar to pure OO-programming, the creation of COM objects is done by COM classes. To identify COM classes, the COM framework provides the notion of class identifiers

(CLSIDs).

The usual way to create a COM object is to call the COM library procedure CoCreateInstance.

The procedure CoCreateInstance

• takes a CLSID and an IID as arguments,

• tries to create an instance of the COM class CLSID,

• returns a reference to an interface object of the created

COM object that implements the requested interface IID.

274



A COM server

• comprises the implementation of one or more COM classes,

• contains a so-called class factory for each implemented

COM class.

The class factory is a COM object that implements the creation of instances of the associated COM class. For this purpose, the class factories provide the interface

IClassFactory.



From the view point of a client, there are three different kinds of servers.

• An in-process server runs in the same process as the client.

• A local server runs on the same machine as the client, but in a different process.

• A remote server runs on a different machine as the client.

The creation of a COM object involves several steps.

The client calls the procedure CoCreateInstance with

• class identifier cid

• interface identifier iid

• optional parameters indicating the preferred kind of server.



The system registry is consulted to locate a server implementing cid.

This results in one of the following cases:

• There is no appropriate server registered for class cid.

• There is an appropriate server registered, but this server is not running. In that case

◦ the server is started or dynamically linked to the client process,

◦ the class factories are created,

◦ references to IClassFactory are entered into the system registry.

◦ the process continues as in following case.



• There is an appropriate server registered that is running.

◦ CoCreateInstance uses the reference to interface IClassFactory stored in the registry to create a corresponding COM object.

◦ It queries the COM objects for the interface iid.



In case of local and remote servers, additional support has to be provided by the COM framework for transparent communication across process boundaries or across machine boundaries.

For this purpose, COM uses techniques similar to those of the remote method invocation mechanism of Java or

CORBA.



6.2.3 Further Features of the COM Framework

The COM framework provides a number of further features that simplify the composition of systems from components.

280



Cooperative garbage collection by reference counting:

• Based on the methods AddRef and Release of IUnknown.

• Before the first reference to an interface object is handed out to a client, the count is set to one.

• It is automatically incremented when another reference to that interface object is passed out.

• If a client stores an interface reference to an additional variable or if it passes the reference to some other client, the client calls AddRef to increment the reference count.

• The method Release is called when a reference is released.

When reaching zero, the interface object is deallocated.



Object reuse can be achieved by composition of COM objects. Essentially there are two different techniques:

• Containment: A COM object X can encapsulate another

COM object Y .

◦ The interface objects of Y become internal objects of X .

◦ Method calls to the interface objects of X can be forwarded to these internal objects.

• Aggregation: Several COM objects Y

1

, .., Y n are composed to form a new COM object X

◦ the interface objects of the Y i become the interface objects of X .

◦ Only the implementation of IUnknown of X has to be newly designed to reflect all the interfaces that are provided by Y

1

, .., Y n

.



Further reading:

Chapter 14 of:

Clemens Szyperski.

Component Software:

Beyond Object-Oriented Programming.

Addison-Wesley, 1997.

It describes

• a technique to specify families of interfaces,

• support for persistence,

• and other COM services.


283

6.3

Enterprise JavaBeans

6.3


284


6.3

Enterprise JavaBeans 285

The Enterprise JavaBeans framework is a component framework developed by Sun Microsystems.

It supports the realization of application servers according to three tier architectural pattern.

Definition (application server):

An application server is a software system that provides services for (remote) clients .

The persistent data involved in such services is usually managed by databases .


6.3


The tasks of an application sever are:

• Accepting and maintaining the connection to clients.

(authorization and security mechanisms, control over the client sessions).

• Reading and writing data from and to the database.

• Transaction mechanisms.

• The core functionality of the supported services.

286


6.3


Client

Home Remote

Session Bean

EJB Container

Home Remote JNDI

JTA

JDBC

Entity Bean

JNDI

JTA

JDBC

Standard API

Name Service

TA-Monitor

Database

Other Sevices

Server


287

6.3


In the following, we describe

• the component model, i.e. what beans are and how they are described, and

• the infrastructure to deploy and work with beans.

288

Further reading:

Enterprise JavaBeans Specification


6.3


6.3.1 Component Model

289


6.3


The Enterprise JavaBeans are the components from which a so-called application assembler constructs a server-side application.

The resulting application is deployed in an EJB container.

After deployment, it is available to clients.

The application and thus the beans can use the mechanisms of the underlying container like:

• transaction mechanisms,

• control for persistence,

• security services,

• etc.


6.3


Bean Species and Parts

The beans are the units of composition in the EJB framework, i.e. the components. We speak of

• bean instances : These are the runtime objects. A bean instance might consist of more than one pure object.

• bean components : This is the software implementing their functionality. A bean component comprises more than one pure class.

There are two different kinds of beans: Entity beans and session beans. In the following, we explain their characteristics and the parts a bean component consists of.


6.3


Entity beans essentially represent the data objects handled by the system (e.g. bank accounts, products, assurance policies, orders, or employees).

An entity bean instance usually corresponds to what is called an entity in the literature about entity-relationship modeling and data base systems.

Entity bean instances are usually persistent. The programmer of the bean can choose between

• bean-managed persistence: persistence mechanisms implemented by programmer;

• container-managed persistence: persistence is managed automatically by the container.


6.3


An entity bean instance can be accessed by different clients communicating with the application sever.

The instance is logically identified by a so-called primary key .


6.3


Session beans are used to model tasks, processes, or behavior of the application server.

A session bean corresponds to a service for a client.

A session bean instance is a private ressource of a client.

The framework distinguishes between

• stateless beans and

• stateful beans , which have a state that is maintained between method invocations. The state is not persistent.

294


6.3


A bean component consists of four or five parts:

• the remote interface,

• the home interface,

• the primary key class (only for entity beans),

• the bean class, and

• the deployment descriptor.

295

We will explain these parts in turn by a simple example of an entity bean representing a bank account.


6.3


The Remote Interface

The remote interface defines the methods that the entity bean provides to the client.

It reflects the functionality of the bean.

296

The bank account bean of our example allows one

• to ask for the number of the account,

• to query for the balance,

• and to change the balance by a positive or negative amount.


6.3

Enterprise JavaBeans public interface BankAccount extends EJBObject {

String getAccountNumber() float getBalance() throws RemoteException; throws RemoteException; void changeBalance(float amount) throws RemoteException;

}

EJBObject is a supertype of all bean instances.

In order to support remote method invocation, it is a subtype of type Remote.

297


6.3


The Home Interface and Primary Key Class

The home interface defines the methods concerning the lifecycle of the bean.

298

The client uses this interface

• to create bean instances,

• to find them,

• and to remove them.

In our example, the home interface defines two methods to create and find an account:


6.3

Enterprise JavaBeans public interface BankAccountHome extends EJBHome {

BankAccount create(String accNo, float initBal) throws CreateException, RemoteException;

BankAccount findByPrimaryKey(BankAccountPK accPK) throws FinderException, RemoteException;

}

Home interfaces have to extend interface EJBHome which contains a method to delete a bean and, as a subtype of

Remote, the functionality for remote method invocation.

299

The method findByPrimaryKey plays a special role in the

EJB framework. It has to take a as parameter. Its return type has to be the type of the corresponding remote interface.


6.3


In our example, we use the account number as primary key.

300 public class BankAccountPK implements java.io.Serializable { public String accountNumber;

} public BankAccountPK(String accNo){ accountNumber = accNo; } public BankAccountPK() { accountNumber = new String(); } public int hashCode() { return accountNumber.hashCode(); } public boolean equals(Object obj) { return accountNumber.equals(obj);

} public String toString() { return accountNumber; }

The specification of the EJB framework requires primary keys to be serializable.


6.3


The Bean Class

The bean class provides implementations for the methods of the home and remote interface. The only exception is the method findByPrimaryKey which is provided in the deployment process.

The bean class must not be a subtype of the home and remote interfaces, i.e. it does not “implement” the interfaces in the sense of Java.

It has to provide implementations for their methods.

The connection between the bean class and the interfaces will be established during deployment.


6.3

Enterprise JavaBeans public class BankAccountBean implements EntityBean { public String accountNumber; public float accountBalance; private EntityContext theContext;

// corresponds to create method of home interface: ejb+create public BankAccountPK ejbCreate(String accNo, float initBal) throws CreateException, RemoteException { accountNumber accountBalance return null;

= accNo;

= initBal;

}

// methods implementing the remote interface public String getAccountNumber() throws RemoteException { return accountNumber;

} public float getBalance() throws RemoteException { return accountBalance;

}


302

6.3

Enterprise JavaBeans public void changeBalance(float amount) throws RemoteException { accountBalance += amount;

}

// the methods of interface javax.ejb.EntityBean

public void setEntityContext(EntityContext ctx) throws RemoteException { theContext = ctx;

} public void unsetEntityContext() throws RemoteException { theContext = null;

}

} public void ejbRemove() throws RemoteException, RemoveException {} public void ejbActivate() throws RemoteException {} public void ejbPassivate() throws RemoteException {} public void ejbLoad() throws RemoteException {} public void ejbStore() throws RemoteException {}


303

6.3


Bean classes have to implement the interface EntityBean of the EJB framework.

The methods of this interface manage the communication between the bean and the container.

304

For example the method setEntityContext allows the container to store so-called context information into the bean. This context information is used by the container to manage the identity of bean instances.


6.3


The Deployment Descriptor

The deployment descriptor

• describes the different parts of a bean and the runtime properties like e.g. whether persistence is container- or bean-managed,

• allows to combine several beans into one unit,

• describes external dependency (e.g. to databases or external beans),

• provides deployment information (e.g. access rights specifying who has the permission to invoke a method).

Deployment descriptors are defined in an XML format.

305


6.3


Here is a very practical example where a component framework uses a description language with formal syntax to capture architectural relations and properties.

The descriptions are later used to deploy the software systems in a semi-automatic way.

<?xml version="1.0" ?>

<!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.

//DTD Enterprise JavaBeans 1.2

//EN http://java.sun.com/j2ee/dtds/ejb-jar_1_2.dtd>

<ejb-jar>

<description> deployment descriptor of entity bean BankAccount

</description>


6.3


<enterprise-beans>

<entity>

<description>

BankAccount represents a bank account.

</description>



<ejb-name>BankAccount</ejb-name>



<home>ejb.samples.accounts.BankAccountHome</home>



<remote>ejb.samples.accounts.BankAccount</remote>



<ejb-class>ejb.samples.accounts.BankAccountBean

</ejb-class>



<persistence-type>Container</persistence-type>



<prim-key-class>ejb.samples.accounts.AccountPK

</prim-key-class>


307

6.3




<primkey-field>accountNumber</prim-key-field>



<reentrant>False</reentrant>



<cmp-field>

<field-name>accountNumber</field-name>

</cmp-field>

<cmp-field>

<field-name>accountBalance</field-name>

</cmp-field>

</entity>

</enterprise-beans>

<assembly-descriptor>

<security-role>

<description>The role of bank employees</description>

<role-name>banker</role-name>

</security-role>


308

6.3




<method-permission>

<role-name>banker</role-name>

<method>


<method-name>*</method-name>

</method>

</method-permission>



<container-transaction>



<method>


<method-name>increaseBalance</method-name>

</method>

<trans-attribute>Required</trans-attribute>

</container-transaction>

</assembly-descriptor>

</ejb-jar>


309

6.3


Further Aspects

In summary, the component model of the EJB framework is based on

• Java interfaces and classes

• and an XML document describing the relationship and properties of the part.

310

I.e. it is a programming language dependent model.


6.3


The EJB specification contains a fairly large number of conventions and rules which

• make it possible that the parts can work together seamlessly,

• allow for the communication with the underlying container,

• make the beans to a large extent independent of the special implementation of the container.


6.3


In the following, we provide some more rules:

• A bean must not return the implicit parameter “this” as result of a method or pass it as a parameter.

• Static variables are forbidden in bean classes.

• Use of threads and synchronization mechanisms is not allowed.

• Use of GUI facilities as well as input- and output-operations are forbidden.

• Use of introspection and reflection must be avoided.

• Beans should not influence class loading and security management.

312


6.3


The basic reason underlying these restrictions is to create a well-defined interface between the components and the container.

313

This interface has to take behavioral and security aspects into account. E.g.

• deadlocks have to be avoided,

• the access rights of beans have to be restricted so that they cannot manipulate the data of other beans.


6.3


6.3.2 Component Infrastructure

314


6.3


The backbone of the EJB component infrastructure is the

EJB container.

A bean instance can only exist within a container.

The container is the runtime environment for bean instances and provides the

“necessary services” , in particular:

• a naming service,

• a transaction monitor,

• access to a database,

• and Java Mail service


6.3


Managing Beans

The major task of the EJB container is to control the lifecycle of bean instances.

It creates and removes instances.

In addition, it is responsible for an efficient management of bean instances:

• Many containers provide mechanisms to passivate and reactivate instances by temporarily storing them on disk.

• Pooling of instances allows to reuse an instance thereby avoiding removing an instance and afterwards creating an equal instance again.

316


6.3


• Support for load balancing between different containers: If one container is very busy, use another less frequented container.

• Mechanism to access beans by name. Containers use the

Java Naming and Directory Interface which is an extension to the naming mechanism underlying RMI.


6.3


Persistence, Transactions, Security

EJB containers have to support a mechanism that is called container-managed persistence.

An entity bean with container-managed persistence relies on the container to perform persistent data access on behalf of the bean instances. The container has to

• transfer the data between the bean instance and the underlying database,

• implement the creation, removal, and lookup of the entity object in database,

• manage the mapping between primary key and EJBObject.


6.3


Transactions ensure data consistency, taking into account failure recovery and multi-user programming.

319

The EJB framework supports distributed transactions: An application can automatically update data in multiple databases which may be distributed across multiple sites.

In case of container-managed transaction demarcation, the container demarcates transactions according to instructions provided by the application assembler in the deployment descriptor.


6.3


These instructions describe e.g. whether the container should run a method

• in a client’s transaction,

• in no transaction,

• or in a new transaction that the container has to start.

320

In order to support such mechanisms, the EJB framework comprises a transaction model.


6.3


The EJB framework provides several mechanisms to secure the applications assembled from the beans.

The container provides the implementation of a security infrastructure that can be controlled by so-called security policies.

321

It is important to have a clear separation between

• application code, i.e. beans,

• and security code, i.e. the security infrastructure of the container and the security policies.

These parts are connected only at deployment time.


6.3


Deployment of Beans

We consider the question of how beans are deployed in containers .

The container developers have to provide tools for the deployment of beans.

For each bean X , the tools take the bean sources as input and generate two classes:

• a class X Home implementing the home interface

( EJB home objects)

• and a class X Object implementing the remote interface

( EJB remote objects).


322

6.3


Primary Key Class

Home Interface

Bean Class

Deployment Descriptor

Remote Interface implements

EJB Home

Container-

Tools generates

EJB Object implements


323

6.3


The EJB home and remote objects

• encapsulate the bean instance:

◦ A client can only access a bean by invoking methods of the home and remote objects.

◦ These objects delegate the client’s method invocations to the bean instance.

• perform operations realizing important tasks of the container:

◦ ressource management,

◦ security mechanisms,

◦ transactions handling,

◦ persistence management.

324


6.3


Client

RMI

Home Interface

Remote Interface

EJB Home Object EJB Remote Object

delegated invocations

Bean Instance

EJB Container

Server


325

6.3


It is important that the EJB framework supports such a delegation and encapsulation technique:

• This way, the container has control over bean instances and can prevent incorrect or malicious access to beans.

• It is the basis to relate the component infrastructure to the components.

• It frees the bean developers to a large extent from taking infrastructure issues into account.

A bean instance is always accessed through its home and remote object. This also holds for the communication among beans.


6.3


Using Beans

To illustrate the usage of beans let us consider the example of the bank account.

A client wishes to access an instance of the

BankAccount-bean.

He has to know the name by which the bean is made accessible in the container.

Usually, this is the name of the bean as given in the deployment descriptor. In our example, the name was

“BankAccount”, and we assume that the bean is accessible under the name “java:comp/env/ejb/BankAccount”.

327


6.3


The following fragment shows the essential steps to access and use a bean:

String BANK_ACCOUNT = "java:comp/env/ejb/BankAccount";

InitialContext ctx = new InitialContext();

Object o = ctx.lookup(BANK_ACCOUNT);

BankAccountHome bh = (BankAccountHome)

PortableRemoteObject.narrow(o,BankAccountHome.class);

BankAccount ba = bh.create("23456735",0.0); ba.changeBalance(32.00);

The creation of a new empty bank account leads to the creation of

• a bank account instance,

• an entity in the underlying database,

• a primary key object, associated with the bean instance.

328


6.3


In summary, we can see that the use of beans is very similar to the use of remote objects. The management of beans by the container is hidden to the client.


7 Description Techniques for

Architectures


7.1

“Unified Modelling Language: An Overview”

7.1.1

“UML Diagrams”

7.1.2

“UML Class Diagrams”

7.1.3

“UML Interaction Diagrams”

7.1.4

“Unified Modeling Language as ADL”

7.2

“Architectural Frameworks”

7.2.1

“An Introduction to Architectural Frameworks”

7.2.2

“A Tiny Architectural Framework”

7.3

“Connectors in Architectural Descriptions”


331

332

The central result of the design phase for a software system is its architecture.

Goal: Define appropriate notations for capturing and expressing this result in a precise way.

It is required to describe software architectures

• on the right level of abstraction,

• in a standardized way to ease communication between the users of the architectural description,

• based on techniques and tools that allow for

◦ consistency checking,

◦ visualization,

◦ and code generation.


333

Architectural descriptions can be compared to programs.

Programming languages

• must allow for the description of efficient implementations,

• provide constructs for the description, of components

• are used for communication between man and machine.

Architectural descriptions

• must allow for the description of abstract concepts,

• concentrate on the connections between components

(treated by their abstract interface properties) and their interaction.

• are essentially used for the communication between people.


7.1 Unified Modeling Language: An Overview 334

7.1 Unified Modeling Language: An Overview



The Unified Modeling Language (UML) comprises a number of notations to support object-oriented analysis and design.

The syntax and meaning for these notations is standardized by the Object Management Group (OMG).

A clear

“architectural framework”

for UML is still under research.

UML is of interest because of its practical relevance.



Literature:

Martin Fowler and Kendall Scott.

UML Destilled.


Grady Booch, James Rumbaugh, and Ivar Jacobson.

The Unified Modeling Language User Guide.


336



7.1.1 UML Diagrams

337



UML is based on graphical notations, so-called diagrams .

Some diagrams describe a software system from the dynamic view (Use case and behavior diagrams).

Other diagrams describe it from the static view (class and implementation diagrams).



Here is an overview over the different kinds of diagrams:

• use case diagram

• class diagram

• behavior diagrams:

◦ statechart diagram

◦ activity diagram

◦ interaction diagrams:

.

sequence diagram

.

collaboration diagram

• implementation diagrams:

◦ component diagram

◦ deployment diagram


339


Diagrams of the Static View

The central language construct of UML is the Class

Diagram.

“Class diagrams”

are used to express the structure of the main abstractions of a software system, in particular the relation between classes and types in an object-oriented design.

340



Implementation diagrams show aspects concerning the structure of software components, including source code structure and runtime implementation structure.

There are two forms:

1.

Component diagrams show the structure of code itself.

2.

Deployment diagrams show the configuration of runtime processing nodes, their connections, and the components that live on them.

341



Diagrams of the Dynamic View

Use case diagrams show actors and use cases together with their relationship.

Actors are

• users of the system to be modeled or

• system components of the environment.

Use cases describe typical scenarios how a system is used.

In the

“bank application example” , actors are the bank

clients and the server of the underlying bank system.

Use cases are helpful to identify the main tasks of the system and its environment.

342



A statechart diagram can be used to describe the behavior of a model element such as an object or an interaction.

It describes possible sequences of states and actions through which the element can proceed during its life time as a result of reacting to concrete events (e.g. signals, operation invocations).

A

“statechart diagram”

is basically a hierarchical state machine with further annotations.



An activity diagram is essentially a flowchart.

Activity diagrams are based on a variation of the state machine notation such that

• the states represent the performance of actions or subactivities

• and the transitions are triggered by the completion of the actions or subactivities.

It can as well be used to describe the dynamic behavior of systems or system components.

344



Interaction diagrams are used to describe patterns of interaction among instances (objects or other model elements). They come in two forms:

• Sequence diagrams:

◦ show the explicit sequence of stimuli,

◦ are better suited for real-time specifications and for complex scenarios.

• Collaboration diagrams:

◦ show the relationships among instances,

◦ are better suited for understanding all of the effects on a given instance and for procedural design.

345



A collaboration diagram shows

• a set of objects,

• links among those objects,

• and messages sent and received by those objects.

An example of collaboration diagram is given and discussed in

“7.1.3” .

346



We used collaboration diagrams as a basis to describe

“process structures”

and

“architectural patterns” .

For these examples, we extended the core notation of UML collaboration diagrams by

• allowing class information to appear together with objects

(e.g. the attribute

“myBankAppl” );

•

“distinguishing”

between active (bold frame) and inactive objects;

• adding further information (e.g. the stereotypes “process”,

“thread”, “memory”, “computation”, etc.; and the shading of the components that trigger activity).



Further Notations and Features

UML provides further notations, as for example:

• Packages : allows to group arbitrary description elements into packages, name them, and specify their import and export relationships.

We used this notation for the

“bank application” .

• Interfaces : allows to separate the interface as it is implemented by a class from the interface that is exported for external use by an object.

E.g.

“obj3”

only exported interface IOnlyA to client 2, although it also implements interface IAlsoBC.



In addition to the diagrams, UML supports conventions about how to annotate and extend diagrams.

Based on these conventions, it often makes sense to combine notational aspects of different diagrams.

This flexibility is certainly an advantage of UML.



7.1.2

UML Class Diagrams

350



Class diagrams describe the types and classes of the relevant objects (e.g. customers, orders) and the different kinds of relationships among them.

The two central relationships are:

• Associations (e.g.: an order is given by a customer)

• Generalizations (e.g.: a customer may be a business customer or a private customer)

Class diagrams describe the attributes and operations of classes and some properties of their relationships.

Class diagrams essentially abstract from temporal information.



Example (Order Processing System):

As scenario, we consider a company with centralized headquarters and several agencies throughout the country.

• In the agencies, customers can order products.

• A sales clerk enters the customer and product name and the desired quantity into a computer.

• The clerk sends a request to the underlying system that computes and shows the price for this potential order.

• The customer acknowledges or cancels the order.

• Distinguish between business and private customers.

Business customers get credit and discounts.


352

7.1 Unified Modeling Language: An Overview customer name: String account(): Table

1 * request quantity: Int

*

1 order price: Int

0..1

1 product name: String regularPrice: Int business customer creditLimit: Int discount(): Int private customer

353



As seen in the

“bank application example” , there are two

types of whole/part relationship:

• Composition is a strong whole/part relationship.

◦ It is denoted by a filled diamond.

◦ An instance (called whole object ) of the class touched by the diamond is considered to be composed of the instances (called part objects ) of those classes that are linked to the other end of the diamond.

◦ The part objects are only parts of exactly one whole object

◦ The lifetime of part objects is restricted by the lifetime of the whole object.



• Aggregation is a weak whole/part relationship.

◦ It is denoted by an unfilled diamond.

◦ A typical example is the relation between a company and its employees.

◦ A part object can participate in more than one aggregation.

◦ The lifetime of part objects is independent of the lifetime of the whole object.



Meaning of Class Diagrams

Class diagrams can be used to express

• implementations:

◦ Classes in the class diagram correspond to classes in an object-oriented program, like in the

“AWT example” .

◦ Generalization often expresses an inheritance relation.

• concepts of the problem domain or interface spec:

◦ Associations are an abstract notion that can be very differently represented in implementations.

◦ They should be used for relationships that are necessary to understand the interaction between elements at the system level.

◦ Attributes are meant to express local properties.

356



As class diagrams do not have a fixed meaning, they can be used with different intentions.

357

Advantage:

A stepwise refinement process, from conceptual notions up to a precise class design, can be carried out based on one notation.

Disadvantage:

Danger of misunderstandings when the interpretation is unclear between partners in a communication.



7.1.3

UML Interaction Diagrams

358



Interaction diagrams are used to describe patterns of interaction among objects.

359

They show a set of objects and the messages and calls expressing the interaction.

They come in two forms:

• Collaboration diagrams : emphasize the organization of the objects that participate in an interaction.

• Sequence diagrams : emphasize the time ordering of the messages sent during the interaction.



Example (MVC Scenario):

Describe interaction in a model-view-controller scenario.

• The model has one view with an associated controller.

• The view allows users to enter data.

• The data is sent to the controller.

• If the data is not well formed, the controller opens a dialog window to explain what is wrong.

• Otherwise, it invokes doService-procedure of the model.

• The model creates a new view with associated controller, performs internal operations changing its state.

• Finally, it notifies all views and controllers.


7.1 Unified Modeling Language: An Overview v1:View

Collaboration diagram

1:dataEntered(d)

3:dialogClosed

4:dataEntered(d) c1:Controller

2:openDialog

14:readData

10:notifyChange

12:notifyChange

5:doService(d) m:Model

6:<<create>>

8:initialize

11:notifyChange

15:readData

7:<<create>>

9:initialize

13:notifyChange

16:readData v2:View c2:Controller


361


Sequence diagrams have two features that do not appear in collaboration diagrams:

• Each object has a lifeline that represents the existence of the object over a period of time.

• Sequence diagrams can express how the foci of control change between objects. A focus is denoted by a tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through subordinate operations by other objects.


7.1 Unified Modeling Language: An Overview v1:View

Sequence diagram c1:Controller m:Model dataEntered(d) openDialog dialogClosed dataEntered(d) notifyChange readData doService(d) notifyChange

<<create>>

<<create>> initialize c2:Controller initialize v2:View notifyChange readData notifyChange readData lifeline

363



7.1.4 Unified Modeling Language as ADL

364



The Unified Modeling Language was not developed as an architecture description language.

Its main goal is the support for the so-called unified object-oriented software development process.

Nevertheless, many authors use parts of UML to describe software architectures.

365

Advantages of UML:

• UML is standardized (although not in all details).

• UML is rather well-known by software developers.



Disadvantages of UML:

• Interplay of the different notations not clearly defined.

• There is no underlying architectural model that can serve as a semantic background for the different notations.

• UML does not support well-defined abstraction mechanisms between different descriptions.

• Component interaction is essentially method invocation.

• UML has weak support for hierarchical descriptions.

• UML does not provide techniques for parameterization.

• UML provides only informal mechanisms to capture global constraints and non-functional properties.


7.2 Architectural Frameworks


367



Architectural frameworks should integrate the concepts, notations, and constructs of architectural descriptions on a semantical basis.

368

Current research has developed different approaches to specify architectures, e.g.

“architecture description languages”

.

ADLs are of great help, but are not sufficient to capture the different issues and properties of software architectures.



It can be helpful to extend the framework idea to architectures, combining suitable techniques, mechanisms, language constructs, and predefined elements into a well-defined coherent framework.

369

Architectural frameworks can also help with the implementation.



7.2.1 An Introduction to Architectural Frameworks

370


7.2 Architectural Frameworks 371

We define an architectural framework to be:

• a collection of languages for architectural description with a well-defined semantics.

• a collection of styles, rules, invariants, and properties governing the use of the languages and their sentences.

• a definition of the constituent elements of an architectural description.

• a definition of what constitutes an implementation of an architectural description.

• optionally, a collection of predefined elements, services, standards, and tools (or tool specifications).



Architectural frameworks share several aspects with component frameworks.

However, architectural frameworks

• need not provide an explicit component model,

• are less implementation oriented and more descriptive,

• have to clearly define what the architecture of a composed system is,

• should support abstraction over their elements,

• should allow formal analysis of the descriptions.

In addition, techniques and tools to generate implementation parts from descriptions are welcome.



It is unlikely for one architectural framework to be suitable for all kinds of software systems. E.g. there may be different frameworks for embedded systems and application systems.

There may as well be domain or even company specific architectural frameworks.

There will be relations between architectural frameworks, e.g. one framework can be built on another one.

Future research, developments, and experiences will determine how the architectural frameworks will look like that will be used for the description of the complex software systems of tomorrow.



7.2.2 A Tiny Architectural Framework

374



Realistic architectural frameworks will have a similar complexity as component frameworks (e.g. the specification of the EJB framework has more than 700 pages).

375

Unfortunately, there exists no generally accepted and practical architectural framework that satisfies the above criteria.

To illustrate at least some aspects of the definition, we invent a tiny architectural framework, called TAF.



The TAF Architectural Framework

TAF is an architectural framework that allows the construction of simple software systems based on encapsulated components.

• The components are linked during system startup.

• TAF uses a graphical notation (GNOTAF) to describe the components.

• The type language of Java is used as an interface specification language.

• The execution model of Java is used as a semantical basis for the description of the components.

376



InterfaceTypeA getServer1()

InterfaceTypeB getServer2()

InterfaceTypeB getServer3()

*

1

Component-

Interface

2

1

* putClient1( InterfaceTypeA ) putClient2( InterfaceTypeC )

377



An architectural description according to TAF consists of:

1. a number of component interface specifications:

◦ The syntax should be described in GNOTAF.

◦ The behavior of the components can be described informally based on the Java execution model.

2. the topology of the architecture which specifies

◦ the number of component instances participating in the architecture,

◦ the names of the instances,

◦ and how they are linked.

3. the startup order given as a list of instance names, i.e. the order in which to start the component instances.



TAF components behave like encapsulated Java code (i.e.

they can be implemented in any programming language as long as the behavior can be simulated by a corresponding implementation in Java).

379

Component instances may have local state, may be passive, or may execute one or more threads.

The only way to access an instance and its local state is by using the interface methods; in particular instances do not share objects.



Runtime model of TAF compliant architectures:

1. The component instances are created.

2. The component instances are linked using the link methods.

◦ A reference to a server port SP is obtained by invoking the method getSP.

◦ This reference is linked to a client port CP of another instance by invoking the method putCP on that instance.

3. The instances are started according to the startup order defined in the architectural description.

◦ For startup, component instances have to implement a start method that might perform some initialization and create some threads.



An implementation of a TAF architectural description A consists of:

1. At least one implementation for each component interface specification of A . Each component implementation is represented by a so-called class name.

2. The specification of the component constructors.

3. A mapping of the instance names occurring in the topology to class names.



A TAF Architectural Description and

Implementation

We demonstrate the application of the TAF framework by a simple formating system that

• reads characters from a file,

• eliminates multiple whitespace characters,

• and formats the input to lines of forty characters.

For illustrative reasons, the system is realized as a pipe and filter architecture.

The interface ports implement the Reader and Writer interfaces defined in the Java IO-library.

382



Writer getWriter()

1

CharPipeCO

1

Reader getReader()

FileInputCO

1 putWriter( Writer )

putReader( Reader )

1

ElimWhiteSpace-

FilterCO


putReader( Reader )

1

FormatFilterCO


383

putReader( Reader )

1

FileOutputCO



The behavior of the components is as follows:

• A CharPipe-component simply pipes characters written to its Writer port to the Reader port.

• The FileInput-component reads from a file and writes the characters to the Writer port it is connected to.

• The ElimWhiteSpaceFilter-component

◦ reads a stream of characters,

◦ eliminates leading whitespace,

◦ substitutes strings of consecutive whitespaces within the stream by one blank,

◦ and writes the result to the Writer port it is connected to.

384



• The FormatFilter-component reads characters from the

Reader port.

◦ It considers blanks as word separator.

◦ After as many words as fit into a line of forty characters, it places a line feed character.

◦ Words longer than forty characters are hyphenated.

• The FileOutput-component reads from its Reader port and writes the characters into a file.

The startup order is pipeone, pipetwo, pipethree, filein, scan, format, and fileout.




386


To implement the architecture, we have to provide an implementation for each component interface specification.

387

Only the constructors of FileInputImpl and FileOutputImpl take an argument (the name of the corresponding file).

There is only one implementing class for each component interface.

Based on this information, we can generate the code for creating and linking of components, as well as startup.


7.2 Architectural Frameworks package pipefilter.application; import pipefilter.*; import pipefilter.pipes.*; import pipefilter.filters.*; public class Format { public static void main(String argv[]) {

String infilename = "input";

String outfilename= "output"; if( argv.length == 1 ) infilenm = argv[0]; if( argv.length == 2 ) outfilenm = argv[1]; try {

// creating the compound objects

FileInputCO

FileOutputCO filein fileout

= new FileInputImpl(infilenm);

= new FileOutputImpl(outfilenm);

ElimWhiteSpaceFilterCO scan = new ElimWhiteSpaceFilterImpl();

FormatFilterCO format = new FormatFilterImpl();

CharPipeCO

CharPipeCO pipeone pipetwo

= new CharPipeImpl();

= new CharPipeImpl();

CharPipeCO pipethree = new CharPipeImpl();

388



// connecting the compound objects filein.putWriter( pipeone.getWriter() ); scan.putReader( pipeone.getReader() ); scan.putWriter( pipetwo.getWriter() ); format.putReader( pipetwo.getReader() ); format.putWriter( pipethree.getWriter() ); fileout.putReader( pipethree.getReader() );

// starting the compound objects pipeone.start(); pipetwo.start(); pipethree.start(); filein.start(); scan.start(); format.start(); fileout.start();

} catch( COCreationException e ) {

System.out.println("Couldn’t create compound object");

System.out.println(e.getMessage());

} } }


389


The simple formatter example shows how architectural descriptions can be related to implementations.

An architectural framework should take this into account, although this should not be at the cost of supporting abstraction mechanisms.

390



More Realistic Architectural Frameworks

Many simplifications of the TAF framework are too restrictive to work for practical situations:

• The TAF framework is built around a simple model of encapsulated components. Having less encapsulated elements makes the interface description of the elements more complex.

• The TAF framework only supports one link phase, i.e.

dynamically evolving systems with changing links cannot be described.

391



• It only supports a minimal model for startup and no mechanism to shutdown components.

• The TAF framework does not say anything about a persistent data model.

• It does not provide schemas for structuring software.

• It does not support deployment in any way.

The main drawback of TAF is its weak semantical basis.

392



The specification of components and the connections between components are too much linked to a programming language.

A more abstract model at the interfaces of components would simplify the analysis of interface and system properties.

Abstraction over communication pattern is one of the foci of modern ADL.



Further literature:

D.C. Luckham, L.M. Augustin, J.J. Kenney, J. Veera, D.

Bryan, and W. Mann.

Specification and analysis of system architecture using

Rapide.

IEEE Transactions on Softaware Engineering, Special Issue on Software Architecture, 21(4):336-355, April 1995.

394


7.3 Connectors in Architectural Descriptions


395



Dedicated ADLs have been developed to provide techniques and tools for the specification of architectures.

Examples of ADLs include

• Acme: combines the essential architectural elements in a simple language and supports natural extensions to more complex architectural features.

• C2: focuses on the description of user interface systems.

• Darwin: supports the analysis of distributed message-passing systems.

• Rapide: based on a very detailed language that supports simulation and analysis of architecture descriptions.

396



Architecture description techniques and languages are still a topic of ongoing research.

397

The companion article presents a technique and language for architectural descriptions that is based on an architectural model in which components and connectors are distinguished.



• An architecture is described by the interfaces of its components and the connections between the interfaces.

• The connections are described with the help of abstract connectors.

• The connectors are objects of their own and can be described independently of component interfaces.

• They have a formal semantics that support abstraction of communication patterns.

• The explained technique forms the foundation of the architectural description language WRIGHT.

398


8 Designing Software

Architectures


8.1

“Software Design and Architecture”

8.1.1

“Methods and Techniques for Design”

8.1.2

“The Role of Architectural Structures for Design”

8.2

“Architectures and Evaluation”

8.2.1

“General Design Rules for Architectures”

8.2.2

“Architectures and their Relation to Requirements”

400


8.1 Software Design and Architecture


401


8.1 Software Design and Architecture 402

A central part of the design of a software system is the design of its architecture. Some authors identify the result of the design phase with the (documented) architecture.

We take a slightly more liberal point of view:

1. The design may lead to results that we would not consider to be part of the architecture (for instance, general layout for the graphical user interface).

2. Architectural decisions may be already taken as part of the requirements phase (e.g. that an application should be

Web-based).

In any case, the result of the design phase includes the architectural description of the software system.



Design is probably the most crucial and difficult phase in the software development process. It should

• clarify weaknesses of the software requirements;

• refine under-specified properties of the software system;

• provide an architecture that realizes the functional and non-functional requirements;

• reuse existing modules and frameworks (reuse of software);

• exploit existing architectural solutions (reuse of concepts);

• resolve optimization conflicts;

• meet technical requirements;

• satisfy restrictions on the design process itself.



8.1.1 Methods and Techniques for Design

404



A primary goal of software engineering is to structure, systematize, and partially automate the development, installation, and maintenance of software systems.

Methods should help to achieve the design goals in a well understood, step-by-step, and measurable process.

Techniques should provide concrete guidelines and tool support for the steps.

Most existing methods describe a process in which components and connectors of the architectural structures are determined and refined.

To illustrate this idea, let us look at three fairly different methods.

405



Functional Design

Classical design methods

• are mainly based on architectural structures from the static view;

• consider an architecture as a set of software modules with uses relations;

• concentrate on the design of completely new systems;

• are mainly driven by functional requirements;

• have decomposition and interface refinement as central design steps.

406



Object-oriented Design

Object-oriented design methods and in particular the so-called unified software development process are based on object-oriented architectural models.

The related modeling language

“UML”

supports the description of different static and dynamic architectural structures by a number of diagram types.

The design focuses on class diagrams expressing the inheritance and uses relation between classes.

The method is mainly driven by identifying the important objects in the system.

407



Extreme Programming

Extreme programming

• integrates requirement capture, design, implementation, and testing;

• creates so-called spike solutions for tough technical or design problems;

• stresses refactoring and advocates to add functionality as late as possible to the system;

• substitutes part of the documentation by the knowledge that the participating software developers acquire during the development process.

408



Advantage:

It is well suited for projects with changing requirements and allows one to handle non-functional and technical requirements from the very beginning.

409

Disadvantage:

A missing explicit design documentation is certainly a problem in long-term projects or for long-living software.

Whereas the other design methods are mainly based on the static architectural view, the exploration of the design space using spikes is more inclined towards the dynamic view.



8.1.2 The Role of Architectural Structures for Design

410



From the previous design approaches, we recognize the impact of software architecture on software design:

1. Architectural structures are used to decompose the system on different levels of abstraction and to capture different views of the system related to the various kinds of requirements.

2. If supported by a well defined notation, they provide the means for documenting the results of design.

3. They provide the space for applying patterns and standard solutions.



The use of patterns and standard solutions is crucial to make software development a mature engineering process. The goal is to enlarge the class of problems that can be solved in a standardized way ( routine design ) and to reduce the need for innovative design .



Examples:

• object-oriented design patterns: descriptions of communicating objects and classes that can be customized to solve a general design problem.

•

“standard or reference architectures” : For instance, the

two- or three-tier client-server reference architectures for enterprise information systems provide a helpful foundation for framework development and further standardization.



Architectural models, structures, aspects, patterns, and notations play a role for the design phase that is similar to the role that programming models, concepts, patterns, and languages play for the implementation phase.

414

In a similar way, the design method is related to the programming paradigm. For instance:

• object-oriented design tends to yield object-oriented architectures;

• object-oriented programming tends to lead to object-oriented programs.


8.2 Architectures and Evaluation


415



The architecture of a software system is not uniquely determined by the requirements.

What makes a “good” architecture?

To show how to evaluate an architecture,

• we summarize the general principles of quality;

• we consider the quality of an architecture relative to the requirements underlying its design;

• we illustrate this dependency by investigating the robustness of an architecture against changes.

416



8.2.1 General Design Rules for Architectures

417


8.2 Architectures and Evaluation 418

There are a number of general rules of thumb that should be taken into account for the design of every architecture.

Most important rule: A software architecture should be as clear and simple as possible.

Examples of simplicity: The operating system Unix and the

World Wide Web.

There are a number of other general criteria and rules to evaluate an architecture.



1. The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns.

Each module should have a well-defined interface.

2. The modules should reflect a separation of concerns that allows their respective development teams to work largely independently of each other.

3. The information-hiding modules should include those that encapsulate idiosyncrasies of the computing infrastructure, thus insulating the bulk of the software from change should the platform change.



4. The architecture should never depend upon a particular version of a commercial product or tool.

5. Modules that produce data should be separate from modules that consume data.

6. For parallel-processing systems, the architecture should feature well-defined processes or tasks that do not necessarily mirror the module structure.

7. Every task or process should be written so that its assignment to a specific processor can be easily changed.

8. The architecture should feature a small number of simple interaction patterns.

420



In addition, the design process and the precision of how the architecture is documented can be the subject of evaluation.

This has an important impact for the project and is often difficult to separate from the evaluation of the architecture itself.



8.2.2 Architectures and their Relation to Requirements



The requirements state what a software system should do and define additional conditions and constraints.

The evaluation of an architecture should determine to which extent the requirements are met.

In the following, we refer only to the

• functional requirements,

• non-functional requirements, and

• technical requirements.

We do not consider management requirements.



The evaluation of an architecture w.r.t. its functional and technical requirements is conceptually rather simple, because the result of such an evaluation is essentially “yes” or “no”.

The evaluation of non-functional requirements is conceptually more difficult because

• they are often only vaguely specified,

• the tradeoffs between competing non-functional requirements are unclear,

• in many cases it is difficult to determine the impact that the architecture has on the non-functional requirements.



Analyzing Architectural Decisions

We discuss the influence of non-functional and technical requirements on the design of architectures for the simple

“order processing system” .

From the given requirements, we can identify three conceptual components:

1. the user interface,

2. the business logic computing the price,

3. and the database.

425



Agency A

Customer meyer

Product

Quantity

Send

Agency B

Customer sixt

Product

Quantity car

ERROR

OK

Agency Z

. . .

Order dean jeans

12

Price

$ 270

Acknowledge Cancel

426

Business logic

Database

Headquarters



The central architectural decision to centralize database and price calculation is only based on non-functional requirements and management constraints:

• make updates to the database and modification of the calculation program simple;

• avoid the costs for multiple database installations.

The functional behavior could have been as well achieved by maintaining a copy of the database in each of the agencies.



To investigate the design decisions underlying the realization of the user interface, we sketch its structure and tasks.

Conceptually, the user interface consists of two components: the dialogue control and the presentation.

The dialogue control

• checks the well-formedness of the input parameters, keeps track of the dialogue state,

• controls what windows are visible to the user in what state of the dialogue,

• initiates the display of error messages, and

• communicates with the application.



In our example, the interface to the application provides three procedures:

1. for checking whether there is a product for a given name;

2. for calculating the price of a request described by customer name, product name, and quantity;

3. for acknowledgment or cancellation of an order.

The presentation is responsible

• for displaying textfields and buttons and

• for handling user input (keyboard input into textfields and button clicks).



In the following, we analyze the impact caused by the

(re-)use of external software on architecture decisions.

The implementation of user interfaces is usually based on external software and tools, i.e. software that is not under control of the development team (e.g. GUI toolkits or Web technology).

We structure the software modules of our user interface example into 3 types of software:

• AE-software : depends on the application and the external software;

• A-software : depends only on the application;

• E-software : depends only on the external software.


430


Presentation

GUI toolkit

Presentation kernel

Dialogue interface

Dialogue control


A-software

AE-software

E-software

431


The goal is to keep the AE-software module small, so that

• the impact of possible modifications can be kept small;

• a change of the external software affects only AE-software and E-software, i.e. if the GUI toolkit is changed only the

AE-software has to be adapted;

• ports of the software to different platforms is simplified. (In our example, we have to satisfy the technical requirement that the application should run on Unix and Windows.)

Now we analyze implications of E-software, used technology, and technical constraints on the dynamic view.



A central architectural issue in our example is the decision how the different parts of the user interface are assigned to the computers in the headquarters and the agencies.

Different solutions are possible:

1. Dialogue control and presentation run on the computers in the agencies.

2. Dialogue control runs in the headquarters; the presentation runs in the agencies.

3. Dialog control and (almost) the complete A- and

AE-software of the presentation runs in the headquarters.

That is, only application independent software runs in the agencies.


433


Advantages of the first solution:

• It only requires a low bandwidth connection between the headquarters and the agencies.

• It tends to be the solution with the best response time of the user interface.

434

Advantage of the second solution:

• Compared to the first: Changes of the dialogue control cause a new installation on all computers in the agencies.

• Compared to the third: It still tends to provide better response times.



Advantage of the third solution:

• All application dependent software runs in the headquarters.

There are essentially two technical alternatives to realize the third solution. Either the presentation is realized

• as Web-pages in a browser

◦ widely platform-independent

• or via a window server that can be controlled from a remote site (like e.g. X server on Unix).

◦ supports better and nicer interfaces

◦ but: different implementations of the AE-software have to be developed for Unix and Windows.



The architectural decisions between the solutions sketched above essentially have to be taken based on the non-functional and technical requirements, in particular based on the available technology and technical infrastructure.

436

The functional requirements have influenced the architecture only at the beginning, when it was decided to structure the system into user interface, business logic, and database.

Of course, after selecting one of the solutions sketched above, the functional requirements are needed to refine the architecture.