信息系统开发方法教程（第5版）

本书在介绍基本概念、开发思想和工作原则的基础上，引入CMM概念介绍信息系统开发过程的管理及内容。从系统的观点出发，站在全局的角度，介绍信息系统的总体规划方法，强调以数据为中心的信息资源规划，并用总体规划的结果指导后续开发工作，从而保证系统良好的整体性。在后续的开发过程中，分阶段介绍了每个阶段的工作内容、工作方法。 

本书系统地介绍信息系统开发中的基本概念、开发思想、基本的工作原则、开发方法及开发过程的管理。本书在介绍基本概念、开发思想和工作原则的基础上,引入CMM概念介绍信息系统开发过程的管理及内容。按照系统的观点,立足全局,介绍信息系统的总体规划方法,强调以数据为中心的信息资源规划,并用总体规划的结果指导后续开发工作,从而保证系统良好的整体性。在后续的开发过程中,分阶段地介绍每个阶段的工作内容、工作方法。在需求分析阶段,以面向管理流程的思想,以图形化文档为主要描述工具,描述、分析和确认信息系统的功能需求;在系统分析阶段,详细介绍如何在总体规划指导下,以需求分析结果为依据构建信息系统的功能模型、数据模型,进而建立支持下一阶段开发的面向对象模型,同时为了减小开发产品与需求之间的偏差,引入黑盒测试方法,在系统分析阶段进行测试数据的设计;在系统设计阶段,以前一阶段所构建的数据模型和面向对象模型为基础,介绍面向对象设计的基本原则、评价标准和基本方法,同时引入白盒测试方法,再进一步开展测试数据的设计。测试数据的设计工作前移体现了测试驱动的思想,利用测试数据可以很好地帮助开发人员理解详细的功能需求并及时发现程序设计中的缺陷;在系统测试及运行维护阶段,系统地介绍各种测试方式、手段、工作原则和工作内容。
本书力求理论与实际的有机结合,用一个教学管理系统案例贯穿整个开发过程,使开发方法具有较强的可操作性,能够有效地指导开发人员构建一个性能良好、实用、可修改、可扩充的信息系统,并为信息资源的开发和利用奠定良好的基础。本书提供与之配套的教学课件,以方便教和学,本书可作为高等院校信息管理与信息系统、计算机应用等专业的本科生教材,也可作为相关管理人员的培训教材,同时也是信息系统开发人员的参考书。

