对于数字仪表板的例子-火龙果软件.PPT

模型-视图-控制器框架 许多交互和界面系统构成的基础 实现了数据层与表示层的分离 MFC基础类 作为一种开发模型用于分布式应用系统的设计与分析中。 模型部件 处理问题逻辑在独立于外在显示内容和形式情况下的内在抽象，封装了问题的核心数据、逻辑、功能的计算关系，独立于界面表示和I/O操作 视图部件 把模型数据、逻辑关系、状态信息、特定形式展示给用户，从模型获得信息，对相同的信息可以有多个不同的显示形式或视图 控制器部件 处理用户与软件的交互 确保界面与模型的对应关系 使模型、视图 协调工作 MVC的实现 类设计的方针 模块化 抽象 信息隐蔽 低耦合 高内聚 可重用 消息限制 实例——计数器 实例——计数器 面向对象设计的过程 （1）首先进行系统架构设计，使系统具有良好的稳定性、开放性和可扩充性 （2）如果系统复杂，应将系统划分为若干个子系统 （3）给系统分配处理机和任务 （4）根据数据结构、文件和数据库选择实现数据存储的基本策略 （5）标识全局资源和确定控制访问这些资源的机制 （6）选择实现软件控制方法 （7）考虑边界条件 （8）建立折衷的优先权 系统设计 逻辑体系架构设计 层次模式分析 （1）分层模式 表示层：图形用户界面、窗口等。 应用逻辑层：管理业务过程的任务和规则。 对象存储层：持久化存储机制，例如，文件系统、数据库等。 设计要求 层与层之间的耦合应尽可能地松散； 级别相同、职责类似的元素应该被组织到同一层中； 复杂的模块应被继续分解为粒度更细的层或子系统； ?应尽量将可能发生变化的元素封装到一层中； 每一层应当只调用下一层提供的功能服务，而不能跨层调用； 一层绝不能使用上一层提供的功能服务，即不能在层与层之间造成双向依赖。 （3）避免循环依赖 子系统划分 设计准则： 子系统应具有良好的接口，通过接口和系统的其他部分通信； 除了少数的“通信类”外，子系统中的类应只和该子系统中的其他类协作； 子系统的数量不宜太多； 可以在子系统内部再次划分，以降低复杂度。 事务分析过程 ① 识别事务源利用数据流图和数据词典，从问题定义和需求分析的结果中，找出各种需要处理的事务。通常，事务来自物理输入装置。有时，设计人员还必须区别系统的输入、中心加工和输出中产生的事务。 ② 规定适当的事务型结构在确定了该数据流图具有事务型特征之后，根据模块划分理论，建立适当的事务型结构。 ③ 识别各种事务和它们定义的操作。从问题定义和需求分析中找出的事务及其操作所必需的全部信息，对于系统内部产生的事务，必须仔细地定义它们的操作。 ④ 注意利用公用模块在事务分析的过程中，如果不同事务的一些中间模块可由具有类似的语法和语义的若干个低层模块组成，则可以把这些低层模块构造成公用模块。 ⑤ 对每一事务，或对联系密切的一组事务，建立一个事务处理模块；如果发现在系统中有类似的事务，可以把它们组成一个事务处理模块。 ⑥ 对事务处理模块规定它们全部的下层操作模块 ⑦ 对操作模块规定它们的全部细节模块变换分析是软件系统结构设计的主要方法。一般，一个大型的软件系统是变换型结构和事务型结构的混合结构。所以，我们通常利用以变换分析为主，事务分析为辅的方式进行软件结构设计。 设计过程 图 说明了使用面向数据流方法逐步设计的过程。 图 面向数据流方法的设计过程 假设的仪表板将完成下述功能： ● 通过模-数转换实现传感器和微处理机接口； ● 在发光二极管面板上显示数据； ● 指示每小时英里数（mile／h），行驶的里程，每加仑油行驶的英里数（mile／Gal）等等； ● 指示加速或减速； ● 超速警告：如果车速超过55mile／h，则发出超速警告铃声。 在软件需求分析阶段应该对上述每条要求以及系统的其他特点进行全面的分析评价，建立起必要的文档资料，特别是数据流图。 实例分析 设计步骤 第1步 复查基本系统模型。 复查的目的是确保系统的输入数据和输出数据符合实际。 第2步 复查并精化数据流图。  数字仪表板系统的数据流图 假设在需求分析阶段产生的数字仪表板系统的数据流图如图所示。 这个数据流图对于软件结构设计的“第一次分割”而言已经足够详细了，因此不需要精化就可以进行下一个设计步骤。 第3步 分析确定数据流的类型。 一般地说，一个系统中的所有信息流都可以认为是变换流，但是，当遇到有明显事务特性的信息流时，建议采用事务分析方法进行设计。在这一步设计人员应该根据数据流图中占优势的属性，确定数据流的全局特性。此外还应该把具有和全局特性不同的特点的局部区域孤立出来，以后可以按照这些子数据流的特点精化根据全局特性得出的软件结构。