《软件工程》实验指导书.docx

《软件工程》实验指导书.docx

《《软件工程》实验指导书.docx》由会员分享，可在线阅读，更多相关《《软件工程》实验指导书.docx（29页珍藏版）》请在冰豆网上搜索。

《软件工程》实验指导书

目录

实验一可行性研究………………………………………………………………………………3

实验二软件需求………………………………………………………………………………11

实验三系统分析与设计…………………………………………………………………………17

实验一可行性研究

一、实验目的

1、了解可行性研究的任务。

2、了解可行性研究的步骤。

3、完成一份可行性分析报告。

二、实验学时：

2学时

三、实验要求

1、仔细阅读图书管理系统的可行性分析报告。

2、模仿图书管理系统可行性分析报告，完成一份完整的可行性分析报告。

四、实验原理

1、可行性研究的任务：

可行性研究的任务是对即将开发的软件系统，从工程、经济、技术的角度，论证系统的可行性。

回答软件是否值得开发、有无可行的解决办法。

可行性研究的目的是用最小的代价在尽可能短的时间内确定问题是否能够解决。

2、可行性研究的步骤：

（1）复查系统规模的目标

（2）研究目前正在使用的系统

（3）导出新系统的高层逻辑模型

（4）重新定义问题

（5）导出和评价所提供的解决办法

（6）推荐行动方案

（7）草拟开发计划

（8）书写文档并提交复查

五、实验内容

1、可行性分析报告实例。

以一个图书管理系统为例，给出它的可行性分析报告，如第五节第2点所示。

2、可行性分析报告

可行性分析报告

1引言

1.1编写目的

可行性分析报告是为“图书管理系统”开发的可行性、必要性提供论据，为开发人员进行系统总体规划设计及具体实施开发工程提供必要的参考资料，在系统开发完成后期为系统的测试、验收提供帮助。

其编写过程由某高校信息工程学院学生完成。

预期读者是从事“图书管理系统”开发的相关人员。

1.2项目背景

本项目名称为“图书管理系统”。

系统功能主要包括：

能够存储一定数量的图书信息，方便有效地进行相应的书籍数据操作和管理，能够对一定数量的读者进行相应的信息存储与管理；能够提供一定的安全机制，提供数据信息授权访问。

本项目的任务提出者为某高校信息学院，开发者为信息学院学生。

1.3定义

以下对LMS、SQLServer、Eclipse分别定义如下。

LMS：

LibraryManagementSystem，图书管理系统。

SOLServer：

所用的数据库管理系统。

Eclipse：

所用的开发工具。

1.4参考文献

【1】陈明.软件工程实用教程.北京：

电子工业出版社，2006年1月.

【2】张海藩.软件工程导论.人民邮电出版社，2006年1月.

【3】潘孝铭.软件文档编写.高等教育出版社，2004年8月.

【4】罗先文.软件工程实物.重庆大学出版社，2005年3月.

2项目概述

2.1要求

图书管理系统应该具有对图书信息、读者信息进行存储和管理的功能，并能够保存图书信息、读者信息、借阅信息、账号信息，具有用户管理的功能。

该系统能极大地减少图书管理员的日常工作，并提供图书借阅报表，给图书管理员的图书管理提供辅助决策的功能。

2.1.1功能

图书管理系统最主要的功能是图书信息管理、读者信息管理、图书借阅管理、用户管理等功能。

2.1.2性能

图书管理系统的使用者是图书管理员和读者。

对于图书管理员的管理工作，性能要求不是很严格，但需要方便图书入库等操作。

对于读者的一般预定、借阅、返还等功能，对性能要求较高，一般需要达到并发数200以上。

2.1.3系统的输出

系统的输出包括以下内容。

（1）图书库存情况。

（2）读者图书预定需要。

（3）学生图书借阅情况。

2.1.4系统的输入

系统的输入包括以下内容。

（1）新书入库。

（2）读者图书借阅。

（3）用户数据添加。

2.1.5处理流程和数据流程

系统处理流程图如图1-1所示。

图1-1系统处理流程

2.1.6可靠性和安全性需求

