An Introduction to Software Architecture

I teach an undergraduate course in software engineering that covers a lot of great information, but is disappointingly light on the subject of software architecture.  As a software engineer, I find it a bit disturbing that such a vital topic is handled so summarily.

At the request of my students, I put together a supplemental presentation on the topic.  When asked if I had any notes of my talk, I had to admit that I did not.  So, for the sake of my students and whoever else is reading this blog entry, here is a written form of my supplemental presentation on software architecture.

Introduction

When you think of the word “architecture,” what comes to mind?  You might imagine the styles in which buildings are designed.  Some might think of electronic devices and how all of their parts work together.  Others might think of how computing systems are connected in a network.

All of these are examples of architectures, and there are many more.  We software engineers are concerned with software architecture, which shares several commonalities with the types of architecture mentioned above:  Software architectures have recognizable styles.  Software architectures describe the parts and their purposes.  Software architectures show how the parts connect and communicate.

Many definitions exist for what software architecture is.  Some are casual and informal while others are precise and detailed, but they all generally agree on the main point:  It is a representation of the major components of the software and how they are connected.  It is a framework that describes the overall structure of a software system and how all of the parts are integrated together into a single, cohesive product.

Architecture is not concerned with how the components will perform their functions.  Rather, architecture is only concerned with what pieces will exist and how they connect and communicate with each other.    Architecture encompasses the structures of a system, supports general properties and qualities, and concentrates on the behavior and interaction of elements.

Given this description, architectural design may seem like a simple task, but many different styles of architecture exist and more than one may be suitable for a given application.  Each has its benefits which can help guide the decision-making process.

The Importance of Software Architecture

It is widely accepted that a carefully considered and well documented architecture provides the highest return on investment of any software engineering work product.  The reason it has such a high payoff is because of the number of benefits it provides as well as the significance of those benefits.  There are three key reasons why architecture matters.

First, it improves communication among stakeholders.  As you may know, communication is considered one of the greatest challenges in software engineering.  Since architecture can be represented using a variety of textual and diagramming notations, it can take on forms that are useful to people of diverse backgrounds.  This enables communication between people who may otherwise find it difficult to do so.  Also, architecture is documented in a variety of views which show different aspects of the system.  This means that stakeholders can view the architecture from a perspective that makes sense to them and addresses their specific concerns.

Second, it captures design decisions that will influence nearly all of the software engineering work that follows.  Here are some examples, and there are numerous others:

• Best practices suggest that the configuration manager should maintain a directory structure that roughly mirrors the architecture.  This simplifies maintenance by helping to pinpoint the precise location of faults as well as guiding various decisions during deployment.
• Software designers frequently come up with multiple designs that would solve a given problem.  An understanding of architectural priorities helps them to select a candidate design that would best support the overall quality goals of the system.
• The development team who constructs the software makes countless decisions through the development process, and many of these decisions are made easier by understanding the architecture.  It also divides the system into distinct elements which the development team can prioritize and use as a basis for metrics, planning, and estimation.
• The testing team can refer to the architecture to identify areas of concern, and testing coverage can be planned accordingly.  Also, testing priorities are more easily established when influenced by the architecture because testers can focus their efforts on the qualities that are most important to stakeholders.

Third and finally, architecture provides a relatively small, simple, and reusable model of the overall software system.  At this level, there are many similarities among the architectures of entirely different software.  Therefore, the same architecture can be reused in many different software systems.  Once an architecture has been used on a project, it can be reviewed for its effectiveness, and then reused or slightly modified for future projects that have similar nonfunctional requirements.  The presence of a simple model makes it easier to determine whether an architecture will work in a new scenario, or how to make any necessary modifications.

Influences on Software Architecture

The importance of architecture as a communication tool comes from the fact that it must satisfy a diverse array of needs, such as technical needs, business needs, and other input from stakeholders.  In a later section below, we will discuss how these concerns can all be incorporated into the decision-making process.

Technical Factors

Of course the architecture must allow for the inclusion of functional requirements – the specific behaviors that the software is expected to perform.  Functional requirements are usually independent of the architecture, but we still must ensure that the architecture does not somehow obstruct them.

From an architectural standpoint, we are more interested in nonfunctional requirements (NFR) – general properties that the system must possess.  The architecture can enable the software to have some of these qualities while hindering others.

 Nonfunctional requirements are also known by other names.  They are often called quality attributes.  Some call them by their nickname:  “the ilities”.  This nickname comes from the fact that many of them end with “-ility” – portability, modifiability, extensibility, and so on.

Most NFRs fall into these broad categories:

• Functionality – the software is sufficiently secure, contains reusable components, and can be ported to other computing platforms if necessary.
• Usability – the software is reasonably easy to learn and use efficiently.
• Reliability – the software is available when users need it, rarely breaks down, and is capable of recovering from problems.
• Performance – the software runs reasonably quickly, uses system resources economically, and can be scaled to support more data, interfaces, or users.
• Supportability – the software can be modified, extended, or repaired without excessive difficulty.

Business Factors

