1,软件工厂
如 果外包厂商有很多客户,则随着业务的开展,有机会改编本质上相同的系统满足客户的不同需求;实际上执行这种程序要求厂商构建很多客户共同需求的业务模型; 除了对客户现有的实践建模之外,还有机会帮助客户对其业务进行再造,产生更有效的模型;然后,复用业务查找这些模型中的通用性和可变性,这些通用性和可变 性又提供了适合组件系统的基础;当然,组件系统又导致适合每个客户的应用系统;以第二种模式运作的软件工厂常常将力量集中在一个行业的客户上,例如电力设 施、金融服务和制造等;同一个行业的客户具有类似的软件需求,一旦厂商熟悉了这些需求,就可以构建反映这些需求的业务模型,然后与以前一样,构建适合的组 件系统,组件系统的可变性使得厂商可以修改组件使其适应不同客户的不同环境;最初,软件工厂可能会销售通过自己的组件系统组装的应用系统,如果组件系统和 业务模型都描述的非常清楚,客户就可以自己创建应用系统了
2,体系结构
高的软件复用率只能通过在体系结构上投资,软件系统的仔细设计,以及用于构建软件系统的可复用组件来实现
3,用例
用例是描述需求的另外一种方式,一图胜千言,如Actor类型关系、用例扩展关系等;用例不是设计,它只是文字版需求规格说明书的另外一种表达方式
4,用例
一个用例的功能是完整的,可被独立使用的
5,用例
分析时用例有两种合作关系,使用和扩展;使用在设计上可能对应着委托,包容,甚至继承,扩展则对应着横切点或扩展点
6,可变性机制
机制 | 变化点类型 | 变体类型 | 使用时机 |
继承 | 虚拟操作 | 子类或子类型 | 保持其它不变,具体化并添加所选择的操作 |
扩展 | 扩展点 | 扩展 | 必须能够同时在每个变化点上附加多个变量 |
使用 | 使用点 | 用例 | 复用抽象用例以创建具体化的用例 |
配置 | 配置项槽 | 配置项 | 选择可替换功能和实现 |
参数 | 参数 | 捆绑参数 | 每个可变特性有多个小的变化点 |
模板实例化 | 模板参数 | 模板实例 | 进行类型适配或选择可替换的代码段 |
生成 | 参数或脚本语言 | 捆绑参数或表达式 | 通过与特定问题有关的语言,大规模的创建一个或多个类型或类 |
7,参数化
参 数化最适合特性变体很小的场合(例如,比句子小,常常是数字值,短语或表达式);当同一个组件内部或跨多个组件分布的多个地方使用同一个变化点时,参数化 可以发挥其最大力量,在这种情况下,一个参数可以控制多个地点的一致选择;参数化还可以用于在使用条件扩展的不同实现中作出选择,这种情况在很多程序设计 语言中是很常见的
8,变化点与配置项
最好是语言直接支持明确表示之
9,用例
用例不只是需求记录文档,还是需求开发手段;用例是可复用的需求文档
10,异常与扩展
我们一直被教育用异常来表示真正的异常,不要用来控制正常流程;但AOP出现前,异常也曾被用来作为扩展的手段
11,应用系统特性与可复用元素
带有公共组件和特性的独立应用系统 | 一些公共实体类和相关的类 |
互操作但是相当不同 | 很多实体类型 |
互操作、集成的应用系统套件 | 一些具体和一些抽象用例,大多数实体类型、绝大多数边界类型和一些控制类型和类 |
作为一般应用系统功能基础定制构建的单独的应用系统 | 一些具体和一些抽象用例,大多数通过公共组件系统复用和具体化的类型和类 |
作为一般应用系统功能基础定制构建的可互操作应用系统 | 一些具体和一些抽象用例,大多数通过公共组件系统复用和具体化的类型和类,很多类型和类还原封不动的复用 |
12,静态依赖降低结构稳定性
13,架构设计师 vs. 过程领导者
尽量不要是同一个人
14,组件系统的有效性
会逐渐下降,应该使用新技术更新,后续应用程序使用更新后的组件系统开发