Chapter 2-Software Architecture Design Space

Chapter Outline
Global Analysis Types of Software Structures Software Static Structure Software Runtime Structure Software Management Structure Software Elements Software Connectors An Agile Approach to Software Architecture Design

Global analysis
Identify the external influencing factors and critical requirements that could affect the architecture Analyze them to come up with strategies for designing the architecture

If all cannot be satisfied, decide which has priority, renegotiate a requirement, or change some external factor to come up with workable strategies

Global analysis (Contd)

Influencing factors
Organizational factors
Development schedule, budget Organizational attitudes, software process

Technological factors
Available hardware and software technology

Product factors
Performance, dependability, cost May be different in future versions

Global analysis(contd)
Many factors affect the entire system
Strategies should address global concerns, but provide guidance for implementing them locally

Occurs throughout the design

New factors, issues or strategies can arise at any time

Consider factors as a group

Might be contradicting Sort out conflicts and resolve them

Global analysis(contd)
Complements the risk analysis and/or requirements analysis Requirements and risk analyses might give the analyzed factors
Then develop strategies to the design

Provides a systematic way of identifying, accommodating and describing the affecting factors

Global analysis(contd)
Analyzing factors
Take as input the organizational, technological and product factors
Make them explicit

Three (3) step procedure

Step 1: Identify and describe the factors Step 2: Characterize the flexibility or the changeability of the factors Step3: Analyze the impact of the factors

Step 1: Identify and describe the factors

Can the factors influence be localized to one component or not? During which stages of development is the factor important? Does the factor require any new expertise or skills?

Step 2: Characterize the flexibility or the changeability of the factors

Flexibility
Is it possible to influence or change the factor so that it makes your task of architecture development easier? In what way can you influence it? To what extent can you influence it?

Changeability
In what way could the factor change? How likely will it change during or after development? How often will it change? Will the factor be affected by changes in the other factors?

Step3: Analyze the impact of the factors

If a factor was to change, which of the following would be affected and how:
Other factors Components Modes of operation of the system Other design decisions

Global analysis (contd)

Develop strategies
Three (3) steps procedure
Step 1: Identify issues and influencing factors Step 2: Develop solutions and specific strategies Step 3: Identify related strategies

Step 1: Identify issues and influencing factors

Identify a handful of important issues that are influenced by the factor and their changeability Limitations or constraints imposed by factors
Aggressive development schedule

A need to reduce the impact of changeability of factors

Design for portability

Difficulty in satisfying product factors

High throughput req. may overload CPU

A common solution to global requirements

Error handling and recovery

Step 2: Develop solutions and specific strategies

For each issue, develop strategies that address the issue and ensure the implementation changeability of the architecture design
Reduce or localize the factors influence Reduce the impact of the factors changeability on the design and other factors Reduce or localize required area of expertise or skills

Reduce overall time and effort

Step 3: Identify related strategies

When a strategy belongs with more than one issue, dont repeat the strategy

Global Analysis Summary

Consider three kinds of influencing factors Organizational factors Constrain design choices
Technological factors Embedded or embodied in the product

Product factors
Functional features and qualities of the product

Global Analysis Summary(contd)

At the end of architecture design you will have
Characterized the important influencing factors and

Developed strategies for ensuring

Buildability Implementation changeability

Software Architecture Design Space

A software architect
is responsible for proposing a concrete architecture that best supports the detailed design and implementation of a specific project. must know what design alternatives are available to them, and which one will best support the functional and nonfunctional requirements. In short, he/she must understand the software architecture's design space.

A software architecture design is a set of software elements connected by a set of connectors. From a dynamic structure point of view, a software element can be a process, an object, an instance of a software component, or a service.

Software Architecture Design Space(contd)

Different software elements may run on different hardware and software platforms and may be implemented in different programming languages or on different software frameworks. Two software elements can run in the same process, on the same computer system, within an intranet, or distributed over the Internet. Depending on their relative location, the connectors between a pair of software elements can be implemented in various forms including local method invocations, remote method invocations, service calls, and messaging through a message queue.

The connectors can also work in synchronous or asynchronous nodes.

In terms of the static structure, a software element can be a package, a class, a component, or a loadable library

Software Architecture Design Space(contd)

A connector can be an import clause, inheritance clause, interface specification, pipe, or filter. A good software architecture should be able to easily adapt to changing environments of business operations without the need for major reengineering of corresponding software systems. Over the last decade, information technology has gone through significant changes:- frameworks, technologies such as. NET and J2EE (Java 2 Enterprise Edition)enhanced the level of encapsulation.

Web services and service-oriented architectures have brought us more flexible connector implementation technologies and software architecture varieties.

Types of Static Structure

Software architecture design can described in terms of software code units like source/binary code files, software modules, or software component deployment units; this is known as the static structure. It may also be described based on the runtime dynamic structure, in which the software elements are threads, processes, sessions, transactions, objects, or software component instances at execution time. An allocation structure may also be used to describe the project management structure of an architecture design. These different types of structures use different connector types and different performance attributes.

Software Static Structure

A software project is typically implemented in multiple filesincludes static file types such as executable files; library files; binary software component modules (usually in the form of DLLs [dynamic linking libraries], JavaBeans, and Enterprise JavaBeans); deployment descriptors; and other resource files. At software development time, the main software elements are source code modules or files. Each module has assigned functional and nonfunctional attributes, and the public APIs (application programming interfaces), defined for each module separate the module's interfaces and implementations. The connectors at this level are module dependent. Module A is connected to module B if, and only if, A needs to invoke some methods in B during execution.

Software Static Structure