In addition to technical requirements, the architecture must also support business concerns, like development costs, maintenance costs, marketability, and so on.  Some nonfunctional requirements span both technical and business concerns.  For example, supportability implies specialized, technical work being performed, but the longer it takes to do so, the more it costs.  Therefore, it is both a technical factor and a business factor.

Stakeholder Input

The ultimate driver for any kind of design decision is the set of needs that the stakeholders have.  If the resulting system does not serve the needs of its stakeholders, then it is a failed product.

A Summary of Common Architectural Styles

Software architectures and building architectures have something meaningful in common:  They both have defined styles that provide certain clues to their layouts and features.

Here is a list of some common architectural styles.

• Data-Centered Architectures for systems whose primary function involves accessing or manipulating a central data store.  Good for database-centric applications.
• Dataflow Architectures for systems that perform a complex series of data processing steps between input and output.  Good for systems that perform a long series of validations, calculations, and/or transformations.
• Call-and-Return Architectures for systems whose functionality can be divided into discreet, mostly independent tasks.  Good for systems that need to be easy to modify or scale.
• Tiered Architectures for systems whose major elements may reside on separate machines in a distributed environment.  Good for systems that need to communicate remotely across a network.
• Object-Oriented Architectures for systems that can be logically separated into distinct components that communicate through messages.  Good for systems that can take advantage of an existing code base by reusing or extending it.
• Layered Architectures for systems whose elements can be arranged in a hierarchical fashion based on their level of abstraction or generalization.  Good for systems that require portability or those that need to encapsulate a particularly complex subsystem.

Selecting an Architectural Style

Here is where things can get tricky – many software applications could be built upon more than one of these architectures.  So how do we go about selecting an architecture when there are so many viable possibilities?

If we are fortunate enough to have documented architectures from previous projects, we have two models to help us out.  A guidance model is a document that summarizes the experience of using a particular architecture, along with an explanation of what problems were encountered and what decisions were made.  When considering multiple architectures, their guidance models can be used to create a decision model which summarizes the relevant points from the guidance models and provides a side-by-side comparison of them.

If we do not have such information available to us, then we can create our own analysis model to gain an understanding of what qualities (NFRs) we will need the architecture to support for us.  An analysis model is a representation of the system, usually from the user’s point of view, that shows us what the users will expect from the system and what constraints and limitations may exist.

Once we have an analysis model, we can apply a technique called the Architectural Tradeoff Analysis Method (ATAM).  The ATAM gives us a way to predict whether an architecture will provide the desired quality attributes.

The Architectural Tradeoff Analysis Method (ATAM)

Here is a brief summary of how the ATAM works:

First, use analysis models to understand what the stakeholders expect in terms of nonfunctional requirements.  It may require multiple models to make sure that all stakeholder concerns have been addressed.

Then select a few candidate architectural styles and diagram them in a way that specifically shows how they might support the NFRs.  For example, if security is a top priority, then diagram the architecture to highlight how it might allow security to be implemented.  This type of diagram is called a view, and the same architecture can be represented in multiple views.  (In fact, that is a best practice.  We will discuss the 4+1 view model below.)

Experiment with each view by making a change to it, and see how that change affects the quality attribute.  Make this same change with all of the views and see how other qualities might be affected.  If a small change has a large, negative impact on the quality, then we have identified a sensitivity point which becomes a major factor in the evaluation of the architecture.

Once sensitivity points have been determined, we have a somewhat reliable picture of which architecture will be most likely to support the nonfunctional requirements.

The ATAM is likely to be repeated a few times as new details emerge.

Documenting Software Architecture

One of the most vital signs of a quality architecture is how well it is documented.  Most software architects advise that every architecture should have at least two views:

• A static view that shows the overall structure of the architecture.
• A dynamic view that shows how the elements behave and communicate.

Others argue that two views is insufficient to communicate all stakeholder concerns.  A much more thorough approach is preferred for most large projects.  The 4+1 view model is considered to be the best overall way to document software architectures for complex systems.  It consists of five views, each of which represents the architecture from a different perspective.

1. The logical view focuses on functionality.  It is usually represented in UML class diagrams or sequence diagrams.
2. The development view focuses on the components of the software that must be built by the programmers.  It is usually represented by UML component diagrams.
3. The process view focuses on dynamic aspects of the system and shows how the elements behave and communicate.  It is often represented by UML activity diagrams.
4. The physical view focuses on how the software will be physically arranged once it is deployed to the users.  A common way to represent this is with UML deployment diagrams.
5. The scenario view (a.k.a. use case view) describes sequences of activities interactions between elements of the system.  There is no standard diagram for communicating this information.  It must be done in a way that the users can understand, which may or may not involve technical diagrams.

FYI:  The reason we do not just call it the “5 view model” is because of the nature of the scenario view.  Rather than being a distinctly different view from the other four, it is usually a combination of the others to constitute the user’s view of the system.

Summary

The diversity of software architectures makes it difficult to define precise processes for specifying them or defining precise criteria for assessing their quality.  We do have some processes that have been incredibly effective, such as the ATAM, and we have documentation strategies to help us document and communicate the important details, such as the 4+1 view model.  As software engineering continues to mature as a discipline, activities such as architectural design are becoming more effective and refined.