概述
软件设计是软件工程中技术方向部分，软件工程大方向上划分，包含管理方向和软件设计方向。管理方向，主要指软件迭代、资源管理等项目进度、宏观质量把控方面，涉及理论知识，书籍，如《敏捷迭代开发：管理者指南》、《敏捷软件开发的组织模式》、《软件项目管理：一个统一的框架》、《OO项目求生法则》。
该总结主要总结软件涉及部分。软件合理设计是项目成功的核心，合理的设计使软件具备灵魂，项目才预示着成功。该部分包含：需求分析、领域建模、软件架构、详细设计、单元测试、代码重构。按照现在经过行业验证和总结出来的结论：该过程不是瀑布式的，整体是一个迭代过程，不同的迭代阶段，偏重点不同，整体偏重点逐渐后移。如图1：
该总结主要来自《UML和模式应用》、《设计模式》两本书，前一本主要介绍了UP敏捷开发思想，其中GRASP（职责驱动设计）尤为可贵。基于面向对象设计6原则和GRASP，设计模式做了完美的补充，前面的是思想，后面的是具体方案，方案详细的诠释思想。
面向对象思想包含：面向对象分析、面向对象设计、面向对象编程。不同阶段涉及知识如下表：
| 设计阶段 | 指导思想 |
|---|---|
| 需求分析、领域建模 | 用例分析、领域建模、活动图 |
| 软件架构、详细设计 | SSD、设计6原则、GRASP、设计模式 |
| 编码 | 设计6原则、GRASP、设计模式、重构、单元测试 |
制品及模型演变过程，如图2：
《UML和模式应用》按照软件开发周期迭代表达了UP敏捷开发的思想，对于软件单个阶段的制品迭代来讲，知识是碎片化的，该总结着重随着开发迭代集中复述制品的迭代方法和过程。
分析阶段
活动图、用例图、领域模型
分析阶段核心是发现业务用例、领域概念，并合理构建领域概念间关系（即领域模型）。在一些软件设计方法中，认为熟悉的领域，可以使用用例驱动设计，经过深入学习和体会，个人认为领域模型至关重要，从最新的设计思想–领域驱动设计，也体现了领域建模有着很高的价值。
对于一个陌生领域，核心场景入手，画活动图，发现需要核心业务用例，用例在用例图中体现；画活动图同时，可以深入了解领域中专业的领域概念，活动图结束后，可以输出用例图和领域概念，深入分析活动图体现的场景，构建合理的领域模型。对于一个陌生领域，很少能一次获取所有用例和构建玩领域模型，这个随着软件迭代及系统顺序图（SSD）等深入分析，循环迭代式完善用例及领域模型，迭代方式如下图：
前期活动图输出用例图及粗略的领域模型，用例图体现领域边界并在领域模型中适当表达，如一些系统的参与者等；随着用例的完善，使用用例规约，合理构建领域概念间关联关系。
活动图
有助于工作流和业务过程可视化。因为用例覆盖过程和工作流分析，所以活动图能够成为编写用例文本的有用的辅助措施，对于那些描述复杂的工作流的业务用例来说更是如此，因为其中涉及大量参与者和并发活动。
画活动图过程中，会发现领域概念和熟悉领域业务流程。有助于用例、领域模型的构建。认识领域过程，首先有主流程活动图，然后根据场景梳理其他活动图。
用例图
参与者：某些具有行为的事物，可以是人、计算机系统或组织。
场景：参与者与系统之间的一系列特定情节或用例的一条执行路劲。
用例：就是一组相关成功和失败的场景集合，用来描述参与者如何使用系统来实现其目标。
用例就是需求，主要是说明系统如何工作的功能性或行为性需求。按照“FURPS+”需求类型，用例强调了“F”（功能性和行为性）。编写用例准则如下：
- 编写简介用例
- 编写黑盒用例
- 采用参与者和参与者目标的视点（目标和典型情况，行为结果价值）
- 发现用例（明确参与者（即边界）、主要参与者和其目标）
- 用例名称用动词开头
- 有用用例测试（老板测试、EBP测试、规模测试）。
用例图体现系统边界及主要系统功能，方便开发迭代纪录，从主要用例场景迭代逐渐完善系统和丰富用例。系统边界体现在系统有哪些使用者。软件迭代过程，初始确定大部分用例名称，详细分析确定架构和有风险用例。在以后的迭代中，每次以10%重要用例分析迭代。
指导用例编写书籍有《编写有效用例》（Writing Effective Use Case)、有效用例模式（Patterns for Effective Use Case)、《用例建模》（Use Case Modeling）、《需求协同：定义需求的讨论会》、《用例：通过背景环境获取需求》。
领域模型
领域建模过程非瀑布式，建立整合系统的完整模型。确定系统主要场景，按照用例场景分析，系统按照用例量迭代，领域模型也随着用例迭代，领域模型可以是草图，个人认为领域模型比较重要，建议保存，大型系统的模型迭代过程最好保存。
建立领域概念间的关联，是领域模型的关键，随着关联关系梳理清楚，即时一个陌生领域也会逐渐清晰。这也是领域建模的价值体现。
领域建模过程也非瀑布式，建立整合系统的完整模型。确定系统主要场景，按照用例场景分析，系统按照用例量迭代，领域模型也随着用例迭代，领域模型可以是草图，个人认为领域模型比较重要，建议保存，大型系统的模型迭代过程最好保存。
参考书籍：《面向对象方法：基础知识》（详细介绍概念领域建模）、《分析模式》（提供有价值的模式）、《数据模型模式》
寻找概念类
- 重用、修改现有的模型。参考《分析模式》
- 使用分类列表
- 用例规约中确定名词短语
添加关联
建立领域概念间的关联，是领域模型的关键，随着关联关系梳理清楚，即时一个陌生领域也会逐渐清晰。这也是领域建模的价值体现。
设计阶段
该阶段使用设计思想和方法，把领域模型转化为设计模型，指导开发编码。此阶段核心关注：低耦合、高内聚、可扩展。主要指导思想和方法为：GRASP职责驱动设计、软件设计6原则和设计模式。除了这些，还有很多原则，很多实际上是场景特化或者相同思想不同称呼，不必开始就完全掌握，随着深入学习，逐渐了解掌握；设计模式实际是对思想的应用，也是对经常出现的场景的总结，掌握设计模式，可以快速有限的提高软件质量和编程质量，核心还是思想。
从分析模型转为设计模型，设计模型演化过程如下（图3）：
SSD（系统顺序图）
描述外部参与者如何与创建的系统机型交互。确定是系统事件。在领域模型基础上，利用SSD，从需求分析转向软件设计。确定系统事件后，使用GRASP职责驱动设计思想，领域模型转为软件类图（领域层）。
软件类图
设计类图
结合设计模式、软件设计6原则，优化软件类图为设计类图。复杂用例，可以结合顺序图或通信图及其他动态图，如状态图等完善优化类图。在编写详细设计文档中，顺序图等动态图也很重要，类图是结果，动态图是分析过程，有助于回顾或参考梳理思路。
实现阶段
按照迭代计划，完成迭代设计代码。实现过程中严格参考编程规范，减少IDE检测代码后的重构工作。代码检测工具，如专业的工具SourceMonitor，及IDE集成的检测工具，如Android Studio中的代码质量检测功能。代码实现过程中，根据实际情况，可能还会抽象出一些工具类等，按照设计思想和方法设计即可。
单元测试
为确保编码效率和质量，核心功能建议做好单元测试，有些人认为测试就是测bug的，没必要做单元测试。我不认为，从一个点时间看，做单元测试不能提高开发效率，但是从整个软件生命周期看，做好单元测试，不仅降低核心功能设计风险，而且提高软件开发效率和质量。单元测试的框架也有很多，也足以说明单元测试的重要性，JUnit、Android自身提供的方法等。
重构
重构主要是通过重构工具检测不良代码实现，确保完成高质量代码，也是一个培养良好习惯的过程。好的代码也可以在一定程度提高软件质量、维护效率等。代码检测基本是一个自动化过程，因此不需要太为检测闹心，只需要搭建好的检测环境和使用正确的工具，重构过程网上也有很多指导方法，工具检测结果也会给出指导性说明。
好的设计也需要高质量的代码，设计是骨，代码是血肉，任何一个不好，都不会有个健壮的软件。
总结
面向对象设计是一个不断实践，持久学习的过程。经过对UML、《UML和模式应用》的学习，了解了软件设计的流水线，对于一个新的项目，不至于摸着石头过河，在开发中有了指向和原则。生命不息，学习不止，再接再厉。
文章中有不合理地方，欢迎指出。