由于图书管理系统的图书量会非常大，所以在对这些图书导入和查询时要保证速度。

在图书借阅过程中又要保证事务的完整性。

对于整个系统，需要完整的权限控制，防止某些人恶意地攻击系统，修改原始记录，同时对于数据库中的数据需要定时备份，防止系统数据丢失。

2.1.7完成期限

本项目的完成期限为2012年6月底。

具体进度见软件项目计划。

2.2项目基本目标

所建议的系统的开发目标应考虑以下几个方面。

（1）系统需要操作方便，方便管理员对整个系统的管理和读者借阅。

（2）系统需要提供综合查询系统，方便图书的查询。

（3）系统需要良好的扩展性，方便功能扩展和性能扩展。

（4）系统需要较好的安全性和灾难恢复机制。

2.3条件、假定和限制

对本项目开发中给出的条件、假定和所受到的限制如下。

2.3.1所建议系统的运行寿命的最小值

系统运行寿命的最小值应为10年。

2.3.2进行系统方案选择比较的时间

系统方案选择比较时间为1个月。

2.3.3经费、投资的来源和限制

经费、投资的来源是某高校信息学院，限制不超过合同上约定的条目。

2.3.4硬件、软件、运行环境和开发环境方面的条件和限制

以下介绍硬件、软件、运行环境和开发环境方面的条件和限制。

（1）硬件资源

服务器：

工作站或小型机。

网络设备：

网络交换机、网卡、网线。

图书条码打印和扫描仪。

打印机。

（2）软件资源。

①服务器端软件选择的具体说明介绍如下。

操作系统：

Windows2000Server或WindowsNT。

数据库管理系统：

SQLServer。

开发工具：

Eclipse。

软件平台：

Tomcat。

②客户端软件选择的具体说明：

Web浏览器。

2.3.5可利用的信息和资源

可参考传统的手工管理方式，了解可利用的信息和资源。

2.3.6系统投入使用的最晚时间

系统投入使用的最晚时间为2012年7月。

2.4进行可行性分析的方法

本次可行性分析是按照前面给出的步骤进行的，即按照复查项目目标和规模，研究目前正使用的系统，导出新系统的高层逻辑模型，重新定义这一循环反复过程进行的。

2.5评价尺度

本系统进行评价时的主要尺寸有：

费用的多少、开发时间的长短以及使用的难易程度等。

3对现有系统的分析

3.1处理流程和数据流程

处理流程图如图1-2所示。

图1-2处理流程图

3.2工作负荷

现有系统的工作主要有以下2个方面的内容。

（1）图书的信息维护。

（2）读者的信息维护。

3.3费用支出

运行现有系统所需要的费用支出包括图书管理人员的工资等。

3.4人员

运行维护现有系统的人员为图书管理员。

3.5设备

现有系统所需要的设备有打印机、扫描仪等。

3.6局限性

现有系统的局限性表现在以下方面：

手工操作难度较大、易出错、工作量大；对图书借阅信息和库存信息详细的查询困难。

4所建议的系统

4.1对所建议的系统的说明

所建议的系统是基于B/S结构的图书管理系统，其利用J2EE技术，解决了对图书的各个流程的控制，并提供了一个良好的、易操作的、直观的用户操作界面，从而实现自动化和系统化的管理。

4.2改进之处

所建议系统与现有系统比较，改进之处包括：

不需要管理人员手工操作查询，可及时更新图书和用户信息，节省了大量的人力、物力资源，提高了管理质量和工作效率。

4.3影响

在建立所建议系统时，预期会带来的影响包括以下几个方面。

4.3.1对设备的影响

由于被系统开发时采用新的技术和手段，所以需要配备符合本报告2.3所列出条件的计算机硬件。

4.3.2对软件的影响

软件环境需符合本报告2.3所列出条件的要求。

4.3.3对用户单位机构的影响

为了运行所建议系统，需要图书管理员熟悉计算机的相关操作。

4.3.4对系统运行过程的影响

用户操作规程按照系统所建议的提示进行；系统失效后，数据库恢复到最新的更新备份状态进行保存。

4.3.5对开发的影响

开发过程需要及时与用户沟通，了解其需求，不断改进和完善系统。

