《软件工程》实验指导书.docx
《《软件工程》实验指导书.docx》由会员分享，可在线阅读，更多相关《《软件工程》实验指导书.docx（23页珍藏版）》请在冰豆网上搜索。
《软件工程》实验指导书
《软件工程》
实验指导书
计算机学院
2017年2月
软件工程实验指导
前 言
软件工程实验是为计算机相关专业本科《软件工程》课程配套设置的，是《软件工程》课程讲授中一个重要的、不可或缺的实践环节。
其目的是使学生能够针对具体软件工程项目，全面掌握软件工程管理、软件需求分析、软件初步设计、软件详细设计、软件测试等阶段的方法和技术，通过该课程设计使学生进一步理解和掌握软件开发模型、软件生命周期、软件过程等理论在软件项目开发过程中的意义和作用，培养学生按照软件工程的原理、方法、技术、标准和规，进行软件开发的能力，培养学生的合作意识和团队精神，培养学生对技术文档的编写能力，从而使学生提高软件工程的综合能力，提高软件项目的管理能力。
按该课程的特点，实验容包括软件开发的两大方法学的专题训练，即结构化（生命周期学）的方法学和面向对象的方法学，通过对一个简单项目，要求学生利用结构化软件开发技术或面向对象的软件开发技术完成对该项目的开发。
因此设置五个实验项目，从项目发的准备工作，系统分析过程，系统设计过程，软件测试到系统实施，覆盖软件开发的整个过程，此外又引入我国国家《计算机开发规》，以规技术文档的书写标准，提高实验教学质量。
通过实验训练，达到如下目的：
使学生进一步了解和掌握软件工程原理，提高对实际项目的分析和设计能力，通过实验课程，熟悉和基本掌握软件工程方法学、软件开发的过程，文档资料的编写格式及规，全面领会和贯通所学习的理论知识，从而培养学生综合运用所学课程知识，分析解决问题的能力，培养学生理论联系实际作风，实事，严肃认真的科学态度和良好的工作作风，为今后从事科学研究工作打下基础。
实验要求
软件工程实验具体要求如下：
每个项目小组必须按照《软件工程实验指导书》附录中给定的文档规标准提供项目文档；
题目自定或采用附录二中的题目；
软件开发的方法自定（结构化或面向对象的方法学）。
实验一用Visio进行功能分析和建模
1.实验目的
掌握结构化分析的方法。
掌握使用Visio2003软件绘制数据流图、状态转换图的一般方法和技巧。
2.实验环境
软件平台:
MicrosoftWindowsXP，软件工具：
MicrisoftVisio2003。
3.实验原理
结构化分析方法以数据字典为核心，采用实体关系图、数据流图和状态转换图等图形来表达需求，直观明了且易于理解和掌握。
数据流图作为功能建模的基础，描述数据怎样转换以及转换的功能，状态转换图作为行为建模的基础，表示系统的各种行为状态以及状态间的转换方式。
4.实验容与要求
绘制学生成绩管理系统（案例如下）的数据流图及状态转换图。
5.撰写实验报告
案例1
某校准备开发一个学生成绩管理系统。
在该系统中，教务人员录入学生信息、课程信息和成绩信息，学生可以随时查询自己所选课程的成绩。
由于学生成绩属于敏感信息，系统必须提供必要的安全措施以防非法存取。
用Visio操作
实验步骤及相关详细讲解：
*第0层DFD图
教务人员维护学生信息和课程信息，并登录学生的选课成绩；
学生查询自己的成绩单。
*第1层DFD图
对第0层DFD图中的一个加工"学生成绩管理"进行展开。
双箭头：
直线——右键格式——线条，线端的起点终点
直线用动态连接线
*第2层DFD图
对第1层DFD图中的一个加工"查询学生成绩"进行展开。
绘制第0层DFD的时候，将整个系统看成一个加工，然后找出作用于该加工的外部实体，以及相应的数据输入和输出。
对于"学生成绩管理系统"而言，整个系统就是一个加工"学生成绩管理"。
从用户的需求描述可知，"教务人员"是数据的源点，"学生"是数据的终点。
另外，教务人员需要录入学生信息、课程信息和成绩，说明"学生信息"、"课程信息"和"成绩"是数据流；同样，"查询请求"和"查询结果"也是数据流。
根据上述分析，得到如图所示的第0层DFD。
绘制下一层数据流图时，细化第0层的加工"学生成绩管理"，从而描述系统的主要功能。
从第0层DFD得知，"学生信息"是教务人员需要录入的一个信息，因此加入一个加?
quot;录入学生信息"，同样得到"录入课程信息"、"登记成绩"两个加工。
另外，数据流"查询请求"和"查询结果"应该由加工"查询成绩"来完成。
这样，我们用"录入学生信息"、"录入课程信息"、"登记学生成绩"和"查询学生成绩"四个加工代替第0层的"学生成绩管理"，同时增加这些数据流对应的数据存储，即"学生"、"课程"和"成绩"，最后得到如图所示的第1层DFD。
为了继续进行分解，我们分析第1层DFD中的加工"查询学生成绩"。
学生查询成绩时需要提供合法性检查，因此，"查询学生成绩"可以分解为"合法性检查"和"查询成绩"两个处理步骤，从而形成如图所示的第2层DFD。
根据以上实例和经验，绘制数据流图应当遵循以下原则：
（1）分层时，子图的输入、输出数据流必须和父图中相应加工的输入、输出数据流一致；
（2）加工的编号应该唯一且具有层次性；
（3）加工不应该只有输入或只有输出，通常既有输入又有输出；
（4）数据流图不应反映处理的顺序；
（5）加工之间应通过数据存储进行通信，避免从一个加工直接流到另一个加工；
（6）数据应通过加工进行流动，避免从一个数据存储直接流到另一个数据存储；
（7）数据流图中所有元素的命名应当对客户有意义，且与业务相关；
（8）不要在一个图中绘制7个以上的加工，否则难于绘制和理解。
通常来说，行为建模用于实时系统。
实时系统中可能存在许多脚本，很多实体需要进行状态划分和描述状态转换图，有时为了描述系统的并发行为，还需要使用其他一些工具进行描述，如Petri网。
在事务系统中，系统行为相对简单，只有某些行为较复杂的实体才需要建立其状态转换图。
（1）分析外部事件，所谓外部事件是指外部实体与系统的一次交互。
（2）分析事件的响应者，该响应者为了响应该事件要进行怎样的活动，这种活动又会激发哪些事件等，这样构成了系统行为的脚本。
（3）根据事件和活动划分实体的状态，也可根据其他知识划分实体状态，考虑发生怎样的事件使该实体进入这个状态，怎样的事件使该实体从这个状态转换到另一状态等。
举例分析：
（在数据流程图中）或UML图中
在"学生成绩管理"系统中，学生成绩信息需要采取安全措施，我们可以采取登录方法避免非法使用系统。
这样，该系统存在"登录"、"正常"和"出错"等状态的转换。
学生启动系统之后，系统处于"登录"状态。
在这种状态下，学生可以进行登录或取消登录。
如果取消登录，系统直接退出；如果登录失败，系统进入"出错处理"状态，在显示错误信息后，又重新回到"登录"状态；如果登录成功，系统进入"正常"状态，即显示操作界面，等待学生查询，学生可以多次查询不同课程的成绩，直到学生选择退出为止。
实验二用例模型设计
1.实验目的
学会IBMRationalRoseEnterpriseEdition的基本操作。
掌握使用Rose进行用例建模。
2.实验环境
软件平台:
MicrosoftWindowsXP，软件工具：
IBMRationalRoseEnterpriseEdition。
3.实验原理
使用用例方法来描述系统功能需求的过程，就是用例建模，它是实现"功能模型"建模的主要手段之一。
用例模型主要包括以下两部分容。
⑴用例图（UseCaseDiagram）
确定系统中所包含的参与者、用例和两者之间或其自身的关系，用例图是基于系统要实现的功能的一个可视化描述。
①参与者（Actor）
②用例（UseCase）
用例是用来描述参与者使用系统，以达到某个目标时所涉及到的一系列的场景的集合。
一个用例的核心并不是上述的图标，而是一个规格化的叙述型文档，它描述了参与者要实现某项功能的事件流程，展示和体现了其所描述的过程中的需求情况。
用例名称一般以“做什么”即“动宾词组”形式来命名。
③用例和参与者及自身的关系
泛化关系（generalization）
包含关系（include）
扩展关系（extend）
⑵用例规约（UseCaseSpecification）
所谓规约，就是业务规则的规格说明。
针对每一个用例，都应该有一个用例规约文档与之相对应，以描述该用户的细节容。
每一个用例的用例规约，都应该包含以下容：
①用例名称（UseCaseName）：
用例的名称一般由"动词+名词"构成，简单说明"做什么"。
②简要说明（BriefDescription）：
简要介绍该用例的作用和目的。
③前置条件（PreviousCondition）：
系统在执行该用例前必须处在的状态。
④事件流（FlowofEvent）
⑤用例场景（UseCaseScenario）：
包括成功场景和失败场景，场景主要由基本流和备选流组合而成。
⑥特殊需求（SpecialRequirement）：
描述与该用例相关的非功能性需求（性能、可靠性、可用性和可扩展性等）以及涉及约束（所使用的操作系统、开发工具等）。
⑦后置条件（PostCondition）：
系统在执行完该用例之后应该处在的状态。
4.实验步骤
（1）找出系统边界以外的角色（actor），角色是与系统进行交互的外部实体，可以是与系统交互的人员、与系统相连并交换信息的设备和其他系统；
（2）从这些角色如何与系统进行交互的角度，使用用例（usecase）来描述角色怎样使用系统以及系统向角色提供什么功能，用例所表示的是从外部用户角度观察的系统功能；
（3）绘制用例图，并编写详细的用例描述。
用例图只能宏观地描述系统的功能，但却不能提供用例模型所必需的所有信息，每个功能的含义和具体实现步骤则以文本方式描述。
5.实验容与要求
绘制用例图，详见教材P95（4.7）。
6.撰写实验报告
实验三用例规约及活动图
一、实验目的
1.熟悉活动图的基本功能和使用方法。
2.掌握用例规约的撰写。
3.掌握如何使用建模工具绘制活动图方法。
二、实验器材
1.计算机一台。
2.RationalRose工具软件。
三、实验原理
1.用例规约描述用例
单纯使用用例图不能提供用例所具有的全部信息，因此，需要使用文字描述那些不能反映在图形上的信息。
用例描述实际上是关于角色与系统如何交互的规格说明，要求清晰明确，没有二义性。
描述用例时，应该只注重外部能力，不涉及部细节。
每一个用例的用例规约，都应该包含以下容：
①用例名称：
用例的名称一般由"动词+名词"构成，简单说明"做什么"。
②简要说明：
简要介绍该用例的作用和目的。
③前置条件：
系统在执行该用例前必须处在的状态。
④事件流：
基本流和备选流。
⑤特殊需求（SpecialRequirement）：
描述与该用例相关的非功能性需求（性能、可靠性、可用性和可扩展性等）以及涉及约束（所使用的操作系统、开发工具等）。
⑥后置条件（PostCondition）：
系统在执行完该用例之后应该处在的状态。
2.活动图描述用例
在UML中，活动图类似于流程图，它描述了执行某个功能的活动。
使用活动图来描述用例，比用例规约更直观。
组成活动图的元素：
①活动的起点－实心圆
②活动的终点－半实心圆
③状态－带圆端的方框
④转移－带箭头的直线
⑤分支－菱形
⑥泳道－将活动图的活动状态分组
四、实验容
图书管理系统的用例图如下：
根据分析设计情况，可进一步添加或细化。
其中图书管理员的用例可细化如下（部分）：
其中删除读者信息一般按照以下步骤进行：
（1）管理员在录入界面，输入待删除的读者的信息；
（2）“业务逻辑”组件在“数据库”中查找待删除的读者信息；
（3）如果不存在，则显示出错信息，返回步骤
（1），如果存在则继续；
（4）“业务逻辑”组件判断“待删除的读者”是否可以删除（如借了书则不能删）；
（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；
（6）在“数据库”中删除相关信息；
（7）显示删除成功信息；
（8）结束。
1.编写“删除读者”用例的规约。
2.绘制“删除读者”用例的活动图。
五、绘图步骤
（1）在用例图中，找到“删除读者”用例，在该用例上单击右键，在弹出的快捷菜单中选“New”，Rose工具会弹出一个菜单，选“ActivityDiagram”，选中后单击，便可以新建好一个活动图，命名为“删除读者”。
（2）新建好活动图后，双击“删除读者”活动图，然后把在左边的工具栏点击“Swinlane”，在右边的图中添加一个泳道，并命名为“图书管理员接口”。
按照此步骤，再添加两个泳道，并分别命名为“业务逻辑接口”、“数据库接口”。
（3）接着在左边的工具上选取开始点，并在“图书管理员接口”的泳道上添加；添加完开始结点后，再来为此活动图添加活动。
参考图如下：
使用工具
Swinlane最后一个图标
六、实验报告要求
1.整理实验结果。
2.小结实验心得体会。
实验四类图
一、实验目的
1.理解类及类间关系的基本概念。
2.掌握如何从需求分析中抽象出类的方法。
3.掌握描绘类间关系的方法。
4.掌握在RationalRose中绘制类及类关系的操作方法。
二、实验器材
1.计算机一台。
2.RationalRose工具软件。
三、实验原理
类图是描述类、接口以及它们之间关系的图，它显示了系统中各个类的静态结构，用于对系统的静态视图（它用于描述系统的功能需求）建模。
发现和定义对象类应以问题域和系统责任为出发点，正确地运用抽象原则，尽可能全面地发现对象的因素，并对其进行检查和整理，最终得到系统的对象类。
我们可以在用例模型的基础上，通过识别实体类、边界类和控制类，从而发现和定义系统中的对象类。
在这里，实体类表示系统存储和管理的永久信息，边界类表示角色与系统之间的交互，控制类表示由系统支持和用户执行的任务，我们使用UML中的构造型<>、<>和<>分别表示实体类、边界类和控制类。
在找到系统的对象类之后，我们需要分析和认识各类对象之间的关系，从而使对象类构成一个整体的、有机的系统模型。
对象与外部的关系有以下几种：
（1）对象之间的分类关系，即泛化关系；
（2）对象之间的组成关系，即聚合关系；
（3）对象之间的静态关系，即关联关系；
（4）对象之间的动态关系，即依赖关系。
四、实验容
通过前面对图书馆管理系统的需求的初步分析，得出系统的用例图和相应的活动态图，初步了解系统的业务处理流程。
现在需要对系统进行静态建模，这就需要利用系统的用例图，活动图来寻找和发现类，并分析它们之间的关系。
1.寻找和抽象出书图书馆管理系统中的实体类。
2.对实体类的关系建模。
五、实验步骤
1.分析：
通过分析和理解问题域，可以识别出系统的实体类，如读者基本信息、借书记录、预订信息、图书基本信息、书目等。
2.绘制类的步骤:
（1）打开前面初步构建的UML模型文件；
（2）打开Rose中的逻辑视图（LogicalView），用鼠标右击“LogicalView”，在弹出来的菜单中选择“New→Classdiagram”项，创建类图。
（3）双击新建的类图，并点右边控件集中选中的类的图标，并用鼠标在图中分别拖出一个类图，并命名，如“Title”。
（4）接下来的一步为设置类的属性，在新的类中双击该类，在打开属性面板中，可以看到在此可以设置类的属性和方法等其他的信息。
点击“Attributes”这个栏目，此栏目为设置类的属性的选项。
在图中间的单击右键，可以看到有一个“Insert”的选项，选中这个选项。
后在出现的对话框中输入相关信息，如书本的ISBN号，在Type这个方框输入此属性的类型值，同时可以看到一栏可以设置此属性的访问权限，一般这些属性都设置Private这个权限。
这个类的其他属性也可以按照以上的做法设置。
（5）设置好类的属性，现在来设置类的方法（也是操作）。
双击类后在弹出的菜单上选“operations”这个选项，在图中的空白地方单击右键，在弹出的菜单中选“insert”这个选项，也就只有这个选项可用。
接着输入方法名，同时可以设置该方法的返回类型，也可以在“Documentations”的方框填写一些相关的方法说明，设置好该方法的访问权限，类的其他方法也可以按上面来设置好。
至此，类的方法和属性都设置好了。
（6）依此绘制其它类。
（7）接下来就可以为各个类添加关系了。
（8）可右击工具箱空白处，点“Customize”，添加其它模型元素。
六、实验报告要求
1.整理实验结果。
2.小结实验心得体会。
实验五交互图
一、实验目的
1.理解顺序图的基本概念。
2.理解协作图的基本概念。
3.掌握在RationalRose中绘制交互图的操作方法。
二、实验器材
1.计算机一台。
2.RationalRose工具软件。
三、实验原理
时序图又叫顺序图，它是强调消息时间顺序的交互图，描述类与类间相互交换以完成期望行为的消息。
时序图向UML用户提供事件流随时间推移的、清晰的和可视化的轨迹。
时序图一般包括如下元素：
类角色、生命线、激活期和消息。
⑴类角色。
代表时序图中的对象在交互中所扮演的角色，一般代表实际对象。
⑵生命线。
代表时序图中的对象在一段时期的存在。
每个对象底部中心都有一条垂直的虚线，这就是对象的生命线，对象间的消息存在于两条虚线之间。
⑶激活期（控制焦点）。
代表时序图中的对象执行一项操作的时期。
每条生命线上窄的矩形代表活动期。
⑷消息。
消息用于实体间传递信息，类角色通过发送和接收消息进行通信。
时序图的组成
四、实验容
通过对图书管理系统的需求分析，并从业务对象中抽象出了类，现在需要对前面所给出的用例进行实现，而用例的实现主要由交互图来指定和描述系统的动态特性。
1.对“登记借书”用例进行动态建模。
五、实验步骤
（1）在Rose软件的左边栏目上的LogiclView单击右键，新建一个时序图。
（2）接下来的是添加类，添加方法。
在上面做好的类找到可以直接拖拉来图中。
课本165页
添加方法
添加属性
（3）添加消息，开始是必须是外面的实体向系统发送消，如管理员登录时向系统发送的消息。
先添加对象消息（→），双击对象消息（即→），打开如图对话框，添加或选择消息（方法）。
（5）可以按上一步的方法来完成其他的方法。
（6）完成了时序图后，可以按F5键便得到“登记借书”的协作图。
六、实验报告要求
1.整理实验结果。
2.小结实验心得体会。
课本165页
按F5后
小人
1
2
3
在输入librarian时点击确定会出错，所以把librarian最后的n改成另一个字母（随便一个）
点击确定回到上一级窗口如图
确定小人出来了
因为名字不一样，删除
上面一个小人
双击下面一个小人改成librarian
小人画完
附录一：
实验题目
题目一：
教务管理系统之子系统——学院课程安排
1．系统简介
每个学期的期中，学校教务处向各个学院发出下各学期的教学计划，包括课程名称、课程代码、课时、班级类别（本科、专科、成人教育、研究生）、班号等；学院教学主管人员根据教学任务和要求给出各个课程的相关限制（如：
任课教师的职称、上课的班数、最高和最低周学时数等）；任课教师自报本人授课计划，经所在教研室协调任可，将教学计划上交学院主管教学计划的人员，批准后上报学校教务处，最终由教务处给出下个学期全学院教师的教学任务书。
假设上述排课过程全部由人工操作，现要求为上述过程实现计算机自动处理过程。
2．限定条件
（1）每位教师的主讲课程门数不超过2门/学期：
讲师以下职称的教师不能承担学院定主课的主讲任务。
（2）学院中层干部的主讲课时不能超过4学时/周。
（3本学期出现严重教学事故的教师不能承担下各学期的主讲任务。
（4）本系统的输入项至少包括：
教务处布置的教学计划，学院教师自报的授课计划和学院定的有关授课限制条件。
（5）本系统的输出项至少包括：
教务处最终下达全院教师的教学任务书和学院各个班级下各学期的课程表（可以不含上课地点）。
题目二：
学校教材定购系统
1．系统简介
本系统可以细化为两个子系统：
销售系统和采购系统
销售系统的主要工作过程为：
首先由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、登记并返给教师或学生领书单，教师或学生可以到书库领书。
采购系统的主要工作过程为：
若是教材脱销，则登记缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
以上功能要求在计算机上实现。
2．技术要求和限制条件
（1）当书库中的各种书籍数量发生变化（包括进书和出书）时，都应修改相关的书库记录，如库存表或进/出库表。
（2）在实现上述销售和采购的工作过程时，需考虑有关的合法性验证。
（3）系统的外部项至少包括：
教师、学生和教材工作人员。
（4）系统的相关数据存储至少包括：
购书表、库存表、缺书登记表、待购教材表、进库表和出库表。
题目三：
机票预定系统
1．系统简介
航空公司为给旅客乘机提供方便，需要开发一个机票预定系统。
各个旅行社把预定机票的旅客信息（、性别、工作单位、（护照）、旅行时间、旅行始发地和目的地，航班舱位要求等）输入到系统中，系统为旅客安排航班。
当旅客交付了预订金后，系统打印出取票通知和帐单给旅客，旅客在飞机起飞前一天凭取票通知和帐单交款取票，系统核对无误即打印出机票给旅客。
此外航空公司为随时掌握各个航班飞机的乘载情况，需要定期进行查询统计，以便适当调整。
2．技术要求和限制条件
（1）在分析系统功能时要考虑有关证件的合法性验证（如、取票通知和交款发票）等。
（2）对于本系统还应补充一下功能：
1．旅客延误了取票时间的处理
2．航班取消后的处理
3．旅客临时更改航班的处理
（3）系统的外部输入项至少包括：
旅客、旅行社和航空公司。
题目四：
学校部工资管理系统
1．系统简介
假设学校共有教职工约1000人，10个行政部门和8个系。
每个月20日前各个部门（包括系和部门）要将出勤情况上报人事处，23日前人事处将出勤工资、奖金及扣款清单送到财务处 。
财务处于每个月月底将教职工的工资表做好并将数据送银行。
每个月3日将工资条发给每个单位。
若由员工调入或调出、校调动、离退休变化，则由人事处通知相关部门和财务处。
2．技术要求和限制条件
（1）本系统的数据存储至少包括：
工资表、部门汇总表、扣税款表、银行发放表等。
（2）除人事处、财务处外，其他职能部门和系名称可以简化表示。
（3）工资、奖金、扣款细节由学生自定义。
题目五：
实验室设备管理系统
1．系统简介
每学年要对实验室设备使用情况进行统计、更新。
其中：
（1）对于已彻底损坏的做报废处理，同时详细记录有关信息。
（2）对于由严重问题（故障）的要及时修理，并记录修理日期、设备名、编号、修理厂家、修理费用、责任人等。
升级会员 