Essential Software Architecture 学习书摘 I

Essential Software Architecture
Ian Gorton

Foreword
Architects learn on the job, bring years of experience in design and technology to business problems they tackle.

Preface
Application servers, component technologies and messaging infrastructures are the basic building blocks that are import to an IT architect.

Definition of Software Architecture

a. Architecture Defines Structure
An architecture must be designed to meet the specific requirements and constrains of the application it is intended for.

In partitioning an application, the architect assigns responsibilities to each constituent component. These responsibilities define the tasks a component can be relied upon to perform within the application. In this manner, each component plays a specific role in the application, and the overall component ensemble that comprise the architecture collaborates to provide the required functionality.

Responsibility-driven Design can be used effectively to help define the key components in an architecture.

A key structural issue for nearly all applications is minimizing dependencies between components, creating a loosely coupled architecture from a set of highly cohesive components.

b. Architecture Specifies Component Communication
A body of work known collectively as architectural patterns or styles has cataloged a number of successfully used structures that facilitate certain kinds of component communication. There patterns are essentially reusable architectural blueprints that describe the structure and interaction between collections of participating components.

Large systems tend to use multiple patterns, combined in ways that satisfy the architecture requirement. When a architecture is based around patterns, it also becomes easy for team members to understand a design.

c. Architecture Addresses Non-functional Requirements
Rather than define what the application does, they are concerned with how the application provides the required functionality.

There are three distinct areas of non-functional requirements:
Technical constraints
Business constraints
Quality constraints
An application architecture must therefore explicitly address these aspects of the design.

d. Architecture is an Abstraction
One of the most powerful mechanisms for describing an architecture is hierarchical decomposition. Different levels of description in the hierarchy tend to be of interest to different developers in project.
In reality, any architectural description must employ abstraction in order to be understandable by the team members and project stakeholders.

e. Architecture View
Views and Beyond approach recommends capturing an architecture model using three different views:
Module: This is a structural view of the architecture, comprising the code modules such as classes, packages and subsystems in the design. It also captures module decomposition, inheritance, associations and aggregations.
Component and Connector: This view describes the behavioral aspects of the architecture. Components are typically objects, threads or processes, and the connectors describe how the components interact. Common connectors are sockets, middleware like CORBA or shared memory.
Allocation: This view shows the processes in the architecture are mapped to hardware, and how they communicate using networks and/or databases.

What Does a Architect Do?
a. Liaison
Architects play many liaison roles. They liaise between the customers or clients of the application and the technical team, often in conjunction with the business and requirement analysts. They liaise between the various engineering teams on a project, as the architecture is central to each of these. They liaise with management, justifying designs, decisions and costs. Much of the time, this liaison takes the form of simply translating and explaining different terminology between different stakeholders.

b. Software Engineering
Excellent design skills are what get a software engineer to the position of architect. They are an essential pre-requisite for the roles. More broadly though, architects must promote good software engineering practices. Their designs must be adequately documented and communicated and their plans must be explicit and justified.

c. Technology Knowledge
Architects have a deep understanding of the technology domains that are relevant to the types of applications they work on. They are influential in evaluating and choosing third party components and technologies. They tract technology development, and understand how new standards, features and products might be usefully exploited in their projects. Just as importantly, good architects know what they don't know.

d. Risk Management
Good architects tend to be cautious. They are constantly enumerating and evaluating the risks associated with the design and technology choices they make. They document and manage these risks in conjunction with project sponsors and management.

Architectures and Technologies
Architects must make design decisions early in a project lifecycle. Judicious prototyping of key architectural components can help increase confidence in a design approach, but sometimes it's still hard to be certain of the success of a particular design choice in a given application context.

Competition between product vendors drives innovation, better feature sets and implementations, and lower prices, but it also places a burden on the architect to select a product that has quality attributes that satisfy the application requirement. Different COTS technology implementation have different sets of strengths and weaknesses and costs, and consequently will be better suited to some types of application than others.

The difficulty for architects is in understanding these strengths and weaknesses early in the development cycle for a project, and choosing an appropriate reification of the architectural patterns they need.

Summary
"The life of a software architect is a long (and sometimes painful) succession of sub-optimal decisions made partly in the dark". -Philippe Krutchen