软件设计师 7日速成

数据流图和数据字典

数据流图

定义

数据流图是一种图形化的工具，用于描述系统中数据的流动情况。它可以帮助我们可视化数据在系统中的处理过程，包括数据的来源、去向、存储位置以及处理方式。

组成元素

数据流图通常包含以下四个基本元素：

外部实体：
- 表示系统之外的数据来源或目的地。
- 例如，客户、供应商、数据库等。
- 在图中通常用一个小方框表示。
处理过程：
- 表示对数据进行某种处理或操作的步骤。
- 例如，计算、验证、存储等。
- 在图中通常用一个圆角矩形表示。
数据流：
- 表示数据在不同部分之间的流动方向。
- 例如，从客户到订单处理系统，从订单处理系统到库存管理系统等。
- 在图中通常用箭头表示，箭头的方向表示数据的流向。
数据存储：
- 表示数据的临时或永久存储位置。
- 例如，文件、数据库表等。
- 在图中通常用一个开口的长方形表示。

示例

假设我们要设计一个简单的图书馆管理系统，以下是它的数据流图：

外部实体：读者、图书管理员
处理过程：借书、还书、查询书籍信息
数据流：读者提交借书请求、系统记录借书信息、图书管理员确认还书
数据存储：图书信息库、借阅记录库

数据字典

定义

数据字典是对系统中所有数据元素的详细描述，包括数据的名称、类型、长度、格式、取值范围、默认值等。它是一个详细的文档，帮助开发人员和用户更好地理解系统中的数据结构。

作用

定义数据：明确每个数据项的含义和属性。
一致性：确保数据在整个系统中的一致性和准确性。
文档化：为系统维护和扩展提供详细的参考。

组成元素

数据字典通常包含以下内容：

数据项（Data Item）：
- 数据项的名称。
- 数据项的类型（如字符型、整型、浮点型等）。
- 数据项的长度。
- 数据项的取值范围。
- 数据项的默认值。
- 数据项的描述。
数据结构（Data Structure）：
- 复合数据项的组成。
- 各个子数据项的关系。
数据流（Data Flow）：
- 数据流的名称。
- 数据流的组成数据项。
- 数据流的来源和去向。
数据存储（Data Store）：
- 数据存储的名称。
- 存储的数据项。
- 存储的方式（如文件、数据库表等）。

示例

假设我们有一个“学生信息”数据字典条目，可能包括以下内容：

数据项：
- 学号（类型：整型，长度：10，取值范围：1000000000-9999999999）
- 姓名（类型：字符型，长度：20）
- 年龄（类型：整型，长度：3，取值范围：16-30）
- 性别（类型：字符型，长度：1，取值范围：M/F）
- 专业（类型：字符型，长度：50）
数据结构：
- 学生信息 = {学号, 姓名, 年龄, 性别, 专业}
数据流：
- 注册信息流 = {学号, 姓名, 年龄, 性别, 专业}
- 来源：注册系统
- 去向：学生信息数据库
数据存储：
- 学生信息数据库
- 存储的数据项：{学号, 姓名, 年龄, 性别, 专业}
- 存储方式：关系数据库表

总结

数据流图（DFD）：图形化工具，描述数据在系统中的流动情况。
数据字典：详细文档，定义系统中所有数据元素的属性和关系。

编译器的词法分析、语法分析、语义分析

词法分析：把源代码分解成一个个记号。
语法分析：检查记号的排列是否符合语言的规则，并生成抽象语法树。
语义分析：检查抽象语法树是否有意义，确保代码的逻辑和上下文正确。

UML图

UML图，全称是“统一建模语言”（Unified Modeling Language）图

UML图的主要用途

需求分析：帮助团队成员理解用户的需求，并通过图表的形式表达出来。
设计：在编码之前，使用UML图来设计软件架构，包括类、对象、接口等的设计。
文档化：作为项目文档的一部分，记录软件的设计决策和系统架构。
沟通：促进开发者、项目经理、客户等不同角色之间的沟通和理解。

常见的UML图类型

