Documenting software architecture, Part 1: What software architecture is, and why it's important to document it

Documenting software architecture, Part 1: What software architecture is, and why it's important to document it

Software architecture has increasingly become important for the development of complex real-time systems. In this new series, learn why and how you should document software architecture. You will learn about the five different views, or aspects, that you should document for any medium- to large-scale software development project. This first article in the series introduces software architecture and the importance of documentation. You'll also get an overview of the architecture views that will be covered in upcoming articles.
在開發複雜的即時交易系統中,軟體架構的重要性日益增加.再這一系列中,將會學習為何及如何將軟體架構文件化.你將會學習到五種不同的看法或觀點.在這系列的首篇文章中將會簡單的說明軟體架構與文件化的重要性.同時也在這篇文章了解接下來這一系列所討論有關架構觀點的概述.

Introduction

Software architecture as a discipline began in the 1970s. With the increasing complexity and pressures of developing complex real-time systems, software architecture emerged as a fundamental construct of mainstream systems engineering and software development.
軟體架構在1970年開始成為一項定律.隨著開發複雜即時系統的複雜度與各式的壓力的增加,軟體架構開始成為大型主機系統核心建置與軟體開發的基本要件.

Like any other enduring discipline, software architecture also had its initial challenges. A software architecture represents the structural and behavioral aspects of a system. The textual and diagrammatic expressions that were used during early efforts to document software architectures were often insufficient and imprecise. What was needed was a consistent and well-understood pseudo- or meta-language to unify all the different ways of representing and documenting software architectures. Engineering and computer science communities, fostered by academic research, have made great strides in developing best practices and guidelines for effective documentation of software architecture.
如同其它千百年來的定律一樣,軟體架構也有一定的挑戰性.一個軟體架構代表的是這個系統的結構與行為的表現.在早期,雖然使用文字跟圖像有助於文件化軟體架構的訂定,但畢竟這種方式並不足夠且不夠嚴謹.我們所需要的是一種具有連貫性與易於了解的通俗腳本語言來作為整合不同的軟體架構文件化的方式. 電腦工程科技社群因學術性方面的研究而獲得在發展更有效率的文件化軟體架構上,其最佳的實作與原則這一方面取得了重大的進展.

In this series, you will learn about documenting software architecture. Discover the different aspects you can document: system context, architectural overview, functional architecture, operational architecture, and architectural decisions.
In this first article, learn what software architecture is and the importance of documenting different aspects of the discipline.
再這一系列,你將學會有關於文件化軟體架構.發現下面各種文件化的不同觀點:系統內部,架構概述,功能性架構,操作性架構,與架構種類.
再這一首篇文章中,將學會何謂軟體架構與在文件化中每個觀點的差異處.

Software architecture

Various researchers have interpreted what software architecture is, and they have different viewpoints on how to best represent the architecture of a software system. None of the interpretations is wrong; each has its own merits. The definition by Bass L, et al captures the essence of what software architecture should entail:
"The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them."
各式各樣的研究都已經闡釋何謂軟體架構,同時他們在對於軟體系統架構的最佳實作也有不同的看法.沒有一種研究是錯誤,每一種都具有他們的價值.根據 Bass L,et al 指出的定義為一個軟體架構的本質應具有下列的特性: 程式設計與計算系統之軟體架構是在系統的內部的結構應為軟體的元件組合,而每一元件皆具有外部可透視性的屬性與各元件之間的關連性.

The definition focuses on architecture made up of coarse-grained constructs (software components) that can be considered building blocks of the architecture. Each software component, or architectural building block, has certain externally visible properties that it announces to the rest of the architectural building blocks. Internal details of the software component design and implementation are not a concern to the rest of the system, which looks at a specific software component as only a black box. The black box has certain properties it exhibits, which the rest of the software components can use to collectively realize the business or IT goals. Software architecture identifies the architectural building blocks, at the right level of granularity. It also identifies and documents how the building blocks are related to one another.
首先此定義著眼於如何將可被視之為建構系統架構之區塊的粗略性元件(軟體元件).每一元件,或架構區塊,都會具有外部可視性之屬性設定資料,其可在架構區塊平台上發佈其相關訊息.軟體元件設計與實作的內部細節,並不是系統平台的關注點,這個應該僅視之如同黑盒子般的軟體元件規格書才是. 此黑盒子應該要在軟體元件平台上發佈其相關特性,使之在此平台上可協同合作了解其業務或IT目標.軟體架構在一定程度的等級上定義出建構架構之區塊.同時也定義並可文件化在架構區塊之間的關連性.

Architecture as it relates to software engineering is about decomposing or partitioning a single system into a set of parts that can be constructed iteratively, incrementally, and independently. The individual parts have explicit relationships with one another. When woven together, the individual parts form the architecture of the system, enterprise, or application.
跟軟體工程相關聯的架構指的是將單一子系統中自系統群集中分離或組合時,其具備有可重復性,擴充性,獨立性的構成行為.其個別之部分子系統具有於其他子系統明確清楚的關連.當將其組合在一起時,個別部分子系統可規範出系統,企業或應用程式的架構.

There is some confusion about the difference between architecture and design. As Clements P, et al. point out, all architectures are designs but not all designs are architectures. Designs that need to be bound in order for the system to meet its functional and nonfunctional requirements and goals are architectural in nature. While architecture considers an architectural building block a black box, design deals with the configuration, customization, and internal workings of an architectural building block. The architecture binds a software component to its external properties. Design is usually much more relaxed than architecture, because it allows more ways to adhere to the external properties of the component. Design also considers various ways to implement the internal details of the component.
對於架構與設計此兩者的差異仍有某種的混淆.如同 Clements P, et al 指出:架構就是設計但設計並不一定是架構. 就本質上,設計是架構本身是基於須滿足系統本身的功能,非功能性的需求和目標.當架構把建構架構區塊視之為黑盒子之下,設計就是要處理其設定,客制,與其他區塊的內部協同合作.架構會以其該軟體元件之外部屬性將其於其本身連結起來.相對於架構,設計是比較容易輕鬆的,因為設計可以使用比較多的方式去存取元件的外部特性.設計同時也有比較多的方式去考慮元件本身的實作細節.

Software architecture can be used recursively. Consider a software component (C1) that is part of a software architecture of a system. The software architect hands the component to the system designer, along with its properties, functional and nonfunctional capabilities it should exhibit, and its relationship to other software components. The designer, after analyzing software component C1, decides it should be broken down into finer-grained components (C11, C12, and C13), each of which provides a reusable function that would be used to implement the properties mandated for C1. The designer details out C11, C12, C13 and their interfaces.
軟體架構可以很容易的被擴充.考慮到一個軟體元件(C1)是一個軟體架構系統中的一個部份.此軟體架構的設計可以藉由下列的方式來操控此元件:特性,其所展示功能與非功能的項目與其與其他元件的關連性.再分析系統元件C1之後,設計者決定要將其在分離出更細的元件(C11,C12,C13),



At this point, to this designer, C11, C12, and C13 are architectural constructs (or components); each of them has explicitly defined external interfaces. To the designer, C11, C12, and C13 are the architecture of software component C1, and the constructs need further elaboration and design to address their internal implementations. Architecture can be used recursively by dividing a large, complex system into small constituent parts and focusing on each part.


Architecture bounds the system using the architectural building blocks that collectively meet the behavioral and quality goals. The stakeholders must be able to understand the architecture. So it is imperative that an architecture is adequately documented, as discussed in the next section.



原文:
http://www.ibm.com/developerworks/library/ar-archdoc1/?S_TACT=105AGX78&S_CMP=HP