昨天有幸听到了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，通过自己的实践、向领域专家的请教、阅读领域书籍提升对领域的了解。