Introduction to Software Architectures

The first thing of a software architecture is thus that it consists of conscious decisions on how to address different concerns from different stakeholders. This includes decisions on concerns where you do not have the right competence available in-house, decisions on concerns where you need to deliver parts of the system in a certain order, decisions on concerns about how to achieve different quality requirements, and decisions on how to balance all these different concerns such that you focus on the most important concerns (side note: how do you prioritise your concerns?).

I will even go so far as to say that the decisions are the software architecture. The rest is just instantiations of these decisions. The instantiation is important, since this brings together all of your decisions into one coherent system that you are able to communicate to others, and to evaluate to ensure that you actually satisfy the right balance of quality requirements.

A more traditional definition is provided by the Software Engineering Institute (The definition below is from their book Software Architecture in Practice (Bass et al. 2012)):

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

If you’ve payed attention to the other sprints in this course, it should not come as a surprise to you that the software archtiecture is documented in a number of different ways, depending on what you are focusing on. Consider the maps below. All three represent London, but from different perspectives.

(There are also Other maps of London that are equally valid representations of the city. For example, there are sewage maps, electricity maps, gas maps, etc.)

If you are sightseeing, you might use the river map and take a boat. If you are walking or driving, the A-Z map is probably your best friend. If you just want to get from point A to point B, you use the tube map.

In the same way, you express your software architecture using different types of “maps” depending on what you intend to do. Philippe Kruchten expressed this in 1994 as the “4+1 view of architecture”:

This has influenced many design methodologies, including UML. The current best practice is to define a set of views (possibly from a suggested superset of potential views) that are relevant for your system. I am a bit old-fasioned, so I usually stick with a subset of Hofmeister et al. (2000)’s views:

A Conceptual View

describing the system as a series of collaborating conceptual “logical” components.

A Module View

describing the system as implementable modules corresponding to UML packages.

An Execution View

studying the runtime behaviour of the modules.

A Code View

focusing on the development and build environment.

In UML, the “Scenarios” that Kruchten describes are your use cases. In Hofmeister et al. (2000), it corresponds to your decisions. In Bass et al. (2012) it is your architectural drivers. You use these scenarios (use cases, decisions, architectural drivers, etc.) to define what you need to model on an architecture level, and then you focus on different engineering concerns of these “whats” in each of the viewpoints.

Once you have the scenarios (decisions) for your first iteration ready, you basically work your way through the different views. There is an implicit order between them, because you need a conceptual overview before you can start defining modules, and you need the modules before you can start allocating these to your runtime platform. You also need the modules and the runtime overview before you start planning how to build, test, and integrate your system. However, it is also important to know that the decisions you take in the process of creating one view will impact the views you have already done, so you need to go back and revise in a highly iterative process.

You set out in your quest for architecture design with a well defined set of intentions; your (and your stakeholders) primary concerns. You have balanced these intentions against each other and the importance of each stakeholder, you have taken decisions on how to realise a system that satisfies these intentions, and you have instantiated your decisions in a number of different views of your system.

As a good engineer, you should not be satisfied here. The software architecture is a relatively cheap artefact to produce, and it has a considerable impact on your quality requirements. Your architecture is also expressed in several different views, and you need to integrate these views into a whole. Lindvall et al. (2003) distinguishes between Early Architecture Evaluation and Late Architecture Evaluation:

There is a range of different evaluation methodologies available, from ad-hoc based “looking at the architecture and trying to find challenges based on past experiences and logical reasoning”, via more structured versions of this, up to simulation-based and mathematical models. The most commonly used is what is called scenario-based, which is a way to structure your experiences and focus your analysis into one scenario at a time.

Once you have evaluated your architecture, you need to decide whether you satisfy your quality requirements (and your other engineering concerns) or not. If you do, then you are done and can continue building your system. If not, you transform the architecture. This means that you change the architecture in one or several ways in order to improve those qualities that were lacking in your evaluation. Then you re-evaluate to see whether your transformations meet their goal and that they did not negatively effect any other of your qualities.

Bass et al. introduces one more crucial aid for designing your architecture, namely Architecture Tactics. When you have your architectural drivers and need to decide how to actually adress these in your software architecture, architectural tactics suggest solutions on an architectural level for different quality requirements. The tactics are described on a high level, so you need to work with them quite extensively in order to actually fit them into your system.

For example, if performance is a concern for you, Bass et al. suggest that you can focus on managing the resource demand (e.g. by reducing overhead, rate limit the incoming data, or be more efficient in your computations), you may manage the resources smarter (e.g. by introducing concurency), or you may divide the work better (e.g. with a different scheduling policy). Of course, you may decide to use several of these tactics at once. Which tactic to use depends on your system and your data.

I suggest that you have a look in the Software Architecture in Practice book by Bass et al. and get an overview of the available tactics. These are good engineering principles that help you achieve your quality requirements in a more repeatable way.

To summarise, software architecture design is about:

• Identifying what needs to be decided in order to support the required functionality with the right level of quality.
• Deciding on solutions (for example with the help of tactics) that will address the required qualities.
• Instantiating those solutions in different viewpoints of the system.
• Evaluating whether your instantiation sufficiently address the decisions, and whether you thus sufficiently satisfy your quality requirements.
• Iterating until you are satisfied.

• C. Larman, Applying UML and Patterns, 3rd Edition, Chapters:
  33. Architecture Analysis
  34. Logical Architecture Refinement
  38. UML Deployment and Component Diagrams
  39. Documenting Architecture: UML & the N+1 View Model

• Architecture Styles

• L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, Third Edition. Addison-Wesley Publishing Co., Reading MA, 2012.
• C. Hofmeister, R. Nord, and D. Soni. Applied Software Architecture. Addison-Wesley, Reading MA, 2000.
• R. Kazman, L. Bass, M. Webb, and G. Abowd. SAAM: A method for analyzing the properties of software architectures. In Proceedings of the 16th international conference on Software engineering, pages 81–90. IEEE Computer Society Press, 1994.
• P.B. Kruchten, “The 4+ 1 view model of architecture.” IEEE software 12.6 (1995): 42-50.
• M. Lindvall, R. T. Tvedt, and P. Costa. An empirically-based process for software architecture evaluation. Empirical Software Engineering, 8:83–108, 2003.
• M. Svahnberg and F. Mårtensson. Six years of evaluating software architectures in student projects. Journal of Systems & Software, 80(11):1893–1901, 2007.

Go through the user stories for this sprint and make sure you have a clear understanding of how to solve each of them.

Revisit and update your risks and contingencies section.

Add and/or revise the following items to your glossary:

• Software Architecture
• The 4+1 Views of Architecture
• Architecture Viewpoints
  • Conceptual View
  • Module View
  • Execution View
  • Code View
• Quality Aspects
  • Quality Attribute
  • Quality Requirement
• Architecture Evaluation
  • Early Architecture Evaluation
  • Late Architecture Evaluation
  • SAAM/ATAM
• Architecture Tactics

Make sure you understand what each item is, the notation for them, and how to use them either in isolation or together with the other concepts.

Are there any common architecture styles? What are their qualities? How can you deal with (new) functionality that uses several of the components in the system (for example, a new feature may require a new UI dialogue, new business logic on several levels, new database connections, new tables in the database)?

Are there any other questions that you want answered? Add them, along with a brief strategy for how to find an answer.