下载文档原格式
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
基于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的火车票网上售票系统，方便用户进行火车票的查询、购买和管理，同时还提供了管理员功能以便对系统进行管理。
用例建模指南用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
1. 什么是用例？传统的需求表述："软件需求规约"(Software Requirement Specification)。
传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
缺点：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。
由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。
在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。
功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。
所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。
1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。
用例模型主要由以下模型元素构成：∙参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
∙用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
需求建模的常用方法
需求建模是软件开发过程中非常重要的一环，它的作用是帮助开发团队更加清晰地了解用户需求，并将这些需求转化为可行的软件功能。
在实际的需求建模中，有许多常用的方法，下面就简单介绍一些常用的方法：
1. 用例建模
用例建模是一种基于场景的方法，它主要通过描述系统和用户之间的交互来帮助开发团队理解用户需求。
在用例建模中，我们通常会将用户的需求描述为一个个场景，然后通过建立用例图、流程图等方式来对这些场景进行描述和分析。
2. 面向对象建模
面向对象建模是一种比较常用的需求建模方法，它通常会将系统中的各个对象进行抽象，然后通过建立类图、时序图等方式来描述这些对象之间的关系和交互。
3. 数据流建模
数据流建模主要是从数据流的角度来分析系统的需求，它将整个系统看作一个数据流的传递过程，然后通过建立数据流图、数据字典等方式来描述数据流的传递过程和数据的属性。
4. 状态转换建模
状态转换建模通常会关注系统的状态变化和状态之间的转换，它通过建立状态图、状态转换表等方式来描述系统的状态变化和状态之间的转换。
总的来说，需求建模的方法还有很多，每种方法都有其独特的优劣和适用范围，因此在实际的需求建模过程中，开发团队应该根据具体的项目需求选择合适的方法来进行建模。
常用系统建模方法系统建模是指对一个系统进行抽象和描述，以便更好地理解和分析系统的结构、行为和功能。
在系统建模中，有许多常用的方法和技术，本文将介绍其中几种常见的系统建模方法。
1. 信息流图（Data Flow Diagram，简称DFD）是一种用于描述系统功能的图形工具。
它通过将系统的各个模块和数据流之间的关系绘制成图表，清晰地显示了数据输入、处理和输出的过程。
DFD是一种简单直观的建模方法，适用于初步了解系统需求和功能的描述。
3. 状态转换图（State Transition Diagram，简称STD）是一种用于描述系统的状态和状态之间转换的图形工具。
它通过绘制系统的状态和状态之间的转换关系，清晰地显示了系统在不同状态下的行为和过程。
STD适用于描述系统中的状态机，是一种常用的建模方法，尤其适用于软件系统的行为建模。
4. 用例图（Use Case Diagram）是一种用于描述系统需求和功能的图形工具。
它通过绘制系统的参与者和用例之间的关系图，清晰地显示了系统的功能和用户之间的交互。
用例图适用于描述系统的功能需求，是一种常用的需求建模方法，常用于需求分析和系统设计中。
5. 结构图（Structure Chart）是一种用于描述软件系统模块和子程序之间的关系的图形工具。
它通过绘制系统的模块和模块之间的调用关系，清晰地显示了系统的结构和模块之间的依赖关系。
结构图适用于描述系统的模块组织和子程序调用，是一种常用的软件设计和实现建模方法。
除了上述常用的系统建模方法外，还有许多其他的建模方法和技术，如层次分析法、Petri网、数据流程图、活动图等等。
不同的建模方法适用于不同的系统和需求，可以根据具体情况选择合适的方法进行建模。
系统建模的目的是为了更好地理解和分析系统，从而进行系统设计、实现和优化，提高系统的可靠性、性能和效率。
软件⼯程之系统建模篇【设计⽤例模型】本⽂主要介绍⽤例模型的设计过程，⾸先从系统层设计⽤例模型，然后分别细化系统层识别的各⽤例，设计更为详细的⽤例模型。
⽤例模型是开发过程的起点，并驱动建模全过程。
以下以办公⾃动化（OA）中的办理发⽂⽤例模型为例，来讲解⽤例模型的设计过程。
⽤例模型包括办理公⽂⽤例图及⽤例描述。
办理发⽂⽤例模型 1、办理公⽂⽤例图 在设计办理发⽂⽤例模型之前，先要识别活动者和⽤例，活动者和⽤例识别以后，才能建⽴⽤例模型。
1.1 活动者识别 活动者是系统分析员与⽤户交流的起点，也是项⽬获得后续产品的关键。
活动者可以是使⽤系统功能的⼈，也可以是软件系统和硬件设备，凡是与系统进⾏信息交换的外部实物，都可以归为系统的活动者。
系统分析员与系统⽤户深⼊交流后，明确系统范围，系统功能和外部关联的事物。
识别活动者需要往复多次，可以通过向⽤户询问类识别活动者。
如：谁/什么对系统运⾏的结果感兴趣，会改变系统中的数据，从系统中获取信息，与系统交互。
通过对具备这些需求的⽤户进⼀步分析，即可识别系统活动者。
1.2 识别过程 与系统发⽣交互的外部实体有草拟⼈、审核⼈、复核⼈、签发⼈和分发⼈。
草拟⼈可识别为发⽂草拟⼈，审核⼈可设别为发⽂审核⼈、复核⼈可识别为发⽂复核⼈，签发⼈⼀般由相关领导担任，可识别为发⽂签发⼈，分发⼈可识别为分发⼈。
1.3 ⽤例识别 发⽂草拟⼈新拟发⽂编辑发⽂并保存在系统中 新拟发⽂⽤例 发⽂草拟⼈修改发⽂修改发⽂并保存所做操作 修改发⽂⽤例 发⽂审核⼈审核发⽂编辑审核意见并保存在系统中 审核发⽂⽤例 发⽂复核⼈复核发⽂编辑复核意见并保存在系统中 复核发⽂⽤例 发⽂签发⼈签发发⽂编辑签发意见并保存在系统中 签发发⽂⽤例 分发⼈ 分发发⽂对分发进⾏登记并保存在系统中 分发发⽂⽤例 发⽂草拟⼈送档案室 将发⽂转⼊档案室 送发⽂⾄档案室⽤例 1.4 ⽤例图 2、⽤例描述 2.1 新拟发⽂ ⽤例⽬标：当发⽂草拟⼈新拟⼀份发⽂时⽤例开始。
使用用例建模系统需求:•介绍用例建模的优点.•定义参与者和用例.•描述用例模型图中可能出现的关系.•介绍使用用例模型图的步骤•介绍用例的详细内容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.。