目录
第1章信息系统基本概念1
1.1信息的基本概念1
1.1.1数据与信息1
1.1.2信息的特性2
1.1.3信息的生命阶段4
1.2信息系统的基本概念9
1.2.1系统的概念9
1.2.2信息系统11
1.3信息系统的开发20
1.3.1信息系统开发中常见的问题20
1.3.2系统的方法21
1.3.3系统开发步骤23
1.3.4信息系统开发的指导思想和工作原则27
1.4信息系统开发的组织及项目管理30
1.4.1信息系统开发人员的组织30
1.4.2系统分析员应具有的基本技能32
1.4.3信息系统开发中的文档管理33
1.4.4信息系统开发中的项目管理36
1.5原型法40
1.5.1原型法开发步骤41
1.5.2原型法的使用前提42
1.5.3原型法的人员组织和工作环境44
思考题45
第2章信息系统开发过程管理46
2.1CMM概述46
2.1.1CMM基本概念46
2.1.2CMM框架49
2.1.3CMM管理手段53
2.2信息系统开发过程模型55
2.2.1常用的开发模型56
2.2.2CMM中的开发流程定义59
2.2.3CMM中的开发流程裁剪63
2.3信息系统开发过程中的标准规范68
2.3.1过程文档的标准规范68
2.3.2开发文档的标准规范70
2.3.3程序编制的标准规范71
思考题71
第3章信息系统总体规划72
3.1信息系统总体规划概述72
3.1.1问题的提出72
3.1.2总体规划的时机75
3.1.3总体规划的内容76
3.1.4总体规划的组织77
3.1.5总体规划的步骤79
3.2数据环境81
3.2.1建立数据库的必要性81
3.2.2四类数据环境82
3.2.3主题数据库规划的内容83
3.3总体业务规划84
3.3.1现行系统的调查85
3.3.2职能域87
3.3.3业务过程88
3.3.4业务活动91
3.3.5业务模型的优化95
3.4总体数据规划100
3.4.1主题数据库规划101
3.4.2信息系统总体结构规划102
3.4.3主题数据库的分布规划109
3.4.4主题数据库的可靠性规划112
3.5信息技术规划112
3.5.1关键技术应用规划112
3.5.2应用开发策略规划115
3.5.3数据管理策略117
3.5.4硬件基础设施规划118
3.5.5开发工具的选择策略120
思考题121
第4章业务流程及功能需求分析122
4.1需求调查概述122
4.1.1良好需求的特征122
4.1.2需求调查的步骤及工作产品124
4.1.3需求调查前的准备125
4.2业务流程调查126
4.2.1业务流程图绘制标准126
4.2.2业务流程概要调查127
4.2.3业务流程详细调查129
4.2.4业务流程审查与确认132
4.3功能需求分析与描述规范134
4.3.1自然语言描述面临的问题135
4.3.2结构式语言136
4.3.3判断树139
4.3.4判断表140
4.3.5功能需求描述范例142
4.4情景描述板143
4.4.1情景描述143
4.4.2UI设计基本原则145
思考题152
第5章系统分析建模153
5.1系统分析概述153
5.1.1系统分析任务及步骤153
5.1.2系统分析的工作产品154
5.1.3系统分析的特点156
5.2系统建模157
5.2.1文档规范157
5.2.2详细的功能分析及过程建模161
5.2.3过程模型的审查与确认166
5.2.4用例模型的设计169
5.3功能描述176
5.3.1用例的活动图描述176
5.3.2状态图181
5.3.3用例说明183
5.4数据建模184
5.4.1关系的基本性质及规范化形式184
5.4.2数据分析建立数据模型189
5.4.3信息分类编码设计193
5.5时序分析199
5.5.1时序图制作规范200
5.5.2功能需求的时序描述200
5.5.3时序描述的检验207
5.6类分析模型208
5.6.1系统分析中的常用类及关系208
5.6.2时序图向类分析模型的转换209
5.6.3构建类分析模型211
5.7测试用例的设计216
5.7.1测试用例的设计步骤216
5.7.2黑盒测试方法218
5.7.3流程测试226
思考题229
第6章信息系统设计230
6.1信息系统设计概述230
6.1.1功能设计的基本任务231
6.1.2系统设计评价标准234
6.1.3系统设计的步骤及工作产品238
6.2系统架构设计239
6.2.1系统架构简介239
6.2.2系统架构的选择243
6.3系统界面设计245
6.3.1输入/输出方式245
6.3.2界面静态设计247
6.3.3界面动态设计250
6.4系统功能设计252
6.4.1系统流程对象设计252
6.4.2系统实体对象设计255
6.5数据库物理设计及持久化设计257
6.5.1数据库物理设计257
6.5.2对象的持久化260
6.6程序设计262
6.6.1应用程序的详细设计263
6.6.2面向对象的程序代码设计269
6.6.3测试程序的设计280
6.6.4白盒测试方法281
6.7系统实现285
6.7.1系统配置及设定285
6.7.2系统的部署286
思考题289
第7章系统测试与运行维护290
7.1系统测试概述290
7.1.1测试的基本方法290
7.1.2测试的基本原则292
7.1.3测试内容及测试手段294
7.1.4测试用例设计策略296
7.2人工测试方法296
7.2.1程序审查会296
7.2.2人工运行298
7.2.3静态检验299
7.3单元测试和集成测试299
7.3.1单元测试300
7.3.2集成测试300
7.3.3测试的执行302
7.4高级测试302
7.4.1系统测试302
7.4.2验收测试及安装测试305
7.5测试计划和控制305
7.5.1测试计划305
7.5.2测试完成的标准306
7.6系统切换307
7.6.1系统切换前的准备308
7.6.2系统切换309
7.7系统运行维护310
7.7.1系统运行310
7.7.2系统维护312
7.7.3系统运行的审计与评价314
思考题315
附录A程序代码编写规范示例317
A.1排版317
A.2注释319
A.3命名320
参考文献322

