系统分析及建模

统都详细地表述出来以后再进行讨论，而习惯于从某个角度整理 出一个从某个侧面观察的问题模型，这就是建模的原则。 ❖ 对于一个系统，基于不同的简化动机（目的）和简化水平（原则）， 可以得到多个模型，这样有助于更深刻和更准确地把握系统的本质。
23
4.6 建模
5、模型评价 利用价值高的模型就是好模型； ▪ 针对特定的建模“动机”和“原则（抽象层次）”，我们通常 会忽略那些与特定抽象层次无关的次要因素，而强调那些具有 广泛影响力的主要因素，这就是在追求模型的使用价值。 ▪ 换言之，内容多的模型未必是好模型，因为价值高的内容有可 能被价值不高的内容淹没了。 ▪ 模型的的好坏，取决于两个因素，即建模的“视角（动机）” 和“抽象层次”，这两个因素决定了模型有没有把握问题的本 质和有没有洽到好处的排除掉干挠视线的次要因素，便于清晰 的认识问题。
5
4.2 系统分析的内容与主要活动
系统分析的基本内容： 系统分析阶段需要对管理信息系统的下列问题进行调研和分析：
（1）确定新系统的目标。 （2）系统的总体结构描述。 （3）子系统功能描述： （4）子系统数据分析： （5）数据输入输出描述： （6）确定技术性能指标，包括可靠性、安全保密性、适用性、可维护性和可移
第 四 章 系 统 分 析 及 建 模
内容简介
❖ 开发周期包括系统分析、系统设计、系统实施等几个重要阶段。 ❖ 本章主要介绍系统分析的相关内容， ❖ 包括：
▪ 系统分析的主要目标和作用； ▪ 系统分析各阶段的主要活动； ▪ 系统分析的方法和工具等； ▪ 最后，给出一个管理信息系统的分析实例。
2
本章内容
13
难题之二
❖ 开发人员与用户之间存在着专业知识的鸿沟。俗话讲，隔行如隔山， 专业知识的壁垒构成了开发人员与用户间的沟通障碍。然而，开发活 动恰恰要求必须由用户来确认系统分析说明的准确性和完整性，必须 确保开发人员完整、准确地理解了用户心目中对新系统的真实要求。 开发人员也必须努力准确理解和表述用户的需求，因此，这个阶段的 活动难度非常大。
现行系统的调 查报告
（审查现行系统 的调查报告）
新系统逻辑方 明确用户信息需求， 用户需求分析，新
4 案的提出
提出新系统的逻辑 系统逻辑模型的建 系统说明书
方案
立（BPR）
审查系统说明书， 若同意，则批准 进入系统设计阶 段
ຫໍສະໝຸດ Baidu
8
4.3 需求分析的重要性
❖ 系统分析的核心任务是用户需求分析。用户需求指的是用户要求新系 统必须满足的所有功能和约束条件，包括用户对功能、性能、可靠性、 安全保密性等方面的要求，以及开发费用、开发周期和可使用资源等 方面的限制，其中功能需求是最基本的。
用户
系统 分析员
系统设计 员\程序员
图4.1 系统分析员是用户与开发人员之间的桥梁
15
4.5 系统分析相关概念
❖ 模型 （1）数学模型（公式）
(2) 描述模型（判定树、结构化英语） （3）图形模型（逻辑模型、物理模型）
16
4.5 系统分析相关概念
❖ 事物 1、 事物及其类型 2、 事物间的关系（1:1、1：n）
22
4.6 建模
4、建模原则 ❖ 在建立模型的过程中，建模者的主观立场或认识问题的角度，被强调
为认知活动的原则，这很重要。 ❖ 建模过程就是简化问题的过程，就是要把某些主要的关键的东西勾勒
出来，把对讨论问题无关紧要的东西暂时略去，以免干扰视线。 ▪ 因此，在讨论一个系统中的某个问题的时候，我们不是把整个系
与计划
划的制订
含计划） （或签协议、订合同）
7
4.2 系统分析的内容与主要活动
活动名称
目标
关键问题
主要成果 （产品）
管理决策
3
现行系统调查
详细调查现行系统 的工作过程，建立 现行系统的逻辑模 型，发现现行系统 存在的主要问题。
现行系统的结构业 务流程和数据的详 细分析，确认存在 的问题（结构化遍 历3W+1H）
植性。 (7) 优化业务处理流程和数据流程，定义经济数学算法和模型。 (8)确定计算机系统配置,计算机网络技术方案。
6
4.2 系统分析的内容与主要活动
活动名称
目标
1
初步调查
明确系统开发 目标和规划
关键问题
主要成果 （产品）
管理决策
是否开发新系统？ 若开发，提出新系统的 目标、规划、主要功能 的初步设想，粗略估计 系统开发所需的资源
❖ 需求分析是管理信息系统开发活动的起点，分析结果能否准确地反映 用户的实际要求，将直接影响到后续各阶段的开发活动，决定着最终 开发出来的系统能否满足用户的需求。这一阶段是系统建设工作中任 务最为繁重、耗费资源最多的一个时期(功能需求、技术需求)。
4
4.1 系统分析的目标
❖ 需求定义必须满足以下几个方面的要求： （1）完备的：所有需求都必须加以正确说明。 （2）一致的：需求之间应该没有逻辑上的矛盾。 （3）非冗余：不应有多余的、含混不清的需求说明。 （4）可理解：参加的各方应能以一种共同的方式来解释和理解需求。 （5）可测试：需求必须能够验证。 （6）可维护：文档的编写应该是可灵活修改和易读的。
❖ 除此之外，系统的边界和结构的不明确性，业务环境的不断变化的特 性，也是系统分析阶段面对的难题。
14
系统分析员的作用
❖ 以上困难的解决往往寄希望于系统分析员。系统分析员是这一阶段的 关键人物，他要充当技术人员与用户间沟通的桥梁。“桥梁”的作用， 对系统分析员的知识面、业务技能等又是一个极大的挑战。
24
4.6 建模
6、模型表述 ❖ 模型是一组具有完整语义的信息，包括两个方面的含义：
▪ 一方面，模型是对现实的简化； ▪ 另一方面，模型反映了认知主体（开发人员）对问题域认识的
视角和抽象层次。不同的视角，表现为各种类型的图 （Diagram）及其包含的元素和关联；不同的抽象层次，表现 为不同类型的视图（View）。两者都是模型不可或缺的要素。 ❖ 尽管说模型是简化的现实，并强调化简价值，但这并不意味着可 以片面地夸大图示信息的作用，好的模型应该是图文并茂，其关 键是可用和易用。
11
4.4 系统分析面临的主要问题
❖ 系统分析活动中，有一些难题是管理信息系统开发项目与生俱来的特 性。
12
难题之一
❖ 需求只能由用户亲自提出来，但用户对计算机系统的不了解，使得他 们无法一次性、完整、准确地讲出所有的需求。实际上，往往是等工 作一段时间，用户对新系统有了一定的认识之后，才会有好的思路和 想法。也有可能是用户心里有想法，但讲不出来。这就需要开发人员 来启发和挖掘需求。
❖ 4.1系统分析的目标 ❖ 4.2系统分析内容和主要活动 ❖ 4.3需求分析的重要性 ❖ 4.4系统分析面临的主要问题 ❖ 4.5系统分析相关概念 ❖ 4.6建模 ❖ 4.7 需求分析说明书的编写
3
4.1 系统分析的目标
❖ 系统分析、系统设计和系统实施构成系统开发周期的三个主要阶段。 系统分析是开发人员和用户共同参与的一项活动。这一阶段的主要任 务是充分挖掘和理解用户对新系统的要求，并将其明确表述成一份书 面资料。这份资料的主要内容就是新系统的逻辑模型，这就是系统分 析说明书，又称用户需求说明书。
25
4.6 建模
7、建模价值 ❖ 建模（Modeling）是捕捉问题本质的过程。为了降低风险和获得高回报，建模活动
普遍应用于各种行业，信息系统（软件）开发更不例外。为了说明建模的价值， Grady Booch曾经给出过一个经典的类比：
▪ 盖一个宠物窝棚、修一个乡间别墅和建一座摩天大楼，三种工作对建筑规划图 纸的依赖程度有质的差异。建立一个简单的系统，模型可有可无；建立一个比 较复杂的系统，模型的必要性增大；建立一个高度复杂的系统，模型则不可缺 少。应用处理简单系统的方法对待复杂系统通常是行不通的，这好比用搭建一 个宠物窝棚的方法来营造一座摩天大厦。
9
4.3 需求分析的重要性
❖ 需求分析阶段的工作质量，对于项目的开发成本有绝对的影响。 费用 1000 修正错误的成本
50
需求
设计
编码 开发测试 应用测试 实际运行
10
经验与教训
❖ 需求定义是否准确、真实，甚至决定项目的成败，必须引起足够的重 视，应有保障需求定义质量的技术手段。如果需求定义不完整、不合 乎逻辑、不贴切或使人易于发生误解，那么后续的开发活动可能就是 在为一个错误的、不合乎逻辑的、不贴切的用户需求定义，设计了一 个好的实现方案，编制了相应的高质量的代码，这样的设计和程序编 码都是徒劳的。不论后续开发工作质量如何，都必然导致项目失败。
20
4.6 建模
2、什么是模型 ❖ 模型并不深奥。
▪ 在你和别人讨论问题时，把你想表达的东西以简化的形式画到纸 上，这就是模型，哪怕是随便勾画了几笔，只要有助于表达问题， 它就是模型了。
❖ 模型可以描述系统的静态结构，也可以描述系统的动态行为；可以描 述系统的宏观面貌，也可以描述系统内的微观交互场景。
❖ 从某个角度看问题，排除不必要的干扰，把问题化简，抓住主要矛盾和事物的本质， 这就是建模的目的。 ▪ 打一个比方，一座大楼在土木设计师眼里可能是一堆钢筋混凝土和表面材质；在 管道设计师眼里可能是一堆管子和接头；在网络工程师眼里可能是一堆网络设备 和布线。不同主体对同一客体的认识结果有赖于各自的视角，即看问题的角度。 这样能更好地集中注意力，从而有效地解决关键问题。
系统开发 建议书
是否同意系统发建议 书？ 若同意，则安排可行 性研究活动。
进一步明确系统 系统开发的技术可行性 可行性研 审定可行性研究报告，
的目标、规划与 研究、经济可行性研究、 究报告
2
可行性研究 功能，提出系统 营运可行性研究，系统
系统开发 （设计）
若同意，则下达系统 开发（设计）任务书
开发的初步方案 开发初步方案与开发计 任务书（
(1) 可选关系 （2）强制关系 3、事物的属性 4、数据实体和对象 （1）结构化方法 （2）面向对象方法
17
4.5 系统分析相关概念
❖ 事件 1、事件及其类型 （1）外部事件 （2）临时事件 （3）状态事件 2、定义事件 （1）区分事件和触发事件的条件以及系统响应 （2）跟踪事物处理的生命周期 （3）暂不考虑技术依赖事件和系统控制 3、实例（图书管理系统）
❖ 建模的意义随着系统复杂程度的增加而越发显著，从起初借助于模型以更好地理解 系统，到后来不得不借助模型来理解系统。人脑对复杂问题的理解能力是有限的， 与模型相应的特定视角和抽象层次是简化复杂问题的有效出发点。
26
4.6 建模
❖ 建模对于复杂软件系统的开发是必要的 ▪ 目前，我们开发的软件，特别是商业软件，通常一开始就很不简单，并且复杂性随着时间 的演进和技术的发展持续上升。一个复杂软件系统的开发必须面对多种未知因素、多个开 发人员、复杂的开发工具和永远不够用的时间。开发人员不可能、更没有必要去了解从问 题到方案的所有细节。他们需要那些基于特定视角的、有助于解决问题的并且是完整的某 一部分信息，即所谓的模型。总之，建模对于复杂软件系统的开发是必要的。
18
4.5 系统分析相关概念
❖ 实体-联系图（ER图） ❖ 类图 （1）概况-具体层次图 （2）整体-局部层次图 （3）类图组成
19
4.6 建模
1、模型作用 ❖ 借助于模型实现对复杂系统的认识，是一种有效手段；
▪ 实际的管理信息系统是一个复杂的系统，我们要开发以计算机处理为基 础的现代管理信息系统，首先就得认识、理解原有的系统或手工业务， 经过反复讨论和修改以后，构造出新的管理信息系统方案。在这一过程 中，模型起着非常关键的作用。
❖ 模型可以帮助我们以化简的形式捕捉现实系统中问题的本质； ❖ 通过模型可以把被讨论的概念可视化，把你心目中的系统实现方案勾勒出来，
把它变成大家能够看得见的东西，便于讨论和修改； ❖ 模型有助于在由“问题”到“方案”的过渡过程中更好的认知、理解和沟通。 ❖ 结论：学习建模是学习软件开发（包括管理信息系统开发）的一项基本技能。
❖ 简单地讲，模型是对现实的简化、或者说，模型是简化的现实； ❖ 模型会先于方案而存在，模型提供了营造方案的蓝图。
21
4.6 建模
3、建模目的 ❖ 建模的目的，是为了认识复杂的问题（或系统）；简化是认识复杂系统的一种有效方
法；而建模是简化问题的有效手段； ❖ “简化”是有目的的进行的
▪ 准确地讲，一个具体的模型是人对现实系统抽象认知的结果，这一结果取决于人 和他观察问题的角度。人是认知活动的主体，他在认识一个事物的时候，往往是 带有主观意志的，即他会从自己的立场或角度来看问题。