类图（Class Diagrams）：显示了系统的静态结构，包括类、属性、方法以及它们之间的关系。比如，一个学生管理系统可能会有“学生”、“课程”这样的类。
对象图（Object Diagrams）：类似于类图，但是它展示了特定时刻的对象实例及其之间的关系。
序列图（Sequence Diagrams）：描述了对象之间如何通过消息传递来进行交互的过程，强调的是时间顺序。
协作图/通信图（Collaboration Diagrams）：也称为通信图，显示了对象之间的连接和它们发送的消息，重点在于对象间的合作关系。
状态图（State Diagrams）：用于表示对象在其生命周期中的不同状态以及状态之间的转换。
活动图（Activity Diagrams）：描述了业务流程或操作的工作流程，类似于流程图。
组件图（Component Diagrams）：展示了系统的物理结构，包括文件、库等组件及其依赖关系。
部署图（Deployment Diagrams）：描述了硬件的物理结构以及在这些硬件上部署的软件组件。

三种设计模式

创建型模式

创建型模式主要关注对象的创建过程，提供了一种在程序中创建对象的最佳方式，而不是直接使用 new 关键字。

单例模式（Singleton Pattern）
- 解释：确保一个类只有一个实例，并提供一个全局访问点。
- 例子：比如一个日志文件管理器，整个应用程序只需要一个日志文件管理器实例来处理所有的日志记录。
工厂方法模式（Factory Method Pattern）
- 解释：定义一个用于创建对象的接口，但由子类决定实例化哪一个类。
- 例子：假设有一个交通工具工厂，它可以生产不同类型的交通工具（如汽车、自行车），具体的交通工具类型由子类决定。
抽象工厂模式（Abstract Factory Pattern）
- 解释：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
- 例子：假设你需要创建一个用户界面组件库，包括按钮、文本框等，不同的操作系统可能有不同的实现方式（如Windows风格和Mac风格）。抽象工厂模式可以帮助你根据操作系统创建相应的组件。

结构型模式

结构型模式关注的是类或对象的组合，它们通过识别简单的结构关系来设计更复杂的结构。

适配器模式（Adapter Pattern）
- 解释：将一个类的接口转换成客户希望的另一个接口，使原本由于接口不兼容而不能一起工作的那些类可以一起工作。
- 例子：假设你有一个旧的音频播放器，只能播放MP3格式的音乐，但你有一个新的音频文件是WAV格式的。适配器模式可以帮助你将WAV文件转换成MP3格式，从而在旧的音频播放器上播放。
装饰器模式（Decorator Pattern）
- 解释：动态地给一个对象添加一些额外的职责，而不改变其接口。
- 例子：假设你有一个文本编辑器，基本功能是显示文本。你可以通过装饰器模式为其添加加粗、斜体等功能，而不需要修改原有的文本显示类。
代理模式（Proxy Pattern）
- 解释：为其他对象提供一种代理以控制对这个对象的访问。
- 例子：假设你有一个远程文件服务器，每次访问文件都需要网络连接。你可以使用代理模式来缓存文件，减少网络请求，提高性能。

行为型模式

行为型模式关注的是对象之间的责任分配和通信，它们描述了类或对象如何交互以及如何分配职责。

观察者模式（Observer Pattern）
- 解释：当一个对象的状态发生变化时，所有依赖于它的对象都会得到通知并自动更新。
- 例子：天气预报系统，多个显示设备（如温度计、湿度计）订阅了一个天气数据源，当天气数据源的数据更新时，所有显示设备都会自动更新显示。
策略模式（Strategy Pattern）
- 解释：定义了一系列可互换的算法，并将这些算法封装在独立的类中，使它们可以相互替换。
- 例子：假设你有一个排序算法，可以根据不同的需求选择不同的排序策略（如快速排序、冒泡排序）。策略模式可以帮助你轻松切换不同的排序算法。
命令模式（Command Pattern）
- 解释：将请求封装成对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
- 例子：假设你有一个遥控器，可以控制多种电器（如电视、空调）。每个按钮对应一个命令对象，按下按钮时，遥控器会执行相应的命令。