软件设计包括一些列原理、概念和实践，可以指导开发高质量的系统或产品。
设计原理建立了指导设计工作的最重要原则。
技术债务是软件开发中的一个概念，它涉及与返工相关的成本，这些成本是由于现在选择“快速而粗糙的”解决方案而导致的，而不是使用会花费更多时间的更好方法。增量地构建软件产品时，不可避免地会产生技术债务。但是，优秀的开发团队必须设法通过定期重构软件来减少技术债务。
控制技术债务而不推迟编码的一种策略是利用多样化和聚合的设计实践。
- 多样化是指识别需求模型元素所建议的可能的备选设计方案的实践。
- 聚合是评估和拒绝不符合软件解决方案定义的非功能性需求所要求约束的备选设计方案的过程。
多样化和聚合融合了：
- 来自建立类似实体经验的直觉和判断力
- 一系列指导演化方式的原则和启发式方法
- 一系列评价质量的标准
- 得出最终设计表示的迭代过程
从需求模型到设计模型的转换：
- 数据设计或类设计将类模型转化为设计类的实现以及软件实现所要求的数据结构。CRC模型(Class-Responsibility-Collaboration) 中定义的对象和关系，以及类属性和其他表示法描述的详细数据内容为数据结构设计活动提供了基础。在软件架构设计中也可能会进行部分类的设计，更详细的类设计则将在设计每个软件组件时进行。
- 架构设计定义了软件的主要结构化元素之间的关系、可满足系统需求的架构风格和模式以及影响架构实现方式的约束。架构设计表示可以从需求模型导出，该设计表示基于的是计算机系统的框架。
- 接口设计描述了软件和协作系统之间、软件和使用人员之间是如何通信的。接口意味着信息流(如数据和控制)和特定的行为类型。因此，使用场景和行为模型为接口设计提供了大量的信息。
- 组件级设计将软件架构的结构化元素变换为对软件组件的过程性描述。从基于类的模型和行为模型中获得的信息是组件设计的基础。
CRC方法(Class-Responsibility-Collaboration)：
- 建立和验证领域模型的一种方法；
- 具体内容：
- 用一张小卡片来表示一个对象，每个项目组成员手持一张卡片扮演这个对象；
- 然后这些项目组成员进行头脑风暴讨论会，针对问题领域互相询问；
- 被问到需要向对方提供服务的队员在卡片上记录下一个职责；
- 直到大家认为整个问题领域中已经没有被遗漏的内容，每一个人的问题都得到解决，并且明确地知道谁将提供该服务。
在软件工程中，设计是质量形成的地方。设计提供了可以用于质量评估的软件表示，设计是将利益相关者的需求准确地转化为最终产品或系统的唯一方法。
软件设计是一个反复的过程，通过该过程可以将需求转换为构建软件的“蓝图”。
- 刚开始，蓝图描述了软件的整体视图，也就是说，设计是在高层次上的表达 - 在该层次上可以直接跟踪到特定的系统目标以及更详细的数据、功能和行为需求。
- 随着设计迭代的开始，后续的细化导致更低抽象层次的设计表示。这些表示仍然能够跟踪到需求，但是在这些较低的抽象层次上，连接可能并不明显。
设计之所以重要，是因为它允许软件团队在实现软件之前评估软件的质量 - 此时修正错误、遗漏或者不一致都不困难且代价不高。但是我们如何在设计过程中评估质量能？在设计阶段，可以通过开展一系列的技术评审(Technical Review, TR)来评估质量。
设计模型 #
软件设计模型等同于建筑师的建房屋的计划。
- 它首先表示要建造的事物的整体(例如房屋的三维渲染)；
- 然后慢慢地精化事物以提供构建每个细节的指导(例如，管道布局)；
- 同样，为软件创建的设计模型提供了各种不同的系统视图。
可以从两个不同的维度观察设计模型：
- 过程维度表示设计模型的演化，设计任务作为软件过程的一部份被执行；
- 抽象维度表示详细级别，分析模型的每个元素转化为一个等价的设计，然后迭代求精。
如上图，虚线表示分析模型和设计模型之间的边界。在某些情况下，分析模型和设计模型之间可能存在明显的差异；而有些情况下，分析模型慢慢地融入设计模型而没有明显的差异。
设计模型的元素使用了很多相同的UML图，有些UML图在分析模型中也会用到。差别在于这些图被求精和细化为设计的一部份，并且提供了更多具体的实施细节，突出了架构的结构和风格、架构中的组件、组件之间以及组件和外界之间的接口。
然而，沿横轴表示的模型元素并不总是顺序开发的。大多数情况下，初步的架构设计是基础，随后是接口设计和组件级设计(通常是并行进行)。通常，直到设计全部完成后才开始部署模型的工作。
在设计过程中的任何地方都可以应用设计模式。这些模式能够使设计人员将设计知识应用到他人已经遇到并解决了特定领域问题中。
参考资料 #
- 《软件工程 - 实践者的研究方法》