Tactics and Architectural Patterns

So far we have learned about patterns and tactics.

Patterns are solutions that resolve multiple forces, whereas tactics focus on specific quality attributes. To more effectively apply both tactics and patterns, architects need to understand how architectural tactics and patterns relate and how to use them effectively.

Patterns are built from a collection of tactics realising some quality attributes and maybe affect some others.

Even different implementation of a pattern may use a different set of tactics.

Let's consider a pipe and filter architectural pattern: from modifiability tactics point of view it contains the following tactics:

• Increase Cohesion / Maintain Semantic Coherence
• Reduce Coupling   / Use Encapsulation
• Reduce Coupling   / Use an Intermediary
• Defer Binding Time/Use Start-Up Time Binding

 Now, using the modifiability tactics catalogue, can you find the tactics that exist in Layer pattern?
Answer: 

• Increase Cohesion / Maintain Semantic Coherence
• Increase Cohesion / Abstract Common Services
• Reduce Coupling   / Use Encapsulation
• Reduce Coupling   / Reduce Communication Paths
• Reduce Coupling   / Use an Intermediary
• Reduce Coupling   / Raise the Abstraction Level

Achieving Quality Attributes - Security

Last week,my post box was compromised,while my new debit card was in the box.
The lucky guy(s) were using my card,when I received a call from the bank asking me if I have used my card that day or not. Eventually the card got cancelled.
This inspired me to pick security for this post, and use this as an example for the tactics involved.

Security Tactics

Tactics for achieving security can be divided into those concerned with resisting attacks, those concerned with detecting attacks, and those concerned with recovering from attacks.Using a familiar analogy, putting a lock on your door is a form of resisting an attack, having a motion sensor inside of your house is a form of detecting an attack, and having insurance is a form of recovering from an attack.

RESISTING ATTACKS

Authenticate users. Authentication is ensuring that a user or remote computer is actually who it purports to be. Passwords and digital certificates for example.

Authorise users. Authorisation is ensuring that an authenticated user has the rights to access and modify either data or services. This is usually managed by providing some access control patterns within a system.

Maintain data confidentiality. Data should be protected from unauthorised access. Confidentiality is usually achieved by applying some form of encryption to data and to communication links. SSL, public/private keys.

Maintain integrity. Data should be delivered as intended. It can have redundant information encoded in it, such as checksums or hash results, which can be encrypted either along with or independently from the original data.

Limit exposure. Attacks typically depend on exploiting a single weakness to attack all data and services on a host. The architect can design the allocation of services to hosts so that limited services are available on each host.

Limit access. Firewalls restrict access based on message source or destination port. Messages from unknown sources may be a form of an attack. It is not always possible to limit access to known sources. 

DETECTING ATTACKS

The detection of an attack is usually through an intrusion detection system. Such systems work by comparing network traffic patterns to a database. In the case of misuse detection, the traffic pattern is compared to historic patterns of known attacks. In the case of anomaly detection, the traffic pattern is compared to a historical baseline of itself. As an example I can refer you to my stolen card story mentioned above. Since the patterns and amount of usage was different from the rest,  the bank could detect this.

RECOVERING FROM ATTACKS

Tactics involved in recovering from an attack can be divided into those concerned with restoring state and those concerned with attacker identification.

The tactics used in restoring the system or data to a correct state overlap with those used for availability since they are both concerned with recovering a consistent state from an inconsistent state. One difference is that special attention is paid to maintaining redundant copies of system administrative data such as passwords, access control lists, domain name services, and user profile data.

The tactic for identifying an attacker is to maintain an audit trail. An audit trail is a copy of each transaction applied to the data in the system together with identifying information. Audit information can be used to trace the actions of an attacker, support nonrepudiation (it provides evidence that a particular request was made), and support system recovery. Audit trails are often attack targets themselves and therefore should be maintained in a trusted fashion.

For my case of stolen card. Bank cancelled the card.

If you are working on a project with some security measures implemented into it, see if you can identify tactics implemented. 

Achieving Quality Attributes - Modifiability

So far I have mostly written about quality attributes, documenting them using scenarios  and architect's goal in achieving them. An architect needs tools to tackle this. 

How does an architect do it?

The answer is there are different levels of action you can take to achieve desired qualities in your system. I will start from the most granular level, where you use the so called tactics.

A tactic is a fundamental design decision that influences the control of a quality attribute response (, do yo remember the QA scenarios we talked about earlier?).

