应用软件设计2UML建模实例
软件架构实验UML建模
通过分析参与者的活动，可以初步确定这样一些用例：
（1）查询信息，（2）学生管理，பைடு நூலகம்3）宿舍分配，（4）住宿管理，（5）基础数据管理，（6）财务管理，（7）时钟支持。
根据前面的需求分析，针对本实验分别建立系统的用例视图（Use-Case View）、逻辑视图（Logical View）。
分析用例，从用例中寻找对象和类。例如，通过分析宿舍分配管理子系统，可以发现以下实体类：学生、宿舍管理员、班级、楼栋、床位等。建立类图。
2.1、静态分析阶段，通过分析该系统的子系统，寻找出实体类，并建立类图。（由于子系统较多，所以就以上述所举的例子宿舍分配管理子系统为例建立类图）
2.2、系统的动态分析——用顺序图表示用例的实现，画出高校学生宿舍管理系统的登录顺序图。（以宿舍管理员登录管理系统进行住宿管理为例画出登录顺序图）
四、实验要求
1、根据上述描述中确定的用例，自己确定每个用例的参与者，并画出关于高校学生宿舍管理系统的用例视图（Use-Case View）。
2、逻辑视图（LogicalView）关注系统是如何实现用例中所描述的功能的，主要是对系统功能性需求提供支持，即在为用户提供服务方面，系统所应该提供的功能。在逻辑视图中，用户将系统更加仔细地分解为一系列的关键抽象，将这些大多数来自于问题域的事物通过采用抽象、封装和继承的原理，使之表现为对象或对象类的形式，借助于类图和类模板等手段，提供系统的详细设计模型图。类图用来显示一个类的集合和它们的逻辑关系有关联、使用、组合、继承关系等。
2.3、利用UML的活动图工具进行工作流程建模，画出学生入住业务流程（活动图）。（提示：
学生的入住业务流程，一般来说是，学生先到宿舍管理中心申请入住，然后学生到财务管理中心尽心缴费，宿舍管理中心回到学生管理中心进行学生信息的核对，如果学生缴费成功并且学生管理中心的学生身份认证正确，那么宿舍管理中心就给学生分配宿舍，否则，任何一个环节出现错误就会取消入住。）
uml基础案例与应用
uml基础案例与应用UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言。
它提供了一种统一的、标准化的表示方法，可以帮助开发人员更清晰、更准确地描述和设计软件系统。
下面列举了十个基于UML的案例与应用：1. 用例图（Use Case Diagram）：用例图是UML中最常用的图之一，用于描述系统的功能和行为。
它通过显示系统与外部实体之间的交互来帮助开发人员理解系统的需求和功能。
2. 类图（Class Diagram）：类图是描述系统中类和类之间关系的图。
它展示了系统中的类、类的属性和方法，以及类之间的关系，如继承、关联、聚合等。
类图可以帮助开发人员理解系统的结构和组织。
3. 对象图（Object Diagram）：对象图是类图的实例化，用于描述系统中对象之间的关系。
它展示了系统中的对象、对象的属性和方法，以及对象之间的关系。
对象图可以帮助开发人员理解系统的运行时状态。
4. 序列图（Sequence Diagram）：序列图是描述系统中对象之间交互的图。
它展示了对象之间的消息传递顺序，以及消息的参数和返回值。
序列图可以帮助开发人员理解系统的动态行为和时序关系。
5. 状态图（State Diagram）：状态图是描述系统中对象状态和状态转换的图。
它展示了对象在不同状态之间的转换条件和动作。
状态图可以帮助开发人员理解系统的状态变化和行为逻辑。
6. 活动图（Activity Diagram）：活动图是描述系统中活动流程和业务流程的图。
它展示了活动之间的控制流和数据流，以及活动的并发和同步。
活动图可以帮助开发人员理解系统的工作流程和业务逻辑。
7. 组件图（Component Diagram）：组件图是描述系统中组件和组件之间关系的图。
它展示了系统中的组件、组件的接口和依赖关系。
组件图可以帮助开发人员理解系统的组件结构和模块化设计。
8. 部署图（Deployment Diagram）：部署图是描述系统中硬件和软件部署的图。
2统一建模语言UML
出现的方式
多态性
(section 2.3.2)
capturing use of single action word to represent different things,
depending on context根据上下文，捕获单一行为词表示的不同内 容
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
图
2.1面向对象开发方法
面向对象的目标： 为实现现实世界和设计中的结构单元间提供直接映射。 基本概念： 类，对象，聚集，消息，客户 面向对象方法的优势： 面向对象的特点：继承，多态，接口，封装 简化开发过程 支持软件复用 改善软件结构
面和向对象以前
Real world concepts
第二章 统一建模语言UML
主要内容
面向对象的设计开发方法 面向对象的目标 面向对象的概念 面向对象的特点 面向对象方法的优势
UML概述
UML的产生发展 UML的基本组成
UML建机制
UML静态建模 类图，对象图，包图，构件图，组合结构图，部署图 UML动态建模 活动图，顺序图，通信图，交互图，时序图，状态图，用例
继承
相对于结构化编程中 的模块重用，面向对 象中的继承体系显得 更灵活，对代码的控 制手段更多，从而推 动了代码复用的程度， 但却加大了学习掌握 的难度。
电子邮件创建示例的需求 Page 1 of 4
1. 概要: Produces e-mail text for various types of customers.给不同类型的用户撰写 电子邮件
UML 建模设计 航 空 订 票 系 统
UML 建模设计航空订票系统姓名：卫飞班级：1528学号：201515614375一、背景1.1背景概述随着知识经济的到来，人类已经逐步进入信息化社会，信息增长的速度越来越快，人们希望利用先进的管理理论方法手段来得到并处理越来越多的信息，以提高工作效率和管理水平。
由于信息资源对人们生活的重要性，不断提高信息的收集，传输，加以利用等活动，日益成为人们社会生活的重要组成部分。
网上机票预订管理系统的产生和发展正好满足人们的这种需求1.2 主要组成及功能1、新用户注册，新用户可以注册，注册时输入用户名可以查询用户可不可用，可用就可以注册，注册时可以判断用户输入的密码和验证密码是否相同，相同才给以注册，如果满意可以点注册，注册成功后用户可以选择不用在回到登陆界面，可以直接陆到用户主界面，以后就可以用这个用户登录了，如果不满意，点取消，所有信息清空，重新输入。
2、验证登陆名密码，正确进入主菜单，根据登录时所选的登录方式（客户、管理员）的不同分别对用户设定不同的访问权限（如果是输入的客户用户名和密码正确，选择以客户方式登陆则主界面里面的管理员界面不能用，如果输入的是管理员的相应用户密码正确，以管理员的方式登陆则管理员界面可用）不正确则清空登录框，最多可以输入三次，三次不正确系统会自动关闭3.我的航班界面。
你可以点击你想查询的有关机票的信息的按钮（舱位信息查询，客机信息查询，航线查询，客户类型信息查询）获得相关信息的表，根据表的内容，你可以在下面的下拉框中选择你要定的票信息，点确定后在下面会显示你的机票的相关内容，如果满意可以点击订票，把相关信息添加到机票数据库表中，如果不满意，可以点重置，所有信息清空，再重新选择。
4.退票功能。
用户可以根据用户信息表中的我的机票信息查询，找出机票号，在输入到机票号查询里，点击查询获得你的机票信息以及价格显示，点击退票则在数据库机票信息表中删除本条信息二、使用Rose绘制图分别有：用例图、类图、包图、顺序图、协作图、状态图、活动图、组件图、部署图情景：机票预订系统是某航空公司推出的一款网上选票系统。
UML完整例子
• “计算机类”、“非计算机类”是该系统中图书
的两大分类，因此应该对其建模，并改名为“计 算机类书籍”和“非计算机类书籍”，以减少歧
义；、
火龙果 整理
筛选备选类
• “外借情况”则是用来表示一次借阅行为， 应该成为一个候选类，多个外借情况将组 成“外借情况列表”，而外借情况中一个 很重要的角色是“朋友”—借阅主体。 • 虽然到本系统中并不需要建立“朋友”的 资料库，但考虑到可能会需要列出某个朋 友的借阅情况，因此还是将其列为候选类。 为了能够更好地表述，将“外借情况”改 名为“借阅记录”，而将“外借情况列表” 改名为“借阅记录列表”；
火龙果 整理
需求描述
• 在使用该系统录入新书籍时系统会自动按 规则生成书号，可以修改信息，但一经创 建就不允许删除。 • 该系统还应该能够对书籍的外借情况进行 记录，可对外借情况列表打印。 • 另外，还希望能够对书籍的购买金额、册 数按特定时间周期进行统计
火龙果 整理
火龙果 整理
4.绘制交互图
• 首先根据自己的喜好和实际的表现需要来 • 不过由于它们在语义上是等价的，因此可
以绘制出一种，再通过建模工具来自动转 换成另一种图 。 选择顺序图或通信图。
火龙果 整理
（1）准备工作
• 分析模型中的交互图彻重于分析类的职责分配
•
一本书只有一册，因此只能够被借一次，因此对于一本 Book而言只能有一个RecordId与其对应
火龙果 整理
限 定 • 分 析
火龙果 整理
3.绘制用例图
• 用例图的绘制流程
（1）记录需求—特性表
编号 说明
火龙果 整理
火龙果 整理
UML完整例子
使用UML对系统进行建模
使用UML对系统进行建模面向对象的软件工程，同传统的面向过程的软件工程相比，在需求的获取、系统分析、设计和实现方面都有着很大的区别。
UML是OOA和OOD的常用工具。
使用UML来构建软件的面向对象的软件工程的过程，就是一个对系统进行不断精化的建模的过程。
这些模型包括用例模型、分析模型、设计模型，然后，我们需要使用具体的计算机语言来建立系统的实现模型。
当然，在整个软件工程中，我们还需要建立系统的测试模型，以保证软件产品的质量。
使用面向对象的工具来构建系统，就应该使用面向对象的软件工程方法。
然我，我们经常会发现，在实际的开发过程中，很多开发人员虽然能够理解UML的所有图形，却仍然不能得心应手的使用UML来构建整个项目，其很大的原因，是仍然在使用原有的软件工程方法，而不清楚如何使用UML来建立系统的这些模型，不清楚分析和设计的区别，以及他们之间的转化。
应用软件系统，就其本质来说，是使用计算机对现实世界进行的数字化模拟。
应用软件的制造过程，按照UML的方法，就是建立这一些列模型的过程。
本文将就一个图书馆系统，说明如何使用UML来对系统进行这一系列的建模。
关于这个图书馆系统，基本的需求比较简单，就是允许学生可以在图书馆借阅和归还图书，另外，也可以通过网络或者图书馆的终端来查阅和预订书。
当然，图书馆管理员也可以对图书进行管理。
为了简化系统，我们没有把图书馆中的人员作细分。
之所以采用这个相对简单案例，是因为很多人都对图书馆系统有很强的感性认识，这样，读者不需要花很多的时间来理解系统包含的业务知识。
同时，也因为本文只是对使用UML 的过程做一个探讨，着眼于使用UML进行建模的过程，说明各个层次的模型之间的区别和联系，展示系统演进的过程，而不会深入UML的细节方面。
对于更加复杂的系统，其分析和设计的方法是相通的，可以举一反三。
用例模型——系统需求的获取用例模型定义系统做什么，是用来获取系统需求的有效手段。
用例模型由“角色”和“用例”组成。
UML完整例子
FEAT09
FEAT10 FEAT11 FEAT12 FEAT13 FEAT14
记录外借情况
外借状态能够自动反应在书籍信息中 按人、按书查询外借情况 列出所有的外借情况 按特定时间段统计购买金额、册数 所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行
火龙果 整理
（3）合并需求获得用例
特性 用例 FEAT01.新增书籍信息 UC01.新增书 FEAT03.书籍信息按计算机类、非计算机类分 籍信息 别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同 的书号规则 FEAT06.录入新书时如果重名将自动提示 FEAT02.修改已有的书籍信息 UC02.修改书 籍信息
书籍 计算机类书籍 非计算机 类书籍 借阅记录 借阅记录列表 书籍列表
在使用“名词动词法”寻找类的时候，很多团 队会在此耗费大量的时间，特别是对于中大型项目，
这样很容易迷失方向。其实在此主要的目的是对问
题领域建立概要的了解，无需太过咬文嚼字
火龙果 整理
（4）关联分析，建模，多重性分析，再建模
火龙果 整理
筛选备选类
• “购买金额”、“册数”都是统计的结果， 都是一个数字，因此不用将其建模，而 “特定时限”则是统计的范围，也无需将 其建模；不过从这里的分析中，我们可以 发现，在该需求描述中隐藏着一个关键 类—书籍列表，也就是执行统计的主体。
（3） 得到候选类
火龙果 整理
•
一本书只有一册，因此只能够被借一次，因此对于一本 Book而言只能有一个RecordId与其对应
火龙果 整理
限 定 • 分 析
火龙果 整理
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.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
E2.点击重新填写，执行B1;
被包含的用例 此用例所包含的用例列表
被扩展的用例 注销，收取罚金
图书管理员用例图
借阅者用例图
系统管理员用例图
2.医院病房监护系统
一1 、问问题题引描入述
为了对危重病人进行实时监护，随时了解病人病情，及时 进行处理，建立病房监护系统。
病症监视器安置在每个病床，通过网络将病人的病症信号 （组合）实时传送到中央监护系统进行分析处理。
在中心值班室里，值班护士使用中央监护系统对病员的情 况进行监控，监护系统实时地将病人的病症信号与标准的病诊 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 并打印病情报告和更新病历。
系统根据医生的要求随时打印病人的病情报告，系统定期 自动更新病历。
2.医院病房监护系统
监视病情
产生 病情报告
哪里去？ ⑶ 执行者需要系统提供哪些功能？ ⑷ 执行者是否需要对系统中的信息进行读、创建、修改、
删除或存储？
通过分析可以初步识别出系统的用例为：中央监护，病 症监护，提供标准病症信号，病历管理，病情报告管理。顶 层用例图为：
顶层用例图
用例描述 用例“中央监护”描述模板
用例名： 中 央 监护
执行者（参与者）： 值班护士、医生
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四 个角色：值班护士，医生，病人，标准病症信号库。
角色：病 人 角色职责： 提供病症信号
角色职责识别：
负责生成、实时提供 各种病症信号。
角色：医 生 角色职责：
对病人负责，负责
处理病情的变化
角色职责识别： (1)需要系统支持以完 成其日常工作 (2)对系统运行结果感 兴趣
▪ 当系统改变状态时，是否通知参与者？——是 ▪ 是否存在影响系统的外部事件？——否
1. 图书馆管理系统
❖ （1）读者请求服务的用例
▪ 登录系统 ▪ 查询自己的借阅信息 ▪ 查询书籍信息 ▪ 预订书籍 ▪ 借阅书籍 ▪ 归还书籍
❖ （2）图书馆管理员处理借书、还书的用例
▪ 处理书籍借阅 ▪ 处理书籍归还（归还处理） ▪ 处理预订信息
用例描述： 对病人的病症信号进行监测、处理，超过极限报警。
功能描述： 1.分解信号：将从病症监护器传送来的组合病症信号分解为系统可以处理的 信号。 2.比较信号：将病人的病症信号与标准信号比较 。 3.报警：如果病症信号发生异常（即高于峰值），发出报警信号。 4.数据格式化：将处理后的数据格式化以便写入病历库 。
❖ 系统需要处理哪些硬设备？ 没有特殊的硬设施
❖ 系统需要和哪些外部系统交互？ 无外部系统
❖ 谁对系统运行产生的结果感兴趣？ 图书管理员 读者
❖ 时间、气温等内部外部条件？ 时间
1. 图书馆管理系统
❖ 识别用例
▪ 特定参与者希望系统提供什么功能？——读者业务、借还 书业务
▪ 系统是否存储和检索信息，如果是，由哪个参与者触 发？——借阅管理员，读者
用例图在需求分析中的应用
识别参与者
确定用例
用例描述
用例建模
案例应用
❖ 图书馆管理系统中的用例图 ❖ 医院病房监护系统用例图 ❖ 客户服务系统中的用例图
1. 图书馆管理系统
1 问题引入
❖ 确定系统涉及的总体信息
▪ 图书馆管理系统是对书籍的借阅及读者信息进行统一管理 的系统，具体包括：
• 读者的借书、还书、书籍预订 • 图书管理员的书籍借出处理、书籍归还处理、预订信息处理 • 系统管理员的系统维护，增加书目、删除或更新书目、增加
1. 图书馆管理系统
❖ （3）系统管理员进行系统维护的用例 ❖ 查询借阅者信息 ❖ 查询书籍信息 ❖ 增加书目 ❖ 删除或更新书目 ❖ 增加书籍 ❖ 添加借阅者账户 ❖ 删除或更新借阅者账户
处理书籍归还
描述项
说明
用例名称 用例描述
归还处理 图书馆管理员输入图书编号进行图书归还
参与者
图书馆管理员
前置条件
图书馆管还信息
基本操作流程
B1. 图书管理员输入图书编号; B2. 点击“查询”
B3. 系统显示该书借阅信息（书名,ISBN，借阅时间，应归还时间 ）,若超时，则执行E1;
B4. 图书管理员点击“归还”; B5. 系统提示“归还成功”。
备选操作流程 E1.收取罚金
书籍、减少书籍、维护读者账户信息、书籍信息查询、读者 信息查询等
1. 图书馆管理系统
2 解答问题
1.1 识别系统的参与者
❖ 谁使用系统的主要功能？ 图书管理员
❖ 谁改变系统的数据？ 图书管理员
❖ 谁从系统获取信息？
图书管理员 读者
❖ 谁需要系统的支持以完成日常工作任务？ 图书管理员
❖ 谁负责维护、管理并保持系统正常运行？ 系统管理员
经过初步的需求分析，得到系统功能要求：
1. 请监视对病系员统的需病求症（进血行压分、析体！温、脉搏等）
2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
更新病历
2.医院病房监护系统
系统名称：医院病房监护系统 根据分析系统主要实现以下功能：
1、病症监视器可以将采集到的病症信号（组合），格式化 后实时的传送到中央监护系统。 2、中央监护系统将病人的病症信号分解后与标准的病症信 号库里的病症信号的正常值进行比较，当病症出现异常时系 统自动报警。 3、当病症信号异常时，系统自动更新病历并打印病情报告。 4、值班护士可以查看病情报告并进行打印。 5、医生可以查看病情报告，要求打印病情报告，也可以查 看或要求打印病历。 6、系统定期自动更新病历。
2.医院病房监护系统
2 解答问题
1. 通过以下六个问题识别角色 (1)谁使用系统的主要功能？ 值班护士、医生、病人 (2)谁需要系统的支持以完成日常工作任务？ 值班护士、医生 (3)谁负责维护，管理并保持系统正常运行？ 系统管理员 (4)系统需要应付（或处理）哪些硬设备？监护器,网络,报警系统 (5)系统需要和哪些外部系统交互？标准病症信号库、病历库 (6)谁（或什么）对系统运行产生的结果（值）感兴趣？ 同(2)
角色：值班护士 角色职责： 负责监视病人的病 情变化 角色职责识别：
(1)使用系统主要功能 (2)对系统运行结果感 兴趣
角色:标准病症信号库 角色职责： 负责向系统提供病症 信号的正常值
角色职责识别： (1)负责保持系统 正常运行 (2)与系统交互
识别用例
回答下面的问题： ⑴ 与系统实现有关的主要问题是什么？ ⑵ 系统需要哪些输入/输出？这些输入/输出从何而来？到