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