Thesis no: MSE-2002: 13 June 2002
Evaluation & Selection of Software Architectures
A Case Study of Positioning System
Adrien G UERRA
Sébastien P EIRONE
Department of Software Engineering and Computer Science Blekinge Institute of Technology
Box 520
SE – 372 25 Ronneby Sweden
Department of Software Engineering and Computer Science Blekinge Institute of Technology
Box 520
SE – 372 25 Ronneby Sweden
Internet : www.bth.se/ipd Phone : +46 457 38 50 00 Fax : + 46 457 271 25 University advisors:
Doru Constantinescu
Department of Telecommunications and Signal Processing Examinator
Claes Wohlin
Department of Software Engineering and Computer Science External advisor:
Hamid Delalat Patent Fabrik AB
Address: Polhemsgatan 27 37140 Karlskrona Sweden Phone: 0705597544
Contact Information:
Authors:
Adrien Guerra
Address: 23 avenue Alfred de Musset 06100 Nice France E-mail: adrien_Guerra@hotmail.com
Sébastien Peirone
Address: Polhemsgatan 37 37140 Karlskrona Sweden E-mail: sebastien.peirone@online.fr
Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies per student.
A BSTRACT
The explosion of the mobile telecommunications market has resulted in the apparition of multiple applications and services. However the particular business pressure has often lead to that these systems have poor quality design and, consequently, implementation.
Software system builders have realized the importance of the overall system organization to address quality requirements.
Practically, they started to use, idiomatically, a number of commonly recognized solutions to guide their design of system structures.
This report analyses and evaluates these solutions and comments on the result obtained when one of them was carefully selected and applied to a system of mobile positioning services.
Keywords: Software architecture, architectural style selection, mobile positioning systems
We would like to thank:
Hamid Delalat to be the starting point of this interesting thesis subject.
Doru Constantinescu for his support: material as well as intellectual on telecommunications issues.
The whole BTH Department of Telecommunications and Signal Processing and especially Markus Fiedler for their friendly welcome and for including us in their celebrations (we love princess tårta).
Mikael Svahnberg for orienting us in our literature search providing us a way out from the jungle of terms, views and definitions of the still under research field of software architecture.
Claes Wohlin for his critical opinion, feedback and advices, which, we hope, made us achieve a thesis of (or at least about…) quality.
1 Introduction ... 1
2 Software Architecture... 3
2.1 History... 3
2.2 Definition ... 5
2.2.1 Architecture View Models ... 7
2.2.2 Comparison with other architectural fields ... 12
2.3 Objectives... 14
2.3.1 Architectural Objectives... 14
2.3.2 Business Goals ... 16
3 Architecture Style... 17
3.1 Definition ... 17
3.2 Objectives... 18
3.3 Taxonomy ... 19
3.3.1 Base of Classification... 19
3.3.2 Classification Strategy ... 20
3.3.3 Data flow... 21
3.3.4 Call-and-return systems ... 24
3.3.5 Independent components... 32
3.3.6 Virtual machine... 35
3.3.7 Data-centered systems ... 37
3.3.8 Heterogeneous styles... 40
3.4 Comparison of Styles ... 43
4 The System... 47
4.1 Description ... 47
4.2 Constraints and Dependencies ... 47
5 Requirements on the System ... 49
5.1 Defining the requirements... 50
5.2 Prioritizing the requirements... 54
5.2.1 The necessity of prioritising requirements... 54
5.2.2 How to prioritise requirements? ... 56
5.2.3 Software architectures specificities... 58
5.2.4 In practice ... 58
5.2.5 The method used... 59
5.3 Results of the requirements prioritisation ... 61
6 Selection of an Architecture Style... 64
6.1 Pre-selection based on system description... 64
6.2 Selection based on quality requirements... 64
7.1.1 Definitions and Terminology... 68
7.1.2 Design and Component Communication ... 69
7.1.3 Remarks... 71
7.2 Characteristics and Description of the Model... 72
7.2.1 System Parameters and Settings ... 73
7.3 Processes Description... 74
7.3.1 Calculate the update time... 74
7.3.2 Define the nextUpdate time... 74
7.3.3 Modifying the update times management... 75
7.3.4 Sheduling... 75
7.3.5 Calculating the distance between 2 points... 75
7.4 Examples ... 76
7.4.1 Example 1... 76
7.4.2 Example 2... 77
7.5 Main Process ... 78
8 Conclusion... 79
REFERENCES... 80
Books... 81
Conferences and other Publications ... 82
ANNEXE A: Material distributed to the skateholders ... 84
ANNEXE B: Screen captures of the system ... 89
Figure 2.1: The 4+1 View Model... 8
Figure 2.2: Relationships between the Software Architectures ... 11
Figure 3. 1: The Pipes-and-Filters Style ... 22
Figure 3.2: The Object-Oriented Organization Style... 25
Figure 3.3: The Main Program & Subroutines Style ... 28
Figure 3. 4: The Layered Style... 30
Figure 3.5: The Event-Based Implicit Invocation Style... 33
Figure 3.6: The Interpreter Style... 36
Figure 3.7: The Blackboard Style ... 38
Figure 3.9: Example of a Locationally Heterogeneous Style ... 41
Table 3.10: Comparison of Styles... 43
Figure 4.1: The System and its environment ... 48
Table 5.1: Two examples of requirements prioritisation scales... 56
Table 5.2: Scoring list with the results of the customer... 61
Table 5.3: Scoring list with the results of the technical responsible... 62
Table 5.4: Final scoring list (joined result) after discussion ... 63
Table 6.1: Comparison of styles based on the final scoring list... 65
Figure 6.2: The architecture chosen: locationally heterogeneous... 66
Figure 7.1: The system design ... 69
Figure 7.2: MCQ main process ... 78
1 1 I I NT N TR RO OD DU UC CT TI IO ON N
As systems keep on getting larger and more complex, software designers are trying to increase the level of abstraction of their design. Software architecture, a sub discipline of software engineering, has recently appeared in result of the concern in the overall system organization.
The study of this field and its different techniques has different benefits; among those reuse is probably the major one. Indeed, experts in various fields such as architecture, economics and software engineering never create a brand new solution for a brand new problem: they reuse the essence of a proven solution to a similar problem.
Thinking in problem/solution pairs is a natural way of coping with any kind of problem; the technique of software architecture based on this way of thinking is the use of architectural styles.
Architectural styles express fundamental structural organization schemas for software systems. They provide a set of predefined subsystems, specify their responsibilities and include rules and guidelines for organizing the relationships between them.
Each style is appropriate for a specific kind of problem, however they can be quite similar, just as problems can. During the past decade, attempts were made to classify architectural styles, to regroup them into related families to provide guidance in the selection.
One domain where applications often suffer from design problems is the mobile services one, indeed in that recently blooming market and consequently highly competitive, business requirements such as short time to market are basically driving the implementation, consequently design often does not get the attention it should.
The intent of this thesis is to research an architectural style enhancing the quality and easing the design of mobile services system, this implies several steps: first we need to analyze and evaluate the different architectural styles available, then we must elaborate a method to select a suitable one given the characteristics of mobile services systems, this style will finally be applied on a specific system of services based on positioning, providing feedback on the correctness of the choice.
1
This report is structured as followed:
• In the second chapter we present the discipline of software architecture: by different approaches we try to give a definition and to list its benefits.
• The third chapter focuses on one special technique of software architecture:
the use of architectural styles, in this part we describe this technique and establish a taxonomy of the major architectural styles enabling us to later compare them.
• The fourth chapter gives an overview of the system to design using one of the architectural styles defined in the preceding chapter, the full understanding of the system to implement is indeed mandatory in the selection process.
• The other material needed to be able to select an architectural style is the requirements that stakeholders have for this system. In the fifth chapter we present the methods studied as well as the one used to elicit and prioritize the requirements for this specific mobile positioning system.
• In the sixth chapter we gather the information from chapter four and five and analyze them in order to make the final selection of what architectural style should be used to design the system at hand.
• The seventh chapter presents the result of this selection: how the system was implemented based on the architectural style selected.
• We conclude this report with chapter eight in which we sum up the work done, explain what was difficult and provide an evaluation of the prototype realized.
2
2 2 S S OF O FT TW WA AR RE E A A RC R CH HI I TE T EC CT TU UR RE E
2.1 H ISTORY
Recently, software architecture has emerged as an important field of study for software engineers, practitioners and researchers but it did not simply appear, well formed and clearly articulated, as a new concern for software systems. Rather, it has emerged over time as a natural evolution of design abstractions, in result of regular increase in the abstraction level or the conceptual size of the building blocks used by engineers to build larger more complex software systems.
The need for modular structuring and explicit handling of product families was first approached in the late sixties and seventies (Dijkstra 1968, Parnas 1976) with active debates about criteria on which to base modularisation of software (Parnas 1972).
Gurus of programming started to focus their attention on the data structure convinced that its quality would ease the whole development. This common belief led to raise the design level of certain elements of software systems, namely abstract data types, above the level of programming languages statements or individual algorithms.
In the late seventies and eighties, research focused on the integration of the design in the heart of the development process and its assimilation in the programming languages, several paradigms appeared resulting in, for example: “programming-in- the-large (DeRemer and Kron 1976), modules (Parnas et al. 1985) and objects.
DeRemer and Kron (1976) argued that creating program modules and connecting them to form larger structures were distinct design effort; they created the first module interconnection language (MIL) to answer the need for a notation to describe how subsystems interconnect to form larger systems.
These early efforts to develop descriptions of system structures and to provide criteria for software modularisation have improved our ability to develop software. However, their primary focus was on the problem of code organization and relationships between the parts base on interactions such as procedure call and simple data sharing.
Since then, software in systems has grown tremendously in size and complexity raising new problems involving the system-level design of software. At this level, the important decisions are concerned with the kinds of modules and subsystems to use and the way these modules and subsystems are organized.
Although these “old" structuring principles still hold, they have to be up-scaled, transformed into principles for the products of today's sizes, to help partitioning large complex systems into units that could be implemented separately by software developers and that would provide downstream benefits in support of extensibility, maintenance and system understandability.
This level of organization, the software architecture level, requires new kinds of abstractions that will capture essential properties of major subsystems and the ways they interact.
3
The term software architecture was introduced in the nineties to address structural issues including the following ones given by Shaw and Garlan (1996): “The organization of a system as a composition of components; global control structure, the protocols for communication, synchronization, and data access; the assignment of functionality to the design elements; the composition of design elements; physical distribution; scaling and performance; dimensions of evolution and selection among design alternatives”.
Today there are numerous books on architectural design, regular conferences and workshops devoted specifically to software architecture, a growing number of commercial tools to aid in aspects of architectural design, courses in software architecture, major government and industrial research projects centered on software architecture, and an increasing number of formal architectural standards.
4
2.2 D EFINITION
What exactly is meant by the term “software architecture?” As Garlan and Perry (1994 and 1995) noticed, the term “architecture” in software is used in different ways, often making difficult to understand what aspect is being addressed.
Among the uses are:
- The architecture of a particular system, as in “the architecture of system S contains 3 components c1, c2 and c3…”
- An architectural style, as in “system S adopts a client-server architecture”
- The general study of software architecture, as in “there are many books on software architecture”
Even though most of the impressive number of definitions appeared in the last decade are dealing with the first use mentioned above, "there is no standard, universally- accepted definition of the term, for software architecture is a field in its infancy, although its roots run deep in software engineering"
(http://www.sei.cmu.edu/architecture/definitions.html, Software Engineering Institute, Carnegie Mellon, which maintains an extensive list of definitions)
We can try to classify the definitions in the following categories:
- Definition as an organised structure of components.
Bass et al. (1998), gave the following definition, that, because often referenced in the literature, seemed to be most agreed upon: “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”.
o Categorization of these components
"We distinguish three different classes of architectural elements: processing elements; data elements; and connection elements. The processing elements are those components that supply the transformation on the data elements; the data elements are those that contain the information that is used and transformed; the connecting elements (which at times may be either processing or data elements, or both) are the glue that holds the different pieces of the architecture together". (Perry and Wolf 1992)
5
o Specification of the connection modes of these components
"A Software Architecture is the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time" (Garlan et Perry 1995).
o A structure in an environment (functional view)
"A software system architecture comprises:
·A collection of software and system components, connections, and constraints.
·A collection of system stakeholders needs statements
·A rationale which demonstrates that the components, connections, and
constraints define a system that, if implemented, would satisfy the collection of system stakeholders needs statements" (Gacek et al. 1995).
- Definition by abstraction: modules and languages.
"A generic architecture is defined as a topological organization of a set of parameterised modules, together with the inter-modular relationships. Designing a software system using a generic architecture consists of instantiating the parameters of each parameterised module by a concrete value while maintaining the inter-modular constraints" (Bhansali and Nii 1992).
- Definition as resolution of problem and decision
"Architecture is the art of producing a specification for a system that when built will satisfy a client's need or the art of solving a problem. Software architecture is architecture that uses software in its solutions. Software architecture requires
· A clear definition of the problem to be solved including identification of client and customer
· A design for the solution, i.e. how the system is to work including structure principles, dynamic, behaviour, etc.
· Technological and economic justification
· Management planning (Source AT&T Systems Architecture Review Board Course).
6
2.2.1 Architecture View Models
While there are numerous similar definitions of software architecture, at the core of all of them is the notion that the architecture of a system describes its gross structure using one or more views. “We conclude that “architecture” is not “the structure” of a system, but is a collection of one or more useful structural views of the same system”(Clements 94)
The “system” modeled by software architecture is usually large and complex in nature. Different stakeholders (e.g., users, business analysts, programmers, testers, and maintainers) typically care about only specific aspects of the software system, and have widely varying mental models based on how they experience the system.
To separate the different areas of concerns, and to reflect the dynamic nature of software architecture, the notion of “views” of software architecture is introduced.
The structure in a view illuminates a set of top-level design decisions, including things such as how the system is composed of interacting parts, where are the main pathways of interaction, and what are the key properties of the parts; additionally, an architectural description ideally includes sufficient information to allow high-level analysis and critical appraisal.
Many different structures are involved in the architecture of a software system. In order to organize them, models have been defined that give a certain view on software architecture.
The models used in industry are mostly those developed by Kruchten (1995) and Soni et al. (1995).
7
2.2.1.1 The 4+1 View Model
In 1995, Kruchten proposed a “4+1” view model to describe the software architecture of a system from multiple perspectives, to separate concerns from various stakeholders of the architecture, and to differentiate the functional and non-functional requirements
o The logical view is the analyst’s abstract object model, which captures the abstraction, encapsulation, and inheritance in the problem domain.
o The process view models concurrency and synchronization aspects of the software system.
o The physical view maps the software elements onto the hardware execution environment; this view also captures the distributed aspects of some systems.
o The development view models the static organization of the software in its development environment. It mainly focuses on the source code structure.
o Scenarios and use-cases show how all four views work together to satisfy user requirements.
The following figure shows the views, the stakeholders and their concerns.
Scenarios
Physical view Process view
Development view
P ROGRAMMERS
• Software management
Logical view
E ND USERS
• Functionality
S YSTEM ENGINEERS
• System topology
• Delivery
• Installation
S YSTEM
INTEGRATORS
• Performance
• Scalability
• Throughput
Figure 2.1: The 4+1 View Model 8
The logical view supports the functional requirements: the services a system should provide to its end users. The designers decompose the system into a set of key abstractions of the domain, which results in a domain model. Kruchten suggests using an object-oriented style to define the logical view.
The process view addresses non-functional requirements, such as performance and availability of resources. It takes into account concurrency and distribution, system integrity and fault tolerance. In this view, the control of execution is described at several levels of abstraction.
The development view focuses on the organization of the actual software modules in a software development environment (SDE). It concerns the internal requirements related to ease of development and software management. The development view is represented by module and subsystem diagrams that show the system's export and import relations.
The physical view also takes into account the system's non-functional requirements. It maps the various elements identified in the logical, process and development view onto the various hardware elements. This mapping should be highly flexible and should have a minimal impact on the source code itself.
The scenarios help to demonstrate that the elements of the four views work together seamlessly. The scenarios are in some respect an abstraction of the most important requirements. A scenario acts as a driver to help designers discover architectural elements, and also helps to illustrate and validate the architecture design.
An example of a scenario is the description of the activation of the “follow me”
function in a telephony switching system (activation of forward direction of incoming calls to another specified extension). Given this scenario, one can discuss how the involved processes communicate with each other via message communication, which components of the system are running, and which hardware devices are involved. The scenario view is in fact redundant with the other views, hence the “+ 1".
The various views are not completely independent of each other. The characterization of the logical elements helps to define the proper process elements. For example, each logical element (object) is either active or passive (autonomy of objects); elements are transient or permanent (persistency of objects). The autonomy and persistency of objects have to do with the process view. The logical view and development view are very close, but address different concerns. The logical elements do not necessarily map one-to-one on development elements. Similar arguments hold for the relation between process view and physical view.
9
2.2.1.2 The “Four Views” Model
Soni et al. (1995) have investigated a number of large systems (telecommunication, control systems, image and signal processing systems) to determine the pragmatic and concrete issues related to the role of software architecture.
The structures they found in the investigated systems can be divided in several broad categories: “Software architecture has at least four distinct incarnations. Within each category, the structures describe the system from a different perspective: “
o “The conceptual architecture describes the system in terms of its major design elements and the relationships among them.”
This view, analogous to the “4+1” logical view, describes the system in terms of its major design elements and relationships between them. Typical elements are components and connectors.
o “The module interconnection architecture encompasses two orthogonal structures: functional decomposition and layers”
This view shows the high-level design of the system. Its purpose is twofold: it describes how to map the conceptual view onto the high-level design artifacts, and it describes the layering structure of subsystems and specifies the interfaces between subsystem layers and low-level design artifacts (e.g., source code modules).
o “The execution architecture describes the dynamic structure of a system.”
This view describes the structure of a system in terms of its run-time platform elements, such as tasks, processes, threads, and address spaces, it captures the distributed and concurrent aspects of the system, as well as other non-functional requirements such as resource sharing, scheduling policies and load balancing.
o “The code architecture describes how the source code, binaries, and libraries are organized in the development environment.”
This view is the low-level design view that describes the interfaces and interdependencies between source code, files, directories, libraries, etc.
10
Resource on resides
Execution architecture
Configured by Implemented by Implemen ted by
Implemen ted by
Assigned to
Assigned to
Assigned to
Code architecture Module architecture Conceptual architecture
Loca ted in
Hardware architecture
Source code
Figure 2.2: Relationships between the Software Architectures
The architectural views have relations with each other as depicted in Figure 2.2.
A conceptual element is implemented by one or more elements of the module architecture.
Module elements are assigned to run-time elements in the execution architecture. In addition, each execution element is implemented by some module elements.
Module elements are implemented by elements of the code architecture.
There is also a relationship between run-time elements and executables, resource files (e.g. help texts in different natural languages) and configuration files in the code architecture.
11
2.2.2 Comparison with other architectural fields
Perry and Wolf (1992) had an interesting approach to define what software architecture is: they compare it with the other fields for which the word architecture has a meaning.
o The architecture of buildings
It is a field from which we can get a lot of information, because it has many common points with what software architecture is supposed to be.
The first common point is in the use of a plan before building the building. This plan fixes the methods and materials to be used according to the goal to reach and makes it possible to assign the various tasks with the qualified people.
In this objective of work sharing, only one part of the construction is shown in details to the appropriate workers: the plan of the lines to the plumbers, the electric plan with the electricians, and so on.
These various views of construction make it possible to study a particular point independently of the other actors, while being assured that the lines, for example, will be placed at the good place at the end. From the quality of the design plan rise finally global properties (resistance, weight, possibility of adding parts...) shown once and for all.
In the case of software architecture, the detailed plans are used to extract information on the whole system: plan of connections, plan of the dependences...
Each one of these characteristics follows the global plan, which makes it possible to ensure that, for example, connections are done between the good parts.
Properties like the absence of lock or performance must be shown on the level of architecture.
The second common point is in the definition of style as a meta-information grouping buildings. The style is employed as a descriptive element (by giving general lines) and prescriptive (by posing limits).
o Electronic architecture
In the field of electronic architecture, we also find the interest to use various approaches; each of them underlining a particular aspect of architecture, either the unit of the instructions (RISC machines) or the configuration (pipeline, multiprocessors...).
Since there are few elements of the different types (resistances, condensers, processors, memories), it is necessary to multiply them to obtain large systems.
All the characteristics and properties of these components are known.
12
This last point differentiates this field with software architecture, since, for the latter, there is a wide range of possible components without duplication. Attempts were made to define types of software components that, after instantiation, would provide the desired piece of software (just as it is necessary to choose the value of resistance once we know we should used one). A success would make possible to only specify these types with their characteristics and their properties in the software architecture.
Another possible analogy with electronic architecture is to conceive the architecture of software as being the printed circuit on which the components will be “glued”.
This analogy is based on complete separation between structure and behaviour, which is not really possible in the case of software architecture but has the advantage of helping us to perceive it as being a solid base for development.
o Network architecture
In this field, we only consider graphs representing the topological configurations (bus, star, ring...) in which the components (mostly machines) are abstract in the form of nodes. This representation of complex system in graphic form eases comprehension of the network organization and can be reproduced on the program level.
However if we want to show the properties of a system, the information contained in a graph is often insufficient. Some research has been undertaken to define the minimal structure for this representation in order to be able to carry out formal handling. This part of search led to the definition of configuration languages in which the interest is only in the skeleton of the program.
o Synthesis
As common points between software architecture and those fields, from the architecture of buildings, we will take the use of multiple views, the possibility of showing properties before construction and the characterisation of a building according to a style; from electronic architecture, we will take, in addition to the need for using various sights, the definition of the types of components; from architecture network, we will take the simplified representation in the form of graphs, in which the nodes correspond to the minimal structure of the components:
their interface.
13
2.3 O BJECTIVES
Now that we have a good view of what software architecture is, it is important to understand why this discipline has had so much attention during the past decade, being considered as one of the most promising sub fields of software engineering. We will try to develop what are the software designers’ motivations in using software architecture but also how they have to consider the business requirements on a product.
2.3.1 Architectural Objectives
There are many architectural objectives that justify certain architectural decisions.
Bass et al. (1998) distinguished different ones, called quality attributes. These quality attributes are discernable at run-time (performance, security, availability, functionality and usability) or they are not discernable at run-time (modifiability, portability, reusability, integrability and testability).
However, in more abstract terms, we can distinguish the following architectural objectives, which are not necessarily orthogonal:
• Comprehension;
• Reuse;
• Evolution;
• Product family.
We will now explain more in detail each of these objectives.
2.3.1.1 Comprehension
Software changes many times during its lifetime. A developer must understand the software well to be able to modify, extend or fix a bug in the system. Approximately half of the time spent on maintenance activities concerns comprehension (Fjeldstad and Hamlen 1979). Improvement of comprehension therefore increases a developer's productivity.
In many cases, the developers who made the software changes did not originally create the part of the software concerned. This is due to the typical lifespan of our systems, which may be decades. An original developer may in the mean time have moved on to another position or may even have left the organization. Moreover, in view of a system's size and complexity, several developers must often have access to the same part of the software.
The nature of today's systems makes it impossible to divide a system from the start into disjoint parts of the software that can be assigned to a single person.
Comprehension of software written by other people is therefore necessary.
14
2.3.1.2 Reuse
Reuse consists of the further use or repeated use of a software artifact. Typically, reuse means that software artifacts are designed for use outside their original contexts to create new systems (Jacobson et al.1997)
Proper application of reuse requires a number of precautions. Design for reuse must be explicitly addressed in an organization to be able to reuse software. Component reuse is currently a hot topic in research and practice.
In general, the number of reusable components greatly influences productivity and quality. However, reuse of software is often hard to achieve, requires a lot of investment and must be managed explicitly to be successful. The benefits of a reuse- oriented organization start at best, two years after introduction (Jacobson et al.1997).
In a business context, two years for return-on-investment is long, especially compared with the time between two releases.
Reusable components can only be developed with a specified architecture in mind.
For a functional equivalent component one may request different implementations depending on the architecture and/or satisfying different non-functional requirements.
In the world of IC (Integrated Circuit) design, it has long been accepted that there are different implementations for a component. In the world of software this is less accepted. For example, a component in a pipeline architecture must behave differently from a component in an event-driven system. In a pipeline architecture a component continuously reacts on new input data while in an event-driven system a component is triggered before it processes data.
It is impossible to combine any arbitrary set of components into a new system. Garlan stressed this point as the architectural mismatch (Garlan et al. 1998).
2.3.1.3 Evolution
From a business perspective, software has come to be the most profitable part of software-intensive systems. Product features of existing systems are often related purely to software extensions.
In the past, product requirements were often assumed to be stable. Today they are more dynamic and evolutionary. Requirements rapidly change and product developers must allow for this fact.
The evolution of hardware also has an impact on software, for example the software controlling image-processing units in a medical system. One must be able to smoothly integrate a new hardware image-processing unit into a new system release or even replace such a unit by software. So the thought of possibly having new image- processing units in the future causes this to be explicitly covered in the software architecture. Good intuition of possible market trends helps to define software architectures that are future proof.
15
2.3.1.4 Product Family
Product family architectures are architectures especially designed to manage (and enhance) many product variations needed for different markets. For example, in different parts of the world there are different television broadcast standards, which affects the software embedded in a television set. A television's user interface is also language-dependant. Furthermore, products may also vary in the number of features they include. A television may be packed with or without an Electronic Programming Guide (EPG). One must be able to switch the EPG feature on or off in a late stage of the production process. Software architecture must be capable of facilitating all such variations, i.e. it must be flexible.
2.3.2 Business Goals
From a business perspective the following goals can be defined for products, having impact on the software architecture within such a product (Jacobson et al.1997):
• Short time-to-market;
• Low cost of product;
• High productivity of organization;
• Adequate predictability of process;
• High reliability of product;
• High quality of product.
Which goals must be emphasized depend very much on the type of product.
The reliability of a product is very important especially for medical systems, e.g. a patient must not be exposed to too much X-ray radiation. The quality of consumer products is also important. It is for example impossible to provide every one of the millions of television users an update of the software in their television every six months.
However, in the highly competitive market of software systems it is more accepted to deliver several software updates after the first release. In this business, time-to-market has high priority, as the aim is to remain ahead of one's competitors. A software architect must be aware of such trade-offs in making proper architectural decisions.
One technique widely used by software architects to achieve such non-functional requirements (e.g. reliability, usability, etc.) is the use of architectural patterns, largely called “architectural styles”.
16
3 3 A A RC R CH H IT I TE EC CT TU U R R E E S S TY T Y LE L E
3.1 D EFINITION
Given the most common definition of software architecture as the system structural level of organization, we can see that there are different possibilities in the choice of components and connectors used in a specific design. When developing a particular system, designers tend not to explore all possible alternatives for its architecture.
Instead, they use specific patterns and idioms that are effective for the domain in which they are working. The choices made were, in practice, informally transferred as architectural idioms and given a name to facilitate reuse and understanding. It is quite common to hear “this system is a client-server” and everyone understands what it means: the system has been designed according to a set of rules defining what a client-server should be. This constrains the design space, permitting developers to ignore complications and alternatives that are not relevant to the system that they are developing. This also exposes the issues that are most important and thus helps the developer make effective choices and locate the best solution more easily.
This is the essence of architectural style: exploiting commonalities across systems by defining a set of design rules to identify families of systems related by common structural and semantic properties. In more details, Shaw and Clements (1996) explain that the differences are based not only on the computational nature of the components chosen but also, and for a larger part, the kind of connectors they use to interact with each other.
According to Shaw (1994), a style is more than a pattern because it has to provide:
• A Vocabulary of design elements. The components and connectors used in the system should be easily identified by their names e.g.: pipes, filters, clients, servers, parsers, databases, etc.
• Design rules: a set of constraints on how those elements can be combined.
These constraints can be topological (for example, prohibiting cycles in a particular pipe-filter style) or dealing with execution semantics (e.g.
assumptions that pipes preserve order or that they are invoked non- deterministically).
• Semantic interpretation, whereby compositions of design elements, suitably constrained by the design rules, have well-defined meanings.
• Style-specific analyses For example, it is possible to analyze systems built in a pipe-filter style for latency or deadlock-freedom whereas such analyses do not necessarily make sense for another system based on a different style (or none). In particular, some styles make it possible to generate code directly from an architectural description
17
3.2 O BJECTIVES
Using a style has many benefits, which can be divided in two types: inherent of the discipline or intrinsic:
• The benefits inherent of the whole software architecture discipline are for example design reuse, providing solutions that have been proven by use with well- understood properties, or communication about the organization of the system being designed (just telling the name of the conventional style used in the design provide a good overview on the system organization: the components used as well as the way they interact).
• The benefits, which are style specific, are:
o A style focuses the design problem on techniques that are effective for a specific class of systems. By recognizing that, for example, real-time considerations are not of interest to a payroll database, developers can instead concentrate on developing a flexible and general set of queries for the database o Code reuse: system designed with the same style will indubitably have some common parts and thus will be partly implemented the same way. For example, systems described in a pipe-filter style might reuse Unix operating system primitives to handle task scheduling, synchronization, and communication through pipes,
o Interoperability. Examples include CORBA object-oriented architectures, the OSI protocol stack, and event-based tool integration,
o Specialized, style-specific analyses and even code generation as described earlier, If a style guarantees that a set of properties hold, it can lead to more powerful analyses than a general architecture permits
o Finally, it is usually possible (and desirable) to provide style-specific graphical depictions of design elements. This makes it possible to provide graphical renderings of designs that match engineers' domain-specific intuitions about how their designs should be visualized
To motivate the idea of style, consider the familiar example of a compiler. The first compiler required years of development effort by a substantial team. Many alternatives had to be considered for the system because no one had built anything like it. Today, however, the principles of compiler construction are well understood.
In particular, a compiler’s structure is expected to include a lexical analyzer, a parser, a collection of semantic checks (such as a type checking), and a code-generating back end. The problem has been focused on these specific pieces, construction techniques have been standardized, and tools have automated many routine aspects of compiler implementation. As a result, an undergraduate can now develop a compiler in a single semester. Elements such as code optimizers can be developed, often separately from the rest of the compiler, and added easily. New techniques and technology are made available with a minimum of additional development effort.
18
3.3 T AXONOMY
Now that we fully understand the benefits of using an architectural style we need to know the different options possible: the following classification address this need as a first step toward making a selection of architectural style(s).
At least, it helps focusing on important design issues by providing a checklist of topics to consider, thereby setting expectations for elements to include in the design.
Eventually the classification should provide guidance to recognize which styles are important candidates for shaping the solution.
3.3.1 Base of Classification
Much of computer science includes phenomena about which we do not yet have well- established scientific truths but do have interesting observations and generalizations.
Brooks (1988) has proposed recognizing three kinds of results:
• Findings: well-established scientific truths
• Observations: reports on actual phenomena
• Rules-of-thumb: generalizations, signed by an author but perhaps not fully supported by data.
His criteria for judging quality are truthfulness and rigor for findings, interestingness for observations, usefulness for rules-of-thumb and freshness for all three.
The following classification presents observations on discriminating among styles and some rules-of-thumb on guiding their use in design.
This classification is based on the work done by Mary Shaw (1994) (with David Garlan 1996 and with Paul Clements 1996). Her attempt to catalog architectural styles was motivated by the observation that architectural abstractions for complex systems exist but we do not study or catalog them as in common in other engineering disciplines.
Her work, based on an extensive set of system descriptions, is widely recognized and referenced heavily in software architecture papers, though empirical and observational accounting for the descriptions that designers actually write, as opposed to inventing styles that may be easy to classify but are of no apparent practical import.
19
3.3.2 Classification Strategy
The following classification discriminates the different architectural styles by the following categories of features:
• Which kinds of components and connectors are used in the style
• How control is shared, allocated, and transferred among the components
• How data is communicated through the system
• How data and control interact
• What type of reasoning is compatible with the style
These categories form the basis of a descriptive classification that shows essential similarities and differences among styles. Features that distinguish styles also help us understand why a particular style is an appropriate solution for one type of problem and not for another.
This shares motivation with recent work on problem frames and patterns. Jackson (1995) does for classes of problems what we are doing for classes of solutions.
Jackson distinguishes classes of problems on the basis of the kinds of information provided and kinds of results expected. In the following classification we define classes of solution by categorizing styles into related groups, or “family”:
• Data-flow
• Call-and-return
• Independent components
• Virtual machine
• Data-centered
We will now explore each of these families and go deeper in details about their main representative(s).
20
3.3.3 Data flow
Data-flow architectures main aimed qualities are reuse and modifiability, to achieve this the system is decomposed as a series of transformations on a stream of data, which flows from input to output. There are many different styles in the data-flow family, however they are specializations (based on different restrictions) or degenerate cases (batch sequential for example) of the main style: the pipes and filters style.
3.3.3.1 Pipes and filters In brief:
System model Data flow between components that incrementally transforms data (stream-to-stream)
Components Filters (purely computational i.e. no state information preserved between instantiations, local processing, asynchronous)
Connectors Pipes which form transmission graphs and move data between graph nodes
Control structure Data flow
Problem:
This pattern is suitable for applications that require a defined series of independent computations to be performed on ordered data. It is particularly useful when each of the computations can be performed incrementally on a data stream. In such cases the computations can, at least in principle, proceed in parallel; when this is possible it can reduce the latency of the system.
Solution:
A common way to structure a program that basically transforms data is to divide it into a collection of computations where each computation is an incremental transformation of the data. These transformations are combined so that outputs of certain transformations serve as inputs to other. The entire application is then the composition of these computations/transformations. Systems of this type are referred to as coarse-grained dataflow or pipe-filter systems.
21
In a pipe and filter style each component has input ports, from which it reads one or more streams of data, and output ports, to which it writes results (one or more transformed streams of data), delivering a complete instance of the result in a standard order. Each component applies a local transformation to the input streams and performs its computation incrementally so output begins before input is consumed.
Thus components are called “filters”.
The connectors of the system control the flow of data through the system. Each connector links an output port to an input port, indicating the path that data will take and carrying out the transmission, thus they are called “pipes”.
The constraints on this style are first that filters must be independent entities, they should not share state with other filters and secondly they do not know the identity of upstream or downstream filters: although their specification might restrict what appears on the input pipes or make guarantees about what appears on output ports, they may not identify the components at the ends of those pipes.
Data flow (Pipes)
Computation (Filters)
Input Output
Figure 3. 1: The Pipes-and-Filters Style
22
Advantages:
• Problem decomposition:
The overall input/output behavior of a system is as a simple composition of the behaviors of the individual filters, thus easily understood by the different actors. The problems can also be hierarchically decomposed.
• System maintenance and reuse:
Any two filters can be hooked together, provided they agree on the data that is being transmitted between them. New filters can be easily added at the appropriate points in the processing sequence and old filters replaced by improved ones and so even at run-time.
• Specialized analysis
Those systems permit for example throughput and deadlock analysis.
• Performance
Parallel processing/concurrent execution of filters is possible.
Disadvantages:
• Batch mentality
Pipes and filter systems often lead to a batch sequential thinking: because of their independent character, designers tend to think of filters as providing a complete transformation of input prior to the activation of the next filter, as a result pipes and filters systems are typically not suitable to handle interactive applications.
• Difficult synchronization and ordering of pipes
Pipes may have to maintain correspondences between two separate but related streams and may require a lowest common denominator on data transmission with added work (parsing and unparsing overhead) leading to performance penalty and increased complexity in writing the filters themselves (infinite queues may be required and deadlock is possible with finite buffers).
23
3.3.4 Call-and-return systems
Call and return architectural styles are designed to address the qualities of modifiability and scalability. They have been dominant in large software systems for the past 30 years.
However within this family a number of styles have emerged each with interesting specific features, the main ones are “Data abstraction and object-oriented organization”, “main program and subroutines” and “layered”.
3.3.4.1 Data abstraction and object-oriented organization In brief:
System model Localize state maintenance
Components Managers (e.g. servers, objects, abstract data types)
Connectors Procedure call (method invocation is essentially procedure call with dynamic binding)
Control structure Decentralized, usually single thread
Problem:
This pattern is suitable for applications in which a central issue is identifying and protecting related bodies of information, especially representation information. When the solution is decomposed to match the natural structure of the data in the problem domain, the components of the solution can encapsulate the data, the essential operations on the data, and the integrity constraints, or invariants, of the data and operations.
Solution:
In this style data representations and their associated primitive operations are encapsulated in an abstract data type or object. The components of this style are the objects or, in other words, instances of the abstract data types. Objects are examples of a sort of component called a manager because it is responsible for preserving the integrity of a resource (here the representation). Objects interact through function and procedure invocations.
24
Two important aspects of this style are that:
• Objects are responsible for their internal representation integrity.
• This internal representation is hidden from other objects.
While inheritance is an important organizing principle for defining the types of objects in a system, it does not have a direct architectural function. In particular, an inheritance relationship is not a connector, since it does not define the interaction between components in a system. Also, in an architectural setting inheritance of properties is not restricted to object types but may include connectors and even architectural styles.
Procedure call
Manager
Figure 3.2: The Object-Oriented Organization Style
25
Advantages:
• Problem decomposition
Natural correspondence with real-world entities.
System decomposition into sets of interacting agents.
• Maintenance
It is possible to change both algorithm and data representation of an object without affecting its clients (its representation is hidden from them).
• Protection of internal representations
Encapsulation allows data/state integrity to be preserved.
Disadvantages:
• Reuse
Objects must know each other’s identities to be able to interact via procedure call. Thus whenever the identity of an object changes it is necessary to modify all other objects that explicitly invoke it. Further there can be side-effect problems in object method invocation.
• System evolution
Adding new functions to the system implies either modifying the existing modules (compromising simplicity and integrity) or adding new modules (penalizing performance).
26
3.3.4.2 Main program and subroutines In brief:
System model Call and definition hierarchy, subsystems often defined via modularity
Components Procedures and explicitly visible data Connectors Procedure calls and explicit data sharing Control structure Single thread
Problem:
This style represents the classical program paradigm aiming to decompose a program into smaller pieces to help achieve modifiability. It is suitable for applications in which the computation can appropriately be defined via a hierarchy of procedure definitions. There is typically a single thread of control and each component in the hierarchy gets this control (optionally along with some data) from its parent and passes it along to its children.
Solution:
The primary organization of many systems mirrors the programming language in which the system is written.
Many programming languages provide natural support for defining nested collections of procedures and for calling them hierarchically. These languages often allow collections of procedures to be grouped into modules, thereby introducing name-space locality. The execution environment usually provides a single thread of control in a single name space.
For languages without support for modularization this often results in a system organized around a main program and a set of subroutines. The main program acts as the driver for the subroutines, typically providing a control loop for sequencing through the subroutines in some order.
27
Sub1 Sub2 Sub3 Main
Figure 3.3: The Main Program & Subroutines Style
28
3.3.4.3 Layered In brief:
System model Hierarchy of opaque layers
Components Usually composites: composites are most often collections of procedures
Connectors Depends on structure of components: often procedure calls under restricted visibility
Control structure Single thread
Problem:
This pattern is suitable for applications that involve distinct classes of services that can be arranged hierarchically. Often there are layers for basic system-level services, for utilities appropriate to many applications, and for specific tasks of the application.
Solution:
A layered system is organized hierarchically, each layer is acting as a server providing service to the layer above it and on the other hand as a client consuming service from the layer below. The connectors are protocols of layers interaction.
In some layered systems inner layers are hidden from all except the adjacent outer layer, except for certain functions carefully selected for export (an “API” to be used by above layers). Thus in these systems the components implement a virtual machine at some layer in the hierarchy. In other layered systems the layers may be only partially opaque.
The most widely known examples of this kind of architectural style are layered communication protocols. In this application area each layer provides a substrate for communication at some level of abstraction. Lower levels define lower levels of interaction, the lowest typically being defined by hardware connections.
Frequently, each class of service is assigned to a layer and several different patterns are used to refine the various layers. Layers are most often used at the higher levels of design, using different patterns to refine the layers.
29
Figure 3. 4: The Layered Style
Advantages:
• Increasing abstraction levels design
A complex problem can be partitioned into a sequence of incremental steps.
• Maintainability, system evolution
If the functionality of the system is appropriately assigned to its different layers, changes to the function of one layer affect at most the two other layers it interacts with (the layers below and/or above).
• Reuse
Different implementations of the same layer can be used interchangeably, provided they support the same interfaces to their adjacent layers. This leads to the possibility of defining standard layer interfaces (e.g. the OSI ISO model and some of the X Window System protocols.)
30
Disadvantages:
• Not universally applicable
Not all systems are easily structured in a layered style.
• May be the wrong model
Even if layered style is applicable, the user may need to control deep functionality.
• Performance penalty
The computation in response to an external event covers multiple layers requiring several switches of method context thus decreasing performance.
• Difficult to determine the correct abstraction level
If the abstractions are wrong, layers need to be bridged (e.g. difficult mapping of existing protocols into the ISO framework) which often ruins the model.
31
3.3.5 Independent components
Independent component architectures consist of a number of independent processes or objects that communicate through messages. Those architectures decouple various portions of the computations in order to achieve modifiability.
3.3.5.1 Event-based, implicit invocation In brief:
System model Independent reactive processes
Components Processes that signal significant events without knowing recipients of signals
Connectors Automatic invocation of processes that have registered interest in events
Control structure Decentralized, individual components are not aware of recipients of signal
Problem:
This pattern is suitable for applications that involve loosely coupled collection of components, each of which carries out some operation and may in the process enable other operations. These are often reactive systems. The pattern is particularly useful for applications that must be reconfigurable on the fly, either by changing a service provider or by enabling and disabling capabilities.
Solution:
The idea behind implicit invocation is that instead of invoking a procedure directly (as it is done traditionally in a system in which the component interfaces provide a collection of procedures and functions), a component can announce (or broadcast) one or more events. Other components in the system can register an interest in an event by associating a procedure with the event. When the event is announced the system itself invokes all of the procedures that have been registered for the event. Thus an event announcement “implicitly” causes the invocation of procedures in other modules.
Architecturally speaking, the components are modules (objects or processes) whose interfaces provide both a collection of procedures and a set of events: allowable incoming and outgoing events.
32
Procedures may be called in the usual way. But in addition, a component can register some of its procedures with events of the system. This will cause these procedures to be invoked when those events are announced at run time. Thus the connectors include traditional procedure call as well as bindings between event announcements and procedure calls.
The main invariant of this style is that announcers of events do not know which components will be affected by those events. Thus components cannot make assumptions about order of processing, or even about what processing will occur as a result of their events.
Implicit invocation Object or Process
Figure 3.5: The Event-Based Implicit Invocation Style
33
Advantages:
• Problem decomposition
Computation and coordination are separate objects thus more independent.
• System evolution
Since there are no static name dependencies, components may be added, replaced or modified without affecting the interfaces of other components in the system.
• Performance
Procedure can be invocated in parallel.
Disadvantages:
• Problem decomposition
This system structure is counter- intuitive.
• Components relinquish control over the computation performed by the system.
They have no knowledge of what component(s) will respond to an event or knowledge of the order and state of responses.
• Exchange of data
Sometimes data can be passed with the event. But in other situations event systems must rely on a shared repository for interaction. In these cases global performance and resource management can become a serious issue.
• Space
Invocations are data-driven thus its implementation might use more space than other styles would.
• Analysis via pre- and post- conditions is difficult
Reasoning about correctness can be problematic, since the meaning of a procedure that announces events will depend on the context of bindings in which it is invoked.
34
3.3.6 Virtual machine
The main quality of virtual machines architectures is portability; those are software styles that simulate some functionality that is not native to the hardware and/or software on which it is implemented. One of the most common examples is the interpreter.
3.3.6.1 Interpreter In brief:
System model Virtual machine Components
One state machine (the execution engine) and three memories (current state of execution engine, program being interpreted, current state of program being interpreted)
Connectors Data access and procedure call
Control structure Usually state-transition for execution engine; input driven for selection of what to interpret
Problem:
This pattern is suitable for applications in which the most appropriate language or machine for executing the solution is not directly available. The pattern is also suitable for applications in which the core problem is defining a notation for expressing solutions, for example as scripts. Interpreters are sometimes used in chains, translating from the desired language/machine to an available language/machine in a series of stages.
Solution:
In an interpreter organization a virtual machine is produced in software. An interpreter includes the pseudo-program being interpreted and the interpretation engine itself.
The pseudo-program includes the program itself and the interpreter’s analog of its execution state (activation record). The interpretation engine includes both the definition of the interpreter and the current state of its execution. Thus an interpreter generally has four components: an interpretation engine to do the work, a memory that contains the pseudo-code to be interpreted, a representation of the control state of the interpretation engine, and a representation of the current state of the program being simulated.
35
Figure 3.6: The Interpreter Style
Interpreters are commonly used to build virtual machines that close the gap between the computing engine expected by the semantics of the program and the computing engine available in hardware. We occasionally speak of a programming language as providing, say, a “virtual Pascal machine.”
Advantages:
• Functionality
Interpreter systems can simulate non-native functionality.
• Testing
Interpreter systems can simulate “disaster” modes (e.g. for safety-critical applications).
• Flexibility
Very general-purpose tool.
Disadvantages:
• Efficiency
It is much, much slower than hardware and much slower than compiled system.
• Testing
An additional layer of software needs to be verified.
36
