Introduction

Informal Definition of SA

• First step in developing the solution

• Overall (high level) structure of the software system

• Software architecture = Components + Connectors

What are components and connectors?

A simple example

Component 1.1

Component 1.2

Component 2

Database

Component 1

Why Software Architecture?

• Complexity → Divide and Conquer– Process: Divide design process to phases

1. Architectural design

2. Detailed design

– Product: Decompose system to components

• Assuring fulfillment of required quality attributes (performance, changeability, etc) from the beginning

Roots of Software Architecture

• Software architecture is similar to building architecture in many ways.

• The idea is not new. Concepts related to SA have been in the literature since 60’s and 70’s (e.g. modularity, info. hiding).

• However, the term is new.

• During the past 10 years SA have received considerable attention and have been subject to many research projects.

Architecture Business Cycle

Motivation

• We add a new role to software development team: Software Architect

• What does software architect do? Simply drawing the some diagrams?

• What else is related to SA?

• Are 2 SAs developed in different environmental conditions for a single system the same?

This part covers two issues:

• What influences software architecture?

• What are influenced by software architecture?

Architectural Influences

• Stakeholders– each stakeholder has different concerns & goals, some

contradictory

• Development Organization– immediate business, long-term business, and organizational

(staff skills, schedule, & budget)

• Background & Experience of the Architects– repeat good results, avoid duplicating disasters

• The Technical Environment– standard industry practices or common SE techniques

Who influences SA?

Figure 1.2 Influence of

stakeholders on the architect

Customers and End Users

• Requirements (including qualities such as performance, maintainability, etc)

• Budget Limitation

• Time Limitation

• Force to apply specific technology, methodology, or organizational discipline

Developing Organization Concerns

Business issues– investing in, and then amortizing the

infrastructure (domain analysis rather than application analysis)

– keeping cost low

– simplicity of implementation

Organizational issues– using the current organizational structure

– utilizing personnel

Technical Environment

• Current trends: today’s information system are web-based and use middleware systems (e.g. J2EE, .Net)

• Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed; both are changing quantities.

Architect’s Background

Architects develop their mindset from

their past experiences.

– Prior good experiences will lead to replication of prior designs.

– Prior bad experiences will be avoided in the new design.

Summary: Influences on the

Architect

Architecture Influences the

Development Organization

• Organizational Structure and Recourses

– Work units are organized around architectural units

– Schedule

– Budget

• Enterprise Goals

– Expertise in building a kind of systems

– Success in a market

– Evaluating a market

– Product-line assets

Architecture Influences Customer

Requirements

• Knowledge of customers to ask for particular features in next systems.

• Support of upgrade, adaptation, etc.

Architecture Influences the

Architect’s Experience and

Technical Environment

• Creation of a system affects the architect’s background.

• Occasionally, a system or an architecture will affect the technical environment.

Architecture Business Cycle

Process Steps in Architecture-Based Development

• Understanding the requirements

• Creating, customizing, or selecting the architecture

• Representing and communicating the architecture

• Analyzing or evaluating the architecture

• Implementing based on architecture

• Ensuring conformance

Creating the Business Case

• Creating a business case is broader than simply assessing the market need for a system.

• How much should the product cost?

• What is its targeted market?

• What is its targeted time to market?

• Will it need to interface with other systems?

• Are there system limitations that it must work within?

Understanding the Requirements

• object-oriented analysis uses scenarios, or "use cases" to embody requirements

• Prototypes may help to model desired behavior, design the user interface, or analyze resource utilization

Communicating the Architecture

• For the architecture to be effective as the backbone of the project's design, it must be communicated clearly and unambiguously to all of the stakeholders.

• Developers must understand the work assignments it requires of them, testers must understand the task structure it imposes on them, management must understand the scheduling implications it suggests, and so forth.

Analyzing or Evaluating the Architecture

• In any design process there will be multiple

candidate designs considered.

• Some will be rejected immediately.

• Others will contend for primacy.

• Choosing among these competing designs in a rational way is one of the architect's greatest challenges.

• Evaluating an architecture for the qualities that it supports is essential to ensuring that the system constructed from that architecture

satisfies its stakeholders' needs.

Implementing Based on the Architecture

• This activity is concerned with keeping the

developers faithful to the structures and interaction protocols constrained by the architecture.

• Having an explicit and well-communicated architecture is the first step toward ensuring architectural conformance.

• Having an environment or infrastructure that

actively assists developers in creating and maintaining the architecture (as opposed to just the code) is better.

Ensuring Conformance to an Architecture

• Finally, when an architecture is created and used, it goes into a maintenance phase.

• Constant vigilance is required to ensure that the actual architecture and its representation remain faithful to each other during this phase.

• Although work in this area is comparatively immature, there has been intense activity in recent years.

What makes a Good Architecture?

• No such thing as an inherently good or badarchitecture.

• Architectures are more or less fit for some stated purpose.

• Architectures can be evaluated - one of the great benefits of paying attention to them -but only in the context of specific goals.

• Rules of Thumb: process & product (structural) recommendations

Process recommendations

• The architecture should be the product of a single architect or a small group of architects with an identified leader.

• The architect (or architecture team) should have the functional requirements for the system and an articulated, prioritized list of quality attributes (such as security or modifiability) that the architecture is expected to satisfy.

• The architecture should be well documented, with at least one static view and one dynamic view using an agreed-on notation that all stakeholders can understand with a minimum of effort.

• The architecture should be circulated to the system's stakeholders, who should be actively involved in its review.

• The architecture should be analyzed for applicable quantitative measures (such as maximum throughput) and formally evaluated for quality attributes before it is too late to make changes to it.

• The architecture should lend itself to

incremental implementation via the creation of a "skeletal" system in which the communication paths are exercised but which at first has minimal functionality.

• The architecture should result in a specific (and small) set of resource contention areas, the resolution of which is clearly specified, circulated, and maintained.

• For example, if network utilization is an area of concern, the architect should produce (and enforce) for each development team guidelines that will result in a minimum of network traffic.

Product Recommendations:

• The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns.

• Each module should have a well-defined interface that encapsulates or "hides" changeable aspects (such as implementation strategies and data structure choices) from other software that uses its facilities.

• Quality attributes should be achieved using well-known architectural tactics specific to each attribute,

• The architecture should never depend on a particular version of a commercial product or tool.

• If it depends upon a particular commercial product, it should be structured such that changing to a different product is straightforward and inexpensive.

• Modules that produce data should be

separate from modules that consume data.

• For parallel-processing systems, the architecture should feature well-defined

processes or tasks that do not necessarily mirror the module decomposition structure.

• Every task or process should be written so that its assignment to a specific processor

can be easily changed, perhaps even at runtime.

• The architecture should feature a small number of simple interaction patterns