4.3.6对地点和设施的影响

无。

4.3.7对经费开支的影响

需要支付开发单位有关费用。

5可行性分析

5.1技术条件可行性分析

本系统是一个基于B/S结构的图书管理系统，采用面向对象技术、数据库技术、分布式技术等先进技术开发的应用程序，现有的开发技术已非常成熟，且被广泛应用于各行各业，利用现有技术完全可以达到功能目标。

考虑开发期较为充裕，预计可以在规定的时间内完成开发。

5.2经济可行性分析

5.2.1支出

支出主要包括以下几个方面。

（1）基本建设投资。

硬件设备：

服务器。

软件：

Windows2000Server或Linux。

数据库管理系统：

SQLServer。

开发工具：

Eclipse。

软件平台：

Tomcat。

（2）其他一次性支出。

一次性支出是系统的设计和开发费用。

（3）非一次性支出。

非一次性支出是系统的维护费用。

5.2.2收益

管理方式的自动化，减少了人力、物力费用，缩短了操作时间，极大地提高了工作效率和系统性能。

5.2.3投资回报周期

根据投资回报周期计算方法，收益的累计数开始超过支出的累计数的时间为1年。

6社会因素方面的可行性

6.1法律方面的可行性

建议系统的研制和开发都选用正版软件，将不会侵犯他人、集体和国家政策和法律。

6.2操作方面的可行性

本系统的研究和开发充分考虑用户工作流程、计算机操作水平等，尽可能提供更人性化、直观的界面，满足用户需要。

系统的操作方式在用户组织内可行。

7可行性结论

经上述可行性分析，系统的研制和开发可以立即进行。

六、实验任务

1、仔细阅读下面的用户需求描述：

饭团的烦恼

“午餐饭团”是学校内部参与人数最多的民间组织。

同一个班的，同一间宿舍的，同一个城市的，用同一种型号手机的，学生们总是以各种理由，各种借口组织各种长久的，临时的饭团。

参加饭团，不仅可以以优惠的价格尝到更加丰富的菜式，还可以在吃饭的时候和同学们唠唠嗑，吹吹牛，增进感情。

但是，随着参加饭团的学生人数越来越多，各个饭团的管理随即变得烦杂。

特别是为了照顾学生们越来越挑剔的胃口，饭团的点菜负责人背负的责任越来越大。

现在，这个重担落在你的肩上，因为，你将要为所有的学生饭团设计一个自动点菜的软件。

饭团点菜的需求如下：

1．经济是我们要考虑的一个因素，既不能吃得太差，又不能铺张浪费。

因此，我们希望最后的人均费用越接近6元越好。

2．菜式丰富是我们要考虑的另一个因素。

为简单起见，我们将各种菜肴的属性归结为荤菜，素菜，辛辣，清淡，并且每个菜只能点一次。

3．请紧记，学生饭团在各大餐馆享受8折优惠。

4．性能要求：

时间1S之内。

输入数据描述如下：

1．菜单

菜名（长度不超过20个字符），价格（原价），荤菜/素菜（在数据库中，可以用1表示是，0表示否，显示时，应该显示荤菜或素菜），辛辣/清淡（在数据库中，可以用1表示是，0表示否，显示时，应该显示辛辣或清淡），图片。

例：

水煮鱼15.00荤菜辛辣

2．每次点菜时输入abcde五个整数，分别表示需要点的荤菜，素菜，辛辣，清淡菜的数目和就餐的人数。

系统根据点菜时的要求自动在菜单中进行搜索，以实现饭团点菜的需求。

输出数据描述如下：

输出数据包含包含菜名（按菜名在原菜单的顺序排序）、菜的价格（原价，保留两位小数）、荤菜/素菜、辛辣/清淡、菜的图片。

菜的总价、饭团优惠价和人均消费，结果保留两位小数。

说明：

1．结果菜单的数目应该恰好为a+b（当然=c+d），荤菜，素菜，辛辣，清淡菜的数目恰好为a，b，c，d。

在满足这样的前提下，选择人均消费最接近6元的点菜方案。

