2022系统分析师案例分析真题背记内容

前言

以下内容仅为个人根据当年系分案例真题问题整理的偏需要记背的考点答案,方便个人背诵和记忆使用。方便文字转语音,所以内容全为纯文字内容,以下内容仅供参考。

背记内容

数据流图、活动图和流程图对比

1.数据流图:
数据流图的特点:通过系统内数据的流动来描述系统功能的-一种方法。强调系统中的数据流动。由:数据流,外部实体,加工,数据存储。
数据流图的适用场景:结构化需求分析,为系统做功能建模。
2.活动图:
活动图的特点:与流程图类似,但可以表现并行执行。活动图的适用场景:面向对象分析与设计建模。
3.流程图:
流程图的特点:能清晰展现业务执行的流程顺序。强调控制流。
流程图的适用场景:结构化需求分析与结构化设计,为系统梳理业务流程。

需求评审的内容:

(1)SRS正确地描述了预期的、满足项目千系人需求的系统行为和特征。
(2) SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
(3)需求是完整的和高质量的。本例中存在需求描述不完整的情况,如:谁向系统请求?输入个人详细信息要输入哪些?选择账户类型,有哪些账户类型供选择?
(4)需求的表示在所有地方都是一致的。
(5)需求为继续进行系统设计、实现和测试提供了足够的基础。
(6 )用例优先级合理度评估。

需求评审的作用:

1、发现二义性需求
2、发现不确定性用户未达成共识的需求
3、发现遗漏的需求
4、为项目干系人在需求问题上达成共识提供支撑
5、降低风险
6、提高软件质量

设计类

识别设计类是面向对象设计过程中的重要环节之一,设计类表达了类的职责,即该类所承担的任务,设计类通常包含以下三种类型:
(1)实体类。实体类映射需求中的每个实体,保存需要存储在永久存储体中的信息,例如,员工信息、请假申请表。
(2)控制类。控制类是用于控制用例工作的类,用于对-一-个或几个用例所特有的控制行为进行建模。例如,提交请假,审批请假。
(3)边界类。边界类用于封装在用例内、外流动的信息或数据流。例如,请假申请页面、请假批准单。

类之间关系

识别类之间的关系是面向对象分析过程中的重要环节之一,常见的类之间关系包括泛化关系、关联关系、聚合关系、组合关系等。

(1)泛化关系。

泛化关系描述了一般事物与该事物中的特殊种类之间的关系,也就是父类与子类之间的关系。继承关系是泛化关系的反关系,也就是说,子类继承了父类,而父类则是子类的泛化。泛化关系实例:员工与部门经理。部门经理也是员工的一种。有点“继承”的味道(用空三角形表示)

(2)关联关系。

关联提供了不同类的对象之间的结构关系,它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系,而不表示两个类之间的关系。其余的关系涉及类元自身的描述,而不是它们的实例。对于关联关系的描述,可以使用关联名称、角色、多重性和导向性来说明。关联关系示例:员工与请假记录之间有关联关系。比如什么1对多的关系,(只要用实线来关联即可)

(3)聚合关系。

聚合关系(Aggregation)是一种特殊的关联关系,所以它继承了关联关系的特质,而且还独有“整体-部分”(Whole-Part)的特质。简言之,聚合关系两端的对象,需具有Whole-Part的关系。是关联关系的特例,是强的关联关系,聚合是整个与个体的关系,即has-a关系,此时整体和部分是可以分离的,他们具有各自的生命周期,部分可以属于多个对象,也可以被多个对象共享;聚合关系示例:基金看板和基金之间是聚合关系。(用空菱形表示)

(4)组合(compostion)。

也是关联关系的一种特例,体现的是一种contain-a关系,比聚合更强,是一种强聚合关系。它同样体现整体与部分的关系,但此时整体与部分是不可分的,整体生命周期的结束也意味着部分生命周期的结束,反之亦然。示例如:大脑和人类。体现在代码层面与关联时一致的,只能从语义来区分。组合与聚合几乎完全相同,唯一区别就是对于组合,“部分”不同脱离“整体”单独存在,其生命周期应该是一致的。(用实心菱形表示)

基于模型的系统工程

基于模型的系统工程(MBSE)是一种形式化的方法,用于支持与复杂系统的开发相关的需求,设计,分析,验证和确认。与以文档为中心的工程,MBSE将模型放在系统设计的中心。MBSE是向以模型为中心的一系列方法转变这一长期趋势的一部分,这些方法被应用于机械、电子和软件等工程领域,以期望取代原来系统工程师们所擅长的以文档为中心的方法,并通过完全融入系统工程过程来影响未来系统工程的实践。