前言
目前信息化已然成为企业经营管理的趋势,也成为人们日常生活、学习、工作的重要组成部分。从技术层面来看,通信技术、遥感和传感技术以及移动终端技术的发展为信息化提供了丰富的数据来源和采集手段,为大数据分析与应用奠定了良好的基础;并行计算的应用则提升了大数据分析和各类信息处理的效率;浏览器/服务器模式使信息系统应用和开发具有了跨平台、跨地域的特点;大容量存储技术、虚拟化资源管理技术打破了实体结构之间的障碍,为海量信息存储提供便利。总之,信息化已经全面渗透到人们生活和工作的方方面面,而信息技术的发展又为信息化实现提供了新手段、新模式,也对信息系统的设计提出了新的要求。
信息技术的发展方式已从过去的技术驱动转变为应用创新与技术驱动相结合的方式。云计算、大数据分析、海量存储、移动智能终端技术的应用无不凸显信息资源的开发与利用的重要作用。信息化与工业化的高度融合使得信息系统的规模越来越大、功能越来越复杂,为了适应需求的变化、适应操作方式的变化、适应信息技术的变化,必须有一套行之有效的方法指导和支持大型复杂信息系统的开发。事实上,为了解决信息化过程中出现的各种问题,人们在信息系统开发方法的研究方面不断探索。在信息系统功能分析与设计方法方面,从面向过程的开发演变为面向对象的开发;在系统功能结构方面,由单层、双层结构演变为多层架构,而这种多层架构又体现在操作页面、功能建模、数据存取等多个角度;在信息的组织与存储方面,在利用成熟和标准化的关系数据库基础上,探讨新型的NoSQL数据库,同时研究构建多维数据库模型;在对开发模型的研究方面,由基于过程的瀑布模型演变为过程模型与以面向对象为主导思想的迭代模型相融合的开发模型,同时引入测试驱动、敏捷式开发等开发思想与方法;在对开发过程的管理方面,由CMM演变为更加灵活、实用的CMMI,并依此管理整个信息系统开发过程。信息系统开发从理论到实践都发生了巨大变化,支持信息系统开发的工具与开发语言也在不断地变化。
信息系统开发方法随信息技术发展的变化，使得编写一本既能够保留经过时间检验而验证有效的传统理论,又能够融合新观点、新方法的信息系统开发教材变得非常困难。本书致力于开发方法的研究,力求与时俱进,在保留和完善既有知识体系的基础上适量增加新的内容,融合新的观点和方法而调整原有的内容。在整个开发过程中坚持“以数据为中心”的观点并注重系统的整体观,自顶向下地进行开发工作。在总体规划中,仍然以业务流程再造思想来构建业务模型,再用主题数据库思想对信息进行整合,以解决“信息孤岛”的问题。在随后的需求分析和系统分析的前期阶段保留了面向过程的思想,从业务流程分析入手寻找信息系统的功能需求和数据存储需求,运用数据库设计的基本理论和信息分类方法指导构建信息系统的多维数据模型,运用面向对象的分析与设计方法构建信息系统的功能结构。多维数据模型能够为信息资源的开发与利用奠定良好的基础,而采用面向对象方法所建立的良好的功能结构能够很好地保证信息系统功能的可修改性、可扩充性、可复用性和可移植性。为减小信息系统功能与需求之间的偏差,本书在系统分析阶段便引入测试驱动的思想,在分析阶段采用黑盒方法进行测试数据的设计,在系统设计阶段采用白盒方法进行测试数据的设计,利用测试数据强化功能需求并对信息系统的功能进行检验。在管理信息系统开发过程方面,继续使用CMM/CMMI进行开发过程的管理和控制。因此,本书面向培养专业技术和管理技能的信息专业人才,适合作为高校信息类、计算机类专业课教材。
本书共分7章,首先介绍信息系统开发的基本概念、基本思想和基本原则,其次介绍信息系统开发过程的管理,最后以信息系统的开发阶段为基础,分章节介绍信息系统总体规划、业务流程及功能需求分析、信息系统分析、信息系统设计、系统测试与运行维护等开发阶段的工作内容、开发方法及相应的工作成果。本书第1～4章内容由陈佳和徐斌共同完成;第5、6章内容由谷锐完成;第7章内容由陈佳完成。书中附带的开发文档、课件由陈佳、谷锐、徐斌共同完成。
因作者水平所限,书中难免存在疏漏和不妥,敬请读者不吝赐教，批评指正。

作者
2018年10月