Such connectors may exhibit the following attributes: Direction: If module A invokes a method of module B during execution, there is a unidirectional connector from module A to module B. Synchronization: A method invocation can be synchronous or asynchronous. Sequence: Some connectors must be used in a particular sequence. For example, module A may invoke a method of module B and pass a callback reference during the invocation. At software deployment time, the elements are binary versions of the project modules and files. Several source code modules may be packaged into the same deployment unit, but the connectors in the deployment structures are the same as those for the source module structures.

Software Static Structure

The software static structure refers to the organization of physical software modules and their interrelations and this structure plays a critical role in software architecture design. Static structure affects the architecture's clarity, construction strategy, maintenance, reengineering, reusability, etc. It plays a crucial role in the management of large software systems because it deals with the packaging of software modules in order to facilitate system construction and maintenance through a clear portrayal of intermodule relations.

Managing static structures involves layers of abstraction and of refinement showing visibility and encapsulation, respectively.

Software Run time Structure

At runtime a project consists of one or more threads, processes, functional units, and data units. These elements may run on the same computer or on multiple computers across a network. The same element in a code structure may implement or support multiple runtime elements. For example, in a client-server application, the same client module may run on many client computers. The connectors at this level inherit attributes from their source-code structure counterparts.

Software Management Structure

A large software project is normally designed and implemented by several project teams, each having its well-defined responsibilities at specific SDLC process stages. At this level, each element consists of manipulation (design, implementation, debugging, etc.) of specific code units assigned to each project team, and the connectors are derived from runtime dependency among the code units and software process dependencies. Some software architectures are best implemented by a particular software management structure. Software management structures are also used for project resource allocation. Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived.

Software Elements
At runtime each software element has well-defined functions and connects to the other elements into a dependency graph through connectors. The elements of a software architecture are usually refined through multiple transformation steps based on their attributes and the project requirement specifications. Depending on each software element's assigned function, there may be different synchronization and performance constraints. For example, some elements are reentrant objects or software components (meaning that multiple threads can execute in an element concurrently without interfering with each other) while some elements are not reentrant and no more than one thread may execute in it at any time.

Software Elements
Depending on the multiplicity of an element, it could be invoked by a limited number of other elements at execution time, or it could be invoked by unlimited elements, as in the case of a server element. Scalability, response time, and throughput become important performance constraints and must be considered during the element's implementation.

Software Connectors
The connectors in software architecture are refined during the design process and are heavily influenced by a project's deployment environment. A connector indicates the necessity during system execution for one of the elements to send a message to another element and potentially get a return message. During software architecture refinement, if two elements are mapped to a single process, the connector can be mapped to a local method invocation. If two elements are mapped to two different processes on the same computer, the connector can be mapped to a local message queue or a pipe. If the two elements are mapped to two different computers, then remote method invocation or web service invocation can be used to refine the connector between them.

Software Connectors
Software connectors are classified according to many attributes, including synchronization mode, initiator, implementation type, active time span, fan-out, information carrier, and environment. Based on the connector's synchronization mode, we can classify all connectors into two categories: blocking connectors and non-blocking connectors. A blocking connector allows one of its incident elements to send a request (method call or message) to another and wait for a response (method return value or message). The element will be blocked from further execution until it receives a response. A non-blocking connector allows one of its incident elements to send a request (method call or message) to another and then continue its execution without waiting for a response.

Software Connectors
Based on the connector's initiator, we can classify all connectors into two categories: one-initiator connectors and two-initiator connectors An initiator is an incident element of a connector that can make a request to its partner. A one initiator connector allows only one of its two incident elements to make a request to the other element, but not another way around. A two-initiator connector allows either one of its two incident elements to make a request to the other element. For a system to support callback between its two subsystems, the two subsystems must be connected by a two-initiator connector.

Software Connectors
If the two incident elements are in the same process, say as two threads, they may use a shared variable to exchange information. If they are mapped to different processes on the same processor, then resources like pipes, files, or local message queues may be used to implement the connector. Method invocations and message passing are more common and more structured ways for carrying information. Remote method invocation and messaging can also allow communication among elements deployed on different processors.

An Agile Approach to Software Architecture Design

Traditional software architecture designs, fundamentally based on a waterfall model (a linear process without integrating feedbacks), do not emphasize the iterative refinement nature and do not use element and connector attributes to capture the key architecture requirements of a software project. There is big gap between a project's requirement specification and a concrete software architecture for its detailed design and implementation. Another weak point of traditional architecture design is that if the deployment environment changes, which are happening more often with the economy's globalization, the architecture design must start from scratch. An iterative, agile approach for developing software architectures that maximizes the reuse of architecture, design, and implementation investments.

An Agile Approach to Software Architecture Design

Given a project specification, abstract high-level software architecture will first be proposed, and attributes will be identified for its elements and connectors. This abstract software architecture will generally be free of deployment considerations. The architecture will then go through multiple refinement processes to support particular deployment constraints. The unique features of this approach include the delayed binding of software connectors for more flexible implementation decisions and the seamless integration of multiple architecture styles in realizing different subsystems or levels of the same system.

Chapter Summary
Software architecture determines the overall structure of a software system and greatly impacts its quality. The architecture can be viewed from multiple perspectives including the code structure (or static structure), runtime structure (or dynamic structure), and management structure (or deployment structure). Each type of structure consists of elements and connectors and their constraint attributes, which are derived from the requirements specification. To minimize the impact of changing project requirements and to maximize the ability to reuse design and implementation, an architect should adopt an iterative process during the design phase. Initial architecture designs should focus on the core functional and nonfunctional requirements; the resulting complex elements can then be refined into subsystems with their own architecture designs. A good architecture solution is typically based on multiple architecture styles for different subsystems or for different system abstraction levels.