📜  OOAD-面向对象设计

📅  最后修改于: 2020-12-14 04:12:33             🧑  作者: Mango


在分析阶段之后,使用面向对象设计(OOD)将概念模型进一步开发为面向对象模型。在OOD中,将分析模型中与技术无关的概念映射到实现类上,确定约束并设计接口,从而形成解决方案领域的模型。简而言之,构建了详细的说明,指定如何在具体技术上构建系统

面向对象设计的阶段可以标识为-

  • 系统上下文的定义
  • 设计系统架构
  • 识别系统中的对象
  • 设计模型的构建
  • 对象接口规范

系统设计

面向对象的系统设计涉及定义系统的上下文,然后设计系统的体系结构。

  • 上下文-系统的上下文具有静态和动态部分。使用整个系统的简单框图设计系统的静态上下文,该框图被扩展为子系统的层次结构。子系统模型由UML包表示。动态上下文描述了系统如何与其环境交互。使用用例图对其进行建模。

  • 系统架构-系统架构是根据系统上下文根据架构设计和领域知识设计的。通常,将系统划分为几层,然后分解每一层以形成子系统。

面向对象的分解

分解意味着按照分而治之的原则,将一个大型的复杂系统划分为具有较小复杂性的较小组件的层次结构。系统的每个主要组成部分都称为子系统。面向对象的分解可识别系统中的各个自治对象以及这些对象之间的通信。

分解的优点是-

  • 各个组件的复杂度较低,因此更易于理解和管理。

  • 它可以使具有专业技能的劳动力分工。

  • 它允许替换或修改子系统,而不会影响其他子系统。

识别并发

并发允许多个对象同时接收事件,并同时执行多个活动。并发在动态模型中标识并表示。

为了启用并发,每个并发元素都分配有单独的控制线程。如果并发处于对象级别,则为两个并发对象分配两个不同的控制线程。如果单个对象的两个操作本质上是并发的,则该对象将在不同的线程之间拆分。

并发与数据完整性,死锁和饥饿问题相关。因此,无论何时需要并发,都需要制定明确的策略。此外,并发需要在设计阶段本身进行识别,并且不能留给实施阶段。

识别模式

在设计应用程序时,针对某些类型的问题采用了一些公认的解决方案。这些是设计模式。模式可以定义为可以在某些类型的应用程序开发问题中使用的文档化的构建基集。

一些常用的设计模式是-

  • 外墙图案
  • 模型视图分离模式
  • 观察者模式
  • 模型视图控制器模式
  • 发布订阅模式
  • 代理模式

控制事件

在系统设计期间,需要识别并适当处理可能发生在系统对象中的事件。

事件是具有时间和空间位置的重大事件的说明。

可以建模的事件有四种类型,即-

  • 信号事件-被一个对象抛出并被另一个对象捕获的命名对象。

  • 呼叫事件-表示操作调度的同步事件。

  • 时间事件-代表时间流逝的事件。

  • 更改事件-表示状态更改的事件

处理边界条件

系统设计阶段需要解决整个系统以及每个子系统的初始化和终止问题。记录的不同方面如下-

  • 系统的启动,即系统从非初始化状态到稳态的过渡。

  • 系统的终止,即关闭所有正在运行的线程,清理资源以及要发送的消息。

  • 系统的初始配置以及需要时的系统重新配置。

  • 预见的故障或系统意外终止。

边界条件是使用边界用例建模的。

对象设计

开发子系统的层次结构之后,将识别系统中的对象并设计其详细信息。在这里,设计人员详细介绍了系统设计期间选择的策略。重点从应用程序域概念转变为计算机概念。蚀刻掉在分析过程中识别出的对象以实现,目的是最小化执行时间,内存消耗和总成本。

对象设计包括以下阶段-

  • 对象识别
  • 对象表示,即设计模型的构建
  • 作业分类
  • 算法设计
  • 关系设计
  • 实现外部交互的控制
  • 将类和关联打包到模块中

对象识别

对象设计的第一步是对象识别。在面向对象的分析阶段中确定的对象被分组为类并进行了精炼,以使其适合于实际实施。

这个阶段的功能是-

  • 识别和完善每个子系统或程序包中的类

  • 定义类之间的链接和关联

  • 设计类之间的层次结构关联,即泛化/专业化和继承

  • 设计聚合

对象表示

一旦确定了类别,就需要使用对象建模技术来表示它们。这个阶段主要涉及构造UML图。

有两种类型的设计模型需要产生-

  • 静态模型-使用类图和对象图描述系统的静态结构。

  • 动态模型-描述系统的动态结构,并使用交互图和状态图显示类之间的交互。

业务分类

在此步骤中,通过将在OOA阶段开发的三个模型(即对象模型,动态模型和功能模型)组合起来,来定义要对对象执行的操作。操作指定要执行的操作,而不是应如何执行。

执行以下与操作有关的任务-

  • 绘制了系统中每个对象的状态转换图。

  • 为对象接收的事件定义了操作。

  • 确定一个事件触发相同或不同对象中的其他事件的情况。

  • 确定动作中的子操作。

  • 主要动作扩展为数据流程图。

算法设计

使用算法定义对象中的操作。算法是解决操作中存在的问题的逐步过程。算法着重于如何做到这一点。