Each tactic can be refined to other tactics, for example a tactic to achieve availability is redundancy, it can be refined to redundancy of data, and redundancy of computation.

However to implement this tactic we may need synchronisation(,to keep redundant copies in synch with original). This means a collection of tactics maybe used in some cases, which we call them patterns. 

In the remainder of this post I will examine tactics for achieving modifiability, as I find it to be easily understood by developers. And some more quality tactics in the next posts.

And please notice I wont cover all quality attribute tactics. Just enough to give you a sound understanding for full details I refer you to this book. 

Modifiability Tactics

The goal of the following tactics is to control the time and cost to implement, test, and deploy changes.

There are three main categories for these tactics which are explained in details in each section:

LOCALIZE MODIFICATIONS 

Generally speaking the less modules a change request affects, results in less cost. The goal of tactics in this set is to assign responsibilities to modules during design such that anticipated changes will be limited in scope :

• Maintain semantic coherence: Semantic coherence refers to the relationships among responsibilities in a module. The goal is to ensure that all of these responsibilities work together without excessive reliance on other modules. Achievement of this goal comes from choosing responsibilities that have semantic coherence. Coupling and cohesion metrics are an attempt to measure semantic coherence, but they are missing the context of a change. Instead, semantic coherence should be measured against a set of anticipated changes. 

• Anticipate expected changes: Considering the set of envisioned changes provides a way to evaluate a particular assignment of responsibilities. The basic question is "For each change, does the proposed decomposition limit the set of modules that need to be modified to accomplish it?" An associated question is "Do fundamentally different changes affect the same modules?" How is this different from semantic coherence? Assigning responsibilities based on semantic coherence assumes that expected changes will be semantically coherent. The tactic of anticipating expected changes does not concern itself with the coherence of a module's responsibilities but rather with minimising the effects of the changes. In reality this tactic is difficult to use by itself since it is not possible to anticipate all changes. For that reason, it is usually used in conjunction with semantic coherence.

• Generalise the module: Making a module more general allows it to compute a broader range of functions based on input. The input can be thought of as defining a language for the module, which can be as simple as making constants input parameters or as complicated as implementing the module as an interpreter and making the input parameters be a program in the interpreter's language. The more general a module, the more likely that requested changes can be made by adjusting the input language rather than by modifying the module.

• Limit possible options: This one is regarding product lines, which exceeds this blog's scope.

PREVENT RIPPLE EFFECTS

A ripple effect from a modification is the necessity of making changes to modules not directly affected by it. For instance, if module A is changed to accomplish a particular modification, then module B is changed only because of the change to module A. B has to be modified because it depends, in some sense, on A. 

There are different dependency types: syntactic, semantic, location, existence of, behaviour of,.. .

• Hide information:Information hiding is the decomposition of the responsibilities for an entity (a system or some decomposition of a system) into smaller pieces and choosing which information to make private and which to make public. The public responsibilities are available through specified interfaces.

• Maintain existing interfaces:If B depends on the name and signature of an interface of A, maintaining this interface and its syntax allows B to remain unchanged. Of course, this tactic will not necessarily work if B has a semantic dependency on A, since changes to the meaning of data and services are difficult to mask. Also, it is difficult to mask dependencies on quality of data or quality of service, resource usage, or resource ownership. Interface stability can also be achieved by separating the interface from the implementation.

• Restrict communication paths: Restrict the modules with which a given module shares data. That is, reduce the number of modules that consume data produced by the given module and the number of modules that produce data consumed by it. This will reduce the ripple effect since data production/consumption introduces dependencies that cause ripples.
• Use an intermediary: If B has any type of dependency on A other than semantic, it is possible to insert an intermediary between B and A that manages activities associated with the dependency. 

DEFER BINDING TIME

Tactics discussed so far minimise the number of modules that require changing to implement modifications. How about time to deploy and allowing non-developers to make changes?

Deferring binding time supports both of those scenarios at the cost of requiring additional infrastructure to support the late binding. We discuss tactics that affect deployment time.

Many tactics are intended to have impact at load-time or runtime, such as the following.

• Runtime registration supports plug-and-play operation at the cost of additional overhead to manage the registration. Publish/subscribe registration, for example, can be implemented at either runtime or load time.
• Configuration files are intended to set parameters at startup.
• Polymorphism allows late binding of method calls.
• Component replacement allows load time binding.
• Adherence to defined protocols allows runtime binding of independent processes.

And finally the tactics distilled:

Patterns, Design Patterns, Architectural Patterns

