搜索
第6章结构化系统分析本章计划学时：8学时本章主要内容•系统分析的任务•数据流图•数据字典•表达处理的工具•实体关系图•系统说明书6.1系统分析的任务•系统分析员与用户在一起充分理解用户的要求，并把双方的理解用书面文档——系统分析说明书表达出来。•分析本质上就是一个发现过程，分析期间推动活动的关键词就是发现和理解。系统分析的困难•系统分析是研制信息系统最重要的阶段，也是最困难的阶段。•困难主要来自三个方面：–问题空间的理解–人与人之间的通讯–环境的不断变化系统分析员要成为业务专家•才能与用户交流顺畅，充分理解用户的要求。•才能确保系统满足了业务需求，甚至用更好的方法来解决业务需求。•在用户中建立可信度，用户才可能接受你的建议。其他要求:系统分析员应有较强的系统观点，较好的逻辑分析能力，能够从复杂的事物中抽象出系统模型。他还应具备较好的口头和书面表达能力，较强的组织能力，善于与人共事。6.1.2系统需求分析的重要任务是理解和表达需求•需求有哪些种类？•如何寻找需求？•如何表述需求？需求的来源—系统相关者•系统需求的主要来源是系统的各种系统相关者，他们是对系统成功感兴趣的所有人（与系统有关系的所有人，也称涉众stakeholder）。•系统分析中获得需求的首要步骤就是确定各类系统相关者。系统相关者•业务用户•信息用户•管理用户•主管用户•外部用户•客户•技术人员系统需求的种类系统需求是新系统必须完成的功能或其局限性。•系统需求一般分为两类：–功能性需求–技术性需求功能性需求•功能需求是系统必须完成的活动或过程，也就是系统将要涉及的商业应用。•功能需求是根据业务过程和业务规则确定的，有些容易获取，有些则是隐含的，需要去发现。技术性需求•技术需求也称非功能性需求，是和公司的环境、硬件和软件有关的所有可操作目标。•例如：系统必须能支持100个并发用户；保存订单的时间不能超过0.5秒等等，涉及系统性能、可靠性、安全性等质量特性。•通常是一些技术目标。如何表述需求•自然语言–不需要任何准备–但既要保证精确无二义性，又要保证叙述不至于晦涩难懂，是困难的（随意性、误会）•模型–模型是人们对复杂问题的一种抽象或者对实物的一种简单实现或规划蓝图。–例如：飞机模型，建筑模型，数学模型等等。模型的作用信息系统模型的作用：–建立模型的过程可以使得分析员更深入地了解和定义信息系统的需求，并发现问题–对复杂问题进行简化–有助于回忆需求的细节–有助于同开发小组的其他成员交流–有助于同客户交流–为以后的维护升级提供了文档信息系统的模型在信息系统分析中有三类常用的图示化模型：1.功能模型•利用数据流图分层描述系统的功能和数据的处理流程•利用数据字典辅助解释数据流图中的每个元素2.数据模型•利用实体关系图描述系统中的数据实体及其关系3.对象模型•利用类图描述对象、对象之间的联系。和数据实体不同，对象在数据之外增加了行为特性如何着手建模构建模型首先需要识别用户的需求，识别需求一般可以从两个方面着手：•识别系统中的事件(Events)建立过程模型（数据流图，DFD）•识别系统中的事物(Things)建立数据模型（实体关系图，ER）1、事件与系统需求事件——在特定时间、特定地点发生的，能够描述出来并值得保存的的事情。系统的所有处理过程都是由事件驱动的，所以将事件列表并进行分析，对于定义系统需求是十分有意义的。事件的类型我们可以从以下类型来寻找事件：–外部事件(externalevent)–时间事件(temporalevent)–状态事件(stateevent)外部事件在系统之外发生，通常是由外部的人或组织激发的事件，这些人或组织是数据的提供者和接收者。–比如图书馆流通系统中的读者外部事件能够导出系统需要处理的关键事务寻找外部事件•首先要确定外部实体，然后再分析。•外部实体需要一个事务处理–比如读者借书•外部实体需要系统提供某些信息–比如读者查阅书目•某些数据改变了，系统需要更新它们–比如书籍的位置改变•管理过程需要某些信息–比如制订新的采购计划需要流通统计情况时间事件当系统时间到达某一刻时发生的事件，这些事件通常要求系统能定时自动地完成某些输出或处理。–如：图书馆流通系统中的按月发布逾期催还名单。–如：每天晚上12：00定时转换归档医疗图像。注意命名时必须包含所要完成的处理和规定期限状态事件系统内部的变化触发系统对某个处理的需要，这种情况的发生称为状态事件–比如：销售系统中库存数一旦低于控制点就产生订货单状态事件一般是外部事件的结果，它的发生是不定时的识别事件的规则•区分事件与具体响应过程–事件响应中的一系列交互过程是完整具体的实现，而不是独立的一个事件。例如：拿信用卡交费•跟踪关键业务的整个生命周期来发现事件–跟踪读者实现从图书馆借书的全部过程•暂时忽略技术性依赖事件和系统控制事件–如管理员登录系统，修改口令，每天的备份事件名称触发点事件源活动响应结果事件目的地客户希望检查产品可订量产品的查询请求客户查询产品的可用量产品可用量详细情况客户客户建立一个订单新订单客户建立新订单实时连接订单确认订单细节交易信息信用卡处理系统客户发装部门银行客户改变或作废订单修改订单的请求客户更新订单修改确认订单修改细节交易信息客户发装部门银行客户和管理层检查订单状态订单状态的查询请求客户或管理部门查询订单的状态订单状态的详细情况客户或管理部门为订单发货订单发货通知发装部记录订单的执行客户退货订单退货通知客户建立退货记录退货确认交易信息客户银行网上订单系统的事件表事件名称触发点事件源活动响应结果事件目的地未来客户需要目录产品目录的查询请求未来客户提供产品目录信息产品目录未来客户客户更新基本信息客户信息修改通知客户更新客户基本信息市场部给客户发送促销材料促销产品细节市场部分发促销单促销单客户和未来客户调整产品目录产品目录更新细节销售部更新产品目录每日交易汇总每天末产生交易汇总报告交易汇总报告财务部每周订单汇总每周末产生订单汇总报告订单汇总报告管理部门网上订单系统的事件表2、事物与系统需求•事物——系统需要处理或保存的对象。–如客户，订单，产品等。•对信息系统中事物的理解和建模是定义系统需求的另外一个重要方面。事物的类型事物的类型：•实在有形：书籍、产品、文档•角色身份：医生、读者、顾客•组织单位：小组、部门•设备：打印机、传感器、鼠标•事件：借阅、订货、销售、罚款•场所：零售店、仓库事物之间的关系•事物间的很多关系对于研究系统也非常重要。•关系：指某些事物间自然发生的联系。–例如：学生和图书，学生可以借阅图书。–例如：一个客户可以发出订单。•对每一个事物分析和它相关的事物，找出关系。事物之间关系的基数•关系的基数：指一个事物关联另外一个事物的数量（一对一，一对多，多对多或者一个具体的数量—4个）。–如：学生和图书，一个学生可以预约多本图书，每本图书可能被多个学生预约。–如：一个客户可以发出多个订单，一个订单只能是一个客户的。事物的属性•属性：有关事物的一条特征信息。–例如：客户的姓名、年龄、电话等。•标识符：能唯一区分事物的属性。–例如：发货单号，职工编号。•复合属性：指包含了许多相关属性的属性。–例如：姓名可能包含姓和名，日期包含年月日。6.2数据流图系统分析阶段：•使用数据流图DFD来建立系统需求的过程模型。（结构化系统分析的方法）•系统分析采用ER图来建立系统的数据模型。结构化分析的思想•数据流图DFD采用一系列分层次的数据流图来描述系统。•DFD的每一个层次都代表了系统的一个抽象水平。高层次DFD中的处理可以进一步分解成低层次、更详细的DFD。分层的数据流图•纵观顶层P1P2P3P4P41P42第一层第二层6.2.1数据流图的基本成分•数据流图用来记录系统中的数据和数据在特定的过程中的流动，即数据如何被采集、处理、保存和使用的（围绕信息系统的功能）外部实体数据处理p1数据存储数据流外部实体指系统以外又与系统有联系的人或事物。它表达了该系统数据的外部来源和去处。例如：人、组织、外部系统等等。•外部实体是数据的来源（谁提供了最初始的数据？）•外部实体是数据的去处（数据对谁有价值？）读者图书管理员馆长读者图书管理员外部实体处理指对数据的逻辑处理功能，也就是对数据的变换功能。别名：功能、处理过程，数据加工标识部分（层次化的功能编号）功能描述部分（动宾词组）功能执行的角色（人，部门，计算机程序），通常可省略P2.2.1识别读者身份图书管理员数据处理数据流是指处理功能的输入或输出（箭头表示数据流向）。•例如：数据，订单，查询要求等经理编制财务报表合格订单编辑订货单计算应收款数据流数据存储表示某种数据保存后的逻辑统称。不是指保存数据的物理地点或物理介质。•流入数据存储的数据流•将处理后的数据写入或修改到数据存储中•流出数据存储的数据流•从数据存储中查询获取数据，不改变原来的数据销售量D2产品销售帐计算销售量累计销售量单价计算销售总额商品编号#_D2产品D5职工D2产品数据存储数据流图中的图形元素有不同的画法，本书使用Gane-Sarson画法储户业务处理帐目存折存取要求其他图形表示事件表中能找到数据流图中出现的一些元素：•活动对应于处理框•事件源和事件目标对应于外部实体•触发点和响应结果是与外部实体相连的数据流•只有数据存储在事件响应表中没有对应的描述一个事件的DFD事件和DFD•事件列表中的每一个事件都可以画出一个DFD图（需要额外添加数据存储元素）•事件列表可以作为画数据流图的一个基础和检验列表–事件对应DFD模型的中间层–事件可以继续分解绘制其具体的处理过程（向下细化）–系统中事件较多时，应进行分组（向上抽象）单个DFD的组合•事件之间有一定的联系，一般通过数据存储建立关联完整的数据流图根据事件表重新组织，绘制完整的DFD模型：•按照事件表，对每一个事件建立一个DFD片段图。•把所有的DFD片段进行分组，归纳为大的处理逻辑，形成上一层DFD（复杂系统层次更多）。•将属于一组内的DFD片段放在一张图上，形成事件层的DFD图。•对每个事件的数据处理进一步分解为下一层DFD（复杂系统层次更多）。完整的数据流图•真正进行结构化系统建模过程中，应该采用自顶向下的分解方法，事件表只是寻找需求的辅助工具（启发）•建模是一个从具体到抽象，又从抽象到具体的过程，需要反复多次6.2.2数据流图的画法•下面我们以高等学校学籍管理系统为例说明画数据流图的方法•如果不能直接建模，可以考虑以下事件：–新生登记–登记期末成绩–期末成绩分析–登记补考成绩–补考后成绩分析–评定奖学金–处理退学、留级、修学、复学–发成绩单……顶层新生名单学籍表学籍管理系统招生办教委用人单位报表毕业生登记表学籍管理系统顶层DFD第一层第二层——“成绩管理”框的展开第三层——“处理期末成绩”框的展开第三层——“分析期末成绩”框的展开第三层——“分析补考成绩”框的展开6.2.3画数据流图的注意事项要注意以下几点：1.关于层次的划分2.语法的正确性3.可读性4.确定系统边界层次的划分应遵守：（1）展开的层次与管理层次一致，也可以划分得更细。（2）同一张图上的所有处理过程应该处于同一个抽象层次上（抽象粒度一致）。（3）一个处理框经过展开，一般以分解为4～10处理框为宜（最好5～9个）（4）最下层的处理过程用几句话，或者用几张判定表，或一张简单的HIPO图能表达清楚1、合理的层次划分一个处理框经过展开，一般以分解为4～10处理框为宜。•如果一次分解后仅有两个处理框，为减少数据流图的层次，可以考虑将它们直接并入上一层中•若一个处理框分解后还是只有一个处理框，则视为无效的分解处理框的合并通常可以从以下几个方面检查数据流图的正确性：（1）数据守恒，或称为输入数据与输出数据匹配①处理有输入就应该有输出②处理有输出就肯定有输入③输入的数据应该全部流出该处理或者要用于产生流出该处理的数据（排除无用数据）④输出的所有数据必须曾经流入过该处理或者是由流入该处理的数据加工产生（保证必要数据）2、正确性检查（2）在一套数据流图中的任何一个数据存储，必定有流入