与给定操作相对应的算法可能不止一种。一旦确定了替代算法,就针对给定的问题域选择最佳算法。选择最佳算法的指标是-

  • 计算复杂度-复杂度决定了算法在计算时间和内存需求方面的效率。

  • 灵活性-灵活性决定了所选择的算法是否可以适当地实现,而又不会在各种环境中丧失适当性。

  • 可理解性-这决定了选择的算法是否容易理解和执行。

关系设计

在对象设计阶段需要制定实现关系的策略。解决的主要关系包括关联,聚合和继承。

设计师应该对关联做以下事情-

  • 标识关联是单向还是双向。

  • 分析关联的路径,并在必要时进行更新。

  • 在多对多关系的情况下,将关联作为单独的对象来实现;或在一对一或一对多关系的情况下作为与其他对象的链接。

关于继承,设计者应执行以下操作-

  • 调整类及其关联。

  • 识别抽象类。

  • 做好准备,以便在需要时共享行为。

实施控制

对象设计者可以在状态图模型的策略中纳入改进。在系统设计中,制定了实现动态模型的基本策略。在对象设计期间,将适当地修饰该策略以进行适当的实现。

动态模型的实现方法是-

  • 将状态表示为程序中的位置-这是传统的过程驱动方法,控制位置定义程序状态。有限状态机可以实现为程序。过渡形成输入语句,主控制路径形成指令序列,分支形成条件,而后向路径形成循环或迭代。

  • 状态机引擎-这种方法通过状态机引擎类直接表示状态机。此类通过应用程序提供的一组转换和动作来执行状态机。

  • 作为并行任务进行控制-在这种方法中,将对象作为编程语言或操作系统中的任务来实现。在这里,事件被实现为任务间调用。它保留了真实对象的固有并发性。

包装类

在任何大型项目中,将实现细致地划分为模块或包都是很重要的。在对象设计期间,将类和对象分组到包中,以使多个组可以在项目上协同工作。

包装的不同方面是-

  • 从外部视图隐藏内部信息-允许将类视为“黑匣子”,并允许更改类实现,而无需该类的任何客户端修改代码。

  • 元素的一致性-如果元素(例如类,操作或模块)是按照一致的计划进行组织的,并且其所有部分都内在相关,则它们是一致的,从而可以实现一个共同的目标。

  • 物理模块的构建-以下准则在构建物理模块时有帮助-

    • 模块中的类应表示同一复合对象中的相似事物或组件。

    • 紧密连接的类应位于同一模块中。

    • 未连接或连接较弱的类应放在单独的模块中。

    • 模块应具有良好的凝聚力,即其组件之间的高度协作。

    • 一个模块与其他模块的耦合度应低,即模块之间的交互或相互依赖性应最小。

设计优化

分析模型捕获有关系统的逻辑信息,而设计模型添加详细信息以支持有效的信息访问。在实施设计之前,应先对其进行优化,以使实施效率更高。优化的目的是使时间,空间和其他指标方面的成本最小化。

但是,设计优化不应过多,因为易于实现,可维护性和可扩展性也是重要的考虑因素。人们经常看到,完美优化的设计更有效,但可读性和重用性却较低。因此,设计师必须在两者之间取得平衡。

设计优化可以做的各种事情是-

  • 添加冗余关联
  • 忽略不可用的关联
  • 算法优化
  • 保存派生的属性以避免重新计算复杂的表达式

冗余协会的增加

在设计优化过程中,将检查派生新关联是否可以减少访问成本。尽管这些冗余关联可能不会添加任何信息,但它们可能会提高整个模型的效率。

省略不可用的协会

关联过多会导致系统难以理解,从而降低系统的整体效率。因此,在优化过程中,将删除所有不可用的关联。

算法优化

在面向对象的系统中,数据结构和算法的优化以协作的方式完成。一旦完成班级设计,就需要优化操作和算法。

通过以下方式获得算法的优化:

  • 重新排列计算任务的顺序
  • 循环的执行顺序与功能模型中的顺序相反
  • 消除算法中的无效路径

保存和存储派生属性

派生属性是那些属性,其值被计算为其它属性(基本属性)的函数。每次需要时都需要重新计算派生属性的值,这是一个耗时的过程。为避免这种情况,可以计算值并将其以其计算形式存储。

但是,这可能会导致更新异常,即基本属性值的更改而派生属性的值没有相应的更改。为了避免这种情况,请采取以下步骤-

  • 每次更新基本属性值时,也会重新计算派生的属性。

  • 所有派生的属性将重新计算并在一个组中定期更新,而不是在每次更新后更新。

设计文件

文档是记录软件制作过程的任何软件开发过程的重要组成部分。对于任何非平凡的软件系统,都需要将其设计决策记录在案,以将设计传达给其他人。

使用领域

尽管是辅助产品,但是良好的文档是必不可少的,尤其是在以下方面:

  • 在设计由许多开发人员开发的软件时
  • 在迭代软件开发策略中
  • 在开发软件项目的后续版本时
  • 用于评估软件
  • 用于查找条件和测试区域
  • 用于软件维护。

内容

有益的文档应实质上包括以下内容-

  • 高级系统架构-流程图和模块图

  • 关键的抽象和机制-类图和对象图。

  • 场景说明主要方面的行为-行为图

特征

一个好的文档的功能是-

  • 简洁,同时,明确,一致和完整

  • 可追溯到系统的需求规格

  • 结构良好

  • 图解而非描述