面向对象设计学习总结

面向对象设计

  • 概述
  • 分析阶段
    • 活动图、用例图、领域模型
    • 活动图
    • 用例图
    • 领域模型
      • 概述
      • 组成
      • 寻找概念类
      • 添加关联
  • 设计阶段
    • SSD(系统顺序图)
    • 软件类图
    • 设计类图
  • 实现阶段
    • 单元测试
    • 重构
  • 总结

概述

软件设计是软件工程中技术方向部分,软件工程大方向上划分,包含管理方向和软件设计方向。管理方向,主要指软件迭代、资源管理等项目进度、宏观质量把控方面,涉及理论知识,书籍,如《敏捷迭代开发:管理者指南》、《敏捷软件开发的组织模式》、《软件项目管理:一个统一的框架》、《OO项目求生法则》。

该总结主要总结软件涉及部分。软件合理设计是项目成功的核心,合理的设计使软件具备灵魂,项目才预示着成功。该部分包含:需求分析、领域建模、软件架构、详细设计、单元测试、代码重构。按照现在经过行业验证和总结出来的结论:该过程不是瀑布式的,整体是一个迭代过程,不同的迭代阶段,偏重点不同,整体偏重点逐渐后移。如图1:
面向对象设计学习总结_第1张图片
该总结主要来自《UML和模式应用》、《设计模式》两本书,前一本主要介绍了UP敏捷开发思想,其中GRASP(职责驱动设计)尤为可贵。基于面向对象设计6原则和GRASP,设计模式做了完美的补充,前面的是思想,后面的是具体方案,方案详细的诠释思想。
面向对象思想包含:面向对象分析、面向对象设计、面向对象编程。不同阶段涉及知识如下表:

设计阶段 指导思想
需求分析、领域建模 用例分析、领域建模、活动图
软件架构、详细设计 SSD、设计6原则、GRASP、设计模式
编码 设计6原则、GRASP、设计模式、重构、单元测试

制品及模型演变过程,如图2:
面向对象设计学习总结_第2张图片《UML和模式应用》按照软件开发周期迭代表达了UP敏捷开发的思想,对于软件单个阶段的制品迭代来讲,知识是碎片化的,该总结着重随着开发迭代集中复述制品的迭代方法和过程。

分析阶段

活动图、用例图、领域模型

分析阶段核心是发现业务用例、领域概念,并合理构建领域概念间关系(即领域模型)。在一些软件设计方法中,认为熟悉的领域,可以使用用例驱动设计,经过深入学习和体会,个人认为领域模型至关重要,从最新的设计思想–领域驱动设计,也体现了领域建模有着很高的价值。

对于一个陌生领域,核心场景入手,画活动图,发现需要核心业务用例,用例在用例图中体现;画活动图同时,可以深入了解领域中专业的领域概念,活动图结束后,可以输出用例图和领域概念,深入分析活动图体现的场景,构建合理的领域模型。对于一个陌生领域,很少能一次获取所有用例和构建玩领域模型,这个随着软件迭代及系统顺序图(SSD)等深入分析,循环迭代式完善用例及领域模型,迭代方式如下图:
面向对象设计学习总结_第3张图片
前期活动图输出用例图及粗略的领域模型,用例图体现领域边界并在领域模型中适当表达,如一些系统的参与者等;随着用例的完善,使用用例规约,合理构建领域概念间关联关系。

活动图

有助于工作流和业务过程可视化。因为用例覆盖过程和工作流分析,所以活动图能够成为编写用例文本的有用的辅助措施,对于那些描述复杂的工作流的业务用例来说更是如此,因为其中涉及大量参与者和并发活动。

画活动图过程中,会发现领域概念和熟悉领域业务流程。有助于用例、领域模型的构建。认识领域过程,首先有主流程活动图,然后根据场景梳理其他活动图。

用例图

参与者:某些具有行为的事物,可以是人、计算机系统或组织。
场景:参与者与系统之间的一系列特定情节或用例的一条执行路劲。
用例:就是一组相关成功和失败的场景集合,用来描述参与者如何使用系统来实现其目标。

用例就是需求,主要是说明系统如何工作的功能性或行为性需求。按照“FURPS+”需求类型,用例强调了“F”(功能性和行为性)。编写用例准则如下:

  1. 编写简介用例
  2. 编写黑盒用例
  3. 采用参与者和参与者目标的视点(目标和典型情况,行为结果价值)
  4. 发现用例(明确参与者(即边界)、主要参与者和其目标)
  5. 用例名称用动词开头
  6. 有用用例测试(老板测试、EBP测试、规模测试)。