第5章系统分析建模
系统分析是在需求分析的基础上,对系统要素进行综合分析并找出解决问题的可行方案的方法,它的基础是需求调查所形成的文档资料。本章以教学管理系统为例,根据获取的用例和收集的文档资料,围绕功能和数据两条主线,运用面向对象分析方法和数据库设计技术进行过程建模、数据建模和功能建模,形成系统逻辑模型。
5.1系统分析概述
系统分析阶段的核心工作是通过对需求的理解和详细分析,确定未来的新系统应该以什么方式和手段实现并满足需求分析中所提出的功能要求。本节主要论述系统分析的任务、工作产品和特点,以便从总体上把握系统分析阶段的工作的要点。
5.1.1系统分析任务及步骤
在系统分析阶段要求系统分析员详细了解每一个业务过程和业务活动的工作流程及信息处理流程,理解管理者(用户)的需求,然后运用信息系统开发理论、开发方法和开发技术确定系统应具有的逻辑功能,再用适当的方法表达出来,即信息系统分析建模,形成系统的逻辑方案,这个方案不但要能够充分反映用户的信息需求并和用户达成一致的意见,而且要能够使系统设计员和程序员由此设计、开发出一个计算机信息系统。
系统分析阶段是系统详细开发的关键性阶段,是确保每个子系统在服从全局的前提下,实现具体功能的重要基础,其关键在于“理解”和“表达”。“理解”是开发人员对系统需求的理解,既要充分理解用户能够明确表达出来的需求,也要善于通过分析挖掘用户没有明确表达出来的需求,同时还要善于对一些需求进行修正以使系统高于用户的期望值。“表达”的目的有两个: 一是把系统分析员对系统的理解通过逻辑模型表达出来,让用户检查,确定系统分析员“理解”的正确性;二是表达出逻辑模型一定要成为下一阶段的工作基础和依据。因此“表达”的关键是用什么样的工具描述对系统的理解,一方面使得用户能够看懂,能够与系统分析员共同讨论和修改,另一方面又要使得系统设计员和程序员能够正确理解,保证开发出的系统最终能够符合用户的需求。
系统分析过程遵循以下工作步骤。
(1) 对需求分析结果做深入分析形成过程模型。
需求分析阶段形成的以数据流程图来描述的过程模型和以用例图形式描述的用例模型是站在用户的角度来定义未来系统应该具有哪些业务功能,有哪些信息需要存储在数据库中,同时也概要说明了对系统性能、安全性、可靠性方面的要求,但是根据这些文档资料还不足以支持后续的开发,必须对需求分析的结果做进一步的分析,分析内容包括以下4点。
① 系统的功能要求。功能要求既包括需求分析中提出的功能需求,也包括分析后新增加的一些功能要求。
② 系统性能要求。结合需求分析的结果,对未来系统在性能方面,如联机系统的响应时间、系统需要的存储容量以及后援存储、重新启动和安全性等方面进行深入的分析。
③ 运行要求。这类要求集中表现在对系统运行及所处环境的要求。如用户希望使用哪种数据库管理系统,需要什么样的存储器等。
④ 将来可能的需求。这类需求是指目前不属于系统开发的范畴,但系统分析员根据以往的经验和对未来的判断,提出的一些新的功能,这部分功能应该高于用户的期望值,而使系统具有先进性和前瞻性。
(2) 数据分析,建立数据库逻辑模型。
在过程模型基础上,按照总体规划中提出的主题数据库模型,运用数据库设计技术,对数据流程中所涉及的主题数据库进行详细的逻辑设计,并根据系统的实际需求建立系统内的一些专用数据库,然后建立或进一步完善数据字典。
(3) 进行功能分析构建用例模型。
以面向对象的思想为指导,对需求分析阶段形成的用例模型做详细分析和设计,使系统具有复用性、可修改性,满足用户需求并适应未来的发展和变化。在用例模型分析中仍使用结构式语言、判断树、判断表、活动图、状态图等工具对用例进行描述,其结果既要能够有利于沟通、协商并获得确认,同时也便于指导后续的开发工作。
(4) 建立类分析模型。
依据用例模型和对用例模型的详细描述,确定每个用例所包含的对象,分析用例的时序,然后将时序分析结果转化为类分析模型。
(5) 整理各项文档资料,并提出系统分析总结报告。
5.1.2系统分析的工作产品
系统分析以需求调查的工作文档为基础,进行过程建模、数据建模、时序分析和构建类分析模型等工作,实现分析建模阶段的工作目标。各工作步骤及工作产品如图51所示。
1. 系统建模
系统建模包括两部分模型,一个是过程模型,另一个是用例模型。需求分析阶段形成的业务流程图表达了用户的功能需求、流程及信息交换关系,是站在用户角度来看系统,每项业务功能应该如何实现还需做进一步分析,通过分析调整和补充一些用户没有提及的功能需求,用数据流程图表达出来。数据流程图表达了功能与数据库基本表之间的关系,反映了数据的变换流程,因此数据流程图是系统的过程模型。结合需求分析阶段的功能描述和情景描述板建立以用例图为主,活动图、状态图为详细说明的用例模型,用例模型反映了每个具体功能(用例)的活动情况及状态。系统分析阶段建立的用例模型使用UML工具来描述。Unified Modeling Language(UML)称为统一建模语言或标准建模语言,该语言支持模型化和软件系统开发的图形化,目前面向对象的分析和设计都使用这种语言来描述。2. 数据建模
在信息系统中,数据被存储在数据库中,如何在数据库中建立一个稳定的、结构合理的数据结构,是系统分析阶段要完成的工作之一。数据库的逻辑结构描述了系统需要建立的基本表、基本表的结构以及每个基本表中应该包含的属性,最终的数据库逻辑结构是运用数据库设计方法对基本表的结构进行优化设计而形成的。数据模型的表达方式是ER图(实体联系图),可以利用ERwin、PowerDesigner等数据建模工具构建数据库的逻辑模型和物理模型。
3. 确定对象、时序分析
在系统多层架构思想指导下,针对每个用例,分析寻找其中的页面对象、业务逻辑对象和数据处理对象,表达在时序图中。对象之间的联系依靠的是消息机制,对象之间的联系可以通过活动图、状态图、用例说明中所描述的动作序列得到,动作序列有一定的时序关系,因此利用时序图可以表达对象、对象之间传递的消息以及消息之间的时序关系。
4. 构建类分析模型
类分析模型即类模型,是系统分析和设计的核心,系统分析阶段构建的类模型是系统的初始结构方案,在时序分析基础上,将时序图中的对象映射成类,将对象之间传递的消息映射成方法,即可形成类模型。对类模型所表达的初始方案所做的优化设计,则在系统设计阶段以迭代方式完成。
5.1.3系统分析的特点
系统分析阶段的特点体现在以下4个方面。
(1) 用画图的方法,直观且容易理解。
不用烦琐的语言来描述,而是用画图的方式,简单明确地表达这个系统的现行状态,使用户能够从这些图中直观地了解系统的概貌和工作流程,这样可以避免用语言描述所带来的理解上的偏差,保证系统分析员能够正确理解系统和需求,系统分析员在理解的基础上所产生的各种模型仍然是用图形工具来描述,也方便用户理解新系统的概况及逻辑功能,提出修正意见。另外作为系统设计员来说,他也能够直接根据这些图形进行系统设计,并保证设计的正确性。因此图形工具是系统分析员和用户、系统分析员和系统设计员之间的“通信手段”。
(2) “自顶向下”的工作原则。
采用“自顶向下”的工作原则,把一个复杂的系统由粗到细、由表及里地分析、认识,符合人类的认识规律,是信息系统开发过程中一直倡导的工作原则。运用这一原则使用户和系统分析员不但对系统有一个总的概念性印象,而且随着逐级向下地扩展,对那些具体的、局部的组成部分也有深刻的理解,系统分析员能够很快地了解现行系统并提出新系统的逻辑结构,用户也能够对此进行评审,提出修改意见。相应地，还可以运用这一原则进行系统设计工作。
(3) 强调逻辑结构而不是物理实现。
系统分析阶段的主要任务是确定新系统能够实现用户提出的哪些需求,能够达到什么目标,至于用哪种计算机、用什么技术、怎么去实现等问题不是系统分析阶段所要解决的。这样做的优点在于系统分析员在分析阶段可以不用过多地考虑具体的实现细节,而把精力放在逻辑功能的确定上,首先确保设计基础是正确的,进而才能保证未来系统的正确性。
(4) 避免重复工作。
系统分析资料一方面可以用来与用户进行交流,另一方面用来进行系统设计,这就大大增强了系统开发的一致性。正确而规范的文档资料又可以提高系统的可修改性,当然它并不能保证系统分析不出错。实际上系统分析阶段中的分析过程也是文档资料的编制过程,系统分析员在编制文档资料的过程中要相当仔细,尽量避免出现错误,特别是逻辑上的错误或矛盾。一旦发现错误就要及时更正,不要把错误带到下一阶段的开发工作中。
5.2系 统 建 模
根据需求分析的结果进行详细的功能分析,采用的工作路线是“自底向上”,从最底层的功能需求开始,考虑在信息系统中为实现功能需求,还需要存储哪些信息和增加哪些业务功能,分析结果用过程模型(即数据流程图)来描述,然后再进行用例模型的设计,以使信息系统具有可复用性、可修改性。
5.2.1文档规范〖*2〗1. 数据流程图绘制标准用数据流程图来描述业务分析结果,其制作规范要求如图52所示。
图52数据流程图图例
(1) 外部实体。
外部实体指不受系统控制,在系统以外的事物或人,它表达了数据处理的外部来源和去处。一般用一个正方形并在其上方和左上方各加一条线来表示。正方形内部要标明外部实体的名称,为了避免在数据流程图中出现线条交叉,同一个外部实体可以在一张图中出现若干次。
(2) 数据流。
数据流表明了数据的流动方向及其名称,是数据载体的表现形式之一。一般用一个带有箭头的直线来表示,箭头指出了数据的流动方向。数据流的名称即数据载体的名称一般写在数据流的上方,其名称一定是名词而不能出现动词。数据流可以来自或流向一个外部实体,表明有信息从外部进入系统或系统要向外部输出信息;数据流可以来自数据存储或流向数据存储,表明有信息要存入数据库中或要从数据库中检索信息,在这种情况下,在数据流上可以没有名称,表明数据流程方向的箭头可以是双向的;数据流也可以来自某一个业务功能或流向业务功能,表明经过业务功能产生了某些信息或为了完成某项功能需要输入某些信息。值得注意的是除了与数据存储相关的数据流之外,数据流中的箭头只采用单箭头来表示。
(3) 数据存储。
数据存储用来指明数据保存的地方。这里所说的“地方”不是指数据保存的物理地点或物理存储介质,而是指数据存储的逻辑描述,实际上就是数据库的逻辑描述。数据存储必须有名称和标识,其名称要适当并且必须是名词。为了便于区别和定义,为每个数据存储定义的标识一般用D或DB开始,后面是英文字符或数字。同外部实体一样,为了避免在一张数据流程图中出现线条的交叉,同一个数据存储可以出现若干次。
(4) 业务功能。
如果将数据流比喻成工厂中的零部件的传送带,数据存储是零部件的存储仓库,那么每一道加工工序就相当于数据流程图中的业务功能,它表达了对数据如何处理的业务逻辑,业务功能符号由三部分组成: 标识部分、功能描述部分和功能完成人(角色)。标识部分用数字表示,用于唯一地标识出这个业务功能以及它所在的管理层次,标识的定义与业务流程图一样。功能描述部分要求用一句简单的祈使句来直接表示这个业务功能所要完成的事情,祈使句中至少要有一个动词和名词,写在长方形的中间位置。这部分的描述中没有主语,主语在功能完成人(角色)部分描述。
数据流程图的制作范例如图53所示。
图53数据流程图绘制范例
2. 用例模型描述规范
(1) 用例。
用例(Use Case)是在不展现系统内部结构的情况下,对系统功能的定义和描述。可以把用例理解为要完成一件事情,而要完成这件事情就需要做一系列的活动,做这些活动时可以采用不同的办法和步骤。用户要做一件事情,这件事情用用例描述出来,但是完成这件事情所需要的一系列活动、办法和步骤并没有在用例上体现出来。
用例来自于用户对系统所期望的功能需求,它反映用户要完成一件事情,信息系统能够如何帮助用户完成这件事情。所以,用例描述了系统在响应来自某个参与者(Actor)的请求时的各种操作行为,参与者则是与系统交互的人或物。用例的命名可以是一个简单的祈使句,其中包含有动词和该动词的宾语,说明系统将要做什么,它以业务功能为基础,抽取在信息系统上将要实现的功能。
(2) 用例模型。
用例模型由用例和参与者(又称角色)组成,其中值得注意的是用户和参与者的概念有所不同,一个用户可以在系统中扮演多个角色,角色是系统行为主体。
用例模型通过用例图来描述,用例模型回答了每个角色执行哪些功能,这些功能内部包含了哪些行为,这些行为的执行序列是什么,这些行为序列对哪些数据做什么处理等。因此,用例模型描述了系统的功能需求,信息系统的开发以实现用例为目标。
(3) 用例图基本符号。
本书使用Rational Rose工具绘制用例图,Rational Rose是Rational公司推出的一种面向对象的统一建模语言的可视化建模工具,不同的建模工具所产生的用例图在形式上略有差别,但表述的内容完全一致。用例图的基本符号(图例)如图54所示。
图54用例图基本符号
用例(Use Case): 用椭圆图形表示,每个用例代表一个功能。用例的名称写在椭圆图形下面。
参与者(Actor): 参与者用线条化的人形表示,即角色。角色是一个比较抽象的概念,对角色的理解参照某场话剧演出,剧情中有若干角色,但具体到某一场次的演出中,某个角色可能会由不同的人来扮演,无论是谁,只要扮演的是同一个角色,那么他的台词、动作等都是一样的。角色可以与管理中的岗位相联系,岗位相对稳定,而具体的人是相对流动的,一个人(用户)在某个岗位上,就要承担这个岗位的职责,一旦这个人调离了这个岗位,那么他就不再承担这个岗位的职责,但这个岗位还在,这个岗位的职责一定会有另外一个人(用户)来承担。因此,在具体执行时,角色是被分配到具体的某个人(用户)来实现的。角色在系统中是比较稳定的,而用户(即系统的操作人员)则是角色的实例。用角色的概念来描述业务功能完成人，可帮助建立一个相对稳定的系统。
单向关联(Unidirectional Association): 参与者和用例是通过单向关联符号连接的,不带箭头的一端是参与者,带有箭头的一端指向用例,表示某个参与者启动某个用例。
扩展(Extend): 表示用例和用例之间的关系,扩展关系描述一个用例扩展使用另外一个用例。
包含(Include): 表示用例和用例之间的关系,包含关系表示的是某个用例中包含使用另外一个用例。
用例图示例如图55所示。
图55用例图示例
图55构建了一个用例模型,它描述了三个参与者与三个用例之间的关系,其中F2用例有两个参与者,它表明F2可以被A1和A3驱动,也就是说,A1和A3拥有对F2功能的操作权限,同时图55还说明系统将实现三个功能。
(4) 用例之间的扩展关系和包含关系。
图55中的用例模型仅包含参与者和用例之间的关系,在实际的需求分析中,必要时还需要描述用例和用例之间的关系。用例间常用的关系是扩展关系和包含关系,如图56所示。
图56用例间的关系
学籍管理员可发起(执行)“学生基本信息管理”,教务处负责人发起(执行)“查询学生基本信息”功能,但值得注意的是,他们在操作功能之前都必须先通过身份认证,没有经过身份认证的系统势必会被认为是一个不安全的系统。因此,“身份认证”功能被抽取为公共功能,作为被包含的用例而存在,如图56所示,在用例间的包含关系中,带有箭头的一端是被包含用例,不带箭头的一端是包含用例,被包含用例描述了多个用例中的共同的行为。
当学校对院系进行机构调整后,学籍管理员需要对学生基本信息进行相应地修改,这种修改被命名为“修改学生所在学院”,由于机构调整并不是经常性的,因此这项功能可在信息修改完毕后从系统中移除,因此可以将“修改学生所在学院”看作是学生基本信息管理用例的扩展。被扩展用例是“学生基本信息管理”,而扩展用例是“修改学生所在学院”,如图56所示,在两个用例图例之间画一个扩展关系,带有箭头的一端是被扩展用例,不带箭头的一端是扩展用例。被扩展用例运行时,不要求扩展用例也同时运行,也就是说扩展用例只有在特定情况下才执行,通常情况下不是必需的,当扩展用例被删除或者是用新的扩展用例来取代时,被扩展用例不会受到影响。
注意扩展关系和包含关系的区别: 如果意图是对某个完整的用例进行扩充,那么可以使用扩展关系;如果意图是将两个或两个以上用例所包含的共同行为分解为单个用例,那么使用包含关系。扩展用例可以在不需要时方便地取消,而包含用例则必须执行,不能被随意取消。扩展用例和包含用例的产生是为了便于系统的复用和修改,这也说明了在需求分析阶段就应该适当地考虑软件的复用性和可修改性问题。
3. 功能(用例)描述标准
业务流程图、数据流程图、用例模型是用图形方式描述业务操作流程和操作功能,但对操作功能的细节无法在图中做详细说明,为此可使用UML工具中的活动图、状态图以及结构式语言、判断树、判断表来进行描述。
5.2.2详细的功能分析及过程建模〖*2〗1. “教学计划管理”功能分析分析图45所描述的教学计划管理,教工1根据实际情况制定和通知培养计划修订日程这两项业务(标识为3.1.1和3.1.2)属于工作通知范畴,在与教工1进行沟通协商后确定这两项业务可以在另外一个被称为“办公自动化系统”中的“通知”功能实现,故可将这两项业务从教学管理系统中除去。同理,标识为3.1.6的制定评估日程也可通过“办公自动化系统”实现,也从教学管理系统中除去。
从图45中可以观察出培养计划要在经过录入、初审、终审三个环节(标识为3.1.3、3.1.4和3.1.5)后再组织计划评估(标识为3.1.7),“组织计划评估”是由多人参与的讨论会,参加人员有各专业秘书、院系教工和教务处的教工1,这项工作属于会议形式的群体决策,无法通过教务管理系统来实现,可将这项业务从教学管理系统中除去,由教工1根据会议结果“整理评估后的培养计划”(标识为3.1.8),“整理评估后的培养计划”实际上完成的是对培养计划的修改,其修改的依据是评估结果,如果初始的专业培养计划已经存在于数据库中,那么教学管理系统可为教工1提供“修改培养计划”功能。完成培养计划的修改形成的最终结果可通过“颁布培养计划”(标识为3.1.9)的操作打印出纸质培养计划书发给各院系。从教学秘书录入培养计划直至打印纸质培养计划书,整个教学计划管理流程以培养计划数据为核心,需要围绕培养计划进行数据库的逻辑设计,建立培养计划主题库。
对图45所描述的教学计划管理中部分业务的详细讨论如下。
(1) 对“专业培养计划录入”的讨论。
输入专业培养计划的功能由专业秘书来完成,在前期需求调查中得知,专业秘书实际上是由各专业的教师兼任的,全校有多少个专业便会有多少个专业秘书,并且专业秘书的上级主管并不是教务处,而是学校下属的各院系。如果教学管理系统的定位在为教务处的管理业务提供支持,管理方式由分层级的分散管理方式变为集中管理方式,那么专业秘书实质上是不受教学管理系统所管理的“外部项”,满足这项功能需求的最好方式是提供网上的信息录入功能。值得注意的是,在实际操作过程中,只提供输入功能是不够的,因为当发现输入中有错误数据时,就必须由修改或删除功能来支持对错误数据的修正。因此,可将“专业培养计划录入”更名为“专业培养计划管理”,并提供新增、删除、修改和查询功能,其中,新增、删除、修改和查询功能的权限仅限于专业秘书所属专业的培养计划,对其他专业的培养计划信息无操作权限。
(2) 对“修改专业培养计划”的讨论。
修改专业培养计划的功能由教务处的教工1这个角色来完成,这就意味着教工1要根据各专业培养计划协调后的结果,对全校专业培养计划进行修改。为使修改操作方便、快捷,首先需要提供查询功能,然后再提供修改功能,查询的权限是全校各专业培养计划。另外,修改专业培养计划操作的前提是专业秘书将专业培养计划信息输入并提交完毕。
(3) 对“审核专业培养计划”和“打印专业培养计划”的讨论。
审核专业培养计划由主管处长来完成,其前提是教工1完成了“修改专业培养计划”并提交修改后的结果。审核过程需要留下审核意见,最终的审核结论可以用“通过”“继续修改”字样来表达。另外,需要研究的一个功能是,审核过程中是否允许主管处长对发现的问题进行修改,如果允许修改,则同样要在审核功能中提供查询和修改功能,否则为不允许修改,处于“继续修改”状态的专业培养计划,将返回给教工1,由教工1在“修改专业培养计划”功能中完成。如果审核仅提出意见,不允许修改,那么势必增加了人员之间的沟通成本。为此,在与用户(主管处长和教工1)沟通后确认审核功能中增加查询和修改功能。
审核工作完毕,即每个专业的专业培养计划所处的状态均为“通过”,则可以进入打印程序,即“通过”状态是打印功能的前提。对打印的方式要进行详细的分析,通常有很多方式来实现,考虑到每个专业都应该获得一份最终审核通过的专业培养计划,故应该提供按专业打印培养计划的功能,至于打印的格式可与用户进行协商,确定最后的打印格式。
“教学计划管理”业务流程的分析结果用数据流程图来描述如图57所示,其中的功能描述标识被重新定义,每项功能都由某一具体角色来完成并体现在功能描述符号的下方。
图57“教学计划管理”数据流程图
2. “排课处理”功能分析
从图47所示的业务流程图中可以看出,“计算机排课”功能(标识为3.3.10.1)的输入信息是“全校教学任务分配表”,这个信息必须存储在数据库中,命名这个数据库为“教师任课信息”库。但是仅有教学任务分配信息还不足以支持实现计算机排课功能,经过详细地调查和确认,可以很明确地知道排课还必须有教室信息,并且教室信息也必须存储在数据库中。将教室信息存储在数据库中引发了一个新的功能——“教室基本信息管理”,也就是说,