信息系统分析与设计复习.docx
《信息系统分析与设计复习.docx》由会员分享，可在线阅读，更多相关《信息系统分析与设计复习.docx（56页珍藏版）》请在冰豆网上搜索。
信息系统分析与设计复习
第四章-信息系统建设概论
1、信息系统的生命周期，各个时期的任务和对应的文档。
2、开发过程模型——瀑布模型、原型模型、螺旋模型、喷泉模型、增量模型的特点、适用场合。
1、瀑布模型
Ø强调阶段的划分和阶段严格的顺序。
Ø各阶段工作任务明确，要求文档完备性。
Ø是一种严格线性的按阶段顺序的、逐步细化的开发模式，消除了软件开发的随意性。
1）特点：
1 简单易用，容易理解。
2 开发的进程一个顺着一个，没有反馈过程，需要严密控制。
3 一个新的项目不适合这种模型。
4 用户直到项目结束才能看到质量如何。
5 不允许或者严格限制变更。
2）适用场合：
适用于一些需求已明确并且变化较少的信息系统。
2、原型模型
快速建立起来的可以在计算机上运行的程序，通常选取信息系统中某个关键功能作为原型。
1）特点：
1 用户积极参与。
2 原型的开发没有严密的阶段性。
3 短期获得测试版本，降低风险。
2）适用场合：
1 需求含糊，用户不能标识出详细的输入、处理和输出需求。
2 设计方案不明确，开发人员不能确定算法的有效性、操作系统的适应性或人机交互的有效性。
3、螺旋模型
把软件开发过程定义成不断上升的螺旋周期，每个周期划分为计划、风险分析、实施和评价四个方面。
沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。
1）特点：
1 风险驱动，在生命周期早期就开始确定项目中存在的风险。
2 需要开发人员具有相当丰富的风险评估经验和专门知识。
3 要求用户参与阶段评价，对用户要求较高。
2）适用场合：
1 单位内部开发的大规模软件项目。
2 风险是项目的主要制约因素。
3 可能会发生重大变更。
4 采用新技术。
4、喷泉模型
喷泉模型以面向对象的软件开发方法为基础，以用户需求作为喷泉模型的源泉，属于面向对象的软件过程模型。
1）特点：
1 各阶段相互重叠，它反映了软件过程并行性的特点。
2 体现认识事物的往返过程。
3 强调增量开发，整个过程是一个迭代的逐步提炼的过程。
4 开发活动之间的无间隙性和循环迭代性。
5 适用于面向对象的开发过程。
6 强调无明显的活动阶段划分。
2）适用场合：
主要用于面向对象技术的软件开发项目，它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性，喷泉模型使开发过程具有迭代性和无间隙性。
5、增量模型
融合了瀑布模型的基本成分和原型的迭代特征。
采用随着日程时间的进展而交错的线性序列。
（搭积木的方式，如按子系统划分增量）
1）特点：
1 以功能递增的方式进行软件开发。
2 能较快地产生可操作的系统。
3 在每一步递增中，都可以把用户/开发者的经验结合到不断求精的产品中。
4 可改善测试效果和降低软件开发总成本。
2）适用场合：
1 项目开始，明确了需求的大部分，但是需求可能会发生变化。
2 对于市场和用户把握不是很准，需要逐步了解。
3 对于有庞大和复杂功能的系统进行功能改进，本身就需要一步一步实施的。
三、原型法的基本思想。
在投入大量的人力、物力之前，在限定的时间内，用最经济的方法构造一个系统原型，使用户尽早看到系统的概貌，在系统原型的实际运行中与用户一起发现问题，提出修改意见，不断完善原型，使它逐步满足用户要求。
第六章-结构化系统分析
一、会画数据流程图。
【例1】假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。
对于每个需要再次定货的零件应该列出下述数据；零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。
零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。
当某种零件的库存数量少于库存量临界值时就应该再次定货。
2、结构化系统分析中数据字典的作用。
1、分层数据流图只是表达了系统的“分解”，为了完整地描述这个系统，还需借助“数据字典”和“小说明”对图中的每个数据和加工给出解释。
2、对数据流图中包含的所有元素的定义的集合构成了数据词典。
词典中可有以下六种类型的条目：
1 数据项（最小组成单位）
2 数据结构
3 数据流
4 数据存储
5 加工
6 外部实体
3、由数据元素组成数据信息的方式有顺序、选择和重复三种基本类型。
可以使用这三种类型的任意组合定义数据字典中的任何条目。
例子：
报名单＝姓名＋单位名＋年龄＋性别＋课程名
常用符号：
＝、＋、［｜］、｛｝、（）、
4、
Ø通常仅重点描述最底层的处理过程。
Ø简单的处理可在数据字典中说明。
Ø复杂的处理逻辑可以借助于“加工逻辑说明（小说明）“单独列在另一张卡片上，附在对应加工条目卡片后。
第七章-结构化系统设计
1、结构化系统设计中模块划分的度量标准。
1、为了衡量模块的相对独立性，提出了模块间的耦合与模块的内聚两个标准。
1 耦合：
模块和模块之间的联系程度。
2 内聚：
模块内部各元素之间的联系程度。
2、设计目标：
模块内的联系越紧越好（内聚强）。
模块间的联系越少越好（耦合弱）。
2、熟悉模块结构图、H图（层次图）的画法，了解IPO图的用途；会识别数据流图的种类，能够将不同种类的数据流图映射成模块结构图。
1、模块结构图的画法
结构图（StructuredChart）描述系统的模块结构及模块间的联系
1）结构图中的主要成分有：
模块：
用长方形表示。
调用：
从一个模块指向另一模块的箭头表示前一个模块调用后一个模块。
有循环调用和条件调用。
数据：
用带圆圈的小箭头表示从一个模块传递给另一模块的数据（有实义）。
控制信息：
带涂黑圆圈的小箭头表示一个模块传送给另一模块的控制信息。
2）画法：
结构图无严格的模块调用顺序，但一般习惯从左至右。
因为约定遵从从上向下的调用，调用关系也可以不使用箭头，而直接使用直线。
模块间传递的信息如果出现在数据字典中，则视为数据，否则为控制信息。
2、H图（层次图）的画法
通常使用层次图描绘软件的层次结构。
在层次图中一个矩形框代表一个模块。
框间的连线表示调用关系（位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块）。
3、IPO图的用途
层次图（H图）只说明了软件系统由哪些模块组成及其控制层次结构，并未说明模块间的信息传递及模块内部的处理。
对一些重要模块还必须根据数据流图、数据字典及H图绘制具体的IPO图。
4、数据流图的种类
1）变换型（Transform）结构。
2）事务型（Transaction）结构。
5、
数据流图模块结构图
1）变换分析：
用来描述输入、处理、输出数据流。
1 确定DFD中的变换中心、逻辑输入和逻辑输出。
2 设计软件结构的顶层和第一层——变换结构。
--第一级分解
A.变换中心确定以后，就相当于决定了主模块的位置，这就是软件结构的顶
层；其功能是主要完成所有模块的控制，它的名称是系统名称，以体现完成整
个系统的功能。
B.顶层确定之后，设计软件结构的第一层。
第一层至少要有输入、输出和变
换三种功能的模块。
C.为每个逻辑输入设计一个输入模块，其功能为向顶层模块提供相应的数据。
D.为每个逻辑输出设计一个输出模块，其功能为输出顶层模块的信息。
E.为变换中心设计一个变换模块，它的功能是将逻辑输入变换为逻辑输出。
3 设计中、下层模块——对第一层的输入、变换及输出模块自顶向下、逐层分解。
--第二级分解
A.输入模块的下属模块的设计（每个输入模块可以设计成两个下属模块：
一个接收，一个转换。
用类似的方法一直分解下去，直到物理输入端。
）
B.输出模块的下属模块的设计（每个输出模块可以设计成两个下属模块：
一个转换，一个发送，一直到物理输出端。
）
C.变换模块的下属模块的设计（根据DFD变换中心的组成情况，按照模块独立性的原则来组织其结构，一般对DFD中每个基本加工建立一个功能模块。
）
4 设计优化——以上步骤设计出的软件结构仅仅是初始结构，还必须根据设计准则对初始结构精细和改进。
A.输入部分的求精：
对每个物理输入设置专门模块，以体现系统的外部接口；其他逻辑输入模块并非真正输入，当它与转换数据的模块都很简单时，可将它们合并成一个。
B.输出部分的求精：
为每个物理输出设置专门模块，其他逻辑输出模块并非真正输出，当它与转换数据的模块都很简单时，可将它们合并成一个模块；同时注意把相同或类似的物理输出模块合并在一起，以降低耦合度。
C.变换部分的求精：
根据设计准则，对模块进行合并或调整。
5 总之，软件结构的求精，带有很大的经验性。
往往形成DFD中的加工与结构图中的模块之间是一对一的映射关系，然后再修改。
但对于一个实际问题，可能把DFD中的两个甚至多个加工组成一个模块，也可能把DFD中的一个加工扩展为两个或更多个模块，根据具体情况要灵活掌握设计方法，以求设计出由高内聚和低耦合的模块所组成的、具有良好特性的软件结构。
2）事务分析：
用来描述多种事务类型的处理。
虽然在任何情况下都可以使用变换分析方法设计软件结构，但是在数据流具有明显的事务特点时，也就是有一个明显的“发射中心”（事务中心）时，还是以采用事务分析方法为宜。
1 综合DFD的映射
一个大型系统的DFD中，既有变换流，又有事务流，属于综合的数据流图，其软件结构设计方法如下：
A.确定DFD整体上的类型。
事务型通常用于对高层数据流图的变换，其优点是把一个大而复杂的系统分解成若干较小的简单的子系统。
变换型通常用于对较低层数据流图的转换。
变换型具有顺序处理的特点，而事务型具有平行分别处理的特点，所以两种类型的DFD导出的软件结构有所不同。
只要从DFD整体的、主要功能处理分析其特点，就可区分出该DFD整体类型。
B.标出局部的DFD范围，确定其类型。
C.按整体和局部的DFD特征,设计出软件结构。
2 分层DFD的映射
A.对于一个复杂问题的数据流图，往往是分层的。
B.分层的数据流图映射成软件结构图也应该是分层的，这样便于设计，也便于修改。
C.由于数据流图的顶层图反映的是系统与外部环境的界面，所以系统的物理输入与物理输出都在顶层或0层图，相应的软件结构图的物理输入与输出部分应放在主图中，便于同DFD的顶层图对照检查。
D.分层DFD的映射方法分类：
Ø主图是变换型，子图是事务型
Ø主图是事务型，子图是变换型
3、模块的内聚是什么，内聚的类型及其含义、紧密程度。
1、模块的内聚
Ø模块的内聚反映模块内部联系的紧密程度。
Ø原则：
一个模块只需要做好一件事情，不要过分关心其他任务。
Ø高内聚性的好处是可以提高程序的可靠性。
2、内聚的类型及其含义、紧密程度
1）偶然内聚：
当同一个子程序中的操作之间无任何联系时，为偶然内聚性，也叫作“无内聚性”。
（比如只是为了将程序中某几处凑巧相同的一些语句组合起来形成的一个模块。
）---低
2）逻辑内聚：
将几个逻辑上相似的功能放在一个模块中。
（比如常见的出错处理模块，工作模块发现错误后，调用错误处理模块，将错误号作为控制参数传入，然后出错处理模块根据不同的错误号执行相应的操作。
）---低
3）时间内聚：
将在有限时间单元内处理的成分组合为同一模块。
（可视化程序设计中在窗口打开时初始化窗口中的控件内容，如列表框的项目、文本框或单选钮的缺省取值；还比如：
C++的构造函数、析构函数。
）---低
4）
步骤内聚：
模块中的操作是按某一特定过程进行的。
（步骤内聚在时间内聚的基础上增加了次序的约束。
）
---中
5）通信内聚：
当模块内的成分引用共同的数据，而不存在其他联系时，称为通信内聚。
---中
6）顺序内聚：
模块中某个成分的输出是另一成分的输入。
（比如显示期末成绩通知。
）---高
Ø是步骤内聚和通信内聚的结合。
Ø顺序内聚有较强的内聚性，但仍然不是最高的内聚类型
7）功能内聚：
一个模块包括并且仅仅包括为完成一个具体任务所需要的所有成分。
---高
Ø功能内聚性是最强也是最好的一种内聚。
Ø仅用一个动宾词组能明确指出这个模块的所有功能。
4、结构化设计中软件结构的深度、宽度、扇入数和扇出数的概念。
1、深度：
表示软件结构中从顶层模块到最底层模块的层数；
2、宽度：
表示控制的总分布；
3、扇出数：
指一个模块直接控制下属的模块个数；
4、扇入数：
指一个模块的直接上属模块个数。
Ø平均扇出系数最好是3~5；
Ø一个模块扇出的上限不超过7；
Ø高层模块高扇出，最低层模块高扇入；
Ø一个好的软件结构的形态准则是：
上面尖、中间宽、下面小，像清真寺的塔。
5、结构化程序设计使用的三种基本逻辑结构。
（顺序结构，选择结构，循环结构）
（当循环）（直到循环）
（a）顺序（b）循环
（c）选择（d）条件
6、结构化模块详细设计的建模工具，会使用这些工具绘制模块内部的处理过程，复习7.6节的思考题。
1、程序流程图（程序框图）
2、盒图（NS图）
在NS图中，每个处理步骤用一个盒子表示。
盒子可以嵌套。
盒子只能从上头进入，从下头走出，除此之外别无其他出入。
3、程序设计语言（PDL）
是用来描述模块内部具体算法的非正式的比较灵活的语言，或称类语言、伪码。
✧思考题
下面是用类C语言描述的一段程序，试分别程序流程图和N-S图表示。
while（p）
{
A;
do
{B;}
while（！
Q）;
}
对应的N-S图如下：
程序流程图如下：
7、结构化分析和设计的建模工具。
第八章-面向对象分析
1、什么是消息。
1、消息是指向对象发出的服务请求（对象间的交互信息）。
1 一个对象向另一个对象发消息请求某项服务，接收消息的对象响应该消息，激发所要求的服务操作，并把操作结果返回给请求服务的对象。
2 一个消息应当包含以下信息：
消息名、接收消息对象的标识、服务类型、输入信息、回答消息。
3 要求服务的消息具有特定的格式和输入参数，这种规定也称为消息协定。
4 因为两个对象是各自独立运行的，对象A如果在某个时刻需要对象B的某项服务，就可以依据消息协议向对象B发送一个消息，对象A在消息发送后可以等待返回消息，也可以不要求回答就执行其他的事务。
2、消息的实现形式：
在面向对象设计和实现中，消息的一般形式就是函数调用【方法调用】。
2、UML的特点。
1 统一了面向对象方法的表示。
2 表示能力强大，可用于各种软件系统建模，以及其他系统建模，如商业系统。
3 与开发过程无关。
4 允许扩展。
5 本身不设计特点语言的语法及规则，但可对应到各种OOP语言框架。
3、RUP软件开发过程四个阶段的任务及工作焦点。
---RUP的
二维结构
1、初始阶段：
确定所设立的项目是否可行。
1 明确说明项目规模，了解环境以及最重要的需求和约束。
2 划分主要子系统，给出系统的体系结构概貌。
3 考虑时间、经费、人员、技术、项目计划和效益等因素。
4 分析项目执行的风险。
Ø工作焦点：
需求和分析工作流。
2、细化阶段：
识别出大多数用例（80%）。
建立健全的体系结构基础，编制项目计划，细化风险评估。
1 用例模型需要完成80%。
2 创建软件结构的描述性文档。
3 创建可执行的系统原型。
4 细化风险列表。
5 创建整个项目的开发计划。
Ø工作焦点：
分析和设计工作流。
3、构造阶段：
识别出最后剩余的用例。
每一次迭代开发都对用例进行分析、设计、编码、测试和集成过程，最终得到满足项目需求的产品。
1 优化资源，使开发成本降到最低。
2 尽快达到质量要求。
3 尽快完成有用的版本。
4 完成所有功能的分析、开发和测试。
5 迭代式、递增地开发随时可以发布的产品。
6 确定准备好软件系统的外部环境。
Ø工作焦点：
实现工作流。
4、交付阶段：
完成最后的软件产品和产品验收测试，并编制用户文档，进行用户培训等工作。
将完整的系统部署到用户所处的环境，确保软件对最终用户是可用的。
1 按用户的要求验证新系统。
2 替换旧的系统。
3 对用户和维护人员进行培训。
4 开始调整工作，例如性能或可用性的增强。
5 与用户达成共识，部署基线与评估标准一致。
Ø工作焦点：
测试和部署工作流。
4、UML中四种关系的表示和区别。
Ø类之间的联系方式：
1、继承/泛化（generalization）：
类之间的关系是指对象分类的层次关系，继承关系对于类中的所有对象都成立，而不特指某个具体对象。
2、实现（realization）：
即描述和实现。
一个接口可以提供某些操作的描述，另一些类需要具体来完成这些操作，即对接口进行实现。
Ø对象关系则是存在于具体对象实例之间的联系：
3、关联（association）：
表达对象与对象的静态联系，是一种长期关系，比如整体和部分关系。
4、依赖（dependency）：
表达对象与对象的动态联系（运行时），是一种短期关系。
五、复习用例图、用例规格说明，会画用例图，书写用例规格说明，会识别用例间的关系，复习课件8.5节的例子、课堂练习。
1、用例建模的内容
1）获取原始需求
2）开发一个可以理解的需求
1 识别参与者。
●参与者是系统之外与系统进行交互的任何事物。
从三个方面来识别：
A.使用系统的个人
Ø谁负责提供、使用或删除信息？
Ø谁将使用某项功能？
B.系统所连接的外部硬件。
例如：
控制建筑物中温度的通风系统不断地从传感器获取温度信息，传感器就是一个参与者。
C.与该系统进行通信的其他信息系统。
例如为自动柜员机系统建模时，中央银行系统就是它的一个参与者。
信用卡系统是销售系统中的一个参与者。
●只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者。
●有时，数据的来源和去向，即提供数据的人员不一定会执行系统功能。
Eg1.新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者。
Eg2.如果学生直接通过Web方式提交个人信息，则认为学生是参与者。
●主要参与者（primaryactor）是从系统中直接获得可度量价值的用户。
●次要参与者（secondaryactor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用
●用例分析的重点是要找到主要参与者。
比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？
图书管理人员是直接操作者，他们的需求和变化对于用例的影响最大。
因此，图书管理员是主要参与者。
●在UML中，参与者使用小人符号。
●在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。
比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。
2
识别用例。
●用例就是功能性需求。
●每个用例至少和一个参与者相关，用例名称要体现参与者希望系统提供的功能。
相关的参与者应是该功能的执行者或者是该功能的直接交互者。
●不能混淆用例和用例所包含的步骤。
比如“借出图书”功能要经过验证读者信息、检查超出可借数量、保存借书记录、修改图书状态等步骤。
●在系统中这些步骤通常不作为单独的功能提供给参与者使用，它们只是一个用例所包含的事件流，或者是用例的子功能。
●当针对整个业务领域建模时，需要使用业务用例。
比如图书馆系统有一项重要工作就是“整理书架”，图书都要放回到固定的位置上。
●信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，即有信息处理的那部分功能。
需要使用系统用例。
3 构建用例图。
3）详细、完整地描述需求
书写用例规格说明。
4）重构用例模型
1 识别用例间的关系。
2 对用例进行组织和分包。
✧用例举例1：
a.客户提出申请要求贷款，申请中包括期限、金额、用途和本人基本情况。
银行收到申请后，置于“申请档案”中，以申请号标识。
b.某公司内部工作岗位的提供：
不论何时，只要一有职位空缺，该地区的人力资源部领导就会通知该地区的所有员工并给其他地区的HR领导发送消息，邀请员工们提出申请。
然后，其他地区HR领导将招聘信息贴在公告板上。
所有对此感兴趣的员工都可以将申请发送到职位空缺的地区的HR领导那里。
✧用例举例2：
在门诊挂号处只能挂当天的号，挂出的号可以退。
病人拿到挂号单后，到相应的科室进行就诊。
医生根据挂号的顺序号，依次给病人看病开处方。
病人拿处方去收款处交费，并拿到发票。
病人拿已经收费的处方去药房拿药。
✧图书馆系统的用例图:
图书馆系统实行开架阅览，并为读者提供了客户端，读者可以查询到馆藏书目和本人在借的图书。
对目前已借出无馆藏的图书可以进行预定，也可以取消预定，这项功能也可以通过互联网实现。
图书管理员通过系统记录图书的出借和归还，以及进行书目的维护、读者信息和借书卡的维护。
2、书写用例规格说明
1 用例名称
2 主要参与者/次要参与者
3 简要描述
4 前置条件
5 后置条件
6 主事件流（主要成功场景/基本路径）
7 备选事件流（扩展路径/替代流程/异常事件流）
8 特殊要求/非功能性需求
9 发生频率
1）用例的前置条件和后置条件
1 前置条件（pre-condition）：
表述在系统允许用例开始以前，系统应确保为真的条件。
这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。
Ø如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到系统中。
1 后置条件（guarantee）：
或称为成功保证。
表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。
Ø一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。
某些用例可能没有前置条件或后置条件，比如“查询书目”用例可以没有后置条件。
2）用例与场景
1 用例描述的是一组动作序列，在复杂的系统中，用例细节可能存在多种不同的情节，称为变体。
比如：
购买商品的用例中收款可以是现金支付、信用卡支付或支票支付。
针对每一种情况有不同的场景，一个场景就是一个具体的故事现场，重现一个参与者如何具体完成用例。
2 主成功场景：
故事的主线，用例通常得到成功执行的典型场景。
3 扩展场景：
失败场景，或因为一些特别条件而出现行为分支的步骤（包括失败和成功）。
3）用例与事件流
1 用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。
2 事件流的描述包括：
a.用例何时开始和结束.
b.用例何时与参与者交互.
c.参与者与系统之间有什么对象或信息被交换.
d.该行为的主事件流和备选事件流.
4）用例的简要描述
用例名：
购买商品
参与者：
出纳员
简要描述：
顾客带着所要购买的商品来到收款处。
收款员记录下商品信息并收款。
付款完成后，顾客带着所购买的商品和收据离开。
5
升级会员 