Software Architecture
Software architecture refers to the high level structures of a software system. The term can be defined as the set of structures needed to reason about the software system, which comprises the software elements, the relations between them, and the properties of both elements and relations.
The term software architecture also denotes the set of practices used to select, define or design a software architecture.
Finally, the term often denotes the documentation of a systems "software architecture". Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.
Applying the term “architecture” to software systems is a metaphor that refers to the classical field of the architecture of buildings. The term “software architecture” is used to denote three concepts—the:
1. High level structure of a software system
2. Discipline of creating such a high level structure
3. Documentation of this high level structure
Model
An architectural model (in software) is a rich and rigorous diagram, created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture.
Some key elements in software architectural model are:
1. rich: for the viewpoint in question, there should be sufficient information to describe the area in detail. The information should not be lacking or vague. The goal is to minimize misunderstandings, not perpetuate them. See notes below on primary concern.
2. rigorous: the architect has applied a specific methodology to create this particular model, and the resulting model looks a particular way. Heres the test of rigorousness: If two architects, in different cities, were describing the same thing, the resulting diagrams would be nearly identical (with the possible exception of visual layout, to a point).
3. diagram: in general, a model may refer to any abstraction that simplifies something for the sake of addressing a particular viewpoint. This definition specifically subclasses architectural models to the subset of model descriptions that are represented as diagrams.
4. standards: standards work when everyone knows them and everyone uses them. This allows a level of communication that cannot be achieved when each diagram is substantially different from another. UML is the most often quoted standard.
5. primary concern: it is easy to be too detailed by including many different needs in a single diagram. This should be avoided. It is better to draw multiple diagrams, one for each viewpoint, than to draw a mega diagram that is so rich in content that it requires a two-year course of study to understand it. Remember this: when building houses, the architect delivers many different diagrams. Each is used differently. Frequently the final package of plans will include diagrams with the floor plan many times: framing plan, electrical plan, heating plan, plumbing, etc. They dont just say: its a floor plan so 100% of the information that CAN go on a floor plan should be put there. The plumbing subcontractor doesnt need the details that the electrician cares about.
6. illustrate: the idea behind creating a model is to communicate and seek valuable feedback. The goal of the diagram should be to answer a specific question and to share that answer with others to (a) see if they agree, and (b) guide their work. Rule of thumb: know what it is you want to say, and whose work you intend to influence with it.
7. specific set of tradeoffs: the architecture tradeoff analysis method (ATAM) methodology describes a process whereby software architecture can be peer-reviewed for appropriateness. ATAM does this by starting with a basic notion: there is no such thing as a one-size-fits-all design. We can create a generic design, but then we need to alter it to specific situations based on the business requirements. In effect, we make tradeoffs. The diagram should make those specific tradeoffs visible. Therefore, before an architect creates a diagram, he or she should be prepared to describe, in words, which tradeoffs they are attempting to illustrate in this model.
8. tradeoffs inherent in the structure and design: a component is not a tradeoff. Tradoffs rarely translate into an image on the diagram. Tradeoffs are the first principles that produced the design models. When an architect wishes to describe or defend a particular tradeoff, the diagram can be used to defend the position.
9. system or ecosystem: modeling in general can be done at different levels of abstraction. It is useful to model the architecture of a specific application, complete with components and interactions. It is also reasonable to model the systems of applications needed to deliver a complete business process (like order-to-cash). It is not commonly useful, however, to view the model of a single component and its classes as software architecture. At that level, the model, while valuable in its own right, illustrates design much more so than architecture.
Introduction to Software Architecture
Processes
Within the framework of software development, software architecture represents the earliest design decision. It is basically characterized by quality criteria like modifiability, maintainability, security or performance. A once established software architecture is modifiable later on only at great expense and effort. The decision about its design is therefore one of the most critical and important points in the development process of a software.
Stakeholders
Traditional software development has been driven by the need of the delivered software to meet the requirements of users. Although the definition of the term user varies, all software development methods are based around this principle in one way or another.
However, the people affected by a software system are not limited to those who use it. Software systems are not just used: They have to be built and tested, they have to be operated, they may have to be repaired, they are usually enhanced, and of course they have to be paid for. Each of these activities involves a number – possibly a significant number – of people in addition to the users.
Each of these groups of people has its own requirements, interests, and needs to be met by the software system. We refer collectively to these people as stakeholders. Understanding the role of the stakeholder is fundamental to understanding the role of the architect in the development of a software product or system.
We define a stakeholder as follows.
Definition. A stakeholder in the architecture of a system is an individual, team, organization, or classes thereof, having an interest in the realization of the system.
Most system development projects include representatives from most if not all of these stakeholder groups, although their relative importance will obviously vary from project to project. However, if you do not at least consider each class, you will have problems in the future. You need to balance and prioritize the needs of the different stakeholder groups, so that when conflicts occur, you can make sound, well-reasoned decisions.
It is also worth noting that, although we don’t consider the architect’s needs explicitly, when acting in that role you are also an architectural stake- holder.
Principle. The architect must ensure that there is adequate stakeholder representation across the board, including nontechnology stakeholders (such as acquirers and users) and technology-focused ones (such as developers, system administrators, and maintainers).
Engineering Design Process
1) Feasibility stage: identifying a set of feasible concepts for the design as a whole
2) Preliminary design stage: selection and development of the best concept.
3) Detailed design stage: development of engineering descriptions of the concept.
4) Planning stage: evaluating and altering the concept to suit the requirements of production, distribution, consumption and product retirement.
Connectors
Designing and implementing the functionality and managing the data of modern large, complex, distributed, multilingual software systems is undoubtedly very difficult. As discussed in the preceding chapters, early software architectural models of system components, their key services, their abstract behaviors, and their nonfunctional properties are indispensable in this endeavor. However, experience has shown time and again that making architectural design decisions that pertain to integrating those components effectively and ensuring the components proper interaction in a system is just as important. Moreover, arriving at such design decisions can be even more challenging than those restricted to the development of functionality. The particular importance in modern systems of mechanisms for assembling functional components and supporting their interaction, that is, software connectors, mandates that they be treated and studied separately. We will do just that in this chapter, and will return to this subject repeatedly throughout the remainder of the book.
Simply put, software connectors perform transfer of control and data among components. Connectors can also provide services, such as persistence, invocation, messaging, and transactions, that are largely independent of the interacting components functionalities. These services are usually considered to be "facilities components" in widely used middleware standards such as CORBA, DCOM, and RMI. However, recognizing these facilities as connectors helps to clarify an architecture and keep the components focus on application- and domain-specific concerns. Treating these services as connectors rather than components can also foster their reuse across applications and domains. Perhaps most importantly, connectors allow architects and engineers to compose heterogeneous functionality, developed at different times, in different locations, by different organizations. As such, connectors can be thought of quite appropriately as the guards at the gate of separation of concerns.
CONNECTORS IN ACTION: A MOTIVATING EXAMPLE
One useful property of connectors is that they are for the most part application-independent architectural elements. That means that they enable us to understand a lot about how a software system accomplishes its tasks without necessarily having to know exactly what the system does. In other words, connectors directly support two key principles of software engineering: abstraction and separation of concerns. Explicitly focusing on connectors also enables development and use of a specific vocabulary of software interaction. In turn, agreeing on appropriate terminology allows us to communicate easily and reason precisely about a number of software system properties that derive from the system components interactions. To illustrate this, we use a very simple example involving two different types of connectors. We intentionally use the terminology associated with those connectors without defining it, to draw attention to this new "language." The appropriate definitions and explanations will be given in the subsequent sections. Nonetheless, you will probably find that you are familiar with some, if not most, of this terminology.
CONNECTOR FOUNDATIONS
The underlying, elementary building blocks of every connector are the primitives for managing the flow of control (that is, changing the processor program counter) and flow of data (that is, performing memory access) in a system. These primitives give enough conceptual power to build sophisticated and complex connectors. In addition to these primitives, every connector maintains one or more channels, also referred to as ducts, which are used to link the interacting components and support the flow of data and control between them. A duct is necessary for realizing a connector, but by itself, it does not provide any additional interaction services. Very simple connectors, such as module linkers, provide their service simply by forming ducts between components. Other connectors augment ducts with some combination of data and control flow to provide richer interaction services. Very complex connectors can also have an internal architecture that includes computation and information storage. For example, a load balancing connector would execute an algorithm for switching incoming traffic among a set of components based on the knowledge about the current and past load state of components.
CONNECTOR TYPES AND THEIR VARIATION DIMENSIONS
Interaction services broadly categorize connectors, but leave many details unexplained. This level of abstraction cannot help us build new connectors, and it cannot be used to model and analyze them in an architecture. Hence, we further classify connectors into eight different types, based on the way in which they realize interaction services:
Procedure call
Event
Data access
Linkage
Stream
Arbitrator
Adaptor
Distributor
Modeling
As we have stated, every software system has an architecture, whether it is a "good" architecture or not. We have previously defined architecture as the set of principal design decisions about a system. Once design decisions have been made, they can be recorded. Design decisions are captured in models; the process of creating models is called modeling. From Chapter 3 we have:
Definitions. An architectural model is an artifact that captures some or all of the design decisions that comprise a systems architecture. Architectural modeling is the reification and documentation of those design decisions.
AMBIGUITY, ACCURACY, AND PRECISION
Architectures are abstractions of systems. They capture information about some aspects of the system and leave out other aspects. Ideally, the principal, most important aspects of a system will be well defined by the architecture. The parts that are specified may describe the nominal state of the system and leave out unusual states. This is, to some extent, normal: Architectures are not meant to be complete implementations of a system. Consequently, the notations used to capture architectures do not have to be completely unambiguous, accurate, and precise.
Three key concepts can be used to characterize architectural models: ambiguity, accuracy, and precision.
what is software architecture?
SPECIFIC MODELING TECHNIQUES
Architects have at their disposal a panoply of notations and techniques for modeling different aspects of architectures. These techniques vary along many dimensions: what they can model, how precisely they can capture architectural semantics, how good their tool support is, and so on. Which methods are used, and for what purposes, will be largely up to a systems architects and stakeholders. While many approaches for modeling architectures are broadly scoped and applicable to many systems in many domains, it is important not to become dogmatically attached to any one approach.
Visualization
The previous chapter covered modeling: how we capture the design decisions that make up a software systems architecture. In practice, there are often different ways to display and interact with the information contained in those models. This is the domain of architectural visualization.
Definition. An architectural visualization defines how architectural models are depicted, and how stakeholders interact with those depictions.
VISUALIZATION CONCEPTS
Visualization plays a critical role in software architecture. The most important message of this chapter is that the way architectures are visualized can be, to an extent, separate from the way they are modeled. The two are closely related; in fact, each modeling notation is associated with one or more canonical or native visualizations. (This will be discussed in more detail below.) Fundamentally, however, a model is just organized information. In the case of architectural models, the information consists of design decisions. Visualizations are the means by which the information in a model is given form: how it is depicted and how users interact with it.
A single architectural model can be visualized in any number of ways, and multiple diverse models can be visualized in similar ways. Thus, visualization can be used to hide (or at least smooth over) differences in back-end modeling notations. Second, visualizations can vary widely—many are graphical, but most ADLs have textual visualizations as well. Research has even been done in the area of esoteric visualizations, such as three-dimensional virtual realities (Feijs and De Jong 1998).
Analysis
Rigorous models of software architectures present a number of advantages over informal boxes-and-lines diagrams. They force the software architect to address issues that might otherwise be missed or ignored. They allow more precise communication among the systems various stakeholders and form a solid blueprint for the systems construction, deployment, execution, and evolution. And they typically present more detail about the architecture than do informal models, so that more questions can be asked and answered more precisely—although there are certainly times where sufficient understanding about certain aspects of a system can be obtained even from informal models.
Definition. Architectural analysis is the activity of discovering important system properties using the systems architectural models.
SCOPE OF ANALYSIS
A software systems architecture can be analyzed from different perspectives and at different levels. Architects may be interested in assessing the properties of individual components or connectors, or even their constituent elements, such as interfaces or ports. More frequently, architects may be interested in the properties exhibited by compositions of components and connectors in a given subsystem or entire system. A specific focus of (sub)system-level analysis may be on the data exchanged among the system elements.
In addition to assessing the properties of a single architecture, architects may at times need to consider two or more architectures simultaneously. One such case is when a given systems architecture is analyzed at multiple levels of abstraction. For example, a more detailed architectural model may be compared to the higher-level model from which it has been derived, to ensure that no existing design decisions have been violated or unintended design decisions introduced. A similar type of analysis takes place when two architectural models at similar levels of abstraction are compared to establish design similarities or conformance to constraints such as those embodied in a reference architecture.
ARCHITECTURAL CONCERN BEING ANALYZED
Architectural analysis techniques are directed at different facets of a given architecture. Some techniques strive to ensure primarily the architectures structural properties; others focus on the behaviors provided by the architectural elements and their composition; yet others may analyze whether the interactions among the architectural elements adhere to certain requirements and constraints; finally, the non-functional properties exhibited by the architecture are frequently considered to be very important and are thus studied carefully.
ANALYSIS TECHNIQUES
A large number of analysis techniques are available to software architects. Some of them are variations on techniques applied to other software development artifacts—primarily formal specifications and code—while others have been developed specifically with software architectures in mind. In this section we discuss a cross-section of architectural analysis techniques. Although it is not intended to provide a complete overview of existing techniques, the cross-section is broadly representative.
Implementation
Implementation is the one phase of software development that is not optional. Regardless of how well the requirements have been captured or how carefully the architecture has been designed and reviewed, software systems must be implemented in code to achieve their ends. Architecture is used to capture important design decisions about a system, using sound engineering principles and knowledge to increase confidence that the target systems qualities match the expectations of its stakeholders. To imbue these qualities in the target system, the implementation must be derived from its architecture.
In terms of implementation, architecture is both prescriptive and restrictive. It is prescriptive in the sense that it gives implementers direction on what to produce—how to structure code modules, how they should be interconnected, and how they should behave. It is restrictive in the sense that its guidelines—particularly those specified in the architectural style—tell developers what they may not do: the forms of communication that are prohibited, the kinds of behaviors or system states that are not allowed, and so on.
EXAMPLES
We have introduced many architectural alternatives for the Lunar Lander application; Chapter 4 presents a catalog of architectural styles, with Lunar Lander designed to fit the constraints of each style. Here, we will examine how architecture frameworks can be used to assist in the construction of working Lunar Lander implementations in two of those styles: pipe-and-filter and C2.
Note that the following sections will include code samples showing actual implementations of Lunar Lander. Certain good coding practices, such as the use of externalized string constants, comprehensive exception and null-value checking, and so on will be left out for simplicitys sake. Real implementations should take these practices into account as they apply equally when doing architecture-based software development.
Deployment and Mobility
After a software system has been designed, implemented, and validated, it is ready for operation. That usually requires that the systems components and connectors first be distributed to the "target" hardware processors. A software system cannot fulfill its purpose until it is deployed, that is, until its executable modules are physically placed on the hardware devices on which they are supposed to run. The outcome of the activity of placing a systems software components on its hardware hosts is the deployment of the systems architecture.
Once the system is in operation, it is possible, and often necessary, to change the physical location of its hardware hosts. For example, laptop computers, personal digital assistants (PDAs), cellular telephones, software-controlled radios, and computers embedded in a vehicle, all move regularly while staying connected. More challenging, more interesting to a software engineer (and even a user), and more pertinent to this book is the relocation or migration of a software component or connector from one hardware host to another. This may need to be done to improve the systems performance, perhaps by collocating a processing component with the data it needs, lessen the computational load on a given host, or to achieve some other property. Relocating software modules in this manner changes the deployment view of the software systems architecture during the systems run time, and is referred to as migration or redeployment. Run time system migration (or redeployment) is thus a type of a software systems mobility.
Architecting Non Functional Requirements
Designing for Non-Functional Properties
Engineering software systems so that they satisfy all their myriad functional requirements is difficult. As we have seen so far, software architectures can help in that task through effective compositions of well-defined components and connectors, which have been verified to adhere to the necessary structural, behavioral, and interaction constraints. While satisfying functional requirements is essential, unfortunately it is not sufficient. Software developers must also provide for non-functional properties (NFPs) of software systems.
Definition. A non-functional property (NFP) of a software system is a constraint on the manner in which the system implements and delivers its functionality.
EFFICIENCY
Definition. Efficiency is a quality that reflects a software systems ability to meet its performance requirements while minimizing its usage of the resources in its computing environment. In other words, efficiency is a measure of a systems resource usage economy.
Note that this definition does not directly address the issue of system correctness. Instead, it implicitly assumes that the system will function as required. In other words, a system cannot be considered efficient if it implements the wrong functionality.
COMPLEXITY
Software complexity can be thought of from different perspectives, and thus defined in different ways. For example, the IEEE definition of complexity (IEEE 1991) is as follows.
Definition. Complexity is the degree to which a software system or one of its components has a design or implementation that is difficult to understand and verify.
SCALABILITY AND HETEROGENEITY
Definition. Scalability is the capability of a software system to be adapted to meet new requirements of size and scope.
Even though a systems scalability refers to its ability to be grown or shrunk to meet changes in the size of the problem, traditionally the difficulty faced by software engineers has been in supporting larger and thus more complex systems. Therefore, we will restrict our discussion to scaling software systems up.
ADAPTABILITY
Definition. Adaptability is a software systems ability to satisfy new requirements and adjust to new operating conditions during its lifetime. Adaptability can be manual or automated. A software systems architecture has an impact on either type of adaptability.
DEPENDABILITY
Software dependability researchers Bev Littlewood and Lorenzo Strigini define dependability informally as a collection of system properties that allows one to rely on a system functioning as required (Littlewood and Strigini 2000). Dependability is a composite NFP that encompasses several other, related NFPs: reliability, availability, robustness, fault-tolerance, survivability, safety, and security. Security is discussed in detail in Chapter 13; here, we focus on the design guidelines required to ensure the remaining facets of dependability in a systems software architecture. The following definitions illustrate the interrelated nature of these different facets of dependability. The role of software architecture in ensuring a software systems dependability is then discussed.
Definition. A software systems reliability is the probability that the system will perform its intended functionality under specified design limits, without failure, over a given time period.
Definition. A software systems availability is the probability that the system is operational at a particular time.
Domain-Specific Software Engineering
Software systems differ in terms of their purpose, size, complexity, provided functionality, quality needs, intended usage, expected or required execution context, involved stakeholders and their concerns, level of criticality to system users, and so on. An argument can be made that this is precisely why software is difficult to develop. However, such differences across individual systems are not unique to software engineering. They can be found in any complex system and any engineering discipline.
As an example, consider two different products of modern engineering: airplanes and television sets. Both airplanes and televisions are complex systems, but their functionalities differ a great deal. They also have very different quality requirements. While it is certainly important for a television to function reliably, in the case of airplanes reliability can be a matter of life and death. Travelers expect airplanes to be robust in the face of atypical situations such as storms, turbulence, loss of cabin air pressure or engine or electrical power, and physical damage to the aircraft. On the other hand, consumers understand when, say, an electrical power surge damages their TV set and are content to wait for the TV to be repaired or simply will buy a new one. People expect that an airplane may be in use for decades and that it will need to be refurbished and upgraded during that time. They do not have the same expectations of a television.
DSSAS, PRODUCT LINES, AND ARCHITECTURAL STYLES
We have discussed domain-specific software architectures (DSSAs) and product lines, as well as their relationship to each other. A natural question arises at this point: What are the relationships among DSSAs, product lines, and architectural styles?
Recall that architectural styles represent a reusable package of design decisions that can be applied to different products to elicit desired qualities. In some sense, both DSSAs and product-line architectures can be seen in the same light. Usually, however, architectural styles are far more general than DSSAs or product lines. Most architectural styles can be applied across many domains. For example, the pipe-and-filter style has been used to develop text-processing applications, typesetting systems, and program compilers. Typically, such diverse applications would not all be members of the same DSSA or product line.
Conventional Architectural styles
Pipes and Filters
In software engineering, a pipeline consists of a chain of processing elements (processes, threads, coroutines, etc.), arranged so that the output of each element is the input of the next; the name is by analogy to a physical pipeline. Usually some amount of buffering is provided between consecutive elements. The information that flows in these pipelines is often a stream of records, bytes or bits, and the elements of a pipeline may be called filters; this is also called the pipes and filters design pattern. Connecting elements into a pipeline is analogous to function composition.
Narrowly speaking, a pipeline is linear and one-directional, though sometimes the term is applied to more general flows. For example, a primarily one-directional pipeline may have some communication in the other direction, known as a return channel or backchannel, as in the lexer hack, or a pipeline may be fully bi-directional. Flows with one-directional tree and directed acyclic graph topologies behave similarly to (linear) pipelines – the lack of cycles makes them simple – and thus may be loosely referred to as "pipelines".
Pipelines are often implemented in a multitasking OS, by launching all elements at the same time as processes, and automatically servicing the data read requests by each process with the data written by the upstream process – this can be called a multiprocessed pipeline. In this way, the CPU will be naturally switched among the processes by the scheduler so as to minimize its idle time. In other common models, elements are implemented as lightweight threads or as coroutines to reduce the OS overhead often involved with processes. Depending upon the OS, threads may be scheduled directly by the OS or by a thread manager. Coroutines are always scheduled by a coroutine manager of some form.
Usually, read and write requests are blocking operations, which means that the execution of the source process, upon writing, is suspended until all data could be written to the destination process, and, likewise, the execution of the destination process, upon reading, is suspended until at least some of the requested data could be obtained from the source process. This cannot lead to a deadlock, where both processes would wait indefinitely for each other to respond, since at least one of the two processes will soon thereafter have its request serviced by the operating system, and continue to run.
Implicit Invocation Style
1. Event announcement instead of method invocation
“Listeners” register interest in and associate methods with events
System invokes all registered methods implicitly
2. Component interfaces are methods and events
3. Two types of connectors
Invocation is either explicit or implicit in response to events
4. Style invariants
“Announcers” are unaware of their events’ effects
No assumption about processing in response to events
Advantages
Component reuse
System evolution-Both at system construction-time & run-time
Disadvantages
Counter-intuitive system structure
Components relinquish computation control to the system
No knowledge of what components will respond to event
No knowledge of order of responses
Layered Style
1. Hierarchical system organization
“Multi-level client-server”
Each layer exposes an interface (API) to be used by above layers
2. Each layer acts as a
Server: service provider to layers “above”
Client: service consumer of layer(s) “below”
3. Connectors are protocols of layer interaction
4. Example: operating systems
5. Virtual machine style results from fully opaque layers
Interpreter Style
Interpreter parses and executes input commands, updating the state maintained by the interpreter
1. Components: Command interpreter, program/interpreter state, user interface.
2. Connectors: Typically very closely bound with direct procedure calls and shared state.
3. Highly dynamic behavior possible, where the set of commands is dynamically modified. System architecture may remain constant while new capabilities are created based upon existing primitives.
4. Superb for end-user programmability; supports dynamically changing set of capabilities
5. Lisp and Scheme
Software architecture refers to the high level structures of a software system. The term can be defined as the set of structures needed to reason about the software system, which comprises the software elements, the relations between them, and the properties of both elements and relations.
The term software architecture also denotes the set of practices used to select, define or design a software architecture.
Finally, the term often denotes the documentation of a systems "software architecture". Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.
Applying the term “architecture” to software systems is a metaphor that refers to the classical field of the architecture of buildings. The term “software architecture” is used to denote three concepts—the:
1. High level structure of a software system
2. Discipline of creating such a high level structure
3. Documentation of this high level structure
Model
An architectural model (in software) is a rich and rigorous diagram, created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture.
Some key elements in software architectural model are:
1. rich: for the viewpoint in question, there should be sufficient information to describe the area in detail. The information should not be lacking or vague. The goal is to minimize misunderstandings, not perpetuate them. See notes below on primary concern.
2. rigorous: the architect has applied a specific methodology to create this particular model, and the resulting model looks a particular way. Heres the test of rigorousness: If two architects, in different cities, were describing the same thing, the resulting diagrams would be nearly identical (with the possible exception of visual layout, to a point).
3. diagram: in general, a model may refer to any abstraction that simplifies something for the sake of addressing a particular viewpoint. This definition specifically subclasses architectural models to the subset of model descriptions that are represented as diagrams.
4. standards: standards work when everyone knows them and everyone uses them. This allows a level of communication that cannot be achieved when each diagram is substantially different from another. UML is the most often quoted standard.
5. primary concern: it is easy to be too detailed by including many different needs in a single diagram. This should be avoided. It is better to draw multiple diagrams, one for each viewpoint, than to draw a mega diagram that is so rich in content that it requires a two-year course of study to understand it. Remember this: when building houses, the architect delivers many different diagrams. Each is used differently. Frequently the final package of plans will include diagrams with the floor plan many times: framing plan, electrical plan, heating plan, plumbing, etc. They dont just say: its a floor plan so 100% of the information that CAN go on a floor plan should be put there. The plumbing subcontractor doesnt need the details that the electrician cares about.
6. illustrate: the idea behind creating a model is to communicate and seek valuable feedback. The goal of the diagram should be to answer a specific question and to share that answer with others to (a) see if they agree, and (b) guide their work. Rule of thumb: know what it is you want to say, and whose work you intend to influence with it.
7. specific set of tradeoffs: the architecture tradeoff analysis method (ATAM) methodology describes a process whereby software architecture can be peer-reviewed for appropriateness. ATAM does this by starting with a basic notion: there is no such thing as a one-size-fits-all design. We can create a generic design, but then we need to alter it to specific situations based on the business requirements. In effect, we make tradeoffs. The diagram should make those specific tradeoffs visible. Therefore, before an architect creates a diagram, he or she should be prepared to describe, in words, which tradeoffs they are attempting to illustrate in this model.
8. tradeoffs inherent in the structure and design: a component is not a tradeoff. Tradoffs rarely translate into an image on the diagram. Tradeoffs are the first principles that produced the design models. When an architect wishes to describe or defend a particular tradeoff, the diagram can be used to defend the position.
9. system or ecosystem: modeling in general can be done at different levels of abstraction. It is useful to model the architecture of a specific application, complete with components and interactions. It is also reasonable to model the systems of applications needed to deliver a complete business process (like order-to-cash). It is not commonly useful, however, to view the model of a single component and its classes as software architecture. At that level, the model, while valuable in its own right, illustrates design much more so than architecture.
Introduction to Software Architecture
Processes
Within the framework of software development, software architecture represents the earliest design decision. It is basically characterized by quality criteria like modifiability, maintainability, security or performance. A once established software architecture is modifiable later on only at great expense and effort. The decision about its design is therefore one of the most critical and important points in the development process of a software.
Stakeholders
Traditional software development has been driven by the need of the delivered software to meet the requirements of users. Although the definition of the term user varies, all software development methods are based around this principle in one way or another.
However, the people affected by a software system are not limited to those who use it. Software systems are not just used: They have to be built and tested, they have to be operated, they may have to be repaired, they are usually enhanced, and of course they have to be paid for. Each of these activities involves a number – possibly a significant number – of people in addition to the users.
Each of these groups of people has its own requirements, interests, and needs to be met by the software system. We refer collectively to these people as stakeholders. Understanding the role of the stakeholder is fundamental to understanding the role of the architect in the development of a software product or system.
We define a stakeholder as follows.
Definition. A stakeholder in the architecture of a system is an individual, team, organization, or classes thereof, having an interest in the realization of the system.
Most system development projects include representatives from most if not all of these stakeholder groups, although their relative importance will obviously vary from project to project. However, if you do not at least consider each class, you will have problems in the future. You need to balance and prioritize the needs of the different stakeholder groups, so that when conflicts occur, you can make sound, well-reasoned decisions.
It is also worth noting that, although we don’t consider the architect’s needs explicitly, when acting in that role you are also an architectural stake- holder.
Principle. The architect must ensure that there is adequate stakeholder representation across the board, including nontechnology stakeholders (such as acquirers and users) and technology-focused ones (such as developers, system administrators, and maintainers).
Engineering Design Process
1) Feasibility stage: identifying a set of feasible concepts for the design as a whole
2) Preliminary design stage: selection and development of the best concept.
3) Detailed design stage: development of engineering descriptions of the concept.
4) Planning stage: evaluating and altering the concept to suit the requirements of production, distribution, consumption and product retirement.
Connectors
Designing and implementing the functionality and managing the data of modern large, complex, distributed, multilingual software systems is undoubtedly very difficult. As discussed in the preceding chapters, early software architectural models of system components, their key services, their abstract behaviors, and their nonfunctional properties are indispensable in this endeavor. However, experience has shown time and again that making architectural design decisions that pertain to integrating those components effectively and ensuring the components proper interaction in a system is just as important. Moreover, arriving at such design decisions can be even more challenging than those restricted to the development of functionality. The particular importance in modern systems of mechanisms for assembling functional components and supporting their interaction, that is, software connectors, mandates that they be treated and studied separately. We will do just that in this chapter, and will return to this subject repeatedly throughout the remainder of the book.
Simply put, software connectors perform transfer of control and data among components. Connectors can also provide services, such as persistence, invocation, messaging, and transactions, that are largely independent of the interacting components functionalities. These services are usually considered to be "facilities components" in widely used middleware standards such as CORBA, DCOM, and RMI. However, recognizing these facilities as connectors helps to clarify an architecture and keep the components focus on application- and domain-specific concerns. Treating these services as connectors rather than components can also foster their reuse across applications and domains. Perhaps most importantly, connectors allow architects and engineers to compose heterogeneous functionality, developed at different times, in different locations, by different organizations. As such, connectors can be thought of quite appropriately as the guards at the gate of separation of concerns.
CONNECTORS IN ACTION: A MOTIVATING EXAMPLE
One useful property of connectors is that they are for the most part application-independent architectural elements. That means that they enable us to understand a lot about how a software system accomplishes its tasks without necessarily having to know exactly what the system does. In other words, connectors directly support two key principles of software engineering: abstraction and separation of concerns. Explicitly focusing on connectors also enables development and use of a specific vocabulary of software interaction. In turn, agreeing on appropriate terminology allows us to communicate easily and reason precisely about a number of software system properties that derive from the system components interactions. To illustrate this, we use a very simple example involving two different types of connectors. We intentionally use the terminology associated with those connectors without defining it, to draw attention to this new "language." The appropriate definitions and explanations will be given in the subsequent sections. Nonetheless, you will probably find that you are familiar with some, if not most, of this terminology.
CONNECTOR FOUNDATIONS
The underlying, elementary building blocks of every connector are the primitives for managing the flow of control (that is, changing the processor program counter) and flow of data (that is, performing memory access) in a system. These primitives give enough conceptual power to build sophisticated and complex connectors. In addition to these primitives, every connector maintains one or more channels, also referred to as ducts, which are used to link the interacting components and support the flow of data and control between them. A duct is necessary for realizing a connector, but by itself, it does not provide any additional interaction services. Very simple connectors, such as module linkers, provide their service simply by forming ducts between components. Other connectors augment ducts with some combination of data and control flow to provide richer interaction services. Very complex connectors can also have an internal architecture that includes computation and information storage. For example, a load balancing connector would execute an algorithm for switching incoming traffic among a set of components based on the knowledge about the current and past load state of components.
CONNECTOR TYPES AND THEIR VARIATION DIMENSIONS
Interaction services broadly categorize connectors, but leave many details unexplained. This level of abstraction cannot help us build new connectors, and it cannot be used to model and analyze them in an architecture. Hence, we further classify connectors into eight different types, based on the way in which they realize interaction services:
Procedure call
Event
Data access
Linkage
Stream
Arbitrator
Adaptor
Distributor
Modeling
As we have stated, every software system has an architecture, whether it is a "good" architecture or not. We have previously defined architecture as the set of principal design decisions about a system. Once design decisions have been made, they can be recorded. Design decisions are captured in models; the process of creating models is called modeling. From Chapter 3 we have:
Definitions. An architectural model is an artifact that captures some or all of the design decisions that comprise a systems architecture. Architectural modeling is the reification and documentation of those design decisions.
AMBIGUITY, ACCURACY, AND PRECISION
Architectures are abstractions of systems. They capture information about some aspects of the system and leave out other aspects. Ideally, the principal, most important aspects of a system will be well defined by the architecture. The parts that are specified may describe the nominal state of the system and leave out unusual states. This is, to some extent, normal: Architectures are not meant to be complete implementations of a system. Consequently, the notations used to capture architectures do not have to be completely unambiguous, accurate, and precise.
Three key concepts can be used to characterize architectural models: ambiguity, accuracy, and precision.
what is software architecture?
SPECIFIC MODELING TECHNIQUES
Architects have at their disposal a panoply of notations and techniques for modeling different aspects of architectures. These techniques vary along many dimensions: what they can model, how precisely they can capture architectural semantics, how good their tool support is, and so on. Which methods are used, and for what purposes, will be largely up to a systems architects and stakeholders. While many approaches for modeling architectures are broadly scoped and applicable to many systems in many domains, it is important not to become dogmatically attached to any one approach.
Visualization
The previous chapter covered modeling: how we capture the design decisions that make up a software systems architecture. In practice, there are often different ways to display and interact with the information contained in those models. This is the domain of architectural visualization.
Definition. An architectural visualization defines how architectural models are depicted, and how stakeholders interact with those depictions.
VISUALIZATION CONCEPTS
Visualization plays a critical role in software architecture. The most important message of this chapter is that the way architectures are visualized can be, to an extent, separate from the way they are modeled. The two are closely related; in fact, each modeling notation is associated with one or more canonical or native visualizations. (This will be discussed in more detail below.) Fundamentally, however, a model is just organized information. In the case of architectural models, the information consists of design decisions. Visualizations are the means by which the information in a model is given form: how it is depicted and how users interact with it.
A single architectural model can be visualized in any number of ways, and multiple diverse models can be visualized in similar ways. Thus, visualization can be used to hide (or at least smooth over) differences in back-end modeling notations. Second, visualizations can vary widely—many are graphical, but most ADLs have textual visualizations as well. Research has even been done in the area of esoteric visualizations, such as three-dimensional virtual realities (Feijs and De Jong 1998).
Analysis
Rigorous models of software architectures present a number of advantages over informal boxes-and-lines diagrams. They force the software architect to address issues that might otherwise be missed or ignored. They allow more precise communication among the systems various stakeholders and form a solid blueprint for the systems construction, deployment, execution, and evolution. And they typically present more detail about the architecture than do informal models, so that more questions can be asked and answered more precisely—although there are certainly times where sufficient understanding about certain aspects of a system can be obtained even from informal models.
Definition. Architectural analysis is the activity of discovering important system properties using the systems architectural models.
SCOPE OF ANALYSIS
A software systems architecture can be analyzed from different perspectives and at different levels. Architects may be interested in assessing the properties of individual components or connectors, or even their constituent elements, such as interfaces or ports. More frequently, architects may be interested in the properties exhibited by compositions of components and connectors in a given subsystem or entire system. A specific focus of (sub)system-level analysis may be on the data exchanged among the system elements.
In addition to assessing the properties of a single architecture, architects may at times need to consider two or more architectures simultaneously. One such case is when a given systems architecture is analyzed at multiple levels of abstraction. For example, a more detailed architectural model may be compared to the higher-level model from which it has been derived, to ensure that no existing design decisions have been violated or unintended design decisions introduced. A similar type of analysis takes place when two architectural models at similar levels of abstraction are compared to establish design similarities or conformance to constraints such as those embodied in a reference architecture.
ARCHITECTURAL CONCERN BEING ANALYZED
Architectural analysis techniques are directed at different facets of a given architecture. Some techniques strive to ensure primarily the architectures structural properties; others focus on the behaviors provided by the architectural elements and their composition; yet others may analyze whether the interactions among the architectural elements adhere to certain requirements and constraints; finally, the non-functional properties exhibited by the architecture are frequently considered to be very important and are thus studied carefully.
ANALYSIS TECHNIQUES
A large number of analysis techniques are available to software architects. Some of them are variations on techniques applied to other software development artifacts—primarily formal specifications and code—while others have been developed specifically with software architectures in mind. In this section we discuss a cross-section of architectural analysis techniques. Although it is not intended to provide a complete overview of existing techniques, the cross-section is broadly representative.
Implementation
Implementation is the one phase of software development that is not optional. Regardless of how well the requirements have been captured or how carefully the architecture has been designed and reviewed, software systems must be implemented in code to achieve their ends. Architecture is used to capture important design decisions about a system, using sound engineering principles and knowledge to increase confidence that the target systems qualities match the expectations of its stakeholders. To imbue these qualities in the target system, the implementation must be derived from its architecture.
In terms of implementation, architecture is both prescriptive and restrictive. It is prescriptive in the sense that it gives implementers direction on what to produce—how to structure code modules, how they should be interconnected, and how they should behave. It is restrictive in the sense that its guidelines—particularly those specified in the architectural style—tell developers what they may not do: the forms of communication that are prohibited, the kinds of behaviors or system states that are not allowed, and so on.
EXAMPLES
We have introduced many architectural alternatives for the Lunar Lander application; Chapter 4 presents a catalog of architectural styles, with Lunar Lander designed to fit the constraints of each style. Here, we will examine how architecture frameworks can be used to assist in the construction of working Lunar Lander implementations in two of those styles: pipe-and-filter and C2.
Note that the following sections will include code samples showing actual implementations of Lunar Lander. Certain good coding practices, such as the use of externalized string constants, comprehensive exception and null-value checking, and so on will be left out for simplicitys sake. Real implementations should take these practices into account as they apply equally when doing architecture-based software development.
Deployment and Mobility
After a software system has been designed, implemented, and validated, it is ready for operation. That usually requires that the systems components and connectors first be distributed to the "target" hardware processors. A software system cannot fulfill its purpose until it is deployed, that is, until its executable modules are physically placed on the hardware devices on which they are supposed to run. The outcome of the activity of placing a systems software components on its hardware hosts is the deployment of the systems architecture.
Once the system is in operation, it is possible, and often necessary, to change the physical location of its hardware hosts. For example, laptop computers, personal digital assistants (PDAs), cellular telephones, software-controlled radios, and computers embedded in a vehicle, all move regularly while staying connected. More challenging, more interesting to a software engineer (and even a user), and more pertinent to this book is the relocation or migration of a software component or connector from one hardware host to another. This may need to be done to improve the systems performance, perhaps by collocating a processing component with the data it needs, lessen the computational load on a given host, or to achieve some other property. Relocating software modules in this manner changes the deployment view of the software systems architecture during the systems run time, and is referred to as migration or redeployment. Run time system migration (or redeployment) is thus a type of a software systems mobility.
Architecting Non Functional Requirements
Designing for Non-Functional Properties
Engineering software systems so that they satisfy all their myriad functional requirements is difficult. As we have seen so far, software architectures can help in that task through effective compositions of well-defined components and connectors, which have been verified to adhere to the necessary structural, behavioral, and interaction constraints. While satisfying functional requirements is essential, unfortunately it is not sufficient. Software developers must also provide for non-functional properties (NFPs) of software systems.
Definition. A non-functional property (NFP) of a software system is a constraint on the manner in which the system implements and delivers its functionality.
EFFICIENCY
Definition. Efficiency is a quality that reflects a software systems ability to meet its performance requirements while minimizing its usage of the resources in its computing environment. In other words, efficiency is a measure of a systems resource usage economy.
Note that this definition does not directly address the issue of system correctness. Instead, it implicitly assumes that the system will function as required. In other words, a system cannot be considered efficient if it implements the wrong functionality.
COMPLEXITY
Software complexity can be thought of from different perspectives, and thus defined in different ways. For example, the IEEE definition of complexity (IEEE 1991) is as follows.
Definition. Complexity is the degree to which a software system or one of its components has a design or implementation that is difficult to understand and verify.
SCALABILITY AND HETEROGENEITY
Definition. Scalability is the capability of a software system to be adapted to meet new requirements of size and scope.
Even though a systems scalability refers to its ability to be grown or shrunk to meet changes in the size of the problem, traditionally the difficulty faced by software engineers has been in supporting larger and thus more complex systems. Therefore, we will restrict our discussion to scaling software systems up.
ADAPTABILITY
Definition. Adaptability is a software systems ability to satisfy new requirements and adjust to new operating conditions during its lifetime. Adaptability can be manual or automated. A software systems architecture has an impact on either type of adaptability.
DEPENDABILITY
Software dependability researchers Bev Littlewood and Lorenzo Strigini define dependability informally as a collection of system properties that allows one to rely on a system functioning as required (Littlewood and Strigini 2000). Dependability is a composite NFP that encompasses several other, related NFPs: reliability, availability, robustness, fault-tolerance, survivability, safety, and security. Security is discussed in detail in Chapter 13; here, we focus on the design guidelines required to ensure the remaining facets of dependability in a systems software architecture. The following definitions illustrate the interrelated nature of these different facets of dependability. The role of software architecture in ensuring a software systems dependability is then discussed.
Definition. A software systems reliability is the probability that the system will perform its intended functionality under specified design limits, without failure, over a given time period.
Definition. A software systems availability is the probability that the system is operational at a particular time.
Domain-Specific Software Engineering
Software systems differ in terms of their purpose, size, complexity, provided functionality, quality needs, intended usage, expected or required execution context, involved stakeholders and their concerns, level of criticality to system users, and so on. An argument can be made that this is precisely why software is difficult to develop. However, such differences across individual systems are not unique to software engineering. They can be found in any complex system and any engineering discipline.
As an example, consider two different products of modern engineering: airplanes and television sets. Both airplanes and televisions are complex systems, but their functionalities differ a great deal. They also have very different quality requirements. While it is certainly important for a television to function reliably, in the case of airplanes reliability can be a matter of life and death. Travelers expect airplanes to be robust in the face of atypical situations such as storms, turbulence, loss of cabin air pressure or engine or electrical power, and physical damage to the aircraft. On the other hand, consumers understand when, say, an electrical power surge damages their TV set and are content to wait for the TV to be repaired or simply will buy a new one. People expect that an airplane may be in use for decades and that it will need to be refurbished and upgraded during that time. They do not have the same expectations of a television.
DSSAS, PRODUCT LINES, AND ARCHITECTURAL STYLES
We have discussed domain-specific software architectures (DSSAs) and product lines, as well as their relationship to each other. A natural question arises at this point: What are the relationships among DSSAs, product lines, and architectural styles?
Recall that architectural styles represent a reusable package of design decisions that can be applied to different products to elicit desired qualities. In some sense, both DSSAs and product-line architectures can be seen in the same light. Usually, however, architectural styles are far more general than DSSAs or product lines. Most architectural styles can be applied across many domains. For example, the pipe-and-filter style has been used to develop text-processing applications, typesetting systems, and program compilers. Typically, such diverse applications would not all be members of the same DSSA or product line.
Conventional Architectural styles
Pipes and Filters
In software engineering, a pipeline consists of a chain of processing elements (processes, threads, coroutines, etc.), arranged so that the output of each element is the input of the next; the name is by analogy to a physical pipeline. Usually some amount of buffering is provided between consecutive elements. The information that flows in these pipelines is often a stream of records, bytes or bits, and the elements of a pipeline may be called filters; this is also called the pipes and filters design pattern. Connecting elements into a pipeline is analogous to function composition.
Narrowly speaking, a pipeline is linear and one-directional, though sometimes the term is applied to more general flows. For example, a primarily one-directional pipeline may have some communication in the other direction, known as a return channel or backchannel, as in the lexer hack, or a pipeline may be fully bi-directional. Flows with one-directional tree and directed acyclic graph topologies behave similarly to (linear) pipelines – the lack of cycles makes them simple – and thus may be loosely referred to as "pipelines".
Pipelines are often implemented in a multitasking OS, by launching all elements at the same time as processes, and automatically servicing the data read requests by each process with the data written by the upstream process – this can be called a multiprocessed pipeline. In this way, the CPU will be naturally switched among the processes by the scheduler so as to minimize its idle time. In other common models, elements are implemented as lightweight threads or as coroutines to reduce the OS overhead often involved with processes. Depending upon the OS, threads may be scheduled directly by the OS or by a thread manager. Coroutines are always scheduled by a coroutine manager of some form.
Usually, read and write requests are blocking operations, which means that the execution of the source process, upon writing, is suspended until all data could be written to the destination process, and, likewise, the execution of the destination process, upon reading, is suspended until at least some of the requested data could be obtained from the source process. This cannot lead to a deadlock, where both processes would wait indefinitely for each other to respond, since at least one of the two processes will soon thereafter have its request serviced by the operating system, and continue to run.
Implicit Invocation Style
1. Event announcement instead of method invocation
“Listeners” register interest in and associate methods with events
System invokes all registered methods implicitly
2. Component interfaces are methods and events
3. Two types of connectors
Invocation is either explicit or implicit in response to events
4. Style invariants
“Announcers” are unaware of their events’ effects
No assumption about processing in response to events
Advantages
Component reuse
System evolution-Both at system construction-time & run-time
Disadvantages
Counter-intuitive system structure
Components relinquish computation control to the system
No knowledge of what components will respond to event
No knowledge of order of responses
Layered Style
1. Hierarchical system organization
“Multi-level client-server”
Each layer exposes an interface (API) to be used by above layers
2. Each layer acts as a
Server: service provider to layers “above”
Client: service consumer of layer(s) “below”
3. Connectors are protocols of layer interaction
4. Example: operating systems
5. Virtual machine style results from fully opaque layers
Interpreter Style
Interpreter parses and executes input commands, updating the state maintained by the interpreter
1. Components: Command interpreter, program/interpreter state, user interface.
2. Connectors: Typically very closely bound with direct procedure calls and shared state.
3. Highly dynamic behavior possible, where the set of commands is dynamically modified. System architecture may remain constant while new capabilities are created based upon existing primitives.
4. Superb for end-user programmability; supports dynamically changing set of capabilities
5. Lisp and Scheme