软件工程串讲2016.ppt

模块独立性（Independency） 模块独立性的概念是模块化、抽象和信息隐藏概念的直接产物，模块独立性是通过开发具有单一功能和与其他模块没有过多交互作用的模块来达到的。 独立性好的模块对其它的模块依赖性小，修改时对其它模块的影响小，易于修改和扩充，因此有良好的可维护性。 模块独立性可用两个定性准则来度量：耦合性（coupling）和内聚性（cohesion）。 耦合是模块之间相对独立性的量度，而内聚则是模块功能相对强度的量度。 模块的内聚性越强，耦合性越弱，独立性越强。 4.3 体系结构设计 体系结构（architecture,又称架构）设计的任务是要识别出组成系统的子系统并建立子系统的控制和通信框架。 体系结构设计是联系需求描述与其他设计活动的桥梁。 系统的组成 系统的组成反映的是系统组织所采用的基本策略。 三种应用广泛的组成类型： 数据中心体系结构（容器模型）； 客户/服务器体系结构； 抽象机或分层体系结构。 4.3.1 数据中心体系结构（容器） 数据中心体系结构（容器模型）的基本特点： 所有共享数据放到一个中心数据库（容器）中，所有子系统都能从中存取数据； 当系统中存在大量的数据共享时，数据中心（容器）模型是最为常用的体系结构风格。 4.3.2 客户/服务器体系结构 客户/服务器模型是一个分布式系统模型，数据和加工过程在多个处理器之间分配； 这种模型的主要组成： 一组为其它子系统提供服务的单机服务器； 一组向服务器请求服务的客户机； 连接客户机与服务器的网络。 4.3.3 分层（抽象机）体系结构 这种模型把系统组织成一系列的层次（抽象机），每一层提供一组服务； 这种模型支持增量式的开发，不同层次的服务可以单独交付； 层与层之间以接口相联系，一个接口发生改变，只有毗邻的层会受到影响； 4.4 控制模型 控制模型考虑子系统之间的控制流，这是分解模型不考虑的问题。 对控制流建模有两种一般性的方法： 集中式控制 一个子系统专门负责控制，控制其他子系统的启动与停止。 基于事件的控制 不将控制信息集中在一个子系统内，每个子系统都能够接受来自系统外部的事件并作出响应。 4.5 从分析到设计的转换——鲁棒性分析 鲁棒性分析是这样一个过程，它采用鲁棒图引导我们从用例转换为支持用例实现的职责模型： 需求模型 设计模型 SRS 用例模型 域模型 鲁棒性分析 鲁棒性分析的输入： 一个用例 这个用例的用例场景 这个用例的活动图（如果可以用到） 域模型（domain model） 鲁棒性分析的输出： 通过一个UML序列图和一些设计组件：边界、服务、实体组件，得出用鲁棒图表示的设计模型。 鲁棒性分析建立设计模型的过程 1.选择一个适当的用例。 2.把一个参与者放到协作图里面。 3.分析这个用例（活动图）。 对于用例的每一个动作： a.确定并增加边界组件 b.确定并增加服务组件 c.确定并增加实体组件 d.画出这些组件间的关联 e.把每个组件都贴上用来满足用例交互的动作标签 4. 把协作图转换成序列图（可选） 4.6 用户界面设计过程 4.7 界面设计的一般原则 用户熟悉； 一致性； 意外最小化； 可恢复性； 用户差异性 4.8错误消息 错误消息的设计对界面设计的成败是非常关键的。 设计很差的错误消息会导致用户对整个系统反感。 错误消息应该是礼貌的、简明的、一致的和建设性的。 4.9 帮助系统设计 软件帮助系统不能是用户手册的简单复制，应该有一个合理的组织与结构，应该为用户提供不同的入口。 第五讲 软件实现与验证 5.1 程序设计与调试 程序设计的任务是把设计转换成程序以及在程序中去除错误，包括编程与调试两个过程。 通常，程序员要对自己开发的程序进行测试，这时程序中的一些明显的错误会暴露出来并被根除，这个过程叫调试。 验证:  “Are we building the product right？”. 检查软件是否符合它的规格描述。 有效性确认: “Are we building the right product？”. 检查软件是否满足客户的期待。 5.2 验证和有效性确认（ Verification Validation） 软件审查 通过对系统的各种静态成果，如需求文档、设计文档、源代码，进行检查和分析发现问题。 May be supplement by tool-based document and code analysis 软件测试 通过使用测试数据执行系统，检查运行结果来发现问题。 The system is executed with test data and its operational behaviour is obser