系分 - 案例分析 - 系统设计

个人总结，仅供参考，欢迎加好友一起讨论

系分 - 案例分析 - 系统设计

结构化设计SD

内聚

模块的内聚类型通常可以分为7种，根据内聚度从高到低排序：

偶然内聚

偶然内聚的模块内，各个组成部分是很随意地组合到一起。偶然内聚的各个部分之间，除了“恰好放在同一个模块内”之外，没有任何关系。

内聚性最弱、也是最差的一种情况，一个模块内干几件没有相关的事情，无法维护。

逻辑内聚

逻辑内聚是指一个模块内的几个组件仅仅因为“逻辑相似”而被放到了一起，即使这几个组件本质上完全不同。几个逻辑上相关的功能被封装到同一个模块里面，然后由调用函数传入控制的参数来确定调用哪个功能。

缺点：接口不容易理解，因为传入控制参数至就会添加参数说明否则谁知道参数。

时间（瞬时）内聚

当Controller处理Http请求之前，用Filter统一做解密、验签、认证、鉴权、接口日志、异常处理等操作，那

么，解密/验签/认证/鉴权/接口日志/异常这些功能之间就产生了时间内聚。

过程内聚

过程内聚是指一个模块内的多个组件之间必须遵循一定的执行顺序才能完成一个完整功能。

通信内聚

通信内聚是指一个模块内的几个组件要操作同一个数据（例如同一个Dto、同一个文件、或者同一张表等）。

顺序内聚

顺序内聚是指在一个模块内的多个组件之间存在“一个组件的输出是下一个组件的输入”这种“流水线”的关系。

功能内聚

功能内聚是指一个模块内所有组件共同完成一个功能、缺一不可。某个组件只要与模块的功能无关，哪怕它与其它组件之间存在着其它内聚，也必须移走。

耦合

模块的耦合类型通常也分为7种，根据耦合度从低到高排序

内容耦合

内容耦合是指一个模块直接使用另一个模块的代码，有三种情况：

1、最常见、大概也是最可恶的内容耦合，无疑就是Ctrl+C/Ctrl+V了。

2、不直接使用代码、但是重复实现功能。

3、通过非正常入口而转入另一个模块内部。

公共耦合

公共耦合是指多个模块访问同一个全局数据。当（某个模块或全局数据）发生变化时，这种耦合可能会导致不受控制的错误传播以及无法预见的副作用。公共耦合也叫共享耦合、全局耦合。

外部耦合

外部耦合是指两个模块共享一个外部强加的数据结构、通信协议或者设备接口。外部耦合基本上与外部工具和设备的通信有关。

控制耦合

控制耦合是指一个模块通过传入一个“做什么”的数据来控制另一个模块的流程。结合内聚类型来看，控制耦合对应的就是逻辑内聚。

标记耦合

模块之间通过共享数据结构传递信息，发送方通过参数发送给接收方，接收方只使用一部分。

数据耦合

数据耦合是指模块间通过传递数值来共享数据。传递的每个值都是基本数据，而且传递的值是就是要共享的值。

非直接耦合

不多做解释，很好理解，没有任何关联和联系。

补：建模信息系统应用架构

逻辑DFD

使用逻辑DFD建模过程需求已经是广泛接受的实践，但是从面向分析的逻辑DFD到面向设计的物理DFD的转变一直有点不好理解。我们希望有一种高层次的通用设计，可以用于设计系统的应用架构以及构成系统的过程，简单地说，我们想要有一个蓝图来指导我们走过详细设计和构造阶段，具体包括：

1. 绘制物理数据流图
2. 前置条件（如逻辑数据模型、逻辑过程模型）
3. 网络架构
4. 数据分布和技术确定（如在不同的服务器上存储特定表的子集）
5. 过程分布和技术确定（如三层客户/服务器和网络计算系统）
6. 人/机边界

数据流图(DFD）是一种系统分析工具，用于建模信息系统的逻辑业务需求。物理数据流图建模作为信息系统一部分实现的技术设计决策和人为设计决策，将同那些实际构造和实现系统的人沟通技术选择和其他设计决策。换句话说，物理DFD用作系统构造和实现的技术性蓝图。

物理DFD

物理DFD使用的基本形状与逻辑DFD相同，也就是包括外部实体、过程、数据流和数据存储。但是，物理DFD的每个过程描述的是要计划的实际实现。物理过程是一个处理器（例如计算机或人），或者是要执行的特定工作的技术性实现（如计算机程序或手工过程）。在系统设计过程中，必须说明如何实际地实现在分析阶段形成的逻辑过程。

物理数据流图有以下两个基本要素：

• 逻辑过程经常被分配到特定的物理处理器，如PC、服务器、人或计算机网络中的基他设备。
• 每个逻辑过程必须实现成一个或多个物理过程。（原因：将过程分解成人执行的部分和由计算机执行的部分；将过程分解成使用一种技术实现的部分和使用另一技术实现的部分；为了处理例外，或者为了安全需求和审计需求而增加的过程）对应地，为了保持原始数据流的本质不变，就必须相应地增加数据流。

物理数据流表示了下列内容：

1. 一个物理过程的输入或输出的计划实现。
2. 一个数据库的命令或动作，如创建、读取、修改或删除。
3. 通过网络从另一个信息系统输入数据或者向另一个信息系统输出数据。
4. 同一个程序中两个模块或子路线之间的数据流。

大多数逻辑数据流将被直接带入物理DFD中，有些可能会被合并成表示业务表格的单个数据流；另一些则可能会分解成多个数据流，作为将逻辑过程分解成多个物理过程的结果；其他一些则可能被复制成使用不同技术实现的多个流。例如，逻辑数据流“订单”可能被实现成以下形式：“表格：订单”、“电话：订单”、“HTML：订单”。

物理外部代理，外部代理从逻辑DFD继续不变地转至物理DFD。按照定义，外部代理在系统分析期间被归类为系统范围以外，所以，它们不应变化。

物理数据存储实现了逻辑数据存储，表示以下内容之一：

1. 数据库
2. 数据库中的表
3. 计算机文件
4. 重要数据的磁带或介质备份
5. 程序需要的临时文件或批处理文件
6. 任意未经计算机处理的文件

面向对象的设计OOD

如同结构化程序设计一样，面向对象设计的两个决定性的目标也是低耦合和高内聚。内聚是对一个类的所有属性和行为相互之间关联的度量。通过争取获得高内聚和低耦合，我们希望每个类主要关注一件事情，而且每个类尽可能地独立。

为了同质量问题做斗争，也为了实现更高层的复用，开发人员开始使用设计模式、对象框架和组件。

• 设计模式，这里不再赘述。
• 对象框架：框架是提供一组相关服务的协作类构成的子系统。如果说模式是写在纸上的设计指南，那么对象框架是在程序中实现的并且已经可用的类。一个比较常见的对象框架是用于将对象翻译成关系表（或者反过来）的软件。当你的应用是面向对象的，但你使用的数据库是非面向对象的（如关系数据库）时，就要使用这个框架。
• 通过使用组件，开发人员可以方便地为其他人封装和分发程序代码。一个组件代表了系统中一个可替换的模块或物理单元（EXE、DLL或数据库）。组件有时称为“超级对象”，但实际上组件包含了一组相关的协作对易用，它们具有一个接口，可以作为一个单元部署。

结语

本章节内容大部分为了补充知识点，大部分的系统设计知识点会以需求分析的方式进行考察，另外一部分就是基于Web的系统设计。

有关Web方面的系统设计，请移步以下连接：
案例分析 - 架构设计（基本）
案例分析 - 系统设计（Web架构）