软件工程作业 用例图,状态图类图
图书管理系统用例建模报告（用例图、类图、时序图）
软件系统分析与设计实验报告学院：计算机科学与技术学院专业：软件工程学号：*********姓名：***实验名称：图书管理系统用例建模时间：一、实验内容与要求本实验要求学生对学校的图书馆管理系统进行需求分析，对系统功能进行用例建模，画出用例图，类图以及相应的时序图。
在使用UML对系统建模时，学会使用UML建模工具，熟悉工具中的功能。
二、用例分析1、读者“借书还书系统”用例图(f书书(from Use Cases)1．1、行为者：主要行为者：读者。
1．2、前置条件：读者进入图书管理系统。
1．3、事件流：1.3.1、主要事件流：1.3.1.1：读者检索所需图书信息，并查看；1.3.1.2：读者检索到所需图书，登录系统，开始借书；1.3.1.3：系统查询图书信息，图书数目是否可借；1.3.1.3.1：图书显示可借，借书成功；1.3.1.3.2：图书显示不可借，借书失败；1.3.1.4：进入续借图书界面，续借图书；1.3.1.5：系统查看预约记录，1.3.1.5.1：没有冲突，续借成功；1.3.1.5.2：有冲突，续借失败；1.3.3.1：1.3.1.6：读者归还图书；1.3.1.6.1：归还时间没有逾期，归还成功；1.3.1.5.2：归还时间逾期，逾期处罚，归还成功；1.3.2、备选事件流：1.3.2.1：图书检索信息失败，未检索到图书，重新输入信息检索；1.3.2.2：未曾检索到用户检索的图书，系统显示相关联的信息的图书；1.3.2.3：用户名或密码输入错误，登录系统失败，重新输入用户名或密码登录；1.3.2.4：系统显示图书不可借后，进入图书预约界面，输入信息预约图书；1.3.3、异常事件流：1.3.3.1：读者登录系统失败，未曾注册用户；1.3.3.1.1：返回系统注册用户后，重新登录。
1．4、后置条件：退出系统。
1．5、1．6、扩展点：无。
2、“图书信息管理系统”用例图书书书书书书(f书书书书(from Use Cases)(from Use Cases)2．1、行为者：主要行为者：管理员；2．2、前置条件：管理员打开图书信息管理系统；2．3、事件流：2.3.1：主要事件流：2.3.1.1：图书管理员输入管理员登录信息，登录系统；2.3.1.2：进入图书信息管理界面，查看已有图书信息，是否有需要购入图书；2.3.1.2.1：录入新购进图书信息，并确认；2.3.1.3：进入读者信息管理界面，管理已有用户信息；2.3.1.4：进入信息通知界面，查看已有用户图书借阅、预约情况；2.3.1.4.1：查看读者所预约图书，自动查询图书信息，确认是否已有可借图书，有则通知读者；2.3.1.4.2：查询读者已借图书信息，根据已借时间及归还时间分类；2.3.1.4.2.1：所借图书即将逾期，启动系统提醒功能；2.3.1.4.2.2：所借图书已经逾期，启动逾期及处罚通知功能；2.3.2：备选事件流：2.3.2.1：管理员用户名或登录名错误，重新登录；2.3.2.2：需要购进新图书，存储信息，通知相关人员；2.3.2.3：读者预约图书没有可借图书，不予通知；2.3.2.4：预约通知提醒后，删除该预约记录；2.3.2.5：读者所借图书距离归还时间仍很久，无需通知；2.3.3：异常事件流：2.3.3.1：登录失败超过一定次数后，系统冻结该用户名，一段时间后可以重用；2．4、后置条件：退出系统；2．5、扩展点：无。
uml软件工程课程设计
uml软件工程课程设计一、课程目标知识目标：1. 掌握UML（统一建模语言）的基本概念、图示及其在软件工程中的应用。
2. 学会使用UML图（如用例图、类图、序列图等）来表达软件系统的结构和行为。
3. 了解软件工程的基本原则，理解UML在软件开发生命周期中的作用。
技能目标：1. 能够运用UML图进行软件需求分析，构建系统的逻辑模型。
2. 能够利用UML图进行软件设计，提高代码的可维护性和可读性。
3. 能够运用UML图进行团队协作，提高沟通与交流效果。
情感态度价值观目标：1. 培养学生对软件工程的兴趣，激发他们探究新技术的热情。
2. 培养学生严谨、细致的工作态度，提高他们解决实际问题的能力。
3. 培养学生团队协作精神，使他们认识到团队合作的重要性。
本课程针对高中年级学生，结合学科特点，注重理论与实践相结合，培养学生运用UML进行软件设计和分析的能力。
课程目标旨在让学生掌握UML的基本知识，提高他们在实际项目中的应用能力，同时培养他们的团队协作和沟通能力，为未来从事软件开发工作打下坚实基础。
通过本课程的学习，学生将能够更好地理解软件工程的概念，提高自身编程素养，形成积极的情感态度价值观。
二、教学内容1. UML基本概念与图示：包括UML的发展历程、基本组成元素、图示类型及用途。
- 教材章节：第一章 绪论- 内容列举：UML的定义、UML图分类、UML的基本元素（类、对象、关系、行为等）2. UML图的应用与实践：- 用例图：描述系统的功能需求，分析用户与系统的交互。
- 类图：表示系统中类的结构及类之间的关系。
- 序列图：描述对象之间的交互过程，展示动态行为。
- 状态图、活动图等其他UML图：分别描述对象的状态变化和活动流程。
- 教材章节：第二章至第五章- 内容列举：用例图、类图、序列图、状态图、活动图等UML图的基本概念、绘制方法及应用实例。
3. 软件工程原则与UML实践：- 教材章节：第六章 软件工程原则- 内容列举：软件工程的基本原则、UML在软件开发生命周期中的应用、UML与敏捷开发等。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
网上订购火车票系统uml类图时序图状态图协作图活动图对象图用例图.docx
（3）实吋信息修改：对于最新路况、车况信息进行修改。
数据管理模块
数据管理模块包括：
（1）数据杳看：対所有数据查看。
（2）数据备份：备份所有数据。
（3）数据恢复：恢复受损数据。
WML
项目名称： 网上订购火车票系统
项目组成员：
学 号：
班 级：
指导教师：
2008年11月10口
1需求分析1
1.1需求概述1
1.2需求分析2
1.3需求模型（用例图）6
动态模型
3.1时序图
3.2状态图16
3.3协作图17
3.4活动图18
4项目组成员分工说明19
5总结20
6参考资料21
1
1.1需求概述
线上预订火车栗系统是一款功能强大、操作简便、易维护的、具有良好人机交互界面的线 上订票系统，它包括用户管理模块、系统参数设置模块、票务信息模块（捉供票价、列车的实 时信息）、订票管理模块（提供订票和退订功能）、实时信息提示模块（提供车况、路况、歹U车晚点等实吋信息）、数据管理模块（提供数据备份、数据操作功能）=实现火车栗线上预定 的自动化的计算机系统，为旅客提供准确、精细、迅速的火车栗销售信息和方便、简单的订栗 功能。
（2）删除用户信息：管理员可以对已有用户信息进行删除操作。
（3）查看用户信息权限：每个用户都具有一定的权限，管理员可以查看用户的管理权限。
（4）修改用户信息权限：管理员可以修改用八的管理权限。
（5）删除管理权限：管理员在权限管理中可以删除管理权限。
（6）添加管理权限：管理员在权限管理中可以添加管理权限。
82静态模型21类图旅客姓名性别需求信息有效证件列车班次发车时间起点终点乘坐人数价格9火车站名称所在地订票票号班次号旅客号票价管理员密码姓名旅客表字段类型含义说明customernamestring旅客的名字旅客的名字customersexvarchar旅客的性别旅客的性别customerwantvarchar旅客的需求旅客的需求信息customeridenvarchar旅客的证件旅客的有效证件班次表字段类型含义说明traintimetime班次时间列车的发车时间trainstartvarchar班次起点列车的始发站trainendvarchar班次终点列车的终点站trainnumberint班次乘坐人数列车的乘坐人数trainpriceint班次价格本次列车的价格订火车票表字段类型含义说明orderidvarchar订火车票号主键pkorderfidvarchar班次号外键fkordercidvarchar旅客号外键fkorderpriceint票价外键fk10管理员表字段类型含义说明adminpasswordvarchar管理员密码管理员密码adminnamevarchar管理员姓名管理员姓名火车站表字段类型含义说明stationnamevarchar火车站名字火车站名字stationaddrvarchar火车站所在地火车站所在地22对象图1
用例图, 类图
Get Upload Files
Receive Data
Manage Log
Breake Connection
Time
18/336
1.用例图 (19/29)
•
20/336
21/336
22/336
1.用例图 (22/29)
23/336
24/336
1.用例图 (25/29)
智能电梯系统
25/336
1.用例图 (26/29)
Deal with Auditing Data
Auditing break connection
break connection
Server 17/336
1.用例图 (18/29)
• 学生课程注册系统例子
– 每个学生都可以增删改查自己的课程注册表 – 每个教师都可以查询课程花名册 – 学校管理人员可以维护全部课程，可以登记
Dat aObjec t
38/336
2.顺序图 (8/19)
40/336
2.顺序图 (9/19) 2.顺序图 (11/19)
41/336
: Actor
FormObject
1: Open form
ControlObject
DataObject
2: Enter information
3: Save informat ion
is displayed
4. Select a file
12/336
1.用例图 (12/29)
• 例子: 远程通讯
– 背景 – 任务
• 远程审核 • 远程客户端
Client
13/336
logon Request Data Receive Data
软件工程设计课程设计
软件工程设计课程设计一、课程目标知识目标：1. 让学生掌握软件工程的基本概念、原理和方法，理解软件生命周期的各个阶段及其任务；2. 培养学生运用UML图进行软件设计的能力，包括用例图、类图、顺序图和状态图等；3. 使学生了解软件设计模式的基本概念和分类，掌握至少三种常见的设计模式。
技能目标：1. 培养学生运用结构化分析方法进行问题分析，能独立完成软件需求规格说明书；2. 提高学生运用面向对象设计方法进行软件设计的能力，能根据需求规格说明书完成软件设计；3. 培养学生编写规范、高质量的代码，具备良好的编程习惯。
情感态度价值观目标：1. 培养学生热爱软件工程学科，树立从事软件工程相关工作的职业理想；2. 培养学生的团队合作意识，学会与他人合作共同解决问题；3. 培养学生严谨、认真、负责的学习态度，养成良好的学习习惯。
课程性质分析：本课程为高年级软件工程专业课程，旨在帮助学生系统掌握软件工程的理论知识和实践技能，提高软件项目开发能力。
学生特点分析：学生已具备一定的编程基础和软件工程基本知识，具有较强的学习能力和实践能力，但部分学生对软件工程的认识尚浅，需要加强引导。
教学要求：结合课程性质和学生特点，将课程目标分解为具体的学习成果，注重理论与实践相结合，强化实践操作，提高学生的实际应用能力。
在教学过程中，关注学生的个体差异，因材施教，激发学生的学习兴趣和潜能。
二、教学内容1. 软件工程概述- 软件与软件工程概念- 软件生命周期- 软件开发模型2. 需求分析- 需求分析概念与方法- 结构化分析方法- 需求规格说明书编写3. 软件设计- 面向对象设计方法- UML图（用例图、类图、顺序图、状态图等）- 设计模式（至少三种常见模式）4. 编码与测试- 编码规范与技巧- 单元测试与集成测试- 系统测试与验收测试5. 软件维护与项目管理- 软件维护策略与实施- 软件项目管理方法- 团队协作与沟通技巧教学大纲安排：第1周：软件工程概述第2-3周：需求分析第4-6周：软件设计第7-8周：编码与测试第9-10周：软件维护与项目管理教学内容进度：第1周：完成软件工程概述部分的学习；第2-3周：学习需求分析，完成需求规格说明书编写；第4-6周：学习软件设计，掌握UML图和设计模式；第7-8周：学习编码与测试，进行项目实践；第9-10周：学习软件维护与项目管理，进行团队协作与沟通训练。
UML第二章作业答案
1.UML如何表示类?类图标中可以指明哪些信息?类是描述一类对象的特征和行为，类图包含一组、接口及他们之间的关联、依赖和泛化的关系。
它不仅显示了信息的结构，同时还描述了系统对象的的行为。
2.什么是类的多重性(关联的基数)?多重性怎么表示?多重性是对象之间关联的一个重要方面，它说明了在关联中的一个类的对象可以对应另一个类的多个对象。
主要包含一组上下限数，用来指出可被允许生成的实例（instance）数量，即最多可以生成多少数目（上限），最少不得低于多少数目（下限）。
关联的两端以"下限..上限"的格式标示出多重性，如图2-12中的1..*。
星号（*）代表无指定上限，下限最低为0。
如果上下限数相同，标示出一个数目就可以了3.两者对象之间能够以多种方式关联吗？关联两边的"employee"和“employer”标示了两者之间的关系，而数字表示两者的关系的限制，是关联两者之间的多重性。
通常有“*”（表示所有，不限），“1”（表示有且仅有一个），“0...”（表示0个或者多个），“0，1”（表示0个或者一个），“n...m”(表示n到m个都可以),“m...*”（表示至少m个）。
在关联中有一种叫“限定关联”，还有一种谓之自身关联。
另外，对象之间的关联就没那么复杂，只是将类的关联实例化而已4.什么是约束？为什么要对类图附加注释？约束用来约束MUL成员的语义。
约束用举例在大括号内的条件来表示（｛contrraint｝），可以直接放在图中，类图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互5.聚集和组成之间有什么区别？聚合关系完全是概念上的，只是区分了整体与组成部分，没有改变整体与其组成部分之间的关联导航的含义，也没有将整体与部分的生命周期联系起来。
而组合是聚合的变种，整体与部分之间有很强的所有关系，也就是说，在组合关系中，一个对象一次只是一个组合的一部分，而在简单的聚合关系中，一个部分可以被好几个整体共享。
软件工程简答题
简答题：软件工程的内容和方法1.开发文档都有哪些用图来表示他们之间的关系;开发文档包括目标程序、源程序、详细设计说明书、概要设计说明书、需求规格说明书、用户需求报告、软件合同,它们之间的关系如图所示;2.;概要设计、版本升级;和RationalRose;软件管理过程主要有CMMI、ISO9000、微软企业文化和敏捷文化现象;3.请详细解释软件的定义和程序的定义;软件的定义：软件=程序+数据+文档;这里的程序是指程序系统;这里的数据不仅包括初始化数据、测试数据,而且包括研发数据、运行数据、维护数据,也包括软件企业积累的项目工程数据和项目管理数据中的大量决策原始记录数据;这里的文档指的是软件开发过程中的分析、设计、实现、测试、维护文档、管理文档;现在有一种新提法正在引起关注,这种提法是：软件=知识+程序+数据+文档;程序是计算机为完成特定任务而执行的指令的有序集合;从应用的角度可理解为：面向过程的程序=算法+数据结构面向对象的程序=对象+信息面向构件的程序=构件+构架4.是否存在这样一种现象：搞系统软件的公司不需要采用CMMI和ISO9000模式CMMI和ISO模式只适用于搞应用软件的企业如果是,为什么如果不是,又是为什么不是;因为CMMI和ISO9000模式规定了严格的管理制度、文档和评估软件能力与成熟度等级的一套标准,它们几乎包括了所有的IT的企业,只是一些优秀的企业自己内部形成特有的企业管理文化,但是它们并不排斥CMMI和ISO9000模式,甚至还充分肯定CMMI和ISO9000体系;5.根据学过的数据库编程经验,举出一个用创建视图的方法进行数据处理的例子;create view j1_spjasselect sno,sname,ssex from studentwhere sno = ‘s1’条件语句视图j1_spj的创建是依据基本表student进行查询;当基本表的记录符合条件语句where sno = ‘s1’规定的条件时,就能查询出基本表中符合条件记录的学号、姓名、性别的值;软件生存周期及开发模型6.简述瀑布模型、增量模型、迭代模型、原型模型的优点和缺点;无关;因为ISO9000或CMMI管理体系是一种过程与质量管理模型,它是适应于任何软件开发模型的,或者说它与任何开发模型无关;开发模型本身只是规定了软件生存周期中的若干步骤或阶段,便于开发人员去开发与维护,它并没有规定管理人员的过程管理方法与任务;为此,ISO9000或CMMI管理体系规定采取阶段评审和不符合项的动态跟踪制度,只有前一阶段的不符合项全部改正后,才允许开发人员进入后一阶段的工作;所谓不符合项,就是在评审中发现的问题项,它与BUG既有联系,又有区别;对于这些不符合项,软件管理部门要列出表格,记录在案,确定负责人,限定改正时间,动态跟踪到底;8.对生存周期模型裁减指南有什么看法“生存周期模型裁减指南”是IT企业或软件组织内部根据软件开发模型的普遍原则,结合本单位的开发经验和行业特点的具体实际定制出来的;它有针对性地对选定的软件开发模型中定义的生存周期,进行恰当地裁减;所谓裁减,就是队员模型中定义的内容进行增、改、删,去掉对本单位或者本项目不适合的部分,增加对本单元或者本项目适用的内容,同时进一步细化;这样可以缩短开发时间,减少开发成本,具有非常现实的意义;软件立项与合同9.什么叫风险分析技能风险和技术风险有何区别这里的风险分析是指软件立项过程中对产品开发、销售等可能出现的风险进行分析;分析方法是将一个大风险化解为多个小风险,然后再一个个克服小风险;技术风险是指采用新技术的风险程度;技能风险是指项目组成员掌握新技术的风险程度;两者的区别在于一个是说新技术如新的开发工具,新的设计思想本身的风险,一个是说人员要掌握这种新技术的风险;10.行业领域业务专家与产品经理有何异同行业领域业务专家是精通某行业领域业务的人,在讲标时能把投标书的内容准确、生动地表述出来,使客户心服口服;而产品经理是某产品需求分析和概要设计的经理或专家,主要负责产品的立项、需求、设计和销售等业务;两者的相同点是：必须精通该产品的功能、性能和接口;不同点是：前者突出熟悉产品的应用业务领域,后者突出熟悉产品的需求与设计; 软件需求11.需求分析的目的是什么需求分析的难点在哪里软件需求分析,其目的是用于说明软件产品或软件项目需要满足的条件和限制;在软件工程项目中首先要获取用户的需求,通过对软件需要的提取、分析、文档化及验证,为进一步的设计和实现提供依据;需求分析的难点是：在系统的功能、性能和接口方面,开发者与客户达成完全一致的需求,让客户最终签字确认,并保证在项目验收前,需求相对稳定不变;万一需求有一点变化,双方必须履行“需求变更管理程序”,而变更管理程序在签订合同时已经做了规定;要知道,合同是具有法律效力的;12.为什么说需求分析是面向流程的系统的功能、性能、接口、界面都是在流程中动态实时的反映出来;在所有的流程物流、人流、资金流、信息流、单据流、报表流、数据流中,数据流最重要,也最具有代表性;因为在计算机网络系统内,一切流程都表现为数据流,或者说是数据流在不同方向的投影;而流程是动态的、实时的;所以说,需求分析是面向流程的;13.需求分析的基本思路是什么需求分析的思路,是从客户的功能需求系统需要做什么出发,由系统的业务流程和数据流程导出系统的业务模型和功能模型,识别出系统的元数据和中间数据,为今后设计数据模型做好充分准备;同时,对系统的软、硬件环境配置,开发工具,开发周期,费用,开发进度,培训,系统风险进行评估;14.业界存在哪三种需求分析方法你认为哪一种更好业界存在三种需求分析方法：面向功能分析、面向对象分析、面向数据分析;以上这三种方法,各自适用于不同的目标系统;目前时尚的方法是面向对象分析,包括面向主体和面向方法;总的来说,对于系统软件和应用软件来说,面向功能需求分析的方法简单明了,而面向对象的需求分析方法则复杂抽象;对于以关系数据库为平台的信息系统软件来说,面向数据需求分析方法的特点是抓住了本质;但是,这三种分析方法都离不开面向流程分析这根总线：功能、对象、数据都是在流程中产生的,又都是为流程服务的;15.需求管理过程的目标和内容是什么需求管理的目标,是保证软件项目或产品满足客户在软件功能、性能、接口三个方面的需求;需求管理过程的内容,主要包括需求确认、需求评审、需求追踪和需求变更活动管理; 16.为什么需求文档要进行同行评审同行评审,是软件工作产品验证的活动,其目的是为了及早和高效地从软件工作产品中识别并消除缺陷;重点在于发现软件工作产品中的缺陷;另外,由于进行同行评审,使大量人员对软件系统中原本不熟悉的部分更加了解,因此同行评审还提高了项目的连续性,培训了后备人员;17.怎么理解不符合项为什么要对它进行跟踪管理不符合项是指没有满足要求的项,不一定是错误,跟bug是不同的;跟踪的意思在于,获得需求目前的实现状态,确保用户所有的需求都得到满足;可靠的跟踪信息可为需求变更、系统维护、关键成员离开、系统再设计和类似系统设计等很多方面,提供参考和指导,并可以减少风险和提高项目成功率;18.需求描述有哪几种工具你喜欢哪一种为什么需求描述工具包括数据流图、业务流程图、用况图、时序图、用户交互图、数据模型图和功能需求列表、性能需求列表、接口需求列表、界面需求列表等;选择哪一种描述工具,主要取决于问题域的本质特征;不同的软件,对分析要求的严格程度不同;我喜欢业务流程图,它包括了物流、资金流、信息流,即业务操作模型,重点是业务操作的流水步骤;业务模型表示了与系统有关的人、设备、其他子系统之间的业务关系和费用关系,它是经过业务流程重组、再创和优化后,并且得到企业领导确认的业务流程图;绘制这个图的工具可以是Office办公软件;软件策划19.简述软件策划的步骤;20.软件策划要实现的具体目标是什么软件策划是项目跟踪和监控的基础,是项目经理和高层经理管理项目的依据;软件策划要实现的具体目标有三个;1．对供项目测试和跟踪用的三个软件估计已建立文档;这三个评估是：➢工作产品规模估计➢工作量及成本估计➢计算机资源估计2．软件项目活动和约定是有计划的,并已建立文档;这里的活动,包括开发活动和管理活动;这里的约定,是指对项目的各种标准、规范、规程的约束;3．受影响的组和个人,同意他们对软件项目的约定;受影响的组和个人有：➢软件工程组项目组➢软件估计组➢系统测试组➢质量保证组➢配置管理组➢合同管理组➢文档支持组其中有的组可能只有一个人21.定义软件过程的含义是什么所谓定义软件过程,就是根据选定的生存周期模型,规定软件的开发阶段,及每一阶段的工作步骤和文档标准等内容;22.项目跟踪与监督的基础是什么在项目策划阶段,要为开发计划制定严格的评审流程;开发计划在经过组织批准生效后,将成为进行项目跟踪与监督的基础;23.软件开发计划书应该包括哪些内容软件开发计划书是软件策划的输出文档,它包括如下10各方面的内容：1．软件项目组的目的、范围、目标和对象;2．软件生存周期的选择与裁减;3．确定软件开发和维护的规范、方法和标准;4．软件工作产品的确定;5．对工作产品规模的估计;6．对工作量和成本的估计;7．关键计算机资源的估计和使用情况;8．项目的进度、里程碑和评审计划;9．风险的识别和评估;10．项目工程设计和工具的计划;24.怎样理解软件中的度量,它有何作用软件中的度量,是指对大量测量数据的统计分析;度量是按规定在项目进行过程中,需要采集的度量数据,以便量化地反映项目的进展情况,为管理者提供对项目进展的适当的可视性,同时度量数据是项目过程改善的基础数据,它们存放在测量数据库中;软件设计25.软件设计的输入/输出是什么对于签订合同的项目,软件设计的输入是用户需求报告/需求规格说明书,输出是概要设计说明书和详细设计说明书;对于立项的项目,软件设计的输入是需求规格说明书,输出是概要设计说明书和详细设计说明书;26.概要设计说明书和详细设计说明书有和区别概要设计说明书,一是要覆盖需求规格说明书的全部内容,二是要作为指导详细设计的依据;它注重框架上的设计,它是软件系统的总体结构设计、全局数据库包括数据结构设计、外部接口设计、功能部件分配设计、部件之间的内部接口设计,它要覆盖需求规格说明书中的功能点列表、性能点列表,接口列表;详细设计说明书,一是要覆盖概要设计说明书的全部内容,二是要作为指导程序设计的依据,它注重微观上和框架内的设计,它是各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计和其他详细设计等;两者的设计者不同,在一般情况下,概要设计说明书是由系统设计师负责,详细设计说明书则是由高级程序员负责;软件建模27.请简述UML的宏观建模思想和微观思想;UML的宏观建模思想是：以“9个模型”和“5张视图”为纲,以“9种图”为目,建立系统的UML模型;“9个模型”包括：业务模型、领域模型、用例模型、分析模型、设计模型、过程模型、部署模型、实现模型和测试模型;“9种图”包括：类图、对象图、用例图、顺序图、协作图、状态图、活动图、构件图、实施图;“5张视图”包括：用例视图、设计视图、进程视图、实现视图、实施视图;UML的微观建模思想是：基本结构模型、高级结构模型、基本行为模型、高级行为模型、体系结构模型5各方面,66个微观建模;基本结构模型包括：对类建模,对关系建模,对公共机制建模,对图建模,对类图建模;高级结构模型包括：对类的语义建模,对关系网络建模,对接口、类型和角色建模,成组的元素建模,对体系结构视图建模,对具体实例、原型实例建模,对对象结构建模;基本行为建模包括：对交互建模、对用例建模、对用例图建模、对交互图建模、对活动图建模;高级行为模型包括：对信号族建模、对异常情况建模、对状态建模、对进程和线程建模、对时间空间建模、对状态建模;体系结构建模包括：对构件建模、对实施建模、对协作建模、对模式和框架建模、对构件图建模、对实施图建模、对系统建模;一般而言,人们最常用的是建立系统的用例图、类图和顺序图;28.请简述UML的优点和缺点;UML的优点：1．UML语言使系统建模过程标准化、统一化、规范化;2．UML在整个软件开发过程中采用相同的概念和表示方法;3．UML采用图形化的表现形式,产生的模型易于理解,易于开发人员与用户之间的沟通,从而能够及时得到用户的反馈信息;4．用UML进行系统建模,所得到的建模制品不仅包括各种模型框图,还有大量丰富的文档;5．UML不是一门程序设计语言,但可以使用代码生成工具将UML模型转换成为多种程序设计语言代码,或使用反向生成工具将程序源代码转换为UML模型但任何事物都有正反两个方面,UML这种新兴的建模工具也存在它本身的一些不足和缺点：1.UML建模可视化图形的内容太多、太深、太宽,导致难学难教;2.UML缺少核心和外围,有些语言定义不够精确且带有二义性;3.UML过多考虑了各种分析、设计、实现的普遍性,过少考虑了它们的特殊性;4.UML过于细致;5.UML对开发者的素质要求过高;29.读者怎样理解下面这段文字：“UML只是一种图形化的建模语言,不是一种方法论,不规定开发者在什么时候、什么情况下、用什么方法去建立什么模型,也没有指定使用哪一种实现工具,Rose只是其中的一种实现工具而已;”请读者再思考一个问题：语言与方法论两者之间有什么联系又有什么区别因为UML认为开发者在什么时候、什么情况下、用什么方法去建立什么模型是软件开发过程中的工作,是方法论的范围,开发者自己应该会明白的;而Rose是UML的一种支撑环境和实现工具;语言只是方法论的一部分,而且只是实现方法论的一种工具,方法论包含语言;方法论要告诉读者在建模过程中做什么、怎么做、什么时候做、为什么做、做的过程中要注意什么;而UML建模语言只是提供了一大堆的可视化图形符号,并没有告诉读者,应该在什么时候,用什么方法、去建立什么模型;软件实现30.实现原则有哪几条软件实现原则包括以下5条：1．尽可能地简单;2．易于验证;3．适应变化;4．遵守某一编程规范;5．选择项目组成员最熟悉的工具或语言;31.面向对象程序设计的特点是什么它与面向过程程序设计有何差异面向对象程序设计有三个特点：1．封装性;把数据和代码结合在一起,对外隐藏了实现的细节;它的好处是有利于程序的模块化;2．继承性;一个新的对象能继承父对象的属性和方法,这一点就像遗传;继承性的好处是可以共享代码;3．多态性;就是一个对象类型可以产生多个对象实例,每个实例还可以有所不同;面向对象程序设计与面向过程程序设计有如下差异：1．面向过程程序设计方法采用函数或过程来描述对数据的操作,但又将函数与其操作的数据分离开来；面向对象程序设计方法将数据和对数据的操作封装在一起,作为一个整体来处理;2．面向过程程序设计方法以功能为中心来设计功能模块,难于维护；而面向对象程序设计方法以数据为中心来描述系统,数据相对与功能而言具有较强的稳定性,因此更易于维护;3．面向过程程序的控制流程由程序中预定顺序来决定；面向对象程序的控制流程由运行时各种事件的实际发生来触发,而不再由预定顺序来决定,更符合实际需要;4．面向对象程序设计方法可以利用框架产品如MFC,Microsoft Foundation Classes进行编程;软件测试32.软件测试的目的和目标是什么简单明了地说,软件测试的目的就是发现软件缺陷;但同时还要时刻牢记在心的是：软件测试的目标是尽可能早地发现软件缺陷,并确保其得以修复;这里的缺陷,包括bug和不符和项;33.什么是软件缺陷我们说,符合下列五个规则之一的就是软件缺陷：1．软件未达到产品说明书需求报告或需求说明书标明的功能；2．软件出现了产品说明书指明不会出现的错误；3．软件未达到产品说明书未指明但应达到的目标；4．软件功能超出产品说明书所指明的范围；5．软件测试人员认为软件难以理解、不易使用、速度缓慢,或者最终客户认为不好; 34.试举例说明软件测试的原则有哪些1．尽早开展测试工作；2．完全测试不可能,把握最优测试量；3．严防寄生虫现象；4．严防杀虫剂现象；5．并非所有的软件缺陷都能修复；6．难以说清楚的软件缺陷；7．产品说明书不断变化8．软件测试人员在产品小组中不受欢迎;35.试阐述软件测试V模型的思想、不足之处和改进方法;软件测试V模型的基本思想,如图所示;我们可以初步了解,左侧是开发阶段,右侧是测试阶段;开发阶段先从定义软件需求开始,然后要把这些需求不断地转换到概要设计和详细设计中去,最后形成程序代码;测试阶段是在代码编写完成以后,先做单元测试开始,然后是集成测试、系统测试和验收测试;对V模型的进一步阐述是：当需求分析完成后,验收测试计划也应完成;当概要设计完成后,系统测试计划也应完成;当详细设计完成后,集成测试计划也应完成,当编码完成后,单元测试计划也应完成;可见,V模型提高了测试的时间与地位;以上的测试V模型,一般只适用于瀑布开发模型,若对迭代开发模型,就显得不足了;实际工作中,V模型只是提高了测试工作的地位,具体测试方法,仍然是黑白盒子法;36.试说出几种软件测试的分类方法;软件测试分类的实质,是软件测试技术的分类;测试工作中采用不同的测试技术,就产生了不同的测试类型,相继也产生了很多的测试类型术语,大概有以下几种;1．动态测试：通过运行程序开展测试工作,即软件测试人员通过使用软件来找出缺陷；2．静态测试：不通过运行程序来开展测试工作；3．黑盒测试：又叫功能测试；4．白盒测试：可以理解为对程序执行路径的测试；5．通过测试：简单的说,就是验证软件至少能做什么,而不会考察其能力有多强；6．失败测试：纯粹是为了验证软件在某一种条件下,是否会出现异常、停止工作等现象的测试；7．负载/压力测试：一方面,可以通过减少软件需要的资源,来测试软件运行的最低配置或者最低资源需求；另一方面,可以正常提供软件需要的资源,但是通过不断加重软件要处理的任务,来测试软件在正常配置下具有的能力指标；8．易用性测试：易用性测试的目的很明确,即简单易用,但是标准不容易确定；9．其他测试：如边界值测试、兼容性测试、回归测试、ALPHA测试和BETA测试等;37.试说出黑盒测试和白盒测试的区别及联系;黑盒测试又称功能测试;在这里,盒子指的是被测试的软件,“黑盒”就是只知道被测试软件的外部情况,主要是界面和接口,被测试软件的内部逻辑结构和数据结构,对测试人员来说是不可见的,主要关注被测试软件的功能实现;白盒测试就是对程序执行路径的测试,又叫做玻璃盒测试、透明盒测试、结构化测试、开放盒测试、基于代码的测试等;黑盒测试和白盒测试的联系是：一般宏观上用黑盒测试,微观上用白盒测试,系统集成人员用黑盒测试方法对系统进行测试,构件开发人员用白盒测试方法对构件进行测试,这是常用的测试方法;38.软件测试工作中要验证哪些文档试举例;软件测试工作中要验证的文档包括两个部分,即被测试文档和测试工作中要编写的文档;现在按生命周期划分如下：1．项目立项阶段的文档项目立项报告、标书、合同;2．需求分析阶段文档需求分析说明书/用户需求报告、验收测试设计说明书、测试计划、客户手册、操作手册;3．项目策划阶段的文档项目开发计划、配置管理计划、质量保证计划;4．设计阶段的文档概要设计说明书、数据库设计说明书、详细设计说明书、系统测试设计说明书、集成测试设计说明书;5．编码阶段的文档自测报告、单元测试说明书;6．测试阶段的文档单元测试报告、集成测试报告、系统测试报告/ALPHA测试、验收测试报告/BETA;7．维护阶段的文档缺陷及修改报告;还有一些管理文档,如工作日报、会议记录、开发进度周报、开发进度月报、开发总结报告等;还有和客户签署的协议,如委托开发协议书、验收手册;提供给客户的所有文档都要经过测试,从这个角度考虑,被测试的文档还可能包括联机帮助文档、样例、模板、常见问题解答、市场宣传材料、授权/注册登记表、客户许可协议,以及包装文字、图片、标签等;39.用自己的话简述实用软件测试的流程,你认同吗有什么想法和建议软件测试的流程分五步展开：1．理解、验证和分解需求；2．编写测试计划包括测试计划；3．测试执行；4．专项测试；5．编写测试报告;认同,没有什么想法和建议;软件发布与实施40.软件项目与软件产品有什么不同软件产品是指不局限于特定业务领域、能被广大用户直接使用的软件系统,如操作系统、编译系统、工具系统、通用财务系统等;软件项目是指针对特定业务领域、徐提供业务流程充足与优化的软件系统,如MIS、ERP、电子商务、自动跟踪控制系统等,它们一般叫做软件项目;软件维护41.传统软件维护分哪几大类传统软件维护分四大类,分别是：纠错性维护；适应性维护；完善性维护；预防性维护;42.简述软件维护的工作程序;软件维护的工作程序与软件开发的工作程序相仿;其工作程序是：维护的需求分析、维护的设计、修改程序代码、维护后的测试、维护后的试运行、维护后的正式运行、维护过程的评审和审计;43.可维护性的软件应具备什么性质所谓软件的可维护性,就是维护人员理解、掌握和修改被维护软件的难易程度;可维护性的软件,必须具备下列4条性质：可理解性、可测试性、可修改性和可移植性;44.面向缺陷维护的内容是什么面向缺陷维护的内容是：该软件产品能够正常运行,可以满足用户的功能、性能、接口需求,只是维护前在个别地方存在缺陷,用户不是非常满意;克服缺陷的方法是修改程序,也就是通常说的只修改程序,不修改数据结构;45.面向功能维护的内容是什么面向功能维护的内容是：该软件产品在功能、性能、接口上存在某些不足,不能满足用户的某些需求,因此需要增加某些功能、性能、接口;解决这些不足的方法是,不但要修改设计,而且也要修改程序,也就是通常说的既修改数据结构,又修改编码;46.怎么理解UML对软件维护的重大影响UML的功能覆盖整个软件的开发周期,从需求分析开始,直到软件的发布、实施和维护为止,因而它对传统意义下的维护工作产生重大影响;UML把软件生存周期定义为4个主要阶段：初始、细化、构造、移交;经过这4个阶段的历程被称为一个开发周期,自动产生一个周期内的所有文档,从而生成一个软件产品;首次经历着4个阶段称为该产品的初开发周期,除非该产品的生命终止,否则它将重复初始、细化、构造和移交这4个阶段,从而演化为下一代产品,这就是对旧有产品的维护,也是新产品的升级换代,也就是开发周期的演化,也就是UML对软件维护工作的影响;软件过程管理47.怎样理解“软件组织、工作产品、软件过程、软件过程资源、软件过程财富”的概念软件组织：CMM/CMMI中的“组织”或“软件组织”,是指软件企业或软件公司自己;。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
v1.0 可编辑可修改
软件工程设计方案
学院计算机学院
专业软件工程
班级 2012 级 4 班
学号 86
姓名黎伟杰
指导教师崔洪刚
（ 2015 年 1 月）
v1.0 可编辑可修改
计算机学院软件工程专业12级4班班学号：86
姓名：黎伟杰协作者：________ 教师评定：
问题定义：为实现一个功能强大的学生宿舍管理信息系统，它主要实现对入住人员的管理及对宿舍的其它管理，如新生、老生的基本信息处理，毕业生退宿，水、电费的超额处理。
该系统功能齐全，操作简便，实用性强，主要包括三个模块：资料管理模块、宿舍管理模块、收费管理模块最后还给出实现的设计思想和关键技术。
系统名称：学生宿舍管理系统
作者名称：广东工业大学计算机学院软件工程12（4）班
86 黎伟杰
系统功能描述：随着计算机的应用与普及，现在越来越多的学校学生宿舍都是利用计算机来控制和管理的，学校的不断发展，人数的不断增长，生活水平的提高，要求也越来越高。
为了改善学校的宿舍管理，为此开发了学生宿舍管理信息系统软件。
本系统要学生用户对它进行查询，管理员有效地对它进行管理用户，即随时可以对它进行添加与删除，在没有旁人指导的情况下，用户也可以进入这个系统并且知道该如何使用它，比如，用户点击进入后就会出现一个系统登陆对话框，根据用户的用户名和密码，点击“登陆”按钮，就可进入系统。
这个系统可以适用于各大院校，具有管理权限的用户可以对系统进行修改，
没有此权限的用户只能对系统进行查询。
用例图：
数据流图：
状态图：
时序图：
类图：。