精华内容
下载资源
问答
  • uml用例描述
    千次阅读
    2018-05-16 18:51:30

    UML(统一建模语言)是当前软件开发中使用最为广泛的建模技术之一,通过使用UML可以构造软件系统的需求模型(用例模型)、静态模型、动态模型和架构模型。UML通过图形和文字符号来描述一个系统,它是绘制软件蓝图的标准语言。熟练掌握UML建模技术是一个优秀的软件从业人员所必备的基本技能之一,越来越多的软件企业在招聘中也需要应聘者具备一定的UML知识基础和实践经验。

    作为UML的初学者,很多人也在尝试使用UML中的图形来描述一个软件系统,构造一个软件系统的蓝图。然而,在使用UML的过程中,一部分人并没有深入理解这些图的作用,以及这些图在绘制过程中的一些技巧。我将陆续通过几篇文章来帮助大家更快更好地学习UML,在软件项目中合理使用UML来提高软件开发效率并规范软件开发流程。

    在本文中我将结合库存管理系统来深入浅出地讲述UML建模中的第一个模型——需求模型的构造,即用例建模,包括如何绘制规范的用例图、如何编写简洁而又清晰的用例文档、以及怎样通过用例图和用例文档来构造软件系统的需求模型。

    在UML中,需求模型又称为用例模型,它主要用于描述系统的功能性需求,即软件可以实现的功能,如登录、注册、入库、出库、查看库存报表、增加员工信息等。常规的用例建模一般包括两个组成部分:绘制用例图和编写用例文档。

     

    1. 绘制用例图

    用例图是UML中比较简单的一种图形,它包含两个主要组成元素,分别是执行者(Actor)和用例(Use Case)。执行者又称为参与者或角色,用例又称为用况或案例。在用例图中,执行者用一个“小人”符号表示,用例用一个“椭圆”符号表示,因此用例图又有一个名字为“小人椭圆图”。最简单的用例图如下:

    在该用例图中,“仓库管理员”表示执行者,“入库”表示一个用例,即系统的一个功能。

     

    执行者是指直接和系统交互的一类事物,执行者主要有如下三类:

    (1) 直接使用系统的人,如使用一个库存管理系统的仓库管理员、仓储部经理等用户,仓库管理员可以通过系统进行入库和出库操作,仓储部经理可以通过系统查看各种报表,如库存报表、财务报表等;

    (2) 与该系统相关的其他系统,如在库存管理系统中如果涉及到付款操作,需要使用另一个软件——支付系统,此时支付系统就是库存管理的执行者之一;

    (3) 自动发生的事件,如时间、温度等自动事件,如果库存管理系统要求每晚零点执行一个数据汇总操作,此时时间就成为该操作的执行者。

    识别一个系统的执行者是用例建模的第一步,在识别出一个系统的执行者后,需要寻找系统的用例,即功能需求。用例是执行者对系统操作的一个动作序列,每一个用例对应执行者对系统的一个完整操作流程。如库存管理系统中,仓库管理员可以登录系统,可以进行入库、出库等操作,在这里登录、入库、出库都是用例,它们都对应系统所提供的一个功能。执行者通过执行用例来完成相应的工作。用例体现了执行者和软件系统的交互过程,因此只用一个简单的“椭圆”来表示用例太过简单,对于每一个用例,需要编写一个详细的用例文档,在下一节将介绍如何编写用例文档。


      转自 刘伟博客

    更多相关内容
  • 是一种被广泛使用的用于发现和记录需求 特别是功能需求 的机制 写出用例是一种最好的理解和描述需求的技巧 注意:这个模板列出可以定义用例的典型标题 但应当强调的是 实用上更重要的是专注于写出完整的可理解的...
  • UML用例描述UML用例描述UML用例描述UML用例描述UML用例描述UML用例描述UML用例描述UML用例描述
  • UML用例需求,如何建立用例图,以及建立用例描述用例描述建立的格式。UML用例需求,如何建立用例图,以及建立用例描述用例描述建立的格式。UML用例需求,如何建立用例图,以及建立用例描述用例描述建立的格式...
  • 网上购物系统UML图及用例描述文档

    热门讨论 2012-06-12 11:15:35
    包含有网上购物系统的UML建模文件,及用例描述文档,及PPT。UML建模文件中的用例图,类图,序列图,构件图,部署图,活动图,详尽,可以直接拿去做毕业设计之用
  • UML用例建模详解

    2021-05-29 19:36:38
    用例模型由若干用例图组成,用例图展示了用例、参与者、以及它们之间的关系,用例描述通常以正文形式描述。 注:参与者可以是人,也可以是外部系统 参与者与用例之间的关系:关联 参与者之间的关系:泛化 用例之间...

    概述

    用例建模一般用在软件的需求分析阶段,用于描述系统的功能需求

    用例模型

    用例模型由若干用例图组成,用例图展示了用例参与者、以及它们之间的关系用例的描述通常以正文形式描述。
    注:参与者可以是人,也可以是外部系统,参与者应该与系统直接交互!

    参与者与用例之间的关系:关联
    参与者之间的关系:泛化
    用例之间的关联(四种):
    继承
    在这里插入图片描述

    使用使用也是一种继承关系
    包含
    在这里插入图片描述

    扩展被包含的用例可以是一个单独的单元,而扩展出来的用例必须依赖于基用例,一旦基用例中扩展点给出条件满足,则扩展用例将被执行。比如vip功能就是一个扩展用例。(注意箭头方向是指向基用例的)
    在这里插入图片描述

    用例描述

    用例描述常以书面文档的方式进行表达,可以使用文本方式进行文字描述,也可以使用图形的方式可视化描述,例如活动图有助于描述复杂用例实现的决策流程,状态转移图有助于描述与状态相关的系统行为,顺序图适合于描述基于时间顺序的消息传递。

    用例描述包含的点:

    • 用例名称:表明用例的用途,如上面示例中的“借阅图书”、“归还图书”。
    • 标识符:[可选]编号惟一标识符一个用例,如“UC200601”。
    • 参与者:[可选]与此用例相关的参与者列表。
    • 简要说明:对该用例进行说明,描述用例作用。注意语言简要,使用自然语言。
    • 前置条件:表示满足了前置条件该用例才会执行
    • 后置条件:后置条件在用例成功完成后得到满足,它提供了系统的部分描述。用例结束后,系统处于什么状态。例如:借阅图书用例后置条件:借书成功,则返回该学生借阅信息;借书失败,则返回失败的原因。
    • 扩展点:如果包括扩展用例,则写出扩展用例在什么情况下使用。应该在编写事件流的同时编写。
    • 基本事件流:即用例的主要事件流,用于描述执行该用例的主要步骤
    • 其他事件流:包含扩展事件流、异常事件流等,用于描述一些特殊过程,比如密码输入错误要做什么,当用户是vip时做什么等等

    建模步骤

    ① 确定系统边界
    ② 确定参与者、用例
    所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲,参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手:

    1. 系统开发完成之后,有哪些人会使用这个系统?
    2. 系统需要从哪些人或其他系统中获得数据?
    3. 系统会为哪些人或其他系统提供数据?
    4. 系统会与哪些其他系统相关联?
    5. 系统是由谁来维护和管理的?

    找到参与者之后,我们就可以根据参与者来确定系统的用例,主要是看各参与者需要系统提供什么样的服务,或者说参与者是如何使用系统的。寻找用例可以从以下问题入手(针对每一个参与者):

    1. 参与者为什么要使用该系统?
    2. 参与者是否会在系统中创建、修改、删除、访问、存储数据?如果是的话,参与者又是如何来完成这些操作的?
    3. 参与者是否会将外部的某些事件通知给该系统?
    4. 系统是否会将内部的某些事件通知该参与者?
      当然需要注意的是在寻找用例是不能太细化,不能去考虑它的实现细节

    ③ 编写用例描述
    这一步就可以通过文档或者图形来对用例进行较为清晰的描述了,当然应该避免用专业术语来描述,因为要让客户看得懂。
    ④ 定义用例间关系
    就是上面说的几种关系,这时就可以把用例进行细化,让图看起来更加整洁简单。
    ⑤ 审核用例图

    展开全文
  • uml用例如何描述

    千次阅读 2010-06-02 13:23:00
    用例就必须理解以下三个概念:--范围 scope:真正被讨论的系统是什么?--主执行者 ...主执行者才能提到描述用例,还要在沉淀。经验只能借鉴而不能照搬!!!!转:---------------------------

    來源:http://space.itpub.net/118838/viewspace-483405

     

    一、难点:

    写 好用例就必须理解以下三个概念:
    --范围 scope:真正被讨论的系统是什么?
    --主执行者 primary actor:    谁有要实现的目标?
    --层次 level:   目标泊层次是高,还是低?
    经典,现在只体会到先确定范围和 主执行者才能提到描述用例,还要在沉淀。经验只能借鉴而不能照搬!!!!
    转:
    ---------------------------
    正体字为原文,斜体字 为本人见解

    1、用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同 条件下,系统对某一项目相关人员的请求所作出的响应。

    从文字上看,比较难理解,举个比较经典的例 子:某人在ATM机提款,这个本身就可以看作一个用例,只是它的层次比较高,细分下去,人可以在ATM上做什么?粗略一想,就有几条:(1)查询余额 (2)提款(3)转帐(4)存款,这四点都可以独立成为一个用例,而且执行者都是人,简单来说,用例就是描述执行者和系统之间的交互的集合。

    2、 从根本上说,用例是文本形式;他们是作为人与人之间,尤其是没有受过专门培训的人员之间互相交流的一种手段。因此,简单的文本通常是编写用例的首选形式。

    很 多人一看到“用例”这两个字就和用例图联系在一起,就是一个小人,一个椭圆,中间有线连接那种图,其实用例图只是用例的图形化表示,用例真正的内容体现在 它的文本描述中,而且描述的语言和平时人们日常写作的语言一样,一般有初中文化的人都看的懂。

    3、 编写用例必须掌握的三个概念:

    (1)     范围(scope):真正被讨论的系统是什么?

    (2)     主执行者(primary actor):谁有要实现的目标?

    (3)     层次(level):目标的层次是高还是低?

    范围很重要,这个和 项目管理 里 面的项目范围概念差不多,不过可能它的粒度小一点,有个可能一个用例只是一个项目的一小块功能交互,只有明确好范围,才能真正把握需求,但这个还需开发方 与客户不断的沟通才能确定。主执行者与项目管理的项目干系人有些联系,很多用例主执行者就是项目干系人中的一员。

    4、 只有一个用例模板是不够的。至少要有两个用例模板:一个是非正式的(或称随意的),在要求不严的项目中使用;另一个是完整正式的,在要求严格的项目中使 用。

    无论正式还是非正式,只要能使客户和开发人员能建立有效的沟通途径,就是好用例,只是有时候一 些项目要求比较严格,文档写的也比较正式而已。

    5、如果把用例作为需求来编写,请 谨记以下两点

    (1)     用例确实是需求。不必将用例转变成行为需求的其他形式。

    (2)     用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。

    需求包含用例,用 例属于需求的一部分,这恰恰反应了:“用例不是万能的....”,下一句想必不用说都知道了吧,呵呵。

    6、 用例仅仅是行为需求,并且是所有的行为需 求。

    注意后半句

    小结:这一章 主要是为用例定位,以及怎么样在不同的环境和时间安排下编写用例,使其达到最好的效果。
    ------------------------------------------------
    二、基本定义:
    执 行者 actor:任何具有行为的人或物。
    项目相关人员 stakeholder :对被讨论系统的行为有特定兴趣的人或物。
    主 执行者 primary actor:启动与被讨论系统的一次交互活动,从而达到某一目标的人或物。
    用例 use case:规定被讨论系统行为的契约。
    范围 scope:界定被讨论的系统。
    前置条件和保证 precondition and guarantee:在用例执行之前和之后必须满足的条件。
    主成功场景 main success scenario:一切顺利的情况。
    扩展 extension:场景执行过程中出现 的不同情况。
    扩 展中的编号:是指在主成功场景中不同情况发生时所处的执行步骤号码(例如,步骤4a步骤4b是指主成功场景中步骤4的两种不同情况)
    下 划线:当一个用例引用另一个用例时,被引用的用例加下划线。
    ----详细  格式  begin ------
    用例名称: 
    通常为动宾词组,体现出对用户有价值的功能目标 
    类型: 
    BUC|BUCR|SUC 

    范 围: 
    写出具体的SuD名称 
    层次: 
    ++|+|!|-|-- 
    优先级: 
    High|Medium|Low 

    版 本: 
    当前版本 
    作者: 
    当前版本的作者 
    日期: 
    当前版本的日期 

    变更历史: 
    历史 版本号 (日期) 版本说明;变更事项 修订者 

    用例图: 说明此用例的 SuD 以及主要用角关系(主用角、次用角、辅用角)和用例关系(包含、扩展、继承)等 

    相关用例: 
    与此用例相关、存在重要联系的用 例 

    简述/背景: 
    说明此用例的主要目的,基本内容和相关背景 
    实现的特性: 
    依次列出此用例实现的主要系统特 性(Feature) 

    情节举例: 
    用具体的实例说明用例执行的一个情况。 

    主用角责权利: 
    主用角: 责权利 

    其他干系者责权利: 
    说明除主用角外,其他次用角、干系人、外部系统的责权利,所扮演的角色 

    干系者名 称:责权利 
    ... 

    后置状态 
    与条件 
    最小保证: 
    无论用例执行成功或失败,系统对所有干系者作出的 最小/最起码的承诺 

    保证条件说明 
    成功保证: 
    用例目标成功达成后,系统为满足所有干系者的利益而作出的承诺,达到的 状态和满足的条件 

    成功状态名称:状态说明,应满足的条件 
    ... 

    失败保证: 
    用例目标失败后,系统 为满足所有干系者的利益而作出的承诺,达到的状态和满足的条件 

    失败状态名称:状态说明,应满足的条件 
    ... 
    前置状 态与条件: 
    用例开始执行前所处的状态和/或应满足的条件 

    状态名称:状态说明,条件说明 
    ... 
    触发事 件: 
    触发用例从前置状态开始执行的事件 
    基本流: 
    说明一个最主要的成功执行路径 

    {名称标记} 
    步 骤编号 事件/步骤描述 
    ... 

    公共流: 被此用例的其他动作流引用的公共步骤 

    {动作流名称} 
    {片 断名称标记} 
    步骤编号 事件/步骤描述 
    ... 

    扩展流: 


    说明除基本流之外的其他成功流、 失败流和可选、替换流 

    {扩展名称标记} 
    扩展位置引用 
    扩展条件: 
    扩展处理 

    ... 

    扩 展点: 
    此用例允许其他用例扩展插入的位置 

    扩展点名称 {扩展点在基本流、扩展流当中的位置} 
    技术和数据变化: 
    此 用例执行时,在技术和数据方面不同的做法 
    非功能需求: 
    (URPS+) 
    包括易用性、可靠性、性能、可维护性等方面的要求 
    业 务规则: 
    作用于此用例的各项业务约束 

    数据字段: 
    说明此用例中用到数据的字段名称、类型等细节,可与领域模型联系起 来 

    未决问题: 
    此用例当前存在的问题 

    备注: 
    其他任何需要说明、补充的事项 

    ---- 详细  格式  end ------
    三、例子
    用例1:(符号)通过万维网购买股票
    (注:这里的符号可以是“黑盒”符号,表示程序运行在与万维网相连的工作站上,表示所讨论的系统 是一个计算机系统,符号的使用完全可以根据个人的喜好来选择,但对范围和层次的标记却不是)
     主 执行者:购买者
    范围:私人顾问/金融包
    层次:用户目标
    项目相关人员和利益:
            购买者----购买股票,并希望所买股票能自动被加到PAF记录中。
            股票代理商----希望得到全部的购买信息。
    前置 条件:用户已经打开PAF。
    最小保证:有足够的登录信息,以便当出现问题时,PAF能够检测到问题,并要求用户提供更详细的信息。
    成功保 证:远程web 站点认可此次购买事件;日志和用户记录被更新。
    主 成功场景:
    1、购买者选择通过万维网来购买股票。
    2、PAF从用户那里得到所用站点的名称(如E*Trade、Schwab等)。
    3、 PAF与该站点建立网络连接,并保持控制权。
    4、购买者在该站点上浏览并购买股票。
    5、PAF截取站点的响应信息,并更新购买者的记录。
    6、 PAF向用户显示更新后的记录情况。
    扩展:
    2a、购买者要使用一个PAF不支持的站点:
        2a1:系统从购买者那里获取新建议,带有取消用例的选项。
    3a、在设置过程中,网络发生故障:
        3a1:系统向购买者报告错误,并建议他退回到前一步。
        3a2:购买者或者此用例,或者重新再试。
    4a、计算机系统崩溃或者在 交易过程中被关掉:
        4a1:(这时,我们该怎么办?)
    4b、Web站点没有及时认可此次购买活动,而是把它推迟处理:
        4b1:PAF把这次推迟事件记入日志,设置一个时钟,定期向购买者询问结果。
    5a、Web站点没有返回关于购买情况的必要信息:
        5a1:PAF把缺少信息的事件记入日志,要求购买者更新存有疑问的交易
    下 面是用例网站公告发布的用例描述
      用例名称:网站公告发布 
      用例标识号:202 
       参与者:负责人 
      简要说明:
      负责人用来填写和修改家教网站首页的公告,公告最终显示在家教网站的 首页上。 
      前置条件:
      负责人已经登陆家教网站管理系统 
      基本事件流:
       1. 负责人鼠标点击“修改公告”按钮
      2. 系统出现一个文本框,显示着原来的公告内容
      3. 负责人可以在文本框上修改公告,也可以完全删除,重新写新的公告
      4. 负责人编辑完文本框,按“提交”按钮,首页公告就被修改
       5. 用例终止 
      其他事件流A1:
      在按“提交”按钮之前,负责人随时可以按“返回”按钮,文本框 的任何修改内容都不会影响网站首页的公告 
      异常事件流:
      1. 提示错误信息,负责人确认
       2. 返回到管理系统主页面 
      后置条件:
      网站首页的公告信息被修改 
       注释:无
    例 子3

    用例:

    用例视图向外部用户展示了其捕获的系统、子系统、类 或者组件的行为。它将系统功能划分成对执行者和有意义的事物。而交互功能的部分被称作用例。

    是 代表系统中各个项目相关人员之间就形态行为。所达成的契约。

    编写用例必须掌握三个概念

    • 范 围:真正被讨论的系统是什么?
    • 主执行者:谁有要实现的目标?
    • 层 次:目标的层次是高是低?

     

    其它概念:

    • 执 行者:任何具有行为的人或物
    •   项 目相关人员:对被讨论的系统的行为有特定兴趣的人或物
    • 主执行者:启动与被讨论系统得一次交互活动,从而达到 某一个目标的人或物
    • 用例:规定被讨论系统行为的契约
    • 范围:界 定被讨论的系统
    • 前置条件和保证:在用例执行之前和之后必须满足的条件
    • 主 成功场景:一切顺利的情况
    • 扩展:场景执行过程中出现的不同情况

     

    三 个命名的目标层次

    1.          概 要层次
    包含多个用户目标。在描述系统时,它们有如下三个方面的功能:
            显示用户目标运行的语境
            显示相关目标的生命周期顺序
            为 低层用例(包括白色用例和蓝色用例)提供一个目录表。

    2.          用 户目标级
    它是主执行者努力使工作得以完成的目标,或是用户使用系统的目标。

    3.          子 功能级
    是指那些再实现用户目标时可能会被用到的目标。

    用例模板
        用例图只是简单地可视化描述系统,我们还需要对用例进行详细的说明。为了明确的描述用例我们需要一个用例模板,但是至今并没有统一的用例模板。用例模板的 内容一般包括:简要描述、前置条件、后置条件、基本事件流、备选事件流等等。
      简要描述:对用例的角色、目的的简要描述。
      前置条 件:执行用例之前系统必须要处于的状态,或者要满足的条件。
      后置条件:用例一旦执行后系统所处的状态。
      基本事件流:描述该用例的 基本流程,指每个流程都“正常”运作时所发生的事情,没有任何备选流而只有最有可能发生的事件流。
      备选事件流:表示这个行为或流程是可选的或 备选的,并不是总要总要执行它们。

    下面是一个用例模板的示例:  

    用例: < 编号 >< 名 称 >

    特 征信息:

         用例在系统中的目标(用例目标描述)

         范围(当前考虑的是哪个系统)

         级别(概要任务 / 首 要任务 / 子功能)

         前提条件(用例执行前系统用具有的状态)

         成功后继条件(用例成功执行后应具有的状态)

         失效后继条件(用例没有完成目标的状态)

         首要角色(与该用例关联的首要角色)

         触发(启动该用例执行的系统动作)

    主 要步骤:

         < 步骤编号 >< 动作描述 >

    扩 展:

         < 有变化情况的步 骤编号 >< 条件 >:< 动作或另外一个用例 >

    变 异:

         < 步骤或变化编号 >< 变异列表 >

    相 关信息:(可选)

         优先级(该用例对于系统组织 的关键程度)

         性能目标(该 用例的执行时间耗费)

         频 度(该用例被执行的频度)

    从属用例:(可选)

    下 属用例:

    与首要角色的联系渠道(包括交互式、静态文件、数据库 等)

    公 开问题:(可选)

    posted on 2006-11-06 22:50 王兴  阅读 (474) 评论(1)   编辑  收藏  网摘  所属分类: 技术文章

    评论

    #1楼   [楼主 ]  2006-11-07 22:09  王兴       

    用例名 称: 
    通常为动宾词组,体现出对用户有价值的功能目标 
    类型: 
    BUC|BUCR|SUC 

    范围: 
    写 出具体的SuD名称 
    层次: 
    ++|+|!|-|-- 
    优先级: 
    High|Medium|Low 

    版 本: 
    当前版本 
    作者: 
    当前版本的作者 
    日期: 
    当前版本的日期 

    变更历史: 
    历史 版本号 (日期) 版本说明;变更事项 修订者 

    用例图: 说明此用例的 SuD 以及主要用角关系(主用角、次用角、辅用角)和用例关系(包含、扩展、继承)等 

    相关用例: 
    与此用例相关、存在重要联系的用 例 

    简述/背景: 
    说明此用例的主要目的,基本内容和相关背景 
    实现的特性: 
    依次列出此用例实现的主要系统特 性(Feature) 

    情节举例: 
    用具体的实例说明用例执行的一个情况。 

    主用角责权利: 
    主用角: 责权利 

    其他干系者责权利: 
    说明除主用角外,其他次用角、干系人、外部系统的责权利,所扮演的角色 

    干系者名 称:责权利 
    ... 

    后置状态 
    与条件 
    最小保证: 
    无论用例执行成功或失败,系统对所有干系者作出的 最小/最起码的承诺 

    保证条件说明 
    成功保证: 
    用例目标成功达成后,系统为满足所有干系者的利益而作出的承诺,达到的 状态和满足的条件 

    成功状态名称:状态说明,应满足的条件 
    ... 

    失败保证: 
    用例目标失败后,系统 为满足所有干系者的利益而作出的承诺,达到的状态和满足的条件 

    失败状态名称:状态说明,应满足的条件 
    ... 
    前置状 态与条件: 
    用例开始执行前所处的状态和/或应满足的条件 

    状态名称:状态说明,条件说明 
    ... 
    触发事 件: 
    触发用例从前置状态开始执行的事件 
    基本流: 
    说明一个最主要的成功执行路径 

    {名称标记} 
    步 骤编号 事件/步骤描述 
    ... 

    公共流: 被此用例的其他动作流引用的公共步骤 

    {动作流名称} 
    {片 断名称标记} 
    步骤编号 事件/步骤描述 
    ... 

    扩展流: 


    说明除基本流之外的其他成功流、 失败流和可选、替换流 

    {扩展名称标记} 
    扩展位置引用 
    扩展条件: 
    扩展处理 

    ... 

    扩 展点: 
    此用例允许其他用例扩展插入的位置 

    扩展点名称 {扩展点在基本流、扩展流当中的位置} 
    技术和数据变化: 
    此 用例执行时,在技术和数据方面不同的做法 
    非功能需求: 
    (URPS+) 
    包括易用性、可靠性、性能、可维护性等方面的要求 
    业 务规则: 
    作用于此用例的各项业务约束 

    数据字段: 
    说明此用例中用到数据的字段名称、类型等细节,可与领域模型联系起 来 

    未决问题: 
    此用例当前存在的问题 

    备注: 
    其他任何需要说明、补充的事项

    展开全文
  • UML建立用例模型

    2022-03-11 08:53:13
    用例模型描述的是外部执行者,如用户所理解的系统功能。它描述了是一个系统“做什么”,而不是“怎么做”,用例不关心系统设计。 用例建模过程 定义系统 确定执行者和用用例 描述执行者和用例关系 确认模型 1.2 ...

    1. 用例模型

    1992年Jacobson提出了Use case的概念以及可视化的表示方法—Use Case图,受到IT界的欢迎,被广泛应用到面向对象的系统分析中。

    1.1 需求分析与用例建模

    用例模型描述的是外部执行者,如用户所理解的系统功能。它描述了是一个系统“做什么”,而不是“怎么做”,用例不关心系统设计。

    用例建模过程

    1. 定义系统
    2. 确定执行者和用用例
    3. 描述执行者和用例关系
    4. 确认模型

    1.2 确定执行者和用例

    用例图中包含的三种模型元素:执行者、用例和连接

    1. 确定执行者

    1. 谁使用系统的主要功能?
    2. 谁需要从系统获得日常工作的支持与服务?
    3. 需要谁维护管理系统的日常运作(副执行者)?
    4. 系统需要控制哪些硬件设备?
    5. 系统需要与其他哪些系统交互?
    6. 谁需要使用系统产生结果(值)?

    2. 识别用例

    1. 与系统实现有关的主要问题是什么?
    2. 系统需要哪些输入/输出?这些输入/输出从何而来?到哪里去?
    3. 执行者需要系统提供哪些功能?
    4. 执行者是否需要对系统中的信息进行读取、创建、修改、删除或存储?如果首先确定系统的角色,也可以通过角色来识别用例。

    3. 建立用例之间的关系

    1. include

    本质上是一种使用关系,当一个用例包含另一个用例时,这两个用例之间就构成了使用关系。

    1. extend

    是向一个用例中加入一些新的动作,构成另一个用例,这两个用例之间的关系就是扩展关系。

    1.3 用例建模实例

    在这里插入图片描述

    在这里插入图片描述
    选课成绩管理子模块
    在这里插入图片描述

    展开全文
  • uml用例文档

    2013-11-19 21:15:12
    本文档中采用UML建模方法,用Use Case模型做了详细的描述
  • UML用例建模解析

    2019-05-21 02:09:55
    UML用例建模解析(一) 【作者:刘伟 http://blog.csdn.net/lovelion】 UML是软件开发中绘制软件蓝图使用标准语言之建模技术,通过UML可以构造软件系统的需求模型(用例模型)、静态模型、动态模型和架构模型。UML...
  • UML中通过用例驱动的方式来一步一步获取对现实世界的理解。 一般我们通过如下三个用例建模步骤来获取对现实世界问题的认知,然后将其转化为计算机世界的实现,主要有如下三个步骤: 业务用例建模 概念用例建模 ...
  • UML用例建模在信息管理系统需求分析中的应用论文 需求分析阶段的任务是确定软件系统功能用例建模是面向对象软件开发技术中的一个重要部分它从用户角度描述软件系统功能以医学院临床管理信息系统为例利用统一建模语言...
  • UML建模之正式用例描述规范

    千次阅读 2013-09-22 14:54:08
    正式用列具有格式规范,包括:用例名、自然语言描述体、图例说明、范围、级别、主执行者、项目相关人员和利益、前置条件、最小保证、成功保证、触发事件、主成功场景、扩展场景和相关信息等项目,用例格式并不是硬性...
  • 用例图是UML图例中重要图例之一,是人、事、物建模的关键方式,特定情况下,在不同的用例间存在一定的关系,包括 -【扩展】:如果一个用例明显地混合了两种或者两种以上的不同场景,即根据情况可能发生多种分支,则...
  • 有关图书管理系统的用例描述,列举了各种用力的细化,格式正确,供大家参考
  • UML 用例规约

    千次阅读 2015-01-07 13:56:34
    用例图是骨架,而用例规约则是其内在的肉用例文档的核心,而用例图作为用例文档的总图  1.前置条件:把它们看做是看门人,它阻止参与者触发该用例直到满足所有条件...事件流描述要点:        3.0
  • UML-用例图介绍

    千次阅读 2019-03-13 08:53:53
    用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统,以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素,如系统、参与者和用例,并且显示这些元素之间的各种关系,如泛化、...
  • UML(统一建模语言)是当前软件开发中使用最为广泛的建模技术之一,通过使用UML可以构造软件系统的需求模型(用例模型)、静态模型、动态模型和架构模型。UML通过图形和文字符号来描述一个系统,它是绘制软件蓝图的...
  • UML实验二用例分析

    2017-12-28 23:05:40
    分析是为了满足需求模型中所描述的功能,探讨系统内部应该有什么样的业务核心机制的过程。将以用户视角描述的需求模型转化为以开发团队视角描述的分析模型。 (2)分析模型包含两个层次的两类模型。两个层次是指...
  • UML用例建模解析(绘制用例图)

    千次阅读 2019-03-01 00:09:40
    UML(统一建模语言)是当前软件开发中使用的最为广泛的建模技术之一,通过使用UML可以构造软件系统的需求模型(用例模型)、静态模型、动态模型和架构模型。 #需求模型: 需求模型又称用例模型,主要用于描述系统的功能...
  • UML03 - 用例视图

    2020-11-16 01:29:22
    与一个或多个参与者之间的一系列消息来描述系统中的交互作用。参与者可以是人,也可以是外部计算机系统和外部进程。图 5–1表述了一个电话目录销售的用例视图。此例是实际 系统简化后的例子。 参与者 ...
  • uml用例

    2016-03-02 15:29:44
    1.0前言uml主要模型包括 - 业务用例模型 - 概念用力模型 - 系统用例模型 - 领域用例模型 - 分析模型 - 软件框架和架构模型 - 设计模型 - 组件模型 - 实施模型 2.0基础用例模型2.1用例模型用例模型...
  • 用例3.类之间关系 1.参与者   参与者可以表示与系统接口相关的任何事物和任何人。包括人、外部系统和其它组织,参与者位于建模系统的外部。比如时间(系统时钟)和打印机等外部硬件设备和其它系统。 2.用例   ...
  • UML-用例建模

    2020-03-10 13:39:59
    为了有效地定义所沟构造系统的需要,提出需求工程的...通过用例来解决需求定义过程中出现的问题,针对需求的难捕获特点,我们需要从用户的角度去理解问题,针对易变的问题,则是通过用例来建立合理的需求结构,因...
  • UML用例

    千次阅读 2010-01-25 08:16:00
    用例图 用例图是被称为参与者的外部用户所能观察到的系统功能的模型图,呈现了一些参与者和一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。用例图指定处理外部业务事件的基本进程。 ...
  • uml课程中的用例描述:关于银行系统管理
  • 进行一个业务用例模型调查进行业务用例说明业务用例的实现事件/动作与职责/活动之间的区别将注意力放在过程自动化上关注信息流程结论附录:业务建模简介就像大多数的软件开发从业者所知道的那样,统一建模语言(UML)...
  • 简要说明本用例描述验证登记收支的操作流程进行该操作的财务人员2 1?简要说明本用例描述验证登记收支的操作流程进行该操作的财务人员 1?基本流 1登录系统 2登记酒店相应收支信息及数据 2备选流 无 3特殊需求 无 前置...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 23,556
精华内容 9,422
关键字:

uml用例描述