2．每个饭团至少点三个菜（包括荤菜和素菜），其中至少有一个荤菜。

3．测试数据样例

输入样例：

21214

输出样例：

水煮鱼15.00荤辣

，口水鸡9.00荤辣

，清炖豆腐6.00素清淡

总价：

30.00元

饭团优惠价：

24.00元

人均消费：

6.00元

以上要求是该系统较其他餐饮系统的不同之处，对于餐饮管理系统的一般需求，请参考现有的餐饮流程和餐饮管理软件。

2、仔细阅读并参考第五节第2点的“图书管理系统”可行性分析报告，完成一份完整的“午餐饭团管理系统”可行性分析报告。

实验二软件需求

一、实验目的

1、了解软件需求的任务。

2、了解软件需求的步骤。

3、了解软件需求特性。

4、完成一份完整的软件需求分析报告。

二、实验学时：

2学时

三、实验要求

1、仔细阅读图书管理系统的需求分析报告。

2、模仿图书管理系统需求分析报告，完成一份完整的需求分析报告。

四、实验原理

1、软件需求的任务：

用户对系统的需求通常可分为如下两类：

（1）功能性需求

功能性需求主要说明待开发系统在功能上实际应做到什么，它是用户最主要的需求，通常包括系统的输入、系统能完成的功能、系统的输出及其他反应。

（2）非功能性需求

非功能性需求从各个角度对所考虑的可能的解决方案的约束和限制。

包括：

工程需求（如交付需求、实现方法需求等）、产品需求（如可靠性需求、可移植性需求、安全保密性需求等）和外部需求（如法规需求、费用需求等）等。

2、软件需求的步骤：

如果需求阶段的工作，可分为以下几个步骤进行。

（1）通过调查研究，获取用户的需求。

（2）去除非本质因素，确定系统的真正需求。

（3）描述需求，建立系统的逻辑模型。

（4）书写需求说明书，进行需求复审。

3、软件需求特性：

在计算机的早期，所求解问题的规模较小，需求分析往往被忽视。

随着软件系统复杂性的提高及规模的扩大，软件需求在软件开发中所处的地位愈加突出，从而分析也愈加困难，它的难点主要体现在以下几个方面：

（1）问题的复杂性。

问题的复杂性是由用户需求所涉及的繁多因素引起的，如运行的环境和系统功能等。

（2）交流障碍。

软件需求涉及人员较多，如软件系统用户、问题领域专家、需求工程师和项目管理员等，这些人具备不同的背景知识，处于不同的角度，扮演不同的角色，造成了相互之间交流的困难。

（3）不完备性和不一致性。

由于各种原因，用户对问题的陈述往往是不完备的，其各方面的需求还可能存在着矛盾。

软件需求要消除其矛盾，形成完备及一致的定义。

（4）需求易变性。

用户需求的变动时一个极为普遍的问题，即使是部分变动，也往往会影响到软件需求的全部，导致不一致性和不完备性。

五、实验内容

1、需求分析报告实例。

以一个图书管理系统为例，给出它的需求分析报告，如第五节第2点所示。

2、需求分析报告

“图书管理系统”需求分析报告

1引言

参见实验一中图书管理系统可行性分析报告的引言。

2需求概述

2.1目标

“图书管理系统”主要提供图书信息和读者基本信息的维护以及借阅等功能，该系统针对的用户是单个中小型图书馆，藏书的种类和数量较少，系统需要操作方便，方便管理员对整个系统的管理和学生借阅图书。

2.2用户类和特征

最终的用户是图书管理员和读者，图书管理员需要进行用户的创建、修改和删除等工作，要求具备计算机知识，如权限管理等。

读者是普通用户，具备一定的计算机操作知识即可。

2.3运行环境

参见实验一中“图书管理系统”可行性分析报告的运行环境。

3功能需求

本系统相应的需求有以下方面。

（1）能够存储一定数量的图书信息，并方便有效地进行相应的书籍数据操作和管理，这主要包括以下内容：

①图书信息的录入、删除及修改。

②图书信息的多关键字检索查询。

③图书的借出、返还和资料统计。

（2）能够对一定数量的读者进行相应的信息存储与管理，这其中包括以下内容：