Before writing about how an architect can achieve system's quality attributes, I thought it would be a good idea to dedicate a post about what a pattern is, and what is the difference between design and architectural patterns, for the sake of speaking the same ubiquitous language.

 I understand there are various definitions for these terms, but let's agree on theses for the scope of this blog.

An architect of a software system designs its architectural structures to solve a variety of design problems. These structures are based on one or more patterns.

So what is a pattern?

A pattern describes a particular recurring design problem that arises in specific design contexts, and represents a well-proven solution for the problem.

The solution is specified in terms of describing the roles of its constituent participants, their responsibilities and relationships, and how they collaborate.

Let's have a look at an example, and have a better understanding of problem, context and solution.

An Example: LAYER PATTERN

Context :Regardless of the interactions and coupling between different elements of a      software system, there is a need to develop and evolve them independently. Without a clear and reasoned separation of concerns, element interactions cannot be supported and elements cannot be independently developed.

Problem : Finding a design that partitions the application into meaningful, tangible elements that can be developed and deployed independently while preserving the architectural vision and addressing concerns such as performance, scalability, maintainability, and comprehensibility.

Solution :Define one or more layers for the software with each layer having a distinct and specific responsibility. Layers define a partitioning of software functionality according to a (sub)system-wide property so that each group of functionality is clearly encapsulated and can evolve independently. Functionality can be partitioned along various dimensions including abstraction, granularity, hardware distance, and rate of change. Layers are associated with each other via a one-way “allowed-to-use” relationship.

The Scope and Abstraction Level 

Here is where many people get confused: what is a design pattern, what is an architectural pattern, how are the different? 

To be honest with you I don't see much value in answering these questions, because after all you just pick a pattern that you need and use it you don't care about what category it fits in.

However because patterns cover various ranges of scale and are applied at various levels of abstraction, it is sometimes useful to broadly classify them as

• Architectural patterns - express a fundamental structural organisation schema for software systems. An architectural pattern provides a set of predefined [major architectural elements], specifies their responsibilities, and includes rules and guidelines for organising the relationships between them.

• Design patterns - provide a scheme for refining the [major architectural elements] of a software system, or the relationships between them. A design pattern describes a commonly recurring structure of communicating [elements] that solves a general design problem within a particular context.

• Idioms – are patterns specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

Note there is significant overlap and ambiguity in these definitions. Architectural design may incorporate any/all of the above types of patterns. 

If you are interested in patterns there is a very good book, I recommend:
 Pattern-Oriented Software Architecture which comes in five volumes.

Quality Attribute Workshop

So far you may have noticed the importance of quality attributes, and the fact that they are key influencing components in success of the designed software.

But how can you capture relevant quality attributes? what do they mean to stakeholders?

how can you tell the priorities ?

Software Engineering Institute suggests using a method called Quality Attribute Workshop,

which facilitates the process of capturing quality attributes and prioritising them.

It is recommended that the method should be used when there is no software yet(early stages),( however to my experience it can be done event after the software is developed and released, as it can help communication among stakeholders and point them to the right direction).

Depending on the size and number and nature of stakeholders you may need more than one workshop to capture required data. Usually it can take 1-2 days. Here are the steps to follow

QAW Steps

1. QAW presentation and Introduction
2. Business/Mission Presentation
3. Architectural Plan presentation
4. Identification of Architectural Drivers
5. Scenario brainstorming
6. Scenario Consolidation
7. Scenario Prioritisation
8. Scenario Refinement -> (1) Iterate as necessary with broader stakeholder community

    For details of how each step works refer to an article by SEI. 

 The benefits of QAW exceeds the time and energy you put into it. 

 Here are some :

• Increased stakeholder communication (Hey developer remember you are in human world not coding)
• clarified quality attribute requirements( using scenarios)
• informed basis for architectural decisions

The out come of QAW is a set of prioritised attribute  scenarios that can be used by the architect, create prototypes and refine requirements into more details.

I highly recommend delving more into this method and mastering it.

Also if you are running a QAW session, you may need a team for capturing requirements, help stakeholders with writing scenarios, stopping lengthy discussions between stakeholders, identifying key quality attributes,.. .

At the time I learned about this, I could not run a full fledged QAW because of my position, however I started by talking to my manager trying to find out what quality attributes he was concerned about, and helped him to express it in a scenario. And then increased the circle of people I talked to.

As an exercise try talking to somebody who has a different role from you, and see what quality attributes they are concerned about.