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

前言

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

背记内容

FAST开发方法

FAST开发方法在系统分析中包括了初始研究、问题分析、需求分析和决策分析等四个阶段，
一，FAST开发在系统 在分析初步研究阶段的主要任务： 1、列出问题和机会 2、协商项目的初步范围 3、评估项目价值 4、计划项目进度表和预算 5、汇报项目计划
二，FAST开发在系统 在问题分析阶段的主要任务： 1、研究问题领域 2、分析问题和机会 3、分析业务过程 4、制定系统改进目标 5、修改项目计划 6、汇报调查结果和建议
三，FAST开发在系统 在需求分析阶段的主要任务： 1、定义需求 2、排列需求的优先次序 3、修改项目计划 4、交流需求陈述
四，FAST开发在系统 在决策分析阶段的主要任务： 1、确定候选方案 2、分析候选方案 3、比较候选方案 4、修改项目计划 5、推荐一种系统

信息系统项目开发的可行性

一般包括了可能性、效益性和必要性三个方面，三者相辅相成，缺一不可。
（1）可能性包括了技术、物资、资金和人员支持的可行性；
（2）效益性包括了实施项目所能带来的经济效益和社会效益；
（3）必要性则比较复杂，包括社会环境、领导意愿、人员素质、认知水平等诸方面的因素。

信息系统项目进行可行性研究内容的四方面：
技术可行性分析、经济可行性分析、运行环境可行性分析以及其他方面的可行性分析等。其中运行环境是制约信息系统在用户单位发挥效益的关键。
1,技术可行性分析需考虑的因素：进行项目开发的风险；人力资源的有效性；技术能力的可能性；物资(产品)的可用性。
2,经济可行性分析包括：支出分析、收益分析、投资回报分析以及敏感性分析等。
3,运行环境可行性分析，需要从用户单位(企业)的管理体制、管理方法、规章制度、工作习惯、人员素质(甚至包括人员的心理承受能力、接受新知识和技能的积极性等)、数据资源积累、硬件(包含系统软件)平台等多方面进行评估，以确定软件系统在交付以后，是否能够在用户单位顺利运行。
4,其他方面的可行性分析，如法律可行性、社会可行性等方面的可行性分析。

这里常考的还有软件系统的可行性，内容基本是类似的。
软件系统的可行性分析：
(1)经济可行性。主要评估项目的建设成本、运行成本和项目建成后可能的经济收益。
(2)技术可行性。研究的对象是信息系统需要实现的功能和性能，以及技术能力约束。
(3）法律可行性。具有比较广泛的内容，它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。
(4）用户使用可行性。从信息系统用户的角度来评估系统的可行性，包括企业的行政管理和工作制度、使用人员的素质和培训要求等。

设计类

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

常见的类关系包括：

(1）关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关 系，而不表示两个类之间的关系。其余的关系涉及类元自身的描述，而不是它们的实例。
（2）依赖关系。两个类A和B，如果B的变化可能会引起A的变化，则称类A依赖于类B。依赖可以由各种原因引起，例如，一个类向另一个类 发送消息、一个类是另一个类的数据成员、一个类是另一个类的某个操作参数等。
（3）泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关 系，也就是说，子类继承了父类，而父类则是子类的泛化。
（4）继承关系。本质上就是泛化关系。继承是在某个类的层次关联中不同的类共享属性和方法的一种机制。父类与子类的关系是一般与特殊 的关系，一个父类可以有多个子类，这些子类都是父类的特例。
（5）聚合关系。表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。例如， 汽车和车轮就是聚合关系，车子坏了，车轮还可以用；车轮坏了，可以再换一个。
（6）组合关系。表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命 周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。例如，一个公司包含多个部门，它们之间的关系就是组合关系。公 司一旦倒闭，也就无所谓部门了。
（7）实现关系。实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个 接口，而每个类分别实现接口中的操作。

组合和继承关系对比

1,封装性：
组合：不破坏封装性，整体类与局部类之间松耦合，相对独立。
继承：破坏封装性，子类与父类紧耦合，子类缺独立性。
2,动态组合：
组合：支持动态组合。
继承：不支持动态组合。
3,创建对象：
组合：创建整体类时，需要创建所有局部类的对象。
继承：创建子类对象时，不需要创建父类对象。

主题数据库

主题数据库的设计要求：

(1)应设计得尽可能的稳定，使能在较长时间内为企业的信息资源提供稳定的服务。
（2）要求主题数据库的逻辑结构独立于当前的计算机硬件和软件的物理实现过程，这样能保持在技术不断进步的情况下，主题数据库的逻辑结构仍然有 效。

主题数据库具有以下基本特征：

(1)面向业务主题。主题数据库是面向业务主题的数据组织存储。
（2）信息共享。主题数据库是对各个应用系统“自建自用”的数据库的否定，强调建立各个应用系统“共建共用”的共享数据库。不同的应用系统统一调用主题 数据库。
（3）一次一处输入系统。主题数据库要求调研分析企业各经营管理层次上的数据源，强调数据的就地采集，就地处理、使用和存储，以及必要的传输、汇 总和集中存储。同一数据必须一次、一处进入系统，保证其准确性、及时性和完整性，但可以多次、多处使用。
（4）由基本表组成。主题数据库是由多个达到基本表规范（满足3NF）要求的数据实体构成的。

SOA （Service-Oriented Architecture)架构

从软件的基本原理定义，可以认为SOA是一个组件模型。它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口就是采用中立的方式进行定义的，它独立于服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

在SOA的架构中，继承了来自对象和构件设计的各种原则。例如封装和自我包含等。那些保证服务的灵活性和松耦合性和复用能力的设计原则，对SOA架构来说同样是非常重要的。

服务有常见的设计原则如下：

（1）明确定义的接口
（2）自包含和模块化
（3）粗粒度
（4）松耦合
（5）互操作性、兼容和策略声明
REST（Representational State Transfer）表述状态转移，是一种只用HTTP和XML进行Web通信的技术，可以降低开发的复杂度，提高系统的可伸缩性。它的简单性和缺少严格配置的文件的特性，使它与SOAP很好的隔离开来，REST从根本上来说只支持几个操作（POST，GET，PUT 和 DELETE），这些操作适用于所有的消息。

REST设计概念和准则：

（1）网络上的所有事物都被抽象为资源
（2）每个资源对应一个唯一的资源标识
（3）通过通用的连接件接口对资源进行操作
（4）对资源的操作不会改变资源标识
（5）所有的操作都是无状态的

云数据库

云数据库是指被优化或部署到一个虚拟计算环境中的数据库，可以实现按需付费、按需扩展、高可用性以及存储整合等优势。根据数据库类型一般分为关系 型数据库和非关系型数据库（NoSQL数据库）。
云数据库的特性有：实例创建快速、支持只读实例、读写分离、故障自动切换、数据备份、Binlog备份、SQL审计、访问白名单、监控与消息通知等。

三层架构的优势

1，良好的复用性，只要接口不变可用在其它处；
2，可维护性好；
3，可扩展性好，支持递增设计；
4，经过合理分层，能让系统整体耦合性降低，达到解耦的效果；
5，可把相同逻辑与抽象级别的内容放在同一层次。