用例建模系统需求
UML网络教学系统—
（3）系统管理员参与者的用例图 另外网站需要一个专门的管理者进行日常 维护与管理，所以需要有系统管理员的参 与。
Page MainTenance
CAI Process
Administrator
Information Update
Process Registration
• 说明： • 页面维护（Page Maintenance）：系统管理员可以对网站进行日常 维护与管理。 • 处理注册申请（Process Registration）：系统管理员可以处理学生或 教师用户的注册申请。 • CAI Process用例：教师上传的课件经过系统管理员的审批和处理 • 页面更新（Information Update）：系统管理员负责网站的页面更新， 除了文章，消息，图片等的更新，还包括页面的美化和板块的调整。
Look throgh info Student
Artical seach
• 说明： • 文章浏览用例（Look through info）:学生可以浏览诸如课程简介，教学 计划，学习方法等教师发布的文章。 • 文章搜索用例（Article search）:学生可以使用搜索功能根据关键字查询 相应的文章。 • 文章下载用例（Download）:学生可以使用下载功能将网站上的课件以 及资料信息下载到本地机器上。 • 权限认证用例（Identify）：此用例用来认证文件下载是否具有下载文件 的权限。
谢谢观赏
报告人： 报告人：马靖 班级： 班级：软件工程 学号： 学号：0950312005
（2）教师参与者的用例图 教师作为教学的主导者，使用此网站可以 发布学习方法，课程重点等和教学相关的 文章，以及和课程相关的通知等，还可以 将某一门课程的课件上传。
如何利用UML用例图描述软件系统的需求
因明
（4）参与者之间的主要关系---泛化（继承）关系
泛化或者继 承
（5）所要注意的问题
（6）如何获 得系统中的 参与者
5、用例模型中的用例（UseCase） （1）用例及其定义—某种特定的功能
（2）用例的分类——业务用例 描述一个业务的流程以及它们与外部各方(如客户和合 作伙伴)之间的交互 代表系统中需要提供的核心功能：如报表数据汇总计算 （3）用例的分类——系统用例 系统既定功能及系统环境的模型，描述且仅仅描述系 统的功能 系统提供的附加其它功能或者服务：如报表打印
Abstract use case – use case that reduces redundancy in two or more other use cases by combining common steps found in both.
（3）用例的横向方面的联系---扩展关联（Extension use case）
2、可以采用UML中的用例模型（用例图）方法 利用用例（Use Case）和用例图、需求文档来确定系 统的高层逻辑视图。
3、用例模型中的基本组成部件
用例最初由Ivar Jackboson博士提出，后被综合 到UML规范之中，成为需求表述的标准化体系。 Ivar Jacobson博士与Grady Booch和James Rumbaugh一道共同创建了UML建模语言，被业界誉 为UML之父。
（2）主要的特性
UML 由图和元模型组成，图是语法，而元模型则给出图的 意思，是UML的语义 它提供了描述软件系统模型的概念，同时由于它采用面向 对象的技术、方法，它的作用域不限于支持面向对象的分 析与设计,还支持从需求分析开始的软件开发的全过程。
（ 3 ）它是编制软件蓝图的标准化语言 ---- 是标准的建模 语言
UML实例UML案例(完整建模)(汽车租赁系统)
theWorkRecord : WorkRecord
系统的状态图
系统的活动图
customer request Employee check the request no new request store the request have new request handle new request
Manager Interface
Skill Worker
系统功能需求
① ② ③ ④ 满足上述需求的系统主要包括以下模块： 基本数据维护模块 基本业务模块 数据库管理模块 信息查询模块
基本数据维护模块
① ② ③ ④ 基本数据维护模块包括的主要功能模块： 添加车辆信息 修改车辆信息 添加员工信息 修改员工数据
基本业务模块
① ② ③ ④ 基本业务模块包含的功能： 用户填写预定申请 工作人员处理预定请求 技术人员填写服务记录 工作人员处理还车
建立UML模型框架
选择J2EE模式
系统的用例图
① ② 创建用例图之前首先需要确定参与者。 系统中的参与者主要有两类： 客户 公司职员
系统的用例图
1. 客户参与的用例图 2. 公司职员参与的用例图
客户参与的用例图
公司职员参与的用例图
系统的时序图
1. 2. 3. 4. 管理人员开展工作的时序图 客户预订车辆的时序图 客户取车的时序图 客户还车的时序图
数据库模块
① ② ③ ④ 数据库模块的功能： 客户信息管理 车辆信息管理 租赁信息管理 职员信息管理
信息查询模块
① ② ③ ④
信息查询模块是查询数据库中的相关信息， 包括： 查询客户信息 查询职员信息 查询车辆信息 查询客户记录
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
基于UML火车票网上售票系统的设计
基于UML火车票网上售票系统的设计火车票网上售票系统是一个基于UML（统一建模语言）的设计，用于方便用户在网上购买火车票。
下面将从系统需求、用例建模、类图设计和时序图设计等方面进行阐述。
1.系统需求规定：1.1用户注册登录：用户可以通过注册账号进行登录1.2查询车次信息：用户可以根据出发地、目的地和日期等条件查询火车票信息1.3购买车票：用户可以选择火车票并进行购买1.4订单管理：用户可以查看已购买的火车票订单，并进行管理1.5确认支付：用户需要确认订单并支付购买的火车票1.6退改签：用户可以选择进行火车票的退改签操作1.7管理员功能：管理员可以对系统进行管理，如添加车次信息、删除车次信息等2.用例建模：2.1用户注册登录用例：-用户输入账号和密码进行注册-用户输入账号和密码进行登录2.2查询车次信息用例：-用户输入出发地、目的地和日期等条件进行查询-用户查看查询结果2.3购买车票用例：-用户选择火车票并添加到购物车-用户确认购买并进行支付2.4订单管理用例：-用户查看已购买的火车票订单列表-用户选择订单进行管理，如退改签操作等2.5退改签用例：-用户选择订单进行退改签操作-用户支付差价（如有）2.6管理员功能用例：-管理员添加车次信息-管理员删除车次信息3.类图设计：3.1 用户类（User）：-属性：账号、密码、订单列表-方法：注册、登录、查询车次信息、购买车票、订单管理、退改签3.2 车次信息类（TrainInfo）：-属性：车次号、出发地、目的地、日期、余票数量-方法：查询车次信息3.3 火车票类（Ticket）：-属性：车次号、座位号、购买用户、购买日期、价格-方法：购买、退票、改签3.4 订单类（Order）：-属性：订单号、购票用户、购买日期、车票列表-方法：支付、取消3.5 管理员类（Admin）：-属性：账号、密码-方法：添加车次信息、删除车次信息4.时序图设计：-用户查询车次信息时序图：用户->系统:输入出发地、目的地和日期等条件系统->数据库:查询车次信息数据库->系统:返回查询结果系统->用户:显示查询结果-用户购买车票时序图：用户->系统:选择火车票进行购买系统->数据库:扣减余票数量数据库->系统:返回购买结果系统->用户:显示购买结果用户->系统:确认支付系统->用户:生成订单并显示支付结果通过上述的需求规定、用例建模、类图设计和时序图设计，可以实现一个基于UML的火车票网上售票系统，方便用户进行火车票的查询、购买和管理，同时还提供了管理员功能以便对系统进行管理。
03-系统需求建模-事件和事物
l
图形模型：描述系统的图表或系统某些方面的示 意性表示
8
１．３ 用于分析和设计的模型
分析阶段创建的模型
l l
设计阶段创建的模型
l l l l l l l l l l
事件列表 事物列表 基于UML的OO方法
l l l l l l
体系结构图 界面布局图 系统结构图 程序流程图 设计类图 时序图 包图 组件图 网络图 部署图 9
u
关联实体 – 解决上述问题的人为增加的数据实体，它
一定包含两端数据实体的关键字
33
５ 类图
u u u
面向对象的方法也强调对系统中所包含事物的理解 面向对象的方法给事物建立的模型即是“类图” “类”和“实体”是明显区别的
34
５ 类图
5.1 有关对象类的更复杂的问题
u
泛化／具体层次图 – 把类按照从最概括的父类到
３ 事物和系统需求
3.4事物的属性
属性：有关事物的一条特定信息 标示符（关键字）：能唯一标志事物的一个属性 复合属性：包括了许多相关属性的属性，如客户全名：名＋姓
所有客户具有如下属性 客户编号 名 姓 住宅电话 公司电话
每个客户的每个属性都有一个值 １０１ １０２ １０３ Ｊｏｈｎ Ｓｍｉｔｈ ５５５－９１８２ ５５５－３４２５ Ｍａｒｙ Ｊｏｎｅｓ ４２３－１２９８ ４２３－３４１９ Ｂｉｌｌ Ｃａｓｐｅｒ ８７４－１２９７
事件分三大类：外部事件、临时事件、状态事件
l 外部事件：系统之外发生的事件，通常是由外部实体或
系统参与者触发的
l 临时事件：由于到达某一时刻所发生的事件 l 状态事件：当系统内部发生了需要处理的情况时所引发
的事件
12
２．１ 事件的类型
用例建模指南
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
需求建模的常用方法
需求建模的常用方法
需求建模是软件开发过程中非常重要的一环，它的作用是帮助开发团队更加清晰地了解用户需求，并将这些需求转化为可行的软件功能。
在实际的需求建模中，有许多常用的方法，下面就简单介绍一些常用的方法：
1. 用例建模
用例建模是一种基于场景的方法，它主要通过描述系统和用户之间的交互来帮助开发团队理解用户需求。
在用例建模中，我们通常会将用户的需求描述为一个个场景，然后通过建立用例图、流程图等方式来对这些场景进行描述和分析。
2. 面向对象建模
面向对象建模是一种比较常用的需求建模方法，它通常会将系统中的各个对象进行抽象，然后通过建立类图、时序图等方式来描述这些对象之间的关系和交互。
3. 数据流建模
数据流建模主要是从数据流的角度来分析系统的需求，它将整个系统看作一个数据流的传递过程，然后通过建立数据流图、数据字典等方式来描述数据流的传递过程和数据的属性。
4. 状态转换建模
状态转换建模通常会关注系统的状态变化和状态之间的转换，它通过建立状态图、状态转换表等方式来描述系统的状态变化和状态之间的转换。
总的来说，需求建模的方法还有很多，每种方法都有其独特的优劣和适用范围，因此在实际的需求建模过程中，开发团队应该根据具体的项目需求选择合适的方法来进行建模。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
使用用例建模系统需求:•介绍用例建模的优点.•定义参与者和用例.•描述用例模型图中可能出现的关系.•介绍使用用例模型图的步骤•介绍用例的详细内容An Introduction toUse-Case Modeling•对于信息系统开发来说，最主要的挑战是能够从关联人员那里提取出正确的确实需要的系统需求，并以关联人员可以理解的方式进行说明，以便需求可以得到证实和验证。
•构建一个软件系统最困难的部分是正确地确定要构建什么。
Fred BrooksUser-centered development–重点是理解关联人员的需求。
Use-case modeling–使用业务事件（business events ）、发起事件的人（actor），以及系统如何响应这些事件（system responds to those events）。
来建模系统功能的过程。
•用例建模来源于面向对象建模技术，但该技术在非对象开发方法中也比较流行，因为它被广泛认为是定义、记录和理解信息系统功能需求的最佳实践。
Benefits of Use-Case Modeling•提供了一个捕捉用户需求的工具•将系统分解成更易于理解（掌控）的小块•提供了与用户及其它关联人员进行交流的工具•提供了确定、分配、跟踪、控制和管理系统开发活动（尤其是增量和迭代开发）的手段•为定义测试计划和测试用例提供基础Benefits of Use-Case Modeling (continued)•为用户文档和系统开发文档提供基准•提供了需求跟踪的工具•提供确定数据对象和实体的起点•提供了用户和系统接口的说明•提供了驱动系统开发的一个框架Use case– a behaviorally related sequence of steps (scenario), both automated and manual, for the purpose of completing a single business task.用例是一系列行为上相关的步骤（场景），既可以是自动的也可以是手工的，其目的是完成一个单一的业务任务。
包括两部分：Use-case diagram：用例图Use-case narrative：用例描述Use case– subset of the overall system functionality•一个用例所描述的场景可能包含一个或多个需求Actor– anyone or anything that needs to interact with the system to exchange information.•human, organization, another information system,external device, even time.Temporal event– a system event triggered by time.•The actor is time.Association–a relationship between an actor and a use case in which an interaction occurs between them.•有箭头的表示参与者发起用例. (1)•Association lacking arrowhead indicates a receiver actor. (2)没箭头的表示参与者是接受者•关联关系可以使双向或单向的Use Case Extends Relationship（扩展关系）Extension use case–一个用例可能包含多个步骤的复杂功能，使得用例难以理解。
为了简化，将较复杂的步骤提取成专门用例，成为扩展用例，它与原用例间是扩展关系。
•一个用例可有多个扩展用例，扩展用例不能被其他用例调用•Labeled <<extends>>.Use Case Uses Relationship使用（包含）关系Abstract use case–多个用例包含相同的功能步骤，把公共步骤提取成抽象用例，代表某种形式的“复用”●抽象用例可以被其它用例调用●箭头指向抽象用例●Labeled <<uses>>Use Case Depends On Relationship（依赖关系）Depends On–use case relationship that specifies which other use cases must be performed before the current use case.•决定用例开发的顺序•Labeled<<depends on>>Use Case Inheritance Relationship(继承关系)Inheritance–当多个参与者共享同样的行为时（发起先同的用例），可以将这些公共行为分配给一个新的抽象参与者，减少与系统的通信。
•其它参与者可以继承此抽象参与者。
需求用例建模过程—P173•构造需求用例的目的是提取和分析需求信息，模型表示用户需要什么，不涉及如何构造和实现•Steps1.Identify business actors.2.Identify business use cases.3.Construct use-case model diagram.4.Documents business requirements use-case narratives.•如何发现actors？•Who or what provides inputs to the system?•Who or what receives outputs from the system?•Are interfaces required to other systems?•是否存在预定时间自动触发的事件?•谁维护系统中的信息?•使用名词或名词词组命名参与者（Actors）Step 2: Identify Business Requirements Use CasesBusiness Requirements Use Case - a use case created during requirements analysis to capture the interactions between a user and the system free of technology and implementation details.•一个系统可能包含许多用例，在需求分析阶段，出于时间和经费的考虑，我们仅粗略关注最关键、最复杂的用例，常称为基本用例（Essential Use Case）•When looking for use cases, ask the following questions:•Actor的主要任务是什么?•What information does the actor need form the system?•What information does the actor provide to the system?•系统需要通知actor发生的变化和事件吗?•Actor需要通知系统发生地变化和事件吗?•Use cases 通常使用动词词组命名(i.e. 提交订单)Step 3: 构建用例模型图(Use Case Diagram)Step 4: 记录业务用例需求描述（Use-Case Narratives)•首先在高层（high level）记录，以便尽快理解系统的事件和量级•然后回到每个用例，扩展它，详细记录业务需求描述。
Use Cases and Project Management•Use-case model 可以驱动整个系统开发过程•完成需求用例后，项目经理和系统分析员可以用需求用例安排项目计划。
•To determine importance of use cases, will create:•Use-case ranking and evaluation matrix•Use-case dependency diagramUse-Case Ranking and Priority Matrix（用例分级）•In most projects, the most important use cases are developed first.Use-case ranking and priority matrix–a tool used to evaluate use cases and determine their priority.•Evaluates use cases on 1-5 scale against six criteria.1.Significant impact on the architectural design.2.Easy to implement but contains significant functionality.3.Includes risky, time-critical, or complex functions.4.Involves significant research or new or risky technology.5.Includes primary business functions.6.Will increase revenue or decrease costs.确定用例的依赖关系Use-case dependency diagram– graphical depiction of the dependencies among use cases.•Provides the following benefits:•Graphical depiction of the system’s events and their states enhancesunderstanding of system functionality.•Helps identify missing use cases.•Helps facilitate project management by depicting which use cases aremore critical.。