系统分析与设计 笔记整理2.docx
- 文档编号:3248185
- 上传时间:2022-11-21
- 格式:DOCX
- 页数:26
- 大小:4.76MB
系统分析与设计 笔记整理2.docx
《系统分析与设计 笔记整理2.docx》由会员分享,可在线阅读,更多相关《系统分析与设计 笔记整理2.docx(26页珍藏版)》请在冰豆网上搜索。
系统分析与设计笔记整理2
系统分析与设计笔记整理
第二部分系统分析任务
第4章开始分析:
调查系统需求
4.1更详细的分析阶段
4.1.2定义系统需求
逻辑模型:
规划阶段,能够很详细地展示系统需要完成哪些功能,而不依赖于任何技术的模型。
物理模型:
设计阶段,表明系统将如何真正实现的模型。
相关细节包括:
4.1.3需求的优先级划分
4.1.4发现原型及可行性
构建原型(发现原型)的主要目的是为了更好地理解用户的需求。
原型的构建不为实现所有的功能,而是用来检验商业需求某种实现方法的可行性。
构建原型,可简化分析员对新的商务处理过程的调查工作。
原型有助于用户发现一些以前从未考虑过的问题,可以使他们(包括分析人员在内)跳出原来的思维模式。
4.1.5产生和评估候选方案
4.1.6和管理部门一起复查各种建议
分析阶段的活动
关键问题
收集信息
我们是否已经拥有了全部的信息来定义系统所必须完成的工作
定义系统需求
我们需要系统做什么
需求的优先级划分
系统要完成的最重要的事是什么
构建可行性的发现原型
我们可以证明这种技术能够实现我们想让它完成的那些功能吗?
我们是否已经构建出一些原型可以使用户完全理解新系统的潜在功能
产生、评估候选方案
创建系统的最好方案是什么
和管理部门一起复查各种建议
我们是否应该继续、设计和实现我们提出的系统
4.3系统需求
系统需求:
是新系统必须完成的功能及其局限性,系统所提供功能的详细定义;
功能需求:
是系统必须完成的活动,也就是系统将要投入的业务应用,描述系统必须完成的活动或过程的一种系统需求;
非功能需求:
是这个系统的固有特征,它不同于系统必须完成或支持的行为,包括以下部分:
1、技术需求:
是一种系统需求,描述了与组织的环境、硬件和软件相关的操作特征;
2、性能需求:
是一种系统需求,描述了与工作方法相关的操作特征,比如生产能力和响应时间;
3、可用性需求:
是一种系统需求,描述了与用户相关的操作特征,比如用户界面、工作流程、在线帮助及文档;
4、可靠性需求:
是一种系统需求,描述了系统的可靠性,比如服务损耗、不正当处理,以及错误检测和恢复;
5、安全需求:
是一种系统需求,描述了用户对特定功能的访问以及访问的文件。
4.4系统相关者——系统需求的来源
4.4.1用户
1、业务用户:
使用系统处理公司的日常事务的人;
2、信息用户:
是需要从系统中获得现有信息的人;
3、管理用户:
负责使公司高效的完成每天的日常事务;
4、主管用户:
把系统和其他系统连接起来,从而使得系统可以向他们提供业务发展趋势和方向等方面的战略信息;
5、外部用户:
客户可以通过系统互联网直接访问系统。
4.4.2客户投资相关者
客户:
给项目提供资金的人或团体。
用户与客户的区别:
用户:
长期接触;
客户:
一次性接触;
4.4.3技术人员
尽管技术人员并不是真正的用户群,但他们是许多技术需求的来源,包括建立和维护公司计算机环境的人。
4.5信息收集技术
4.5.1明确主要问题(不是方法)
主题
对用户来说的问题
商业处理过程是什么样的
你要干什么
商业过程应该怎样完成
为完成它,需要哪些步骤
需求什么样的信息
你要使用哪些信息?
你要使用什么样的表单或报告
4.5.2复查现有报表、表格和过程描述
外部信息源:
公司外部,即业界的专业公司和其他一些公司。
内部信息源:
现有的商业文档和过程描述。
获得对过程最初理解的一个好方法,新系统分析员对现有系统的初步复查将是他们很快跟上开发速度,识别出在面谈中也许不会提及的商业规则。
4.5.3主持与用户的面谈和讨论
1.准备面谈;2.主持面谈;3.面谈的后续工作;4.面谈时应注意
4.5.4观察并记录商业过程
1.观察
2.使用活动图来进行记录
⑴工作流
Ø处理商业事务的一系列步骤。
Ø在工作流建模中很少采用单一的方法,通常采用流程图、数据流图和活动图。
Ø数据流图可以很好地在工作流中捕获各种数据,但它们不能表示控制流。
Ø流程图和活动图是专门用来代表处理步骤中的控制流的,但它们不能表示数据流。
⑵活动图
Ø一种工作流图,用来描述用户的活动以及这些活动的顺序。
①同步条:
活动图中的一种符号,用来分解或合并顺序路径。
②活动图矩形区:
活动图中的矩形区域,它代表着单个实体所完成的活动
⑶创建活动图准则
Ø使用决策符来表示一个“或/或者”的情况,只能选择其中的一条路径,不能同时选择两条。
Ø对并行的路径使用同步条,在这种情况下,两条路径同时得以执行。
4.5.5建立原型
1.原型:
一个规模更大的系统的最初可运转模型。
2.实体模型:
最终产品的一个样例,这个样例只能进行观察而不能实际执行。
3.有效原型的特性:
可操作性:
原型应该是一个能运转的模型,重点是可运行性。
集中性:
为测试一个具体概念或者验证一种方法,一个原型应该集中于单一的目标。
额外的执行能力,不是具体目标的一部分,应该被排除在外。
快速性:
需要一些诸如CASE这样的工具以便快速地建立和更改原型。
4.5.6分发和收集调查表4.5.7主持联合应用程序设计会议4.5.8研究供应商的解决方案
第5章系统需求建模
5.1模型和建模
5.1.2模型的类型
1、数学模型:
描述系统技术方面的一系列公式;
2、描述模型:
藐视系统某些方面的叙述性的备忘录、报表或列表;
3、图形模型:
图表和系统某些方面的示意性表示。
5.2事件、活动和用例
5.2.2事件的类型
1、外部事件:
系统之外发生的时间,通常都是由外部实体或动作参与者触发的;
2、临时事件:
由于到达某一时刻所发生的事件;
3、状态事件:
当系统背部发生了需要处理的情况时所引发的事件。
5.2.5关注每个事件和由此产生的用例
事件表:
一个用例列表,该表以各个事件为行,以各个事件的关键信息为列。
5.4实体-联系图
5.4.1ERD概念的实例
传统系统开发方法(结构化技术和信息工程技术)把重点集中在新系统的数据存储需求上。
包括:
数据实体、数据实体的属性,以及它们之间的关系。
使用实体-联系图(ERD)定义数据存储需求的模型。
一个简单的ERD图:
带有扩展属性的ERD图:
大学课程注册ERD(含有多对多关系):
①在ERD图中,每个学生某门课的成绩该存放在什么地方呢?
这是非常重要的数据。
尽管模型显示了一个学生选修了哪一课程项,但是模型中却没有存储成绩。
②解决方法:
增加一个数据实体,该实体表示学生和课程项之间的关系,把它称为关联实体。
成绩作为关联实体的属性。
5.5类图
5.5.2有关对象类的更复杂的问题
1、概括/具体层次图
继承:
允许子类共享其父类所具有的的特征的概念;
2、整体-局部层次图
聚合:
对象及其各个部分之间的一种整体-局部关系;
合成:
对象及其与它不可分割的各部分之间的一种整体-局部关系。
5.5.3设计类图符号
1、抽象类:
一种不能被实例化(即不嫩创建对象)的类,仅为了使其子类能够继承它的属性、方法及关联;
2、具体类:
能被实例化的类(即可以创建对象)。
(如图:
账户类是一个抽象类,客户类、储蓄账户、支票账户都是具体类。
)
3、关联类:
(如图:
课程注册是一个关联类。
)
4、域模型:
一个没有方法的类图,并且是作为需求模型被创建的。
5.5.4落基山运动用品商店实例的域模型类图
第6章需求的传统描述方法
6.1用传统的观点和面向对象的观点看待活动/用例
传统方法和面向对象方法的区别:
1、当一个事件发生时所发生的事情不同;
2、系统建模和实现方法不同。
传统方法把系统看做一个处理的集合体,一些由人完成,另一些由计算机完成。
面向对象方法把系统看成是一个相互影响的对象(事物)的集合。
6.2数据流图
数据流图(DFD)是一种图形化的系统模型,在一幅图中展示信息系统的主要需求:
输入、输出、处理和数据存储,用处理、外部实体、数据流及数据存储来表示系统需求的图表;
DFD的符号:
当使用传统观方法时,确定用例然后用数据流通片段为每一个用例细节建模,下图结合了事件表的ERD和DFD:
6.2.1数据流图和抽象水平
DFD的特征:
抽象、概括;
抽象水平:
把系统分解成一个逐渐细化的分层集合的建模技术。
1、关联图:
在单个处理符号中该做系统内所有处理活动的DFD;
关联图(顶层图):
在单个处理符号中概括系统内所有处理活动的DFD。
2、DFD片段:
用一个单一处理符号表示系统响应一个事件的DFD;
3、事件分割的系统模型
事件分割的系统模型或0层图:
一个为系统需求建立模型的DFD,建模过程中对应于系统或子系统中每个事件使用单个处理。
0层图:
表示工具,它对整个系统或子系统进行比关联图更加详细的汇总。
分析员避免设计0层图的原因:
①信息内容与DFD片段的集合重复。
②图表常常复杂而不实用,特别是对于需要响应许多事件的大系统而言。
冗余性和复杂性是分析员无论何时都要尽可能避免的两个DFD特征。
6.2.4评估DFD质量
DFD建模中常见的错误类型:
基于处理的错误:
①处理的名称一般为动宾结构,不能只是一个动词(“增加”→“增加学生”、“计算”→“计算分数”);
②一个处理至少应有一个输入和一个输出。
若只有输入而没有输出(称为“黑洞”)或只有输出而没有输入(称为“奇迹”)都是不正确的:
黑洞:
带有输入数据的且不用其来产生输出数据的处理或数据存储;
奇迹:
带有没有任何产生来源弄数据元素的一个处理货数据存储;
③在进行处理时依据仅有的输入无法导出输出数据,这说明可能缺少输入数据或处理分解有误;
④流入处理的数据应与流出处理的数据不相同;若相同,则有可能表明该处理没有存在的价值(流入“处理订单”的信息为“订单”,流出的信息为“订单”→“客户订单”、“已处理的订单”)。
基于数据流的错误:
①数据流表明处理过程之间数据的传递关系,而非控制和时间先后次序关系。
(“更正错误的学生信息”→“错误的学生信息”或“更正后的学生信息”);
②高层数据流与相应的底层数据流内容不一致;
③数据流不能直接连接两个外部实体、两个数据存储,以及数据存储与外部实体,数据流的一端至少应为处理。
1、最小化复杂度
人们在对复杂的信息处理上是有局限性的,当太多的信息同时出现时,人们把这种现象叫做信息超量。
信息超量;当太多的信息同时呈现给一个人时所发生的一种难以理解的情况;
分析员要在任何一个DFD中避免信息超量可以遵循以下两条DFD构造规则:
(1)7±2规则:
一种限制模型中组成元素个数或元素之间的连接数不超过9的模型设计规则;
Ø单个DFD中不应有超过7±2个处理;
Ø单个DFD不应超过7±2个数据流进出一个处理、数据存储和数据元素。
Ø规则是一般的准则,不是不可违反的。
Ø打破这些规则的DFD虽仍可读,但易发生潜在问题。
(2)接口最小化:
一种通过限制模型中各个元素之间的连接数来达到简单的目的的模型设计原则;
2、保证数据流一致性
三个经常发生且容易判别的一致性错误:
一个处理和它的处理分解在数据流内容中有差别;
有数据流出却没有相应的数据流入;
有数据流入却没有相应的数据流出。
平衡:
进出处理的数据流与进出处理分解DFD的数据流在数据内容上保持一致的状态;
黑洞:
带有输入数据的且不用其来产生输出数据的处理或数据存储;
奇迹:
带有没有任何产生来源弄数据元素的一个处理货数据存储;
6
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统分析与设计 笔记整理2 系统分析 设计 笔记 整理