业务用例模型
uml的用例模型
UML（Unified Modeling Language）统一建模语言是一种用于对软件密集系统进行可视化建模的标准化建模语言。
用例模型是UML中的一个重要概念，主要用于描述系统的功能需求和行为。
用例模型主要由三个部分组成：参与者（Actor）、用例（Use Case）和它们之间的关系。
参与者（Actor）：参与者是与系统进行交互的用户或其他系统，可以是外部实体或内部实体。
用例（Use Case）：用例描述了系统执行的功能，即参与者与系统之间的交互行为。
一个用例通常描述了一个单一的功能或业务过程。
关系：关系描述了参与者与用例之间的交互，包括关联（Association）、泛化（Generalization）和依赖（Dependency）等。
在构建用例模型时，通常首先识别参与者，然后确定系统的功能需求，为每个功能需求创建一个用例。
接着，通过添加关系来描述参与者与用例之间的交互。
用例模型的主要目的是帮助开发人员理解系统的功能需求和行为，以便更好地设计和实现系统。
通过用例模型，开发人员可以更好地理解系统的边界、参与者与系统的交互以及系统的功能需求，从而更好地进行系统设计和开发。
软件工程之用例模型总结
软件工程之用例模型总结一、用例模型1.用例概念用例：使用系统时发现的功能性需求，不应过于复杂，简单的来说就是你希望系统能够有什么功能，能够增加系统的价值。
用例模型包括用例描述和用例图，我们主要把中心放在用例描述上。
用例模型包含参与者和场景，场景包括成功场景和失败场景。
因此用例模型中有多个场景；每个场景是一个用例。
用例必须注重为用户提供可观察的返回值，就是系统触发了一个用例之后能够给用户带来什么。
一般用例都是黑盒用例，即不考虑如何实现。
e Case Description每个用例都有一个描述。
怎样确定用例？(1)确定一个功能；(2)写一个用例；(1)主要参与者：调用系统服务完成目标的人。
(2)次要参与者：为系统提供服务的人。
(3)写出每个项目相关人员的理想需求，从中分析功能。
(4)PreCondition:执行到这个用例之前必须为真的情况，比如必须已成功登录或通过验证。
(5)PostCondition:成功执行完此用例后的情况，比如登录用例的后置条件是成功登录（不考虑其他失败情况）。
(6)main flow：将最理想的步骤列出。
一般main flow步骤如下：(1)参与者发生动作。
(2)系统验证。
(3)返回结果。
(7)extension flow：扩展步骤,通常格式为：(1)系统检测到**有问题;在main flow中的第一步扩展，则用1a,1b,1c;3.如何确保正确的用例EBP原则:一般用例都需要遵守这个规则，即确定主要用例。
用例中的主要用例是一些重复做但是有意义的事，比如收银员收钱，重复多次是有意义的，因为钱收得多了；但是像登录系统，这种做100次却没有意义的用例，不能被称为主要用例；(1)EBP（基本业务过程）原则的用例写入；(2)如果要写编辑A，删除A，添加A，可以合并成“管理A”；4.用例图每个用例描述都是一个用例，左边是主要参与者（希望系统为他提供服务）和次要参与者（提供给系统服务的人）；在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据库的；关系：(1)泛化关系，在参与者和用例中都能泛化。
UML 业务用例模型
业务用例模型业务用例模型：业务用例模型描述一个业务的流程以及它们与外部各方（如客户和合作伙伴）之间的交互。
解释由业务用例和主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的。
直接与客户或合作伙伴相关的活动以及与外部各方并不直接相关的支持和管理任务都可以在模型中给出。
模型以业务用例（相当于我们常说的“流程”）的形式对业务进行说明。
登记处的主角和用例。
业务用例的不同类型当考查业务中的活动时，您至少可以确定三类工作，它们对应着三种业务用例类型。
第一类是在商业上比较重要的活动，常称为业务流程。
第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。
系统管理、清洁和安全等工作就是这类活动的示例。
该业务用例具有支持的性质。
第三类是管理工作。
具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系。
通常，管理类型的业务用例概括地描述了CEO 和业务用例中工作人员之间的关系。
它还说明了业务用例是如何被开发和“启动”（实例化）的。
在餐馆中，核心业务用例是市场营销(Marketing) 和用餐服务(Serving Dinner)，而采购(Purchasing Supplies) 是支撑业务用例。
请注意，有时候您当作核心业务用例的用例在其他业务中会成为支撑业务用例。
例如，在软件开发公司中，软件开发是核心业务用例；而在银行或保险公司中，它却是支撑业务用例。
一个业务有多个业务用例一个业务有多个业务用例。
多个不同业务用例的实例或一个业务用例的多个实例并行执行的情况是很正常的。
一个用例实例可以遵循的路径的数目几乎是没有限制的。
这些不同的路径代表了工作流程说明中用例实例的各种选择。
根据具体事件和情况，用例实例可以沿着多种可能路径中的一种进行下去，例如：●来自主角的输入。
●一条业务规则。
在对业务用例建模时，您可以假定用例实例可以在不互相冲突的情况下同时进行。
在业务开发的这个阶段，您应该侧重于业务应该作些什么。
软件工程中英对照术语表
abstract class 抽象类,提供一组子类共有行为的类，但它本身并不具有实例。
抽象类表示一个概念，从中派生的类代表对这一概念的实施。
Abstraction 抽象,对视图或模型的创建，其中忽略了不必要的细节，以便专注于一组特定的相关细节。
access modifier存取权限,对类、方法或属性进行访问控制的关键字。
Java 中的存取权限可以是公有、私有、保护和包装（默认）。
accessor methods存取器方法,由对象提供的、用于定义连接该对象实例变量的方法。
用来返回实例变量值的存取器方法被称为获取方法；用来为实例变量指定值的存取器方法被称为设置方法。
acceptance验收,客户接受软件产品（作为部分或完整履行合同的结果）所有权的操作。
action动作,对构成计算过程抽象的可执行语句的规范。
动作通常会导致系统状态发生变化，这是通过向一个对象发送消息或是更改链接或属性值来实现。
action sequence动作序列,解析为一系列先后发生的动作的表达式。
action state动作状态,表示不可分动作的执行状态，通常指的是调用一个操作。
activation激活,动作的执行active class主动类,表示系统中控制线程的类。
请参见主动对象。
activity活动,要求角色执行的工作单元。
active object主动对象,拥有线程并可发起控制活动的对象。
主动类的实例。
activity graph活动图,状态机的特例，用于对涉及一个或多个分类器的进程建模。
对比：状态图(statechart diagram)。
同义词：活动图(activity diagram)。
actor主角,系统之外与系统交互的某人或某事物。
actor class主角类,定义一组主角实例，其中每个主角实例相对于系统而言都担任着同样的角色。
在与用例交互时这些用例的用户所担任的一组紧密相关的角色。
主角为每个要与其通信的用例都准备了一个角色。
业务模型的定义和分类
业务模型的定义和分类业务模型是指对企业或组织的业务活动进行描述和分析的一种框架或工具。
它用于理解和解释组织的运作方式，帮助管理者制定决策和规划战略。
业务模型可以根据不同的分类标准进行划分和描述，下面将详细介绍业务模型的定义和分类。
一、业务模型的定义业务模型是对企业或组织的业务活动进行抽象和描述的模型。
它通过表示和描述组织的业务流程、业务规则、业务角色、业务数据等要素，揭示了企业或组织的运作机制和商业逻辑。
业务模型能够帮助企业或组织理清业务关系、优化业务流程、提升业务效率。
它是企业或组织制定战略、规划发展的重要依据。
二、业务模型的分类根据不同的分类标准，业务模型可以分为多种类型，下面将介绍几种常见的业务模型分类。
1. 流程模型流程模型是一种描述业务活动流程和顺序的模型。
它通过定义业务流程中各个环节的输入、输出、活动和决策条件，揭示了业务活动的执行顺序和规则。
流程模型可以采用流程图、时序图等方式进行表示，便于理解和沟通。
通过分析流程模型，企业或组织可以找出流程中的瓶颈和问题，提出优化方案，提升业务效率。
2. 数据模型数据模型是一种描述业务数据和数据关系的模型。
它通过定义业务数据的属性、类型、关联关系等，揭示了业务数据的组织和结构。
数据模型可以采用实体关系图、类图等方式进行表示，便于理解和分析。
通过分析数据模型，企业或组织可以理清业务数据的流向和关系，优化数据存储和管理方式，提高数据的质量和可用性。
3. 角色模型角色模型是一种描述业务角色和职责的模型。
它通过定义各个角色的权限、职能、责任等，揭示了组织内部角色之间的协作和配合关系。
角色模型可以采用组织结构图、职责矩阵等方式进行表示，便于理解和管理。
通过分析角色模型，企业或组织可以明确各个角色的职责和权限，优化组织架构和人员配置，提升工作效率和协同能力。
4. 系统模型系统模型是一种描述业务系统和功能的模型。
它通过定义业务系统的组成、功能和交互关系，揭示了系统之间的协作和互动方式。
企业架构研究总结（21）——TOGAF架构开发方法（ADM）之业务架构阶段
企业架构研究总结（21）——TOGAF架构开发⽅法（ADM）之业务架构阶段1.3 业务架构（Business Architecture）企业架构开发⽅法各阶段——业务架构1.3.1 ⽬标描述基线业务架构开发基于原则、业务⽬标和策略驱动⼒的⽬标业务架构，描述产品和/或服务策略，以及业务环境在组织、功能、过程、信息和地理这些⽅⾯的内容分析基线和⽬标业务架构之间的差距选择和开发相关的架构视⾓，通过这些视⾓架构师可以阐述业务架构是如何对各⼲系⼈的关注点进⾏解答的。
选择与选中的视⾓相关的⼯具和技术1.3.2 ⽅法针对业务架构的了解是进⾏其他领域（数据、应⽤和技术）架构⼯作的前提条件，因⽽如果不是因为组织中其他⼀些诸如企业规划、业务战略规划以及业务流程再造等⽅⾯流程，针对业务架构的制定应该是要⾸选进⾏的架构活动。
业务架构是⽤来将其后架构⼯作的业务价值阐述给相关⼲系⼈所必不可少的⼯具，它也可⽤来为各个⽀持和参与后续架构⼯作的⼲系⼈阐明企业架构的投资回报。
在实践过程中，业务架构的关键元素也许已经在其他⼯作中被明确，⽽在这种情况下，组织就需要验证和更新当前已经⽂档化的业务战略和规划，并/或在已经明确的业务驱动⼒、业务战略、⽬标与架构开发⼯作相关的特定业务需求之间建⽴关联。
⽽在另外⼀种情况下，业务架构⼯作也许并没有或者很少被执⾏，⽽这就需要架构团队研究、验证架构将要⽀持的各个关键业务⽬标和流程，并获得相关⼲系⼈的认同。
然⽽不论处在以上哪种情况，TOGAF ADM的业务情景技术，或者是其他⽤来阐明关键业务需求以及为IT架构指明其技术需求的⽅法，都需要被纳⼊到架构师的⼯具箱之中。
需要注意的是，在架构活动中应尽量重⽤各种已经存在的材料，并且针对信息的收集和分析也应该依据架构⼯作的范围⽽采⽤那些能够促成明智决策的信息。
如果架构活动关注于业务流程的定义，则在此阶段组织需要在此⽅⾯进⾏很多细致的⼯作，⽽如果关注点更着重于其他领域（数据/信息、应⽤系统和基础设施）中的⽬标架构，那么组织就需要在这个阶段构建⼀幅⽆需包含众多⾮必要细节的全景图。
第4章 建立用例模型
学习内容
用例模型概述 系统用例模型 业务用例模型 用例描述文档规范
用例模型概述
用例的模型元素 用例图建模分析步骤 寻找用例的方法
用例模型概述
用例模型：主要用来描述系统和系统外部环境 的关系，直接影响着其他模型。 用例：是一组系统使用场景的集合，每个场景 又是由一些事件序列构成，发起这个事件的用 户就是系统使用的参与者。 用例图：是系统的高层描述，角色和用例，在 实现阶段则变成了对象和接口这样的底层描述。
系统用例模型
（4） 右击展开导航树上的“需求定义“节点，在弹出菜单中 选择”新建框图“，再在”新建框图“菜单下选择”用例图“ 。则在该包上增加了一个节点，一个名称以”usecasediagram“ 开头的节点，它代表这个用例图全局属性，可在属性选项卡中 修改该节点名称为“会议管理系统用例图”。
用例模型概述
1. 用例的模型元素
用例的表示：用例的表示符号为一个椭圆，下面是用例的名称 （也可以放在椭圆中间）。
取款 取款 图 4.3用例的表示法
用例模型概述
1. 用例的模型元素
（4） 关系：关系反应了参与者和用例之间,用例和用例之间
以及参与者和参与者之间的相互作用，用例和参与者之间是关 联关系，一般角色为用例的启动者，用单向关联，否则为双向 关联。 用例之间的关系有三种： 包含、扩展、泛化
系统用例模型
2.会议管理系统用例图模型元素识别结果
（4）系统：经过前面分析，未来系统将要实现 的需求特征包含：编辑会议申请、编辑会议 纪要、获取会议通知、分配会议室资源、发 送会议通知，这些元素属于系统内，其余在 系统外，属于系统环境 。
软件工程：UML之用例模型
二、主角
Hwadee 华迪实训
•系统所使用的外部硬件。
示例： 控制建筑物中温度的通风系统不断地从建筑物中的传感器处获取温度信息。所以，
传感器就是一个主角。 •与该系统交互的其他系统。
示例： 一个自动柜员机必须和保存银行帐户的中央系统进行通信。中央系统很可能是一个外
部系统，因此它应该是一个主角。 如果您在构建一个基于 Internet 的应用程序，那么您的主要主角在某种意义上将是 匿名的。您并不真正知道这些主要主角是谁，而且也无法假定他们的技能和背景。但 您仍能说明您希望他们在您的系统中担任的角色。 示例：
(2) UML表示法 定义UML符号的表示法,为开发者或开发工具使用这 些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达 的是应用级的模型,在语义上它是UML元模型的实例。
7
一、UML简介
Hwadee 华迪实训
标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:
配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设 备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的 依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的 对应关系。 从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据 需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其 中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、 对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。 其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互 关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言 UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静 态建模机制和动态建模机制两大类。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
武汉工程大学计算机科学与工程学院
《信息系统建模》实验报告
专业班级计算机科学与技术01实验地点机电大楼403 学生学号指导教师刘菲
学生姓名实验时间3月16日
实验项目业务建模
实验类别操作性（）验证性（）设计性（√）综合性（）其它
实验目的及要求1．学习使用Rational Rose对题目进行进度安排。
2．掌握信息系统业务建模的方法。
3．掌握建立业务用例模型、绘制用例图的方法。
4. 掌握建立业务对象模型、绘制类图的方法。
5. 掌握详述业务用例、绘制活动图的方法
成绩评定表
类别评分标准分值得分合计
上机表现积极出勤、遵守纪律
主动完成实验设计任务
30分
实验报告及时递交、填写规范
内容完整、体现收获
70分
说明：
评阅教师：
日期：年月日
实验内容
图书管理系统的原始需求如下所示：
（1）该系统是一个基于WEB的计算机应用系统；
（2）读者登录系统后，可以查询图书信息以及借阅信息；
（3）读者可以修改自己的资料信息；
（4）管理员登录系统后，可以完成读者的借书、还书业务；
（5）管理员可以对图书信息进行增加、修改和删除；
（6）管理员可以对读者信息进行增加、修改和删除；
（7）对到期的图书，系统会自动向读者发送催还信息；
要求：
1、对图书管理系统进行业务分析，建立业务用例模型。
查询图书信息
修改个人信息读者
查询借阅信息
登录
借书
还书
维护读者信息图书管理员
维护图书信息
时间
发送催还信息2、对图书管理系统进行业务分析，建立业务对象模型。
图书管理员
图书
管理
1..n
1
3. 图书管理系统中对于“新增读者信息”进行详细描述，包含以下信息：
（1）"读者"填写申请表，并交给"图书管理员"；
（2）"图书管理员"将申请表中的信息通过录入界面，输入到图书管理系统；
（3）系统中的"业务逻辑"组件将判断输入的信息是否合法；
（4）如果不合法则转入步骤（5），否则转入步骤（6）；
（5）显示"添加错误信息"，转到（8）；
（6）在数据库添加相应的用户信息；
（7）显示"添加成功信息"；
（8）结束。
根据对“新增读者信息”的详细描述，绘制相应的活动图。
4. 图书管理系统中对于“删除读者信息”进行详细描述，包含以下信息：
（1）管理员在录入界面，输入待删除的读者名；
（2）“业务逻辑”组件在数据库中，查找待删除的读者名；
（3）如果不存在，则显示出错信息，返回步骤（1），如果存在则继续；
（4）“业务逻辑”组件判断“待删除的读者”是否可以删除；
（5）如果不可以，则显示出错信息，返回步骤（8），如果可以则继续；
（6）在数据库中，删除相关信息；
（7）显示删除成功信息；
（8）结束。
根据对“删除读者信息”的详细描述，绘制相应的活动图。
5. 对“处理订货”的工作流程进行详细描述，包含以下信息：
（1）顾客查询商品，选择合适商品下订单；
（2）销售人员接收订单，到库房中查询商品库存；
（3）若库存量充足，则销售人员计算账单金额，转（5）；
（4）若库存量不足，则销售人员拒绝订单，转（6）；
（5）顾客接收账单，付款；
（6）结束。
实验总结
通过这次试验，学会了如何使用Rational Rose工具画各种图。
同时也学会了如何画用例图，活动图，收获很大。