用例图体现系统边界及主要系统功能,方便开发迭代纪录,从主要用例场景迭代逐渐完善系统和丰富用例。系统边界体现在系统有哪些使用者。软件迭代过程,初始确定大部分用例名称,详细分析确定架构和有风险用例。在以后的迭代中,每次以10%重要用例分析迭代。

指导用例编写书籍有《编写有效用例》(Writing Effective Use Case)、有效用例模式(Patterns for Effective Use Case)、《用例建模》(Use Case Modeling)、《需求协同:定义需求的讨论会》、《用例:通过背景环境获取需求》。

领域模型

概述

领域建模过程非瀑布式,建立整个系统的完整模型。确定系统主要场景,按照用例场景分析,系统按照用例量迭代,领域模型也随着用例迭代,领域模型可以是草图,个人认为领域模型比较重要,建议保存,大型系统的模型迭代过程最好保存。

建立领域概念间的关联,是领域模型的关键,随着关联关系梳理清楚,即时一个陌生领域也会逐渐清晰。这也是领域建模的价值体现。

参考书籍:《面向对象方法:基础知识》(详细介绍概念领域建模)、《分析模式》(提供有价值的模式)、《数据模型模式》

组成

类名:概念类类名
属性:必要属性的非必须的

寻找概念类

  1. 重用、修改现有的模型。参考《分析模式》
  2. 使用分类列表
  3. 用例规约中确定名词短语

添加关联

建立领域概念间的关联,是领域模型的关键,随着关联关系梳理清楚,即时一个陌生领域也会逐渐清晰。这也是领域建模的价值体现。

设计阶段

该阶段使用设计思想和方法,把领域模型转化为设计模型,指导开发编码。此阶段核心关注:低耦合、高内聚、可扩展。主要指导思想和方法为:GRASP职责驱动设计、软件设计6原则和设计模式。除了这些,还有很多原则,很多实际上是场景特化或者相同思想不同称呼,不必开始就完全掌握,随着深入学习,逐渐了解掌握;设计模式实际是对思想的应用,也是对经常出现的场景的总结,掌握设计模式,可以快速有限的提高软件质量和编程质量,核心还是思想。

从分析模型转为设计模型,设计模型演化过程如下(图3):
面向对象设计学习总结_第4张图片

SSD(系统顺序图)

描述外部参与者如何与创建的系统机型交互。确定是系统事件。在领域模型基础上,利用SSD,从需求分析转向软件设计。确定系统事件后,使用GRASP职责驱动设计思想,领域模型转为软件类图(领域层)。

软件类图

也即规格说明(软件)透视图,表示方法同领域模型的类图。用来描述软件的抽象物或具有规格说明接口的构件,但是并不约束特定实现。

设计类图

结合设计模式、软件设计6原则,优化软件类图为设计类图。复杂用例,可以结合顺序图或通信图及其他动态图,如状态图等完善优化类图。在编写详细设计文档中,顺序图等动态图也很重要,类图是结果,动态图是分析过程,有助于回顾或参考梳理思路。

实现阶段

按照迭代计划,完成迭代设计代码。实现过程中严格参考编程规范,减少IDE检测代码后的重构工作。代码检测工具,如专业的工具SourceMonitor,及IDE集成的检测工具,如Android Studio中的代码质量检测功能。代码实现过程中,根据实际情况,可能还会抽象出一些工具类等,按照设计思想和方法设计即可。

单元测试

为确保编码效率和质量,核心功能建议做好单元测试,有些人认为测试就是测bug的,没必要做单元测试。我不认为,从一个点时间看,做单元测试不能提高开发效率,但是从整个软件生命周期看,做好单元测试,不仅降低核心功能设计风险,而且提高软件开发效率和质量。单元测试的框架也有很多,也足以说明单元测试的重要性,JUnit、Android自身提供的方法等。

重构

重构主要是通过重构工具检测不良代码实现,确保完成高质量代码,也是一个培养良好习惯的过程。好的代码也可以在一定程度提高软件质量、维护效率等。代码检测基本是一个自动化过程,因此不需要太为检测闹心,只需要搭建好的检测环境和使用正确的工具,重构过程网上也有很多指导方法,工具检测结果也会给出指导性说明。

好的设计也需要高质量的代码,设计是骨,代码是血肉,任何一个不好,都不会有个健壮的软件。

总结

面向对象设计是一个不断实践,持久学习的过程。经过对UML、《UML和模式应用》的学习,了解了软件设计的流水线,对于一个新的项目,不至于摸着石头过河,在开发中有了指向和原则。生命不息,学习不止,再接再厉。

文章中有不合理地方,欢迎指出。

你可能感兴趣的:(软件架构与设计)