基于文档的设计方法的局限性主要有:
(1)在基于文档的方法中,许多文档是由不同的作者生成的,以从各种利益相关者的观点(例如系统行为,软件,硬件,安全,安全性或其他学科)中捕获系统的设计。不利于利益相关者之间的沟通,容易产生歧义。
(2)开发复杂系统的能力有限,基于文本的设计方案无法进行前期仿真验证。
(3)自然语言容易引入形容词等模糊描述,很难保证准确性

两阶段提交协议2PC

经常用来管理分布式事务。

(1)2PC包含协调者和参与者两类站点,只有协调者才拥有提交或撤销事务的决定权,而其他参与者各自负责在其本地数据库中执行写操作,并向协调者提出撤销或提交事务的意向。
(2)2PC分为两个阶段:表决阶段和执行阶段。
①表决阶段,目的是形成一个共同的决定。协调者给所有参与者发送“准备提交”消息,并进入等待状态,所有参与者给与回复“建议提交”或“建议撤销”。只要有一个结点选择撤销,则整体事务撤销,否则,执行该事务。
②执行阶段,目的是实现这个协调者的决定。根据协调者的指令,参与者或者提交事务,或者撤销事务,并给协调者发送确认消息。

2PC不能解决当前问题。

(1)分布式数据库遵循的是CAP原则,会在一定程度上牺牲一致性。
(2)大多数NoSQL数据库并不支持2PC。
(3)分布式两阶段提交协议2PC一般针对的对象在逻辑上是一个整体,对某一个整体事务需要在多个物理节点上执行时,进行表决和执行,对多个数据库的不同服务并不是很合适。

区块链

区块链的主要特征去中心化和开放性

1、去中心化
区块链采用了分布式计算和存储,不存在中心化的硬件或管理机构,因此使得任意节点的权利和义务都是均等的。
2、开放性
区块链的系统的一个开放性质的,除了交易各方的私有信息被加密外,区块链的数据对所有人公开的。

区块链的全部特征如下:

去中心化:由于使用分布式核算和存储,区块链体系不存在中心化的硬件或管理机构,因此任意节点的权利和义务都是均等的,系统中的数据块由整个系统中具有维护功能的节点来共同维护。

开放性:系统是开放的,除交易各方的私有信息被加密之外,区块链的数据对所有人公开,任何人都可以通过公开的接口查询区块链数据和开发相关应用,因此整个系统信息高度透明。

自治性:区块链采用基于协商一致的规范和协议(如一套公开透明的算法)使得整个系统中的所有节点能够在去信任的环境中自由安全的交换数据,使得对 “人” 的信任换成了对机器的信任,任何人为的干预都不起作用。

信息不可篡改:一旦信息经过验证并添加至区块链,就会永久的存储起来,除非能够同时控制系统中超过 51% 的节点,否则单个节点上对数据库的修改是无效的,因此区块链的数据稳定性和可靠性极高。

匿名性:由于节点之间的交换遵循固定的算法,其数据交互是无须信任的(区块链中的程序规则会自行判断活动是否有效),因此交易对手无须通过公开身份的方式让对方对自己产生信任,对信用的累积非常有帮助。

可靠性:区块链上的数据保存多个副本,任何节点的故障都不会影响数据的可靠性。共识机制使得修改大量区块的成本极高,几乎是不可能的。破坏数据并不符合重要参与者的自身利益,这种实用设计增强了区块链上的数据可靠性

全球流通:区块链资产首先是基于互联网的,只要有互联网的地方,区块链资产就可以进行流通。这里的互联网可以是万维网,也可以使各种局域网,所以区块链资产是全球流通的。只要有互联网,就可以把区块链资产转账,相较于中心化的方式,区块链资产在全球流通的转账手续费非常低,比如比特币早期转账手续费为 0.0001BTC,相对于传统转账来说,区块链资产到账也非常快。一般几分钟到 1 小时就能到账。

数据可信度问题