①读者信息的登记、删除和修改。

②读者资料的统计和查询。

③能够提供一定的安全机制，提供数据信息授权访问。

需求补充说明的几点如下：

（1）数据保存：

用户长期保存在数据库的数据有以下几种。

①图书信息：

图书的基本信息。

②读者信息：

读者的基本信息。

③借阅信息：

图书的借阅信息。

④账号信息：

图书管理员和读者的登陆账号。

（2）系统用户：

图书管理员、读者。

①图书管理员：

对图书和读者数据可执行添加、修改、删除及其查询等操作。

②读者：

可查询图书以及查询与本人相关的借阅信息。

3.1确定执行者

执行者是与用户交互的外部实体，它既可以是人员，也可以是外部系统或硬件设备。

确定执行者可以通过提出以下问题得到。

（1）谁使用系统的主要功能？

（2）谁需要系统的支持以完成日常工作任务？

（3）谁从系统获取信息？

（4）谁负责维护和管理系统以保证其正常运行？

（5）系统需要应付（处理）哪些外部硬件设备？

（6）系统需要和哪些外部系统交互？

在本例中，可以确定“图书管理员”和“读者”为系统的执行者。

“图书管理员”负责使用系统的主要功能，“读者”从系统中获取所需的信息。

3.2确定用例

用例描述了一个完整的系统事件流程，其重点在于执行者与系统之间的交互而不是内在的系统活动，并对执行者产生有价值的可观测结果。

确定用例可以通过提出以下问题得到。

（1）参与者需要从系统中获取得什么功能？

参与者需要做什么？

（2）参与者读取、产生、删除、修改或存储系统的某些信息吗？

（3）系统中发生事件需要通知参与者吗？

参与者需要通知系统某件事情吗？

（4）系统的输入/输出信息是什么？

这些信息从哪儿来到哪儿去？

（5）采用什么实现方法满足某些特殊要求？

本例中我们通过一定的调研和分析得到“图书系统管理”的用例图，如图2-1所示。

图2-1“图书管理系统”的用例图

3.3编写用例文档

用例图不能提供用例所具有的全部信息，为此需要使用文字描述那些不能放在图形上的信息。

用例文档是关于执行者与系统如何交互的规格说明，要求清晰明确，没有二义性。

在描述用例时，应该只注重外部能力，不涉及内部细节。

下面给出用例文档。

1.图书信息的维护用例

用例名：

图书信息的维护。

参与执行者：

图书管理员。

入口条件：

图书管理员已经登录到该系统中。

事件流：

当有新书入库时，图书管理员在录入页面输入书的信息，单击“提交”按钮，系统将书的信息保存到数据库中；当某一本图书的信息需要修改时，图书管理员通过输入查询条件，搜索出该书时，单击“修改”按钮，系统在可编辑状态显示图书的当前信息，图书管理员修改具体信息，单击“保存”按钮，系统将更新数据库中该书的信息；当需要删除一本或者多本图书时，图书管理员查找到需要删除的图书记录，单击“删除”按钮，系统提示“确认要删除？

”对话框，当管理员选择“是”时，系统将删除数据库中相应图书的信息，反之，则不进行任何操作。

出口条件：

系统将数据库中的图书信息通过相应的操作；添加图书信息时，将新的图书信息保存在数据库中；修改图书信息时，将数据库中该图书的信息做相应的更新操作；删除图书信息时，则删除数据库中的相应记录。

异常事件：

在图书进行修改和删除时，先查出需要进行处理的图书记录，如果数据库中不存在符合条件的记录，查询无结果时，则无法进行修改和删除操作。

2.读者的信息维护用例

用例名：

读者信息的维护。

参与执行者：

图书管理员。

入口条件：

图书管理员已经登陆到该系统中。

事件流：

当有新的读者时，图书管理员在录入页面输入读者信息时，单击“提交”按钮，系统将读者的信息保存到数据库中；当某一个读者的信息需要修改时，图书管理员通过输入查询条件，搜索出该读者的信息时，单击“修改”按钮，系统在可编辑状态下示读者的当前信息，图书管理员修改具体信息，单击“保存”按钮，系统将更新数据库中读者的信息；当需要删除一本或者多个读者时，图书管理员查找到需要删除的读者记录，单击“删除”按钮，系统提示“确认删除？

