软件架构的魅力6–读书笔记

最后一篇了。这本书 http://book.douban.com/subject/3669563/ 反反复复读了三遍。其实读到最后一遍,已经不关注书里在说什么了,而是关注作者为什么这样说,他们的理念是怎么得来的?

从中感悟出一些方法论上的东西:进入一个领域,先要理解概念,然后抽取共性,形成全局运转图,从顶到下,共性归类,建立起隔离带,再逐步细化,形成整个的系统概念。

软件产品线架构:

何谓软件产品线?SEI的定义:A software product line is a set of software-intensive system that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

软件产品线的几个重要特征:

1 有产品家族,一系列的产品成员。

2 所有产品都是服务于一些特定相似的领域。

3 成员有相同或相似的功能,这些功能来自一些公共的、固化的、并且是受严格管理的核心软件资产。这个应该是软件产品线的核心。

4 产品是在一种严格规划和管理的有序状况下系统化进行的工作。

将多个产品整理为产品线架构,有个产品线架构变革过程模型PLAEM供参考:

PLAEM:Product Line Architecture Evolution Model

需求分析阶段->系统架构阶段->构件设计阶段->测试及配置管理->产品线演化阶段->技术及管理因素

其中最重要的就是产品间的共性和可变性分析:Commonality Analysis和Variability Analysis。

1 共性和可变性分析,会在产品线的应用领域内界定公共词汇,奠定公共的沟通基础。

2 分析结果有助于界定一个产品家族可能的范围。

3 分析结果最终严格确定了产品家族中每个成员所具有的相同的功能或特性,这是产品线的共性部分。

4 精确定义产品家族每个成员所具有的独特的功能或特性。这可以包括使用环境、组成结构、功能行为、控制流程和逻辑的各异性等,这组成了产品线的可变性部分。

5 产品线中各个产品的各异功能或特征的变化范围,需要严格定义,这将最终定义成为一个变化区间。这是系统的弹性,演化的范围。

共性/可变性分析流程:

识别和划分领域->单个领域共性分析->单个领域可变性分析->将一些可变性化为共性->可变性可变范围参数化->设定可变性的绑定时间(注:指在空间/范围维度、时间维度的变化可能性,以便设计人员能够应用不同的绑定方式来应对每个可变性的发生。)

在分析过程结束后,进入构建阶段。参考业界产品线的实践,有两种方式来构建自己的产品线架构:

1 框架风格的产品线架构(Framework):构建一个通用、可靠的整体产品的总架构,一个其领域内的应用框架(非公共开发框架),类似J2EE这样风格的。

2 标准产品风格的产品线架构(Standard Product):采用一个标准产品作为应对变化的基石,所有的各异性要求都是在对该标准产品客户化定制的基础之上进行应对。

一点感悟:框架风格的产品线架构,一般是国际大公司的价值基础,像国内的小公司是很难支撑起这样的工作量和难度。

しゅうりょう

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s