软件设计的编写

在总体设计中对产品进行划分，设计出子系统和模块，
在概要设计中对子系统进行划分，设计出模块和子模块，
在详细设计中，设计出子模块的每个功能和特性。

1. 划分模块不等于划分功能：
   模块的粒度比需求更细
   多个模块协作才能完成一个需求
   一个模块可以被多个需求复用
   例如“人体”的需求设计：
   

2. 正确的模块划分：
   逐层向下分解问题：把一个复杂问题分解为多个步骤；分为单一功能，结构简单的元件。
   重新组合归纳问题：抽象和归纳相似元件。

3. 设计的原则：
   单一职责： 引起一个模块变化的需求应该只有一类；
   开发-封闭：模块通过拓展而不是修改来满足新需求；
   里氏替换：一个抽象的具体类型实现应能完全替换抽象所在的位置
   依赖倒置：抽象应该封装细节，模块接口对外的职责是契约式的，不是由具体实现来决定抽象应该怎么做；
   接口隔离：不应该让对外的接口过于抽象，从而增加接口调用的复杂性，注意分离出易变的需求与不变的需求；
   重用发布等价：对外发布的系统是模块化的，每个模块应该是可重用的，独立的模块；
   共同封闭：一个变化应仅影响系统中的一个模块；
   共同重用：模块是自身封闭的闭包，当需要重用这个模块中的一部分时，我们需要将这个模块整体重用；
   无依赖环：模块之间的依赖关系不能形成环；
   稳定依赖：易变的模块应该依赖于稳定的模块；
   稳定抽象：最稳定的模块应该是最抽象的，不稳定的应该具体实现；

4. 软件架构设计的五视图法：
   逻辑架构：逻辑分层，功能特性，职责划分，子系统模块类，职责间协作关系，接口；
   开发架构：源文件，配置文件，程序库，框架，目录结构，编译依赖；
   运行架构：控制流，进程线程，系统启动停止，控制流通信，加锁同步；
   物理架构：安装和部署，服务器，云服务，设备，基础环境；
   数据架构：业务逻辑模型，文件格式，数据库设计；

• 逻辑结构特点：按功能特性，职责划分，可以描述框架功能和外部接口，模块和外部系统关系

用户直接使用的功能
为实现用户功能必须的辅助功能模块
为复用扩展设计的基础框架

• 物理架构：关注系统安装部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性，可伸缩性要求
• 数据架构：关注持久化数据的存储方案，不仅包括实体数据存储格式，还包括数据传递，数据复制，数据同步等策略；
• 数据架构和物理架构的关系：对于很多集成系统，数据需要在不同系统之间传递，复制和暂存，这往往要涉及到不同的物理机器，即，可以把数据放在物理架构之中考虑，以便体现集成系统的数据分布与传递特征；
• 开发架构：关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架，类库以及开发的系统将运行于其上的系统软件或中间件。

逻辑层一般会映射到开发架构中的多个程序包
开发架构中的源码文件可以包含逻辑架构中一到多个类

• 运行架构：关注对象/逻辑单元在运行时的关系，以及相关的同步，异步，通信等问题，关注逻辑单元的交互过程。

5. UML（unified modeling language 统一建模语言）：

• 用例图：描述（谁-干什么）模块的范围，功能点
  扩展描述 include：即一个用例包含另一个用例
  extend：一个用例扩展到另一个用例，有条件限制

  

• 状态图：描述被处理的模型状态变化，适合表现可以反复变化的业务行为
  

• 时序图：描述各个部分功能职责，对象之间协作也是一个责任传递，连线上应该用动词描述其职责传递。
  

• 活动图：描述业务处理过程，分为带泳道和不带泳道，从1点开始，可以有多个终点，可以有并发和同步，与传统意义上的流程图最接近。

• 类图：描述抽象的对象关系。