数据流

解题技巧

1.补充和完善数据流

(1)平衡原则：父图和子图的输入/输出数据流一致

(2)每个加工至少有一个输入流和一个输出流，反应此加工的数据来源和结果，加工的输出数据流应该都有其对应的输入数据流

(3)遗漏的数据流：依据说明，如缺失某个一个加工的数据来源【成绩单的输入需要有学生基本信息和成绩列表】

2.找出错误或多余的数据流

参考完善数据流，上层图和下层图对照分析，然后检查是否每个加工至少有一个输入流和一个输出流，是否加工的输出数据流都有其对应的输入数据流

3.找出多余的文件

在某层数据流图中，只画流程图各加工之间的公共数据文件时，如果一个文件仅仅作用于一个加工，即和该文件有关的输入输出数据流只涉及一个加工，那么该文件可以作为局部文件出现在该加工的子图中，在父图中则可以省略。这个规则是为了使整个流程图的层次结构更为清晰、科学。当然这些文件如果画出，并不会造成理解错误。

另外，如果某层图只有一层细化图，即该层图没有子图，则不存在局部文件和外部文件之分，其中涉及的任何文件都不作为多余的文件。

解答题

1..绘制1层数据流要注意的问题

保持父图与子图平衡。父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量和名字上相同。如果父图的一个输入（或输出）数据流对应于子图中几个输入（或输出）数据流，而子图中组成这些数据流的数据项全体正好是父图中的这一个数据流。那么它们仍算是平衡的。

2.逻辑数据流图和物理数据图主要区别

物理数据流图关注的是系统中的物理实体，以及一些具体的文档、报告和其他输入/输出硬拷贝。物流数据流图用作系统构建和实现的技术性蓝图。

逻辑数据流图强调参与者所做的事情，可以帮助设计者决定需要哪些系统资源，为了运行系统用户必须执行的活动，在系统安装之后如何保护和控制这些系统。逻辑数据流图是物理数据流图去掉了所以的物流细节后得到的变换形式，逻辑数据流图被用做系统分析的需求分析阶段的起点。

3.程序流图运用的场合和作用

程序流程图通常在进行详细设计时使用，用来描述程序的逻辑结构

数据库

1.补充 E-R 图：实体联系图

2.完整性约束：先属性名称，再 主键 和 外键 关联关系

3.数据库表存在问题，如：主键由两个键组成，将表按主键进行拆分，拆成两个表

4.实体间的联系：一对一，一对多，多对多

5.关系模式：实体定义，即，实体(属性1，属性2，…)

UML图

1.补充参与者名称与用例名称

2.用例描述：参与者、主要事件流、备选事件流、前置条件、后置条件

3.关系图形表示法【重点】

依赖：一个类的实现需要另一个类的协助，代码体现为局部变量、方法的参数或者对静态方法的调用；带箭头的虚线，指向被使用者

关联：一个类知道另一个类的属性和方法，代码体现为成员变量；带普通箭头的实心线，指向被拥有者

聚合：体现整体与部分、拥有的关系，即has-a的关系；带空心菱形的实心线，菱形指向整体（特点：生命周期不同，即整体消亡后，部分也可独立存在）

组合：contains-a的关系；带实心菱形的实线，菱形指向整体（特点：生命周期相同，即整体消亡后部分不可独立存在）

泛化：继承；带三角箭头的实线，箭头指向父类

实现：接口；带三角箭头的虚线，箭头指向接口

4.类与类的之间的多重度【重点】

多重度又称重复度，多重度表示为一个整数范围 n..m，整数n定义所连接的最少对象的数目，而m则为最多对象数（当不知道确切的最大数时，最大数用*号表示）。最常见的多重性有0..1，0..*，1..1，1..*，而*与0..*是等价的

5.用例之间的关系

包含关系（<<include>>）：可以从两个或者两个以上的用例中提取公共行为

扩展关系（<<extend>>）：如果一个用例明显地混合了两种或者两种以上不同的场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或者多个扩展用例，这样可以使描述可能更加清晰

泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将他们的共性抽象为父用例，其他用例作为泛化关系中的子用例

算法题

观察者模式：

意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发送变化时，所有依赖于它的对象都得到通知并自动更新

适用场合：

（1）当一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两者封装在独立的对象中以使得它们可以独立地改变和复用

（2）当一个对象的改变需要同时改变其他对象，而不知道具体有多少个对象有待改变时

（3）当一个对象必须通知其他对象，而它又不能假定其他对象是谁，即不希望这些对象是紧耦合的

代码补全

设计模式：责任链模式

来源：新新许愿树