”对话框，当管理员选择“是”时，系统将删除数据库中相应读者的信息，反之，则不进行任何操作。

出口条件：

系统将数据库中的读者信息通过相应的操作；添加读者信息时，将新的读者信息保存在数据库中；修改读者信息时，将数据库中该读者的信息做相应的更新操作；删除读者信息时，则删除数据库中的相应记录。

异常事件：

在进行修改和删除读者信息时，先查出需要进行处理的读者记录，如果数据库中不存在符合条件的记录，查询无结果时，则无法进行修改和删除操作。

3.图书信息的查询用例

用例名：

图书信息的查询。

参与执行者：

图书管理员，读者。

入口条件：

无。

事件流：

通过交互界面输入查询条件（如书名、作者名等）搜索图书记录。

出口条件：

若有符合条件的课程信息，则系统显示这些图书信息。

否则系统提示用户从新输入查询条件。

4.读者信息的查询用例

用例名：

读者信息的查询。

参与执行者：

图书管理员。

入口条件：

用户已经登陆到该系统中。

事件流：

通过交互界面输入查询条件（如读者证、读者姓名等）搜索读者记录。

出口条件：

若有符合条件的读者信息，则系统显示这些读者信息。

否则系统提示用户从新输入查询条件。

5.查询个人基本信息用例

用例名：

查询个人基本信息。

参与执行者：

读者。

入口条件：

用户已经登陆到该系统中。

事件流：

单击“查询个人基本信息”按钮。

出口条件：

系统显示读者本人信息。

6.查询个人借阅信息用例

用例名：

查询个人借阅信息。

参与执行者：

读者。

入口条件：

用户已经登陆到该系统中。

事件流：

单击“查询个人借阅信息”按钮。

出口条件：

系统显示读者借阅信息。

7.借书用例

用例名：

借书。

参与执行者：

图书管理员、读者。

入口条件：

图书管理员已经登陆到该系统中。

事件流：

图书管理员在借书页面，输入图书编号和读者证号，单击“保存”按钮。

出口条件：

系统将这些记录保存到数据库中。

异常事件：

如果该图书未入库，则数据库不存在图书编号，提示“该书未入库”；如果数据库中不存在该读者证号，也相应地给出提示。

8.还书用例

用例名：

还书。

参与执行者：

图书管理员、读者。

入口条件：

图书管理员已经登陆到该系统中。

事件流：

图书管理员在还书页面，输入图书编号，单击“还书”按钮。

出口条件：

系统将删除数据库中的该条借书记录。

异常事件：

如果数据库中不存在这本书的借阅记录，提示“非本馆借出的图书”，如果该书已经过期，也相应地给出提示。

9.口令管理用例

用例名：

口令管理。

参与执行者：

图书管理员、读者。

入口条件：

用户已经登陆到该系统中。

事件流：

用户单击“修改密码”按钮，在口令修改页面输入新的密码，单击保存按钮。

出口条件：

数据库中的密码被修改成最新的密码。

4非功能类需求

4.1性能需求

图书管理系统的使用者时图书管理员和在校学生。

对于图书管理员的管理工作，性能要求不是很严格，但需要方便图书的入库等操作。

对于学生的图书借阅、查询等功能，对性能的要求较高，一般需要达到并发数200以上。

4.2安全性需求

由于图书管理系统的图书量非常大，所以在对这些图书导入和查询时要保证速度。

在图书借阅过程中又要保证事务的完整性。

对于整个系统，需要完整的权限控制，防止某些人恶意地攻击系统，修改原始记录。

同时对于数据库中的数据需要定时备份，防止系统数据丢失。

此外，系统要求用户在登陆时需要身份验证。

5故障处理

在正常情况下，应不出错。

一旦发生意外，不如掉电，网络不通等，也应保证系统数据不会丢失。

6外部接口需求

（略）

六、实验任务

1、仔细阅读并参考第五节第2点的“图书管理系统”需求