页数：43页文件大小：4.27 MB来源： 软件工程ppt课件
本课件讲解面向对象设计的子系统划分与设计，先说明子系统之间的客户供应商与平等伙伴交互方式、层次组织与块状组织方案及拓扑结构，随后依次展开问题域、人机交互、任务管理与数据管理四类子系统的设计内容，并给出ATM系统的设计示例。
10.3.2类构件模块独立性强。具有单一、完整的功能，且经过反复测试被确认是正确的。具有高度可塑性。可重用的软构件必须具有高度可裁剪性，也就是说，必须提供为适应特定需求而扩充或修改已有构件的机制，而且所提供的机制必须使用起来非常简单方便。接口清晰、简明、可靠。软构件应该提供清晰、简明、可靠的对外接口，而且还应该有详尽的文档说明，以方便用户使用。
10.3.2类构件类构件的重用方式实例重构继承重构多态重构
实例重构
继承重构当已有的类构件
多态重构利用
多态性不仅可以使对象的对外接口更加一般化(基类与派生类的许多对外接口是相同的)，从而降低了消息连接的复杂程度，而且还提供了一种简便可靠的软构件组合机制。系统运行时，根据接收消息的对象类型，由多态性机制启动正确的方法，去响应一个一般化的消息，从而简化了消息界面和软构件连接过程。
软件重用的效益整体
本页正文以课件图示为主，源文件仅提取到上述文字说明，具体图形内容请对照原课件图片。
质量随着每一次重用
生产率
的全过程时，创建计划、模型、文档、代码和数据所需花费的时间将减少，从而将用较少的投入给客户提供相同级别的产品，因此，生产率得到了提高。
由于应用领域、问题复杂程度、项目组的结构和大小、项目期限、可应用的技术等许多因素都对项目组的生产率有影响，因此，不同开发组织对软件重用带来生产率提高的数字的报告并不相同，但基本上30%~50%的重用大约可以导致生产率提高25%~40%。
成本软件重用带来的净
本节内容提纲
系统分解
本页正文以课件图示为主，源文件仅提取到上述文字说明，具体图形内容请对照原课件图片。
子系统之间的交互方式客户
-供应商关系作为“客户”的子系统调用作为“供应商”的子系统，后者完成某些服务工作并返回结果。使用这种交互方案，作为客户的子系统必须了解作为供应商的子系统的接口，然而后者却无须了解前者的接口，因为任何交互行为都是由前者驱动的。平等伙伴关系每个子系统都可能调用其他子系统，因此，每个子系统都必须了解其他子系统的接口。
组织系统的方案层次
组织系统的方案利用层次
和块的各种可能的组合，可以成功地由多个子系统组成一个完整的软件系统。当混合使用层次结构和块状结构时，同一层次可以由若干块组成，而同一块也可以分为若干层。
设计系统的拓扑结构
由子系统组成完整的系统时，典型的拓扑结构有管道形、树形、星形等。设计者应该采用与问题结构相适应的、尽可能简单的拓扑结构，以减少子系统之间的交互数量。
本节内容提纲
设计问题域子系统
面向对象分析所得出的问题域精确模型，为设计问题域子系统奠定了良好的基础，建立了完整的框架。只要可能，就应该保持面向对象分析所建立的问题域结构。通常，面向对象设计仅需从实现角度对问题域模型做一些补充或修改，主要是增添、合并或分解类与对象、属性及服务，调整继承关系等等。当问题域子系统过分复杂庞大时，应该把它进一步分解成若干个更小的子系统。
设计问题域子系统
在面向对象设计过程中，可能对面向对象分析所得出的问题域模型做的补充或修改。增添一般化类以建立协议调整继承层次把问题域类组合在一起重用已有的类调整需求。
调整需求有两种情况
重用已有的类
如果有可能重用已有的类，典型过程如下：选择有可能被重用的已有类，标出这些候选类中对本问题无用的属性和服务，尽量重用那些能使无用的属性和服务降到最低程度的类。在被重用的已有类和问题域类之间添加泛化关系(即从被重用的已有类派生出问题域类)。标出问题域类中从已有类继承来的属性和服务，现在已经无须在问题域类内定义它们了。
修改与问题域类相关的关联，必要时改为与被重用的已有类相关的关联。
增添一般化类以建立协议
在设计过程中常常发现，一些具体类需要有一个公共的协议，也就是说，它们都需要定义一组类似的服务。在这种情况下可以引入一个附加类(例如，根类)，以便建立这个协议(即命名公共服务集合，这些服务在具体类中仔细定义)。
调整继承关系
如果面向对象分析模型中包含了多重继承关系，然而所使用的程序设计语言却并不提供多重继承机制，则必须修改面向对象分析的结果。即使使用支持多重继承的语言，有时也会出于实现考虑而对面向对象分析结果作一些调整。
调整继承关系使用多重
继承机制时，应该避免出现属性及服务的命名冲突。多重继承结构转换成单继承结构，在多重继承结构中的某些继承关系，经简化后将不再存在，这表明需要在各个具体类中重复定义某些属性和服务。
例子由于在面向对象分析过程中已经对ATM系统做了相当仔细的分析，而且假设所使用的实现环境能完全支持面向对象分析模型的实现，因此，在面向对象设计阶段无须对已有的问题域模型作实质性的修改或扩充。
本节内容提纲
设计人机交互子系统
从面向对象设计的角度补充关于设计人机交互子系统的策略。分类用户描述用户设计命令层次设计人机交互类。
分类用户设计者应该认真
研究使用它的用户。应该深入到用户的工作现场，仔细观察用户是怎样做他们的工作的。通常从下列几个不同角度进行分类：按技能水平分类(新手、初级、中级、高级)按职务分类(总经理、经理、职员)按所属集团分类(职员、顾客)。
描述用户应该仔细了解将来
设计命令层次
设计命令层次的工作通常包含以下几项内容。研究现有的人机交互含义和准则设计图形用户界面时，应该保持与普通Windows应用程序界面相一致，并遵守广大用户习惯的约定，这样才会被用户接受和喜爱。确定初始的命令层次所谓命令层次，实质上是用过程抽象机制组织起来的、可供选用的服务的表示形式。
设计命令层次时，通常先从对服务的过程抽象着手，然后再进一步修改它们，以适合具体应用环境的需要。
设计命令层次精化
设计人机交互类
人机交互类与所使用的操作系统及编程语言密切相关。例如，在Windows环境下运行的VisualC++语言提供了MFC类库，设计人机交互类时，往往仅需从MFC类库中选出一些适用的类，然后从这些类派生出符合自己需要的类就可以了。
本节内容提纲
设计任务管理子系统
设计任务管理子系统
设计任务管理子系统，包括确定各类任务并把任务分配给适当的硬件或软件去执行。常见的任务包括：事件驱动型任务时钟驱动型任务优先任务关键任务协调任务。
事件驱动型任务
事件通常是表明某些数据到达的信号。这类任务可能主要完成通信工作。例如，与设备、屏幕窗口、其他任务、子系统、另一个处理器或其他系统通信。工作过程：任务处于睡眠状态(不消耗处理器时间)，等待来自数据线或其他数据源的中断。一旦接收到中断就唤醒了该任务，接收数据并把数据放入内存缓冲区或其他目的地，通知需要知道这件事的对象，然后该任务又回到睡眠状态。
时钟驱动型任务
优先任务
优先任务可以满足高优先级或低优先级的处理需求：高优先级：某些服务具有很高的优先级，为了在严格限定的时间内完成这种服务，可能需要把这类服务分离成独立的任务。低优先级：与高优先级相反，有些服务是低优先级的，属于低优先级处理(通常指那些背景处理)。设计时可能用额外的任务把这样的处理分离出来。
关键任务
协调任务当系统中存在3个以上
该增加一个任务，用它作为协调任务。引入协调任务会增加系统的总开销(增加从一个任务到另一个任务的转换时间)，但是引入协调任务有助于把不同任务之间的协调控制封装起来。使用状态转换矩阵可以比较方便地描述该任务的行为。这类任务应该仅做协调工作，不要让它再承担其他服务工作。
本节内容提纲
设计数据管理子系统
下载地址：{{downurl}}
{{{a}}}
{{#b}}{{{b}}}
{{/b}} {{/title}} {{#nolog}}登陆注册
{{/nolog}} {{#djsx}}点我刷新
{{/djsx}} {{#gocz}} {{/gocz}} {{#ffqr}} {{/ffqr}}