本资料为本站精心整理的案例分析一本通,包含复习说明、考点分析、考点汇总、案例真题及解析等全部内容,请网友务必结合案例分析专题课程认真学习。
第1章是案例分析概述,大家认真浏览一遍,做到心中有数即可。
第2章是历年案例真题精华考点,包括软件架构设计、软件系统设计、数据库系统设计、嵌入式系统设计以及Web系统设计。
第3章是第二版教材下篇架构设计考点,此章为第二版教材新增内容,有大量关于不同架构设计实战内容,涉及到不少新技术,务必也要掌握。
第4章是案例分析真题,包括2016年以来的历年全部真题,务必全部做完。
第5章是案例分析真题答案解析,每做完一年真题,要认真核对答案解析,查漏补缺。
第1章案例分析概述
1.1 案例分析作答要求
案例分析第一题必做,后面四道题四选二。机试选做题很简单,选哪一道题就做哪一道,不选的就清空不要写任何数据。考试的时候灵活应变,看清楚要求即可。
除此之外 ,综合知识和案例分析2个科目连考,作答总时长240分钟,综合知识科目最长作答时长150分钟,最短作答时长120分钟。本站不建议大家提前交卷,案例时间较为紧张,需要全都利用起来。
1.2 历年真题考点分析
根据历年真题考点分析,将架构案例分析真题分为如下几个大类:
①软件架构设计:每年必考1 -2题,并且是第1题必选题,必须掌握,主要涉及质量属性、软件架构风格、软件架构评估、MVC架构、面向服务的架构SOA、ESB、J2EE架构等。
②软件系统设计:几乎每年必考1题,主要涉及UML的图、关系的识别,尤其是类图、用例图、活动图、状态图;设计模式识别;数据流图、E-R图等简单识别;信息安全相关技术;项目管理-进度管理-关键路径。
③数据库系统设计:几乎每年必考1题,主要考查数据库的一些新技术的比较,如关系型数据库、非关系型数据库NoSQL以及内存数据库Redis等,还会包括反规范化技术、主从复制、负载均衡等。
④嵌入式系统设计:几乎每年必考1题,选做题,考查比较的多的是嵌入式系统的实时性和可靠性以及容错性等概念。大概率会考到一些嵌入式领域陌生技术,如果是完全没见过的技术,不选即可。
⑤Web系统设计:几乎每年必考1题,主要考查Web相关技术,一般结合架构进行考查。偶尔会考到新技术,遇到完全没听说过的技术,就不选。
改版后下篇八大架构是重中之重。
此外,若偶尔考到一些完全陌生的架构和技术,可直接选择忽略,因为陌生技术不会再考第二次,无法归纳总结,完全没有必要了解。
历年案例分析考点归纳如下(红色字体是试题一必答题)。
年份 | 试题 | 考查范围 | 考查知识点 |
202411 | 试题一 | 软件架构 | 质量属性六要素,ping/echo,心跳模式 |
试题二 | 数据库 | cache-aside架构,缓存处理 | |
试题三 | 嵌入式 | ROS1,ROS2定义、特点和改进,选词填空 | |
试题四 | Web系统 | Elasticsearch分词,架构填空,RESTful架构特点 | |
试题五 | 软件设计 | 安全分析4个步骤,填空题,形式化开发和软件测试的特点 | |
202405 | 试题一 | 软件架构 | 微服务优缺点、质量属性效用树、质量属性六要素 |
试题二 | 软件系统 | 序列图、协作图、序列图三种消息、图填空、条件分支 | |
试题三 | 数据库 | Mysql分布式锁、Redis分布式死锁、Redis命令 | |
试题四 | 嵌入式 | SOME/IP协议特点、SOME/IP填空、DDS和AP模块流程图 | |
试题五 | Web系统 | 架构图填空、MongoDB非结构化和矢量化存储、热温冷数据 | |
2023 | 试题一 | 软件架构 | 大数据架构Lambda和Kappa |
试题二 | 软件系统 | Sysml需求图和用例图、需求图七类关系等 | |
试题三 | 数据库 | 读写分离架构、Redis缓存、主从复制 | |
试题四 | 嵌入式 | Hibernate架构、数据持久层、jwt | |
试题五 | Web系统 | 数字孪生概念、技术选择、架构图填空 | |
2022 | 试题一 | 软件架构 | 架构风格,质量属性 |
试题二 | 软件系统 | 结构化分析:数据流图、E-R图、数据字典 | |
试题三 | 嵌入式 | 宇航装备架构、看图填空、故障分析 | |
试题四 | 数据库 | 同步和异步、缓存分片、布隆过滤器 | |
试题五 | Web系统 | MQTT协议、看图填空、云计算、边缘计算 | |
2021 | 试题一 | 软件架构 | 架构风格,质量属性 |
试题二 | 软件系统 | 用例图、顺序图填空、模型对比 | |
试题三 | 软件架构 | 数据定义分布管理涵义、基于FACE的架构(题目不全) | |
试题四 | 数据库 | 反规范化设计方法、数据不一致、Redis同步 | |
试题五 | Web系统 | 云平台智能家居,看图填空,TCP/UDP区别 | |
2020 | 试题一 | 软件架构 | 架构风格,质量属性 |
试题二 | 数据库 | 逻辑设计、关系模式、主键、超类实体、派生属性 | |
试题三 | 嵌入式 | 需求到架构映射、FACE架构 | |
试题四 | 数据库 | 内存数据库redis,内存淘汰机制 | |
试题五 | Web系统 | 非功能性需求,SSM框架,数据访问机制 | |
2019 | 试题一 | 软件架构 | 架构风格,质量属性 |
试题二 | 软件系统 | 数据流图求实体、加工、补充数据流;系统流程图区别 | |
试题三 | 嵌入式 | 信息物理系统三层结构概念、填空;三类安全威胁 | |
试题四 | 数据库 | 数据库读写并发操作、key/value方案探讨 | |
试题五 | Web系统 | 非功能性需求、分布式架构图、SQL注入攻击 | |
2018 | 试题一 | 软件架构 | 非功能性需求、C/S架构 |
试题二 | 软件系统 | 数据流图、ER图、实体和类、用例 | |
试题三 | 嵌入式 | 简单任务和复杂任务、基本消息通信BMTS | |
试题四 | 数据库 | MemCache和Redis、数据可靠性和一致性 | |
试题五 | Web系统 | SOA、ESB、信息安全、根据描述填图 | |
2017 | 试题一 | 软件架构 | 质量属性效用树、架构风险、敏感点、权衡点 |
试题二 | 软件架构 | MVC、EJB、J2EE | |
试题三 | 嵌入式 | 机器人操作系统ROS和RTOS、根据描述填流程图 | |
试题四 | 数据库 | ORM和数据库程序在线访问、数据访问层、工厂设计模式 | |
试题五 | Web系统 | 响应式web设计、高并发web架构、主从复制机制 | |
2016 | 试题一 | 软件架构 | 质量属性、架构风格对比、根据描述填空 |
试题二 | 软件系统 | 用例图参与者、用例关系、类图关系 | |
试题三 | 嵌入式 | RTOS特点、实时性分类、缺陷故障失效关系图 | |
试题四 | Web系统 | 应用服务器、PHP和Java、J2EE架构 | |
试题五 | 软件系统 | Scrum敏捷开发状态图、MVC架构应用 |
1.3 学习建议
第一步,听课,听一遍系统架构设计师《案例分析专题课程》,里面详细讲解了大量典型案例真题、解题技巧、如何分析题目等,很重要。
第二步,学习考点,读此一本通第2章、第3章案例真题精华考点,将相关考点都理解和记忆,不理解的再去听课程对应部分知识点。
第三步,刷题,做此一本通第4章历年案例真题,先按题目分类进行专题训练,再按年份做题,并按规定90分钟练习,以模拟真实考试场景,浏览五道题目,第一题必做,其他四选二。做完后核对答案(在第5章),看看自己哪些知识点需要加强。当然,四选二的题,要选择自己擅长的题目,要学会临场应变。
第二版教材下篇架构设计是纯新增内容,有大量关于不同架构设计实战内容,涉及到不少新技术,是比较难理解的,大家一定要先听教材下篇的课程讲解,再来看第3章,否则很难把握重点,同时,因为这一块实战性强,新技术多,老师也难免会有遗漏错误之处,敬请理解,也欢迎大家一起讨论反馈。
1.4答题技巧
答题时,先看问题,再看题目描述。
第一题必做,先做完第一题。对于四选二,快速浏览所有题目问题和问题描述,是否能看懂,再进行选题。
问题与题目描述相结合,尤其是遇到系统分析和设计以及新技术等问题,答案一般都在题目描述里,从题目描述里抽象总结出问题答案即可。当然要以简练的语言写出答案,一般题目会有最大字数要求,不建议超过。
列条目回答问题,把自己认为对的都写上,多写不会扣分,少写一定会扣分。
若遇到新的知识点,没关系,要稳住心态。能避开则避开,否则就理解所问问题的倾向性,顺势答题即可。
第2章历年案例真题精华考点
注意 :本章只是结合历年真题考查情况做的精简汇总,还是要以第一阶段:基础精讲为准,将案例分析涉及到的知识点章节内容全部理解记忆,必要时可以将官方教材通读一遍。
2.1 软件架构设计
系统架构设计师案例分析必考题,每年会必考1-2题,并且第1题是必选题,必须要掌握,主要考查质量属性、软件架构风格、软件架构评估、MVC架构、面向服务的架构SOA等知识。
对于其他未考查的架构领域重点知识如DSSA、ABSD等,也必须重点掌握,最好将软件架构设计章节通读一遍。
本题考查比较简单,知识点固定,一般可以拿到20分。
2.1.1质量属性效用树、质量属性判断
在架构评估过程中,所普遍关注的质量属性有以下几种。
(1) 性能:指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略:优先级队列、增加计算资源、减 少计算开销、引入并发机制、采用资源调度等 。
(2) 可靠性:是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性通常用平均失效等待时间 (Mean Time To Failure, MTTF ) 和平均失效 间隔时间(Mean Time Between Failure,MTBF)来衡量。在失效率为常数和修复时间很短的情况下,MTTF和 MTBF几乎相等。可分为容错和健壮性。容错是指在错误发生时确保系统正确的行为,并进行内部“修复”。健壮性是指系统不受错误使用和错误输入的影响,按既定程序忽略错误。设计策略:冗余、心跳、选举、Ping/Echo。
(3) 可用性:是系统能够正常运行的时间比例,经常用两次故障之间的时间长度或在出现故障 时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略:冗余、心跳、选举、Ping/Echo。
(4) 安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。可分为机密性、完整性、不可否认性、可控性。机密性保证信息不泄露给未授权的用户、实体或过程;完整性保证信息的完整和准确,防止信息被非法修改;不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为;可控性保证对信息的传播及内容具有控制的能力,防止为非法者所用。设计策略:入侵检测、用户认证、用户授权、追踪审计。
(5) 可修改性:是指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考查这些变更的代价来衡量可修改性。可分为可维护性、可扩展性、结构重组和可移植性。
可维护性:在错误发生后“修复”软件系统的难易程度。
可扩展性:软件因适应新需求或需求变化而增加新功能的能力。
结构重组:重新组织软件系统的构件及构件之间的关系。
可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。设计策略:接口-实现分类、抽象、信息隐藏。
(6) 功能性:是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
(7) 可变性:指架构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定 义的规则,在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基 础时,可变性是很重要的。
(8) 互操作性:作为系统组成部分的软件不是独立存在的,通常与其他系统或自身环境相互作用。为了支持互操作性,软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件架构。
质量属性效用树
ATAM方法采用效用树(Utility tree)这一工具来对质量属性进行分类和优先级排序。效用树的结构包括:树根–质量属性–属性分类–质量属性场景(叶子节点)。需要注意的是,ATAM主要关注4类质量属性:性能、安全性、可修改性和可用性,这是因为这4个质量属性是利益相关者最为关心的。
2.1.2软件架构风格必背概念
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族,即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。
敏感点和权衡点:敏感点是指为了实现某种特定的质量属性,一个或多个构件所具有的特性。权衡点是影响多个质量属性的特性,是多个质量属性的敏感点。
架构风险:是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
风险点与非风险点:不是以标准专业术语形式出现的,只是一个常规概念,即可能引起风险的因素,可称为风险点。某个做法如果有隐患,有可能导致一些问题,则为风险点;而如果某件事是可行的可接受的,则为非风险点。
架构风格对比
所有架构风格汇总如下,要理解每个架构风格的含义,有生疏的同学再去学习第一阶段:基础知识。
架构风格名 | 子风格 | 常考关键字及实例 | 简介 | ||
数据流 | 批处理 | 一个接一个顺序串行执行,数据以整体的方式传递 | |||
管道-过滤器 | 传统编译器、网络报文处理 | 一个接一个,前一个输出是后一个 输入 | |||
调用/返回 | 主程序/子程序 | 显示调用,主程序直接调用子程序 | |||
面向对象 | 构件是对象,通过对象调用封装的 方法和属性 | ||||
层次型 | 分层,每层最多影响其上下两层, 有调用关系 | ||||
C/S | 瘦客户机 | 三层C/S结构为客户端、应用服务器和数据库服务器 | |||
B/S | 零客户端 | 三层B/S结构为浏览器、Web服务器和数据库服务器 | |||
以数据为中心 | 仓库 | 现代编译器的集成开发环境IDE,以数据为中心。又称为数据共享风格 | 中央共享数据源,独立处理单元 | ||
黑板 | 包括知识源、黑板和控制三部分。适用于解决复杂的非结构化的问题,如信号处理、问题规划和编译器优化等 | ||||
虚拟机 | 解释器 | 自定义一套规则,开发构件, 增加灵活性,能够跨平台适配 | 解释自定义的规则,解释引擎、存 储区、数据结构 | ||
规则系统 | 包括规则集、规则解释器、选择器及工作内存,用于人工智能和DSS中 | ||||
独立构件 | 进程通信 | 进程之间消息传递,点对点独立传递,同步或异步方式 | |||
事件系统 | 事件触发调用,如程序语言的 语法高亮、语法错误提示 | 基于事件的隐式调用,通过事件驱动 | |||
C2风格 | 构件和连接件、顶部和底部 | 通过连接件绑定在一起按照一组规则运作的并行构件网络 | |||
闭环-过程控制 | 汽车巡航定速,空调温度调 节,设定参数,并不断调整。 | 发出控制命令并接受反馈,循环往复达到平衡。 |
架构风格 | 主要特点 | 主要优点 | 主要缺点 | 适合领域 | |
管道-过滤器 | 过滤器相对独立 | 高内聚、低耦合; 支持软件复用;可 维护性、可扩展性 较强;具有并发性、灵活性 | 不适于交互性强的应用,对于存在关系的数据流必须进行协调 | 系统可划分清晰的模块;模块相对独立;有清晰的模块接口 | |
解释器风格 | 系统核心是虚拟机 | 自定义一套规则, 开发构件,增加灵 活性,能够跨平台适配,可扩展性强 | 执行效率低,如果 语法规则数量太 多,会增加系统复杂度,性能较差 | 适合于模式匹配系统与语言编译器 | |
面向对象 | 构件是对象,对象是通过函数和过程的调用 来交互的 | 高度模块化;实现封装;代码共享灵活;易维护;性能好 | 增加了对象之间的 依赖关系 | 多种领域 | |
事件系统 | 构件不直接调用一个 过程,而是触发或广播一个或多个事件 | 支持软件复用;容易实现并发处理和多任务;可扩展性好;具有类层次结构;简化代码 | 对系统计算的控制能力弱;各个对象的逻辑关系复杂 | 一个系统对外部的 表现可以从它对事 件的处理表征出来 | |
层次型 | 构件组成一个层次结构;多层相互协同工作,每一层为上层提供服务,并作为下层的客户,只对与自己相邻的层可见 | 支持系统设计过程中的逐级抽象;可扩展性好;支持软件复用 | 不同层次之间耦合度高的系统很难实现,即难以划分层次 | 适合功能层次的抽象和相互之间低耦合的系统 | |
仓库 | 由中央数据结构(说明当前数据状态)和一组独立构件(对中央数据进行操作)组成 | 中央数据结构实现了数据的集中,以数据为中心 | 适合于特定领域 | 以数据为中心 |
2.1.3MVC架构
MVC强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离,形成了模型、视图、控制器三个核心模块。
(1) 模型(Model):是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。
(2) 视图(View):是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是 用户看到并与之交互的界面。视图向用户显示相关的数据,并能接收用户的输入数据,但是它并不 进行任何实际的业务处理。
(3) 控制器(Controller):是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。
![图片[1]-软考高级-系统架构设计师案例分析一本通【含精华知识点】-IT谷](http://itgu.com/wp-content/uploads/2025/05/13f3910d99964104a5d23bcf41a61a23.png)
MVC分层有助于管理复杂的应用程序,因为可以在一个时间内专门关注一个方面。例如,可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。MVC分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。
MVC可以将业务处理与显示分离,将应用分为控制器、模型和视图,增加了应用的可拓展性、 强壮性及灵活性。基于MVC的优点,目前比较先进的Web应用框架都是基于MVC设计模式的。
2.1.4J2EE架构
四层结构:
●客户层组件:J2EE应用程序可以是基于Web方式的,也可以是基于传统方式的、静态的HTML(标准通用标记语言下的一个应用)页面和Applets(客户层组件)。
●Web层组件:J2EE Web层组件可以是JSP页面或Servlet。
●业务层组件:业务层代码的逻辑用来满足特定领域的业务逻辑处理。
●信息系统层:企业信息系统层处理企业信息系统软件包括企业基础建设系统,例如企业资源计划(ERP)、大型机事务处理、数据库系统和其它的遗留信息系统。例如,J2EE应用组件可能为了数据库连接需要访问企业信息系统。
EJB是JavaEE服务器端组件模型,设计目标与核心应用是部署分布式应用程序。简单来说就是把已经编写好的程序(即:类)打包放在服务器上执行。凭借java跨平台的优势,用EJB 技术部署的分布式系统可以不限于特定的平台。
EJB中有三种企业级的bean:会话(session)beans,实体(entity)beans,和消息驱动(message-driven)beans。会话bean表示与客户端程序的临时交互。当客户端程序执行完后,会话bean和相关数据就会消失。相反,实体bean表示数据库的表中一行永久的记录。当客户端程序中止或服务器关闭时,就会有潜在的服务保证实体 bean的数据得以保存。消息驱动bean结合了会话 bean和JMS的消息监听器的特性,允许一个业务层组件异步接收JMS消息。
JSP+Servlet+JavaBean+DAO
JSP:用于显示、收集数据的部分。 作为MVC中的视图V 。
Servlet:作为业务逻辑层,用于处理复杂的业务逻辑,如验证数据、实例化JavaBean、调用DAO连接数据库等。作为MVC中的控制器C。在其中会调用Service方法处理服务。
JavaBean:用于数据的封装,方便将查询结果在Servlet与JSP页面之间进行传递等。DAO:用于连接数据库及进行数据库的操作如:查询、删除、更改等。
DAO与JavaBean合在一起为MVC中的模型M。
基本流程:JSP发一个数据到Servlet,Servlet收到后做下解析再根据数据调用相应的Service服务,Service如果有要调用数据库就通过DAO跟数据库交互,使用JavaBean完成封装,返回结果给Servlet,Servlet再返回给JSP。
2.1.5面向服务的架构SOA
SOA是一种设计理念,其中包含多个服务,服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行,服务之间通过网络进行调用。
![图片[2]-软考高级-系统架构设计师案例分析一本通【含精华知识点】-IT谷](http://itgu.com/wp-content/uploads/2025/05/19f13cdd-fa7a-418c-a855-e172a4e76cdb-1024x529.png)
2.1.6企业服务总线ESB
简单来说是一根管道,用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务,ESB做了消息的转化、解释以及路由的工作,以此来让不同的服务互联互通。
![图片[3]-软考高级-系统架构设计师案例分析一本通【含精华知识点】-IT谷](http://itgu.com/wp-content/uploads/2025/05/1d94514eaa0462f24422bbf0982e2172-1024x410.jpg)
ESB的特点:
(1)SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种服务进行连接与整合;
(2)描述服务的元数据和服务注册管理;
(3)在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一些模式如同步模式、异步模式等;
(4)发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。
ESB的主要功能:
①服务位置透明性;
②传输协议转换;
③消息格式转换;
④消息路由;
⑤消息增强;
⑥安全性;
⑦监控与管理。
2.2软件系统设计
选做题,几乎每年必考1题,但是不会涉及大范围的系统分析与设计原理,而是偏向于软件设计与建模的范围,主要考查UML中的图、关系的识别;设计模式识别;数据流图、E-R图等;信息 安全相关技术;项目管理-进度管理-关键路径。答案基本都在题目描述里,从题目描述抽象总结出问题答案。本题考查比较简单,一般可以拿到20分。
2.2.1数据流图 (DFD)
数据流图中的基本图形元素包括数据流、加工、数据存储和外部实体。
●数据流:数据的流向。在DFD中,数据流的流向可以有以下几种:从一个加工流向另一个加工;从加工流向数据存储(写);从数据存储流向加工(读);从外部实体流向加工(输入);从加工流向外部实体(输出)。数据流必须与加工有关。除了流向数据存储或从数据存储流出的数据流不必命名外,每个数据流都必须有一个明确的名字。
●加工:描述了输入数据流到输出数据流之间的变换,也就是输入数据流经过什么处理后变 成了输出数据流。一个加工可以有多个输入数据流和多个输出数据流,但至少有一个输入数据流和一个输出数据流。“黑 洞”:加工有输入但没输出。“奇迹”:加工没输入但有输出;“灰洞”:加工输入不足以产生输出。
●数据存储:用来存储数据。DFD中的数据存储在具体实现时可以用文件系统实现,也可以用数据库系统实现。数据存储的存储介质可以是磁盘、磁带或其他存储介质。
●外部实体:外部实体是指存在于软件系统之外的人员或组织,它指出系统所需数据的发源地和系统所产生的数据的归宿地。例如,对于一个考务处理系统而言,考生向系统提供报名单(输入数据 流),所以考生是考务处理系统的一个数据发源地;而考务处理系统要将考试成绩的统计分析表(输出 数据流)传递给考试中心,所以考试中心是该系统的一个数据归宿地。
![图片[4]-软考高级-系统架构设计师案例分析一本通【含精华知识点】-IT谷](http://itgu.com/wp-content/uploads/2025/05/4146605d-12ce-4838-977c-04fe6f18d22a-1024x376.jpg)
数据流图的主要考点:
- 补充外部实体
外部实体就是与信息系统进行交互的实体,可以是人员、组织或外部系统。外部实体会与信息系统进行交互,反应在数据流图中就是一个个事件流,依据事件的名称结合题目说明就可以轻易得出答案。(根据外部实体与信息系统之间的数据流得到外部实体,仅看上下文数据流图就可以) - 补充数据存储
数据存储出现在0层数据流图中,反应系统内部数据的存储,可以直接根据数据流图中数据存储的输入数据流和输出数据流判断该数据存储的名字(一般为输入数据流名+表/信息表/文件即可)。快速定位数据存储:找从加工流向数据存储的加工所在的功能描述。 - 补充加工
一般情况下,数据流图中的加工名称与信息系统的功能标题一一对应。
详细分析题目说明,掌握数据平衡原则。
数据流图的设计原则:
- 数据平衡原则
(1)父图与子图平衡
父图与子图:如果某图(记为A)中的某一个加工分解成一张子图(记为B),则称A是B的父图,B 是A的子图。父图与子图平衡:是指任何一张DFD子图边界上的输入/输出数据流必须与其父图中对应加工的输入/输出数据流保持一致。
(2)每张图的图内平衡
对于图内的每一个加工,要求既要有输入数据流,也要有输出数据流,避免出现黑洞、奇迹、灰洞。根据这一原则,可以对每个输入进行判断,是否有相应的输出,反之亦然,就可以知道是否缺少某条数据流,从而进行相应的补充。 - 数据流相关原则
在DFD中,数据流的流向可以有以下几种:从一个加工流向另一个加工;从加工流向数据存储(写);从数据存储流向加工(读);从外部实体流向加工(输入);从加工流向外部实体(输出)。 数据流必须与加工有关。除了流向数据存储或从数据存储流出的数据流不必命名外,每个数据流都必须有一个明确的名字。
外部实体与外部实体之间不存在数据流;外部实体与数据存储之间不存在数据流;数据存储与 数据存储之间不存在数据流。 - 加工相关原则
对于每个加工,必须既有输入数据流,又有输出数据流。
对同一个加工来说,输入数据流和输出数据流名称不能相同(但类型要匹配),即使它们的组成成分相同。
数据字典 (DD):
- 相关概念
数据字典:就是为数据流图中的每个数据流、文件、加工,以及组成数据流或文件的数据项做出说明。
符号 | 含义 | 举例及说明 |
---|---|---|
= | 被定义为 | |
+ | 与 | x = a + b,表示 x 由 a 和 b 组成 |
[…|…] | 或 | x = [a|b],表示 x 由 a 或 b 组成 |
{…} | 重复 | x = {a},表示 x 由 0 个或多个 a 组成 |
m{…}n 或 {…}nm | 重复 | x = 2{a}5 或 x = {a}52,表示 x 中最少出现 2 次 a,最多出现 5 次 a。5、2 为重复出现的上、下限 |
(…) | 可选 | x = (a) 表示 a 可在 x 中出现,也可不出现 |
“…” | 基本数据元素 | x = “a”,表示 x 是取值为字符 a 的数据元素 |
. . | 连接符 | x = 1. .9,表示 x 可取 1~9 中的任意值 |
- 数据字典的内容
数据字典的4类条目:数据流、数据项、数据存储、基本加工。 - 加工逻辑描述(加工规格说明)
在数据流图的分解中,位于层次树最低层的加工也称为基本加工或原子加工,每一个基本加工都需要进一步说明,这称为加工规格说明。
在编写基本加工的规格说明时,主要目的是表达“做什么”而不是“怎么做”。
常用的加工逻辑描述方法(加工规格说明)有结构化语言、判定表(决策表)和判定树(决策树)三种 。
2.2.2E-R图
E-R模型,就是实体-联系模型,用来描述现实世界的概念模型(接近于人的思维方式,容易理解),其中有三个主要的概念:实体、联系和属性。
1.实体
用矩形表示,每个实体由一组属性表示,包括候选键、主键、外键。实体集是指具有相同属性的实体集合。
候选键:能唯一地标识一行元组的属性集。
主键:从候选键中选一个作为主键。
外键:在另一个关系模式中充当主键的属性。
2.联系
用菱形表示,实体集之间的对应关系称为联系,分为一对一(1:1)、一 对多(1:n 或 1:* )、多对多(m:n 或 : )。
①一对一 联系(1:1)。实体集A中的一个实体最多只与实体集B中的一个实体相联系,反之亦然 。
②一对多联系(1:n 或 1:*)。实体集A中的一个实体可与实体集B中的多个实体相联系。
③多对多联系(m:n或 *:* )。实体集A中的多个实体可与实体集B中的多个实体相联系。多对多的联系会产生一个新的关系模式,此关系模式的属性由联系的两个实体的主键以及自己的特有属性所组成。
1:1:一个学校只有一名校长,而每位校长只在一个学校工作。
1:n 或 1:*:一个学校有很多学生,而每个学生只在一个学校上课。
m:n 或 *:*:一名学生可以选修多门课程,而一门课程也可以由多名学生选修。
![图片[5]-软考高级-系统架构设计师案例分析一本通【含精华知识点】-IT谷](http://itgu.com/wp-content/uploads/2025/05/4b0fe94097474f13a95b8c15475588bc-1024x704.png)
3.属性
用椭圆表示,是实体某方面的特性。 E-R模型中的属性分为:
①简单和复合属性:简单属性是原子的、不可再分的,复合属性可以划分为多个子属性,如通信地址 。
②单值和多值属性:对于一个特定的实体都只有一个单独的值(单值属性)。例如,对于一个特定的员工,只对应一个员工号、员工姓名。而员工可能有0个、1个或多个亲属,那么员工的亲属姓名可能有多个,这样的属性称为多值属性。
③NULL属性:某个属性没有值或属性值未知时,使用NULL值,表示无意义或不知道。
④派生属性:派生属性可以从其他属性得来。例如,职工实体集中有“参加工作时间”和“工作年限”属性,那么“工作年限”的值可以由当前时间和参加工作时间得到。“工作年限”就是一个派生属性。
弱实体集:一个实体的存在必须以另一个实体为前提,这类实体称为弱实体集。例如:职工的家属必须以职工在职为前提,依赖于职工。
4.实体-联系方法
构件 | 说明 |
矩形 | 表示实体集 |
双边矩形 | 表示弱实体集 |
菱形 | 表示联系集 |
双边菱形 | 表示弱实体集对应的标识性联系 |
椭圆 | 表示属性 |
线段 | 将属性与相关的实体集连接,或将实体集与联系集相连 |
双椭圆 | 表示多值属性 |
虚椭圆 | 表示派生属性 |
双线 | 表示一个实体全部参与到联系集中 |
2.2.3UML
UML中有四种关系:依赖、关联、泛化和实现,如下图所示
![图片[6]-软考高级-系统架构设计师案例分析一本通【含精华知识点】-IT谷](http://itgu.com/wp-content/uploads/2025/05/QQ20250507-200145.png)
主要考查用例图、类图、顺序图、活动图、状态图。
2 以上提供的代码或者素材均为作者提供和网友推荐收集整理而来,仅供学习和研究使用;
3 若作商业用途,请联系原作者授权,若本站侵犯了您的权益请 联系站长 进行删除处理;
暂无评论内容