分布式交易账本、哈希散列函数、公私钥签名、时间戳就是区块链的核心技术,其中分布式交易账本、公私钥签名最适合解决数据信任问题的技术。
分布式交易账本使交易账本在全网不止一份,而是有多份,当有人想篡改账本时,非常难以实现,所以能解决数据可信度问题。
公私钥签名是使用非对称加密机制,做签名,以验证持有人以及防止伪造的效果,这种技术也极难被破解,能验证持有人自然能一定程度解决数据可信度的问题。

三层Web架构

定义

1.表示层 :主要是指 与 用户交互的界面 , 用于接收用户输入的数据和显示处理后用户需要的数据
2.业务逻辑层 :表示层和数据库访问层之间的桥梁 , 实现业务逻辑 , 具体包含:验证、计算、业务规则等等。
3.数据访问层 :与数据库打交道 , 主要实现对数据的增、删、改、查等。

三层架构的特征

1.各司其职
2.高内聚低耦合
高内聚 : 尽可能类的每个成员方法只完成一件事
低耦合 : 减少类内部,一个成员方法调用另一个成员方法
从类角度来看, 高内聚低耦合:减少类内部,对其他类的调用
从功能块来看 , 高内聚低耦合:减少模块之间的交互复杂度
简单来说,就是 解耦 :只做自己功能内的事
任何一层发生变化都不会影响到另外一层!!!

面向接口编程

设计与实现分开
在一个面向对象的系统中,系统的各种功能是由许许多多的不同对象协作完成的。在这种情况下,各个对象内部是如何实现自己的 , 对系统设计人员来讲就不那么重要了;而各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信,大到各模块之间的交互,在系统设计之初都是要着重考虑的,这也是系统设计的主要工作内容。面向接口编程就是指按照这种思想来编程。

自己(huaqian)搜集的资料,算是比较全的了,共享给大家!! 共勉!!考试加油!! 资料1:复习笔记精华版(全90页)可以hold住早上的考试了! 资料2:系统分析师考试大纲 资料3:系统分析师考试试分类精解(2018版) 资料4:系统分析师十年真题(上午+下午真题+答案解析): 2007年下半年 系统分析师 综合知识.docx 2007年下半年 系统分析师 案例分析.docx 2007年下半年 系统分析师 论文.docx 2007年下半年 系统分析师 详细答案.docx 2008年上半年 系统分析师 综合知识.docx 2008年上半年 系统分析师 案例分析.docx 2008年上半年 系统分析师 论文.docx 2008年上半年 系统分析师 详细答案.docx 2008年下半年 系统分析师 综合知识.docx 2008年下半年 系统分析师 案例分析.docx 2008年下半年 系统分析师 论文.docx 2008年下半年 系统分析师 详细答案.docx 2009年上半年 系统分析师 综合知识.docx 2009年上半年 系统分析师 案例分析.docx 2009年上半年 系统分析师 论文.docx 2009年上半年 系统分析师 详细答案.docx 2010年上半年 系统分析师 综合知识.docx 2010年上半年 系统分析师 案例分析.docx 2010年上半年 系统分析师 论文.docx 2010年上半年 系统分析师 详细答案.docx 2011年上半年 系统分析师 综合知识.docx 2011年上半年 系统分析师 案例分析.docx 2011年上半年 系统分析师 论文.docx 2011年上半年 系统分析师 详细答案.docx 2012年上半年 系统分析师 综合知识.docx 2012年上半年 系统分析师 案例分析.docx 2012年上半年 系统分析师 论文.docx 2012年上半年 系统分析师 详细答案.docx 2013年上半年 系统分析师 综合知识.docx 2013年上半年 系统分析师 案例分析.docx 2013年上半年 系统分析师 论文.docx 2013年上半年 系统分析师 详细答案.docx 2014年上半年 系统分析师 综合知识.docx 2014年上半年 系统分析师 案例分析.docx 2014年上半年 系统分析师 论文.docx 2014年上半年 系统分析师 详细答案.docx 2015年上半年 系统分析师 综合知识.docx 2015年上半年 系统分析师 案例分析.docx 2015年上半年 系统分析师 论文.docx 2015年上半年 系统分析师 详细答案.docx 2016年上半年 系统分析师 综合知识.docx 2016年上半年 系统分析师 案例分析.docx 2016年上半年 系统分析师 论文.docx 2016年上半年 系统分析师 详细答案.docx 2017年上半年 系统分析师 综合知识.docx 2017年上半年 系统分析师 案例分析.docx 2017年上半年 系统分析师 论文.docx 2017年上半年 系统分析师 详细答案.docx
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

十幺卜入

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值