流程图:以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程,描述处理过程的控制流。
数据流图:作为一种图形化工具,用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。
两者的区别主要包括:
(1)数据流图中的处理过程可并行;流程图在某个时间点只能处于一个处理过程。
(2)数据流图展现系统的数据流;流程图展现系统的控制流。
(3)数据流图展现全局的处理过程,过程之间遵循不同的计时标准;流程图中处理过程遵循一致的计时标准。
(4)数据流图适用于系统分析中的逻辑建模阶段;流程图适用于系统设计中的物理建模阶段。
状态图:主要用于描述一个对象在其生存期间的动态行为,表现一个对象所经历的状态序列,引起状态转移的事件(event),以及因状态转移而伴随的动作(action)。
活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式,活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的转移可能需要事件的触发)。
两者最大的区别是:
状态图侧重于描述行为的结果,而活动图侧重描述行为的动作。其次活动图可描述并发行为,而状态图不能。
活动图描述的是对象活动的顺序关系所遵循的规则,它着重表现系统的行为,而非处理过程;而流程图着重描述处理过程。
流程图一般都限于顺序进程,而活动图则可以支持并发进程。
活动图是面向对象的,而流程图是面向过程的。
数据流:数据流是数据在系统内传播的路径,因此由一组成分固定的数据组成。
外部实体:代表系统之外的实体,可以是人、物或其他软件系统。
加工(处理):加工是对数据进行处理的单元,它接收一定的数据输入,对其进行处理,并产生输出。
数据存储:表示信息的静态存储,可以是文件、文件的一部分、数据库的元素等。
(1)子图与父图之间的平衡:
是指任何一张DFD子图边界上的输入/输出数据流必须与其父图对应加工的输入/输出数据流保持一致。
如果父图中某个加工的一条数据流对应于子图中的几条数据流,而子图中组成这些数据流的数据项全体正好等于父图中的这条数据流,那么它们仍然是平衡的。
(2)子图内部:加工的输入和输出需要平衡。
其中,数据流图常见3种错误:
用例之间的关系主要有泛化(Generalization)、包含(Include)和扩展(Extend)。
(1)当可以从两个或多个用例中提取公共行为时,可以使用包含关系来表示。
(2)如果一个用例混合了两种或两种以上不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例。
(3)当多个用例共同拥有一个类似的结构和行为的时候,可以将它们的共性抽象成父用例,其他的用例作为泛化关系中的子用例。
依赖关系:一个事物发生变化影响另一个事物。
泛化关系:特殊/一般关系。
关联关系:描述了一组链,链是对象之间的连接。
聚合关系:整体与部分生命周期不同。
组合关系:整体与部分生命周期相同。
实现关系:接口与类之间的关系。
这3种模型都涉及数据、控制和操作等共同的概念,但侧重点不同,从不同侧面反映了系统的实质性内容,综合起来全面地反映了对目标系统的需求。
功能模型指明了系统应该“做什么”;动态模型明确规定了什么时候做;对象模型则定义了做事情的实体。
(1)实体类。实体类映射需求中的每个实体,保存需要存储在永久存储体中的信息,例如,用户、商品等。
(2)控制类。控制类是用于控制用例工作的类,用于对一个或几个用例所特有的控制行为进行建模。例如,结算、备货等。
(3)边界类。边界类用于封装在用例内、外流动的信息或数据流。例如,浏览器、购物车等。