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

1、Name：Mail：Mobile：中 科 院 计 算 所 培 训 中 心 软件产品线架构组织与技术谢新华谢新华http:/2第一章 软件框架技术的设计思想3一、架构、框架与复用一、架构、框架与复用框架在软件复用中的意义 共享框架与产品线架构 产品线架构设计与软件组织 4框架（Framework）的特征框架是可以通过某种回调机制进行扩展的软件系统或者子系统。框架的概念主要来自于对“重用概率”的分析。一个软件单元被重用，单元粒度越大，重用概率越低，但是重用价值越大。反之，单元粒度越小，重用概率越高，但是重用价值越小。框架的智慧在于，在单元粒度比较大的情况下，追求高的重用概率。5框架和架构的关系6二

2、业务模式与框架技术所谓“模式”强调的是某种功能单元可能被使用上百次，但使用的方式却不尽相同。模式是一种灵活的思想，运用它却需要智慧和想象力，因为没有两种完全一样的功能需求。条理性工程条理性工程：应用经过考验的模式，通过恰当的组合和微小的修改达到目的。探索性工程：对新的各种各样的设计的非结构化探索。7第二章第二章 利用需求模式发现业务的共性利用需求模式发现业务的共性8一、发现需求的变化规律一、发现需求的变化规律发现需求的变化规律 发现与归纳需求模式 从事件响应上下文发现模式建立跨领域的需求模式 9确定和使用模式的技能与以下一些能力有关从不同的抽象层次来看待工作的能力；按不同的方式进行分类的能力

3、发现望远镜与注满水的玻璃半球都是放大镜的能力；指出显然不同事情之间相似之处的能力；以抽象的方式来看问题的能力。10第三章第三章 产品线架构的组织与原则产品线架构的组织与原则11一、组织产品线的需求一、组织产品线的需求开发产品系列的前景文档，描述产品共同的工作方式以及共享的特性。为了更好的理解共享用法的模型，也应该设计一套用例，先是用户如何与共同运行的不同应用自建交互。开发定义关于共享功能的特殊需求的公共软件需求，例如，公共GUI和通信协议。为系列中的每个产品开发前景文档、补充规格说明以及定义特殊功能的用例模型。12二、确定范围 在核心资产库中，软件架构是重中之重，而一个可以在几乎所有产品线中

4、不同产品可以通用的架构，设计的关键是架构设计中有一组明确允许可以发生变化的，所以，识别允许的变化是架构设计责任的一部分。13三、确定变化点 由于产品可能会以很多方式发生变化，在产品线设计之初，我们必须确定在产品线的需求分析中获取变化点。其中包括特性、平台、用户接口、质量属性以及目标市场等。其次，在产品线的架构设计中，我们还可以获取其它的变化点，最后，在产品线的实现过程中，对变化点可能会带来新的灵感。这是必要，因为某些决策只有在获取更多的信息之后才能确定。14四、支持变化点在我们面向对象的设计模式中，利用泛化和特化可以实现这种变化。它的特点是系统具有相同的接口但具有不同的行为。把扩展点构建到元素

5、的实现中，也就是放在可以安全的添加额外的行为和功能的地方。可以通过元素、子系统或子系统集合引入构建参数来完成，这里可能需要使用配置文件，必要的时候可以使用反射。15五、产品线架构的组织原则五、产品线架构的组织原则产品线架构设计的五个原则被称之为VRASP模型（Vision、Rhythm、Anticipation、Partnering、Simplification）。这个模型重点在于框架设计的组织方面。16构思：构思：构思原则说明了如何向架构的受益人描绘一幅一致的、有约束力的、以及灵活的未来图像。作为架构师，关键是要确保它提出来的架构设想与公司的业务目标相吻合，对于一个大型公司，做到这点事实上并

6、不容易。17预见：预见：首席架构师必须对未来发展走向有敏锐的洞察力，但这种预见往往和现行的标准有冲突，这就需要在两者间做出平衡，而这种平衡也是非常难处理的。18节奏：节奏：节奏原则确保软件组织可以定期根据可预测的速度、内容和质量对工件进行取舍。在新颖的性能和规定的发布日期之间，有时候必须进行取舍，以确保发布日期，但这点可能和公司高层的设想不同，这如何解决呢？19协作：协作：当首席架构师开始架构设计的时候，协作显得及其重要，我们一定要确保公司、周边合作者、领域架构师和开发组都能理解架构的关键思想。20简化：简化：简化原则要求澄清并最小化架构与创建，当发现两个小组开发的构件有重叠的部分以后，应该可

7、以考虑指定一个共享的构件，如何实现简化是构架师最值得关注的一个问题，非此架构设计的意义就显得不大。21第四章第四章 产品线架构的构思与预见产品线架构的构思与预见22 形成并统一框架构思 阐明风险权衡后果 应用前瞻性思维提出建设性构思 预测、验证和调整 预测产品线架构方向的改变 在过程中评估风险与机会2324在构思中把握一致性和灵活性的考虑 一致性的问题一致性的问题：是指受益人使用框架与期望值的符合程度。也就是说受益人尽管有不同的视点，但共享的框架对他们的利益来说应该保持一致。而且他们对框架的理解也应该一致。灵活性的问题灵活性的问题：是指受益人不破坏框架的情况下，利用共享框架来创建新的没有预见到

8、的情况下的容易程度。这就使框架必须对于创建的解决放案相对容易，如果框架没有灵活性，则软件架构就可能逐渐衰退。25产品线的预测、验证和调整 26第五章第五章 产品线开发中的节奏与协作产品线开发中的节奏与协作27保证节拍、过程与进展定期再评估、同步和调整架构保持节奏确保用户对架构的信心通过节奏协调明确的活动建立合作型组织28保证节拍、过程与进展保证节拍、过程与进展29节奏中需要避免的情况节奏稳定，但缺少内容节奏稳定，但缺少内容：如果每次交付并不能使接受团体从中获得利益，那受益人对于节奏也就没有什么兴趣了。有内容，但节奏不稳定有内容，但节奏不稳定；这样的情况使交付不规则，参与者无法知道何时发生交接，

9、结构框架设计的努力将失去意义30保持节奏确保用户对架构的信心要避免走捷径抛弃功能和推迟发布的权衡 确保对定期建立的承诺 产品线架构的同步发布 建立合作型组织 31第六章 简化架构保持平衡32 从组织和架构两方面思考简化 澄清组织与架构 澄清关键特征的价值与优先级 明确最小需求构建共享核心元素33澄清关键特征的价值与优先级 获得这些能力所带来的经济价值。开发新能力所需要的成本。开发新能力需要学习知识的量及重要性。开发这些能力所减少的风险。34客户满意度的客户满意度的Kano模型模型 35第七章 框架设计的技术实现方案36封装类或者接口的变化利用外观模式封装类的变化37利用适配器模式封装接口变化38封装业务单元的变化利用模板方法封装业务单元变化39利用工厂模式封装对象变化40利用桥接模式封装业务单元变化41利用装饰器模式封装核心业务单元42利用观察者模式处理业务单元的变化43第八章 产品线架构设计中必须注意的问题44从系统的观点考虑问题；关注组织和业务，而不仅仅是技术本身；关注团队特点；采用领航者方法推广架构；关注风险和效益；拥抱变化而设计，把变化看成机会。