软件产品线架构组织与技术

1、 软件产品线架构组织与技术谢新华2第一章 软件框架技术的设计思想3一、架构、框架与复用框架在软件复用中的意义 共享框架与产品线架构 产品线架构设计与软件组织 4框架Framework 的特征框架是可以通过某种回调机制进行扩展的软件系统或者子系统。框架的概念主要来自于对“重用概率的分析。一个软件单元被重用，单元粒度越大，重用概率越低，但是重用价值越大。反之，单元粒度越小，重用概率越高，但是重用价值越小。框架的智慧在于，在单元粒度比较大的情况下，追求高的重用概率。5框架和架构的关系6二、业务模式与框架技术所谓“模式强调的是某种功能单元可能被使用上百次，但使用的方式却不尽相同。模式是一种灵活的思想，

2、运用它却需要智慧和想象力，因为没有两种完全一样的功能需求。条理性工程：应用经过考验的模式，通过恰当的组合和微小的修改到达目的。探索性工程：对新的各种各样的设计的非结构化探索。7第二章 利用需求模式发现业务的共性8一、发现需求的变化规律发现需求的变化规律 发现与归纳需求模式 从事件响应上下文发现模式建立跨领域的需求模式 9确定和使用模式的技能与以下一些能力有关从不同的抽象层次来看待工作的能力；按不同的方式进行分类的能力；发现望远镜与注满水的玻璃半球都是放大镜的能力；指出显然不同事情之间相似之处的能力；以抽象的方式来看问题的能力。10第三章 产品线架构的组织与原那么11一、组织产品线的需求开发产品

3、系列的前景文档，描述产品共同的工作方式以及共享的特性。为了更好的理解共享用法的模型，也应该设计一套用例，先是用户如何与共同运行的不同应用自建交互。开发定义关于共享功能的特殊需求的公共软件需求，例如，公共GUI和通信协议。为系列中的每个产品开发前景文档、补充规格说明以及定义特殊功能的用例模型。12二、确定范围 在核心资产库中，软件架构是重中之重，而一个可以在几乎所有产品线中不同产品可以通用的架构，设计的关键是架构设计中有一组明确允许可以发生变化的，所以，识别允许的变化是架构设计责任的一局部。 13三、确定变化点 由于产品可能会以很多方式发生变化，在产品线设计之初，我们必须确定在产品线的需求分析中

4、获取变化点。其中包括特性、平台、用户接口、质量属性以及目标市场等。其次，在产品线的架构设计中，我们还可以获取其它的变化点，最后，在产品线的实现过程中，对变化点可能会带来新的灵感。这是必要，因为某些决策只有在获取更多的信息之后才能确定。14四、支持变化点在我们面向对象的设计模式中，利用泛化和特化可以实现这种变化。它的特点是系统具有相同的接口但具有不同的行为。把扩展点构建到元素的实现中，也就是放在可以平安的添加额外的行为和功能的地方。可以通过元素、子系统或子系统集合引入构建参数来完成，这里可能需要使用配置文件，必要的时候可以使用反射。15五、产品线架构的组织原那么产品线架构设计的五个原那么被称之为

5、VRASP模型Vision、Rhythm、Anticipation、Partnering、 Simplification。这个模型重点在于框架设计的组织方面。16构思：构思原那么说明了如何向架构的受益人描绘一幅一致的、有约束力的、以及灵活的未来图像。作为架构师，关键是要确保它提出来的架构设想与公司的业务目标相吻合，对于一个大型公司，做到这点事实上并不容易。17预见：首席架构师必须对未来开展走向有敏锐的洞察力，但这种预见往往和现行的标准有冲突，这就需要在两者间做出平衡，而这种平衡也是非常难处理的。18节奏：节奏原那么确保软件组织可以定期根据可预测的速度、内容和质量对工件进行取舍。在新颖的性能和规

6、定的发布日期之间，有时候必须进行取舍，以确保发布日期，但这点可能和公司高层的设想不同，这如何解决呢？19协作：当首席架构师开始架构设计的时候，协作显得及其重要，我们一定要确保公司、周边合作者、领域架构师和开发组都能理解架构的关键思想。20简化：简化原那么要求澄清并最小化架构与创立，当发现两个小组开发的构件有重叠的局部以后，应该可以考虑指定一个共享的构件，如何实现简化是构架师最值得关注的一个问题，非此架构设计的意义就显得不大。21第四章 产品线架构的构思与预见22 形成并统一框架构思 说明风险权衡后果 应用前瞻性思维提出建设性构思 预测、验证和调整 预测产品线架构方向的改变 在过程中评估风险与时

7、机2324在构思中把握一致性和灵活性的考虑 一致性的问题：是指受益人使用框架与期望值的符合程度。也就是说受益人尽管有不同的视点，但共享的框架对他们的利益来说应该保持一致。而且他们对框架的理解也应该一致。灵活性的问题：是指受益人不破坏框架的情况下，利用共享框架来创立新的没有预见到的情况下的容易程度。这就使框架必须对于创立的解决放案相对容易，如果框架没有灵活性，那么软件架构就可能逐渐衰退。25产品线的预测、验证和调整 26第五章 产品线开发中的节奏与协作27保证节拍、过程与进展定期再评估、同步和调整架构保持节奏确保用户对架构的信心通过节奏协调明确的活动建立合作型组织28保证节拍、过程与进展29节奏

8、中需要防止的情况节奏稳定，但缺少内容：如果每次交付并不能使接受团体从中获得利益，那受益人对于节奏也就没有什么兴趣了。有内容，但节奏不稳定；这样的情况使交付不规那么，参与者无法知道何时发生交接，结构框架设计的努力将失去意义30保持节奏确保用户对架构的信心要防止走捷径抛弃功能和推迟发布的权衡 确保对定期建立的承诺 产品线架构的同步发布 建立合作型组织 31第六章 简化架构保持平衡32 从组织和架构两方面思考简化 澄清组织与架构 澄清关键特征的价值与优先级 明确最小需求构建共享核心元素33澄清关键特征的价值与优先级 获得这些能力所带来的经济价值。开发新能力所需要的本钱。开发新能力需要学习知识的量及重要性。开发这些能力所减少的风险。34客户满意度的Kano模型 35第七章 框架设计的技术实现方案36封装类或者接口的变化利用外观模式封装类的变化37利用适配器模式封装接口变化38封装业务单元的变化利用模板方法封装业务单元变化39利用工厂模式封装对象变化40利用桥接模式封装业务单