昨天有幸聽到了David Weiss大叔的講座，覺得真的很好，不愧是大師，之前看論文找資料想不明白的問題，大叔幾句話就說得通通透透，遂想記下聽完的總結，大體梳理下FAST過程的脈絡
學到的最重要的兩點：
Software Engineering ---> 就是不停的Make Decisions
Module ---> 就是Work Assignment
一、FAST process是什麼
1.1軟體産品線(Software Product Line)
軟體産品線：Software Product Line，其思想源于傳統的産品線(如Ford汽車的産品線)，由于和傳統工業類似，目前在軟體方面也出現了需要大規模定制生産類似的（但又有所不同的）産品，Product Line的思想也就被借鑒過來，形成了軟體産品線的思想，另外SPL也稱為軟體家族，Software Family，下面統一使用Family。目前關于Family的研究有很多，也形成了幾個發展比較好的流派如FAST，FODA，COPA等等。而FAST方法源自工業界，作為Family的方法學級别工具有比較好的應用。關于Family介紹詳見傳送門：http://www.sei.cmu.edu/productlines/.軟體産品線的目标是提高生産率，方式是通過實作除代碼級别的更進階别複用reuse完成。具體形式是自動的生成産品部分代碼和文檔。
建立一個産品線，最重要的一點是要實作工件(artifact)的複用，這裡的工件不僅僅是指代碼，也包含需求文檔和參考架構等等。需要實作複用，就要有相當多的共同點才可以，而SPL中最重要的一點就是識别Family中的共同點Commonality和差異點Variability。
1.2 FAST process
FAST：Family-Oriented Abstraction ,Specification ,Translation 是David Weiss在上個世紀末提出來的關于軟體産品線(軟體家族)的一種方法學。它的目标是提高重用，提升效率，形式是自動生成代碼和文檔。
FAST process中的：
1) Family指的就是Software Product Line，Family和SPL的意思是一樣的
2) Abstraction，抽象使我們描述一個物體最重要的工具，用來描述Family也是，我們通常使用抽象來發現Family中的Commonality和Variability
3) Specification，我們通過上面的Abstraction已經得到了一個Family(或者SPL)的抽象描述，下面我們需要定義一種描述Family以及Family Member的方式，也就是給出Family, Family Member的Specification。
4) Translation，有了上面的嚴格的Specification，我們就可以使用某種辦法将Specification轉換成實際的軟體産品Family member
Fast is a process for defining families and developing environments for generating family members.
FAST方法定義了使用的一系列的活動Activities以及這些活動的産出工件Artifact等等
二、FAST process的主要内容
如下圖主要給出了FAST process的主要流程，
FAST process一共分為以下兩步：Domain Engineering 和 Product Engineering(Application Engineering)，其中Domain Engineering完成主要的領域分析工作，并且産生Product Engineering Environment（支援Application Engineering的一系列工具集、 Core Asset等等），然後由Product Engineering來使用Product Engineering Environment提供的工具完成對具體Family member的開發(即定義成員，然後自動生成成員的文檔和代碼等等)。其中Domain Engineering是兩者中更重要的部分，我們這裡隻讨論Domain Engineering.
下面給出FAST過程中需要産生的工件artifacts。
根據此圖，由上到下的一步一步産出，也就是一個FAST過程的典型過程。(另外Domain Engineering 和 Application Engineering可以并行，在Domain Engineering 完成某部分工作的時候，Application Engineering就可以利用這部分産出進行産品的設計，其使用的結果也可以反過來回報Domain Engineering部分，使其完善。)
2.1 Domain Engineering
Domain Engineering是過程的開始，它負責對Family的Domain需求進行分析，需要給出Domain Model。由上面的Artifact圖可見，Domain Engineering主要的工作有兩步：Domain Modeling，Domain Implement。Domain Engineering的流程如下
首先通過對涉及的Domain進行分析，得到Domain Model，然後再由Domain Implement部分對Domain Model中需要實作的部分進行實作，得到Product Engineering Environment。
下面對Domain Model中的一些工件進行說明。
2.1.1 Economical Model
Economical model ：給出對此Domain使用Family方法之經濟模型，判定使用SPL方法是否是經濟可行的，是否真的能帶來收益(一般當Family中的産品多于等于3個，進行SPL就是可行的)。
2.1.2 Family Definition
1) Commonalities and VariabilityAmong Family members.對Family進行分析，得到Family members的共同性和差異性
a) 對差異性進行參數化(量化，以參數Parameters的形式表示)
關于Commonality和Variability的分析，我們有比較重要的兩種Abstraction Method：術語和共同點。通過對領域的術語的精确定義和對共同點(對所有Family成員都為True的假設)的分析是比較好的兩個着手點.
2) Decision Model
像昨天Weiss大叔說的，做軟體工程，其實最重要的也是一直做的事就是決策，一直不停的Make Decision。
在這裡，我們需要做的就是給出每個Family member關于上面的Variability所做出的Decision，把它們組織起來形成一個表 ，Decision Model Table，其中不僅包括使用者做的選擇，也包括這些Decision可能對其他Decision的影響，Contrains，如選擇一個Decision就必須進行另外一個Decision等等。
引用原話：“Decision Model is the set of decisions, the (partial) order in which they must be made to specify products, including the binding time ,and the mapping to modules.”
2.1.3 FAST Product Line Architecture：
一般也叫做參考架構或者架構，是整個Family中産品的程式基本架構，關系到整個産品線的擴充性和穩定性，是非常重要的部分。在定義了Family之後我們就應該給出這個Family的參考架構。
另外關于軟體的架構，我們把它定義為modules，以及module的interface，modules之間的關系的集合。
由于不同的人看架構要以不同的視角去看，是以Family的Architecture也提供了不同的Views，下面是FAST方法的Key Architecture Structures。
1) Module Structure：
Module是什麼：像昨天Weiss大叔說的，Module不是别的，它是 a work assignment， ，配置設定者隻負責給出工作的要求，其它的則由被配置設定到的個體完成。
這裡就用到一個基本的概念：資訊隐藏，原則上說我們需要将每個Secret都隐藏到子產品中間，也就是我們需要将每個Variability都實作為一個子產品。而在這個視圖(或是Structure)下，我們不關心具體的工作，隻關心這些工作是如何劃分如何配置設定的，有多少個人來完成這個Module？(更适合管理者檢視)
原則上Module Structure要給出每個Module的組成關系(也就是系統的分解圖，一般是個樹型結構)
2) Use Structure
在這個視圖下，需要給出不同的Module之間的使用關系，側重于Module的互動，Module直接的使用更像是一個樹的結構
3) Process Structure
在這個視圖下，側重于程序的并發、同步的方面，給出類似程序時序圖的結構
4) Module Interface Specification.
在這個視圖下，主要給出每個Module的接口規範，給出對Module的Interface要求和限制等等。需要有：module提供的服務、服務的文法結構、用到的資料類型、程式要達到的效果、測試用例、記錄做出Decision和實作的資訊。
另外，在此處定義了Architecture之後，在對應的Domain Implementation部分要給出具體的Architecture實作，包括支援架構的類庫，模版等等。
2.1.4 Application Modeling Language：key of PE Environment
也叫做Domain Specification Language，主要是用來描述Family member的，FAST中的S：specification 部分就由AML書寫。其中AML的實作方式有兩種
1) Compose：使用組裝的方式，将元件組裝成Family member（自動生成文檔和代碼），實作起來比較容易。
2) Compile：使用編譯的方式，将AML編譯成Family member，實作難度較大。、
根據此處AML的實作方式的選擇不同，在具體的Domain Implementation部分要給出對應的AML實作方案，或者是Compositor或是Compiler
2.1.4 System Composition Mapping
（Mapping From Parametersof Variation to Modules）
由于分離關注點的思想，我們将每個Parameters ofVariability都封裝在一個具體的module中，我們将定義一個從Decision 到Modules的映射，Decision Table。其内容包括
VariabilityId/Variability Name/Value Set /Constrains/ Module，如圖：
這樣就可以将每個Decision對應到一些具體的Module上，根據這個對應關系，我們就可以在Application Domain進行了Decision之後，選擇正确的Module進行組裝或者編譯使用，達到自動依靠參考架構和代碼模版生成代碼的功能。如圖例，From Decisions To Implementation。
有了AML和System CompositionMapping，我們就有了自動生成部分代碼或文檔的方法，相應的生成工具也要在Domain Implementation中給出
引用原話“Product generation consistsof walking the decision graph , applying the constraints ,and retrieving theassociated modules.”
2.2 Domain Engineering work flow
下面以工件為主體，給出DomainEngineering的流程：
| 工件對應在Implementation部分工作 | Analysis部分工件 | 工件的目的 |
| 1.Economical Model | 确定使用SPL方法是否是否有效用，經濟可行 | |
| 2.Commonality Analysis | 1) 得到術語表 2) 得到Commonality 3) 得到 Variability 4) 得到變化點的參數化值 5) 給出對于Common和Variation進行說明的情景 | |
| 3.Decision Model | 得到對于每個Family中産品 的Decision Table，即根據Variability的參數值選擇，以及其中的限制等等。 | |
| 實作參考架構，代碼、文檔模版，library of templates等。 | 4.Family Design | 得到參考架構，要給出module , use relation, interface ,process 等視圖 |
| 和Decision Model一起，用于生成産品的Generator | 5.Composition Mapping | 給出從Decision到Modules的映射方式，即每個Decision所涉及Modules，為生産Family Member做準備 |
| 6.AML | 給出定義Application（家族成員）的方式 | |
| 7.Tool Set Design | 給出AML，和Composition Mapping等工具的實作大體方式 | |
| 8.Application Engineering Process | 給出如何使用Tool Set進行Application Engineering的過程。 |
此外在完成了Domain Engineering 過程後，Application Engineering部分利用完成的Tool Set和定義好的Application Engineering Process完成對産品成員的定義，并利用Generator對産品代碼和文檔進行生成。
另外，産生的産品文檔和代碼需要與Core Asset保持可以追溯的性質，是以需要有Configuration Management Tool的介入，上面沒有給出。而且在産出了産品之後，還需要分析其是否滿足需求，這也用到了Analysis Tool 部分，這個在上面也沒有讨論。
2.3其他
2.3.1 Binding time
關于Binding time，即Make Decisions的時間。在我們實作産品的時候要将Variability的Parameter綁定到我們的Architecture中，即給出使用的Parameters，這個決定制定的時間是不一定的，根據Variability的不同，binding time也會跟随實踐情況而變，确定正确的Binding時間很重要，要根據決策順序給出決策圖來拓撲進行，原則是盡量将綁定推遲。
2.3.2架構
關于軟體架構的利益相關人：
Product Management 、System Engineering、Architects、Software Development、System Verification、Project Management、Services.
不同的利益相關人希望關注的Concerns不同，是以不同的利益相關人需要不同的Views，這也就有了Architecture Views的出現
3.2.3領域相關
關于domain：work hard。每個領域都有自己的特殊性質，它們的參考架構，應用模式也各不相同，學習相關Domain唯一的方法，David Weiss大叔給出的方案也是Work Hard，通過自己的實踐、向領域專家的請教、閱讀領域書籍提升對領域的了解。