软件企业増值税即征即退专题培训.pptVIP

第四章 软件体系结构描述 4.8 软件体系结构的设计 ◇ 体系结构设计的原则 软件系统的部件应该实现策略或处理问题，但不能同时处理两者。 策略部件负责处理上下文相关的决策、信息的语义和解释的知识、把不相交计算组合形成结果、对参数值进行选择等问题。 实现部件负责全面规范算法的执行，执行中不需要对上下文相关信息进行决策。上下文和解释是部件外部施加的，它通常由传给部件的参数提供。 7.策略和实现的分离 第四章 软件体系结构描述 4.8 软件体系结构的设计 ◇ 体系结构设计的原则 由于独立于特定的上下文环境，纯实现部件更容易重用和维护，而策略部件通常是与特定应用相关的，需要随着应用的变化而变化。 如果不能将一个软件体系结构分解成策略和实现的不同部件，至少应该在一个部件内将策略和实现的功能加以分离。 7.策略和实现的分离 第四章 软件体系结构描述 4.8 软件体系结构的设计 ◇ 体系结构设计的原则 任何一个部件都应该包含两个部分，接口和实现。 接口部分定义了部件所提供的功能，并规范了功能的使用方法。该接口对部件的客户是可访问的。该类型的输出接口是由函数原型构成的。 实现部分包括了实现部件所提供功能的实际代码。实现部分还可以包含只服务于部件内部操作的另外的函数和数据结构。实现部分对部件客户来说是不可用的。 8.接口和实现的分离 第四章 软件体系结构描述 4.8 软件体系结构的设计 ◇ 体系结构设计的原则 该原理的主要目的是防止部件的客户接触到实现的细节，而只为客户提供部件的接口规范和使用方法。另外，该原理还允许独立于其他部件的应用而实现一个部件的功能。就像封装一样，接口和实现的分离也是一种用来获得信息隐藏的技术。该原理强调“一个客户只应该知道它需要知道的东西”。 接口和实现的分离也支持可变性。如果部件的接口和实现分离，那么它就更容易在系统中进行改变。这种分离避免了客户直接受到部件变化的影响。该原理使部件行为和表示的改变特别容易，尤其是那些不影响接口的改变，例如对运行性能的提高。 8.接口和实现的分离 第四章 软件体系结构描述 4.8 软件体系结构的设计 ◇ 体系结构设计方法的元模型 元模型是对各种体系结构设计模型的抽象。 元模型中有三处用到了领域知识的概念。 要区分几种特殊化的“领域”概念：问题领域知识、商业领域知识、解决方案领域知识、通用知识，等等。 第四章 软件体系结构描述 4.8 软件体系结构的设计 ◇ 体系结构设计方法的元模型 商业领域知识是指商业过程观点下的与问题有关的知识。包括商业过程方面的知识、用户调查、市场分析报告等。 解决方案领域知识是指提供领域概念的知识。这些领域概念用于解决问题，并独立于特定需求。解决方案领域知识还包括如何从这一解决方案领域生产软件系统。 通用知识是指软件工程师的一般背景和经验。 系统/产品知识是指关于一个系统、一个系统族或一个产品的知识。 问题领域知识是指客户观点下的与问题有关的知识。包括需求规格说明文档、与客户面谈、客户发布的原型等。 第四章 软件体系结构描述 4.8 软件体系结构的设计 ◇ 体系结构设计方法的元模型 第一阶段：捕捉需求。 客户：表示那些关心软件体系结构设计的系统相关人员。包括：客户、最终用户、系统开发人员、系统维护人员、销售人员等。 领域知识：表示在解决某一问题中所应用的知识的范围。 需求规格说明：表示规格说明，描述了所要开发的体系结构系统的需求。 第四章 软件体系结构描述 4.5 软件体系结构与UML ◇ 顺序图 用来反映若干个对象之间的动态协作关系，也就是随着时间的推移，对象之间是如何交互的 第四章 软件体系结构描述 4.5 软件体系结构与UML ◇ 协作图 描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系。 如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择协作图。这两种图合称为交互图。 第四章 软件体系结构描述 4.5 软件体系结构与UML ◇ 状态图 描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常，状态图是对类图的补充 第四章 软件体系结构描述 4.5 软件体系结构与UML ◇ 活动图 描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动 第四章 软件体系结构描述 4.5 软件体系结构与UML ◇ 构件图 描述代码构件的物理结构及各构件之间