精华内容
下载资源
问答
  • 软考之用例模型

    2019-12-15 15:04:57
    用例模型主要由以下模型元素构成: 参与者(Actor) 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境。 用例(Use Case) 用例用于表示系统所提供的服务,它...

    用例概念理解

    用例模型主要由以下模型元素构成:

    参与者(Actor)

    • 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境。

    用例(Use Case)

    • 用例用于表示系统所提供的服务,它定义了系统是如何被参与者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

    通讯关联(Communication Association)

    • 通讯关联用于表示参与者和用例之间的对应关系,它表示参与者使用了系统中的哪些服务(用例),或者说系统所提供的服务(用例)是被哪些参与者所使用的。

    这大三种模型元素在UML中的表述如下图所示

    • 20190716093603.png

    通讯关联表示的是参与者和用例之间的关系,箭头表示在这一关系中哪一方是对话的主动发起者,箭头所指方是对话的被动接受者;如果你不想强调对话中的主动与被动关系,可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的,该信息流是缺省存在的(用例本身描述的就是参与者和系统之间的对话),并且信息流向是双向的,它与通讯关联箭头所指的方向亳无关系。

    事件流

    • 用例描述的是参与者与系统之间的对话,对话的细节
      用事件流进行描述。

    事件流分类

    基本事件流

    • 描述正常流程
      备选事件流
    • 描述异常终止流程

    小结

    优点:

    • 用例方法站在用户的角度(从系统外部)来描述系统的功能,将需求与设计分离,在面向对象的分析设计方法中,用例模型主要用于表述系统的功能性需求,系统的设计主要由对象模型来记录表述。

    • 用例方法比传统的SRS更易于被用户所理解,它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

    用例建模

    用例模型主要包括以下两部分内容:

    用例图(Use Case Diagram)

    • 确定系统中所包含的参与者、用例和两者之间的对应关系,用例图描述的是关于系统功能的一个概述。

    用例规约(Use Case Specification)

    • 针对每一个用例都应该有一个用例规约文档与之相对应,该文档描述用例的细节内容。

    寻找参与者

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

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

    这些问题有助于我们抽象出系统的参与者。对于ATM机的例子,回答这些问题可以使我们找到更多的参与者:操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。
    20190716094948.png

    系统边界决定了参与者

    参与者是由系统的边界所决定的,如果我们所要定义的系统边界仅限于ATM机本身,那么后台服务器就是一个外部的系统,可以抽象为一个参与者。

    20190716095036.png

    如果我们所要定义的系统边界扩大至整个银行系统,ATM机和后台服务器都是整个银行系统的一部分,这时候后台服务器就不再被抽象成为一个参与者。

    20190716095057.png

    用例规约

    用例规约用以描述每一个用例的详情,用例模型是由用例图和每一个用例的详细描述――用例规约所组成的,RUP-统一软件过程中提供了用例规约的模板,每一个用例的用例规约都应该包含以下内容:

    简要说明 (Brief Description)

    • 简要介绍该用例的作用和目的。

    事件流 (Flow of Event)

    • 包括基本流和备选流,事件流应该表示出所有的场景。

    用例场景 (Use-Case Scenario)

    • 包括成功场景和失败场景,场景主要是由基本流和备
      选流组合而成的。

    特殊需求 (Special Requirement)

    • 描述与该用例相关的非功能性需求(包括性能、可靠性、可用性和可扩展性等)和设计约束(所使用的操作系统、开发工具等)。

    前置条件 (Pre-Condition)

    • 执行用例之前系统必须所处的状态。

    后置条件 (Post-Condition)

    • 用例执行完毕后系统可能处于的一组状态。

    注:用例规约基本上是用文本方式来表述的,为了更加清晰地描述事件流,也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了,就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其他图形。如活动图有助于描述复杂的决策流程,状态转移图有助于描述与状态相关的系统行为,序列图适合于描述基于时间顺序的消息传递。

    基本流

    基本流描述的是该用例最正常的一种场景,在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流:

    • 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

    • 用一句简短的标题来概括每一步骤的主要内容。

    • 当整个用例模型基本稳定之后,我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性,即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息;(2)对此系统有什么样的响应。

    在描述参与者和系统之间的信息交换时,需指出来回传递的具体信息。例如,只表述参与者输入了客户信息就不够明确,最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内,可以在词汇表中定义客户信息等内容,使用例不至于陷入过多的细节。

    备选流

    备选流负责描述用例执行过程中异常的或偶尔发生的一些情况,备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时,应该包括以下几个要素:

    • 起点:该备选流从事件流的哪一步开始;

    • 条件:在什么条件下会触发该备选流;

    • 动作:系统在该备选流下会采取哪些动作;

    • 恢复:该备选流结束之后,该用例应如何继续执行。

    备选流的描述格式可以与基本流的格式一致,也需要编号并以标题概述其内容,编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。

    用例场景

    用例在实际执行的时候会有很多的不同情况发生,称之为用例场景;在用例规约中,场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏,同时也可以对后续的开发工作起到很大的帮助:开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。

    特殊需求

    特殊需求通常是非功能性需求,它为一个用例所专有,但不适合在用例的事件流文本中进行说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性(包括可用性、可靠性、性能或支持性需求等)。此外,其他一些设计约束,如操作系统及环境、兼容性需求等,也可以在此节中记录。

    需要注意的是,这里记录的是专属于该用例的特殊需求;对于一些全局的非功能性需求和设计约束,它们并不是该用例所专有的,应把它们记录在《补充规约》中。

    前置和后置条件

    前置条件是执行用例之前必须存在的系统状态,后置条件是用例一执行完毕后系统可能处于的一组状态。

    检查用例模型

    用例模型完成之后,可以对用例模型进行检查,看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查:

    功能需求的完备性

    • 现有的用例模型是否完整地描述了系统功能,这也是我们判断用例建模工作是否结束的标志。

    模型是否易于理解

    • 用例模型最大的优点就在于它应该易于被不同的涉众所理解,因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。

    是否存在不一致性

    • 系统的用例模型是由多个系统分析员协同完成的,模型本身也是由多个工件所组成的,所以要特别注意不同工件之前是否存在前后矛盾或冲突的地方,避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。

    避免二义性语义

    • 好的需求定义应该是无二义性的,即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中,应该避免定义含义模糊的需求,即无二义性。

    系统需求

    RUP中根据FURPS+模型将系统需求分为以下几类:

    • 功能(Functionality)
    • 可用性(Usability)
    • 可靠性(Reliability)
    • 性能(Performance)
    • 可支持性(Supportability)
    • 设计约束等

    除了第一项功能性需求之外的其他需求都归之为非功能性需求。

    需求工件集

    用例模型主要用于描述系统的功能性需求,对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。

    • 用例模型:记录功能性需求
    • 用例图:描述参与者和用例之间的关系
    • 用例规约:描述每一个用例的细节信息
    • 补充规约:记录一些全局性的功能需求、非功能性需求和设计约束等
    • 词汇表:记录一些系统需求相关的术语

    在实际应用中,除了这些工件之外,我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的,如编译器,我们很难用用例方法来表述它所处理的语言的方法规则,在这种情况下,采用传统的BNF范式来表述更加合适一些。在电信软件行业中,很多电信标准都是采用SDL语言来描述的,我们也不必用UML来改写这些标准(UML对SDL存在着这样的兼容性),只需将SDL形式的电信标准作为需求工件之一,在其他工件中对其加以引用就可以了。总之,万万不可拘泥于用例建模的形式,应灵活运用各种方式的长处

    补充规约

    补充规约记录那些在用例模型中不易表述的系统需求,主要包括以下内容。

    功能性

    • 功能性需求主要在用例模型中刻画,但是也有部分需求不适合在用例中表述。有些功能性需求是全局性的,适用于所有的用例,如出错处理、I18N支持等,我们不需要在所有的用例中描述这些功能性需求,只需要在补充规约中统一描述就可以了。

    可用性

    • 记录所有可用性相关的需求,如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。

    可靠性

    • 定义系统可靠性相关的各种指标,包括:
      • 可用性:指出可用时间百分比(xx.xx%),系统处于使用、维护、降级模式等操作的小时数;
      • 平均故障间隔时间(MTBF):通常表示为小时数,但也可表示为天数、月数或年数;
      • 平均修复时间(MTTR):系统在发生故障后可以暂停运行的时间;
      • 精确度:指出系统输出要求具备的精密度(分辨率)和精确度(按照某一已知的标准);
      • 最高错误或缺陷率:通常表示为bugs/KLOC(每千行代码的错误数目)或bugs/function-point(每个功能点的错误数目)。

    性能

    • 记录系统性能相关的各种指标,包括:
      • 对事务的响应时间(平均、最长);
      • 吞吐量(例如每秒处理的事务数);
      • 容量(例如系统可以容纳的客户或事务数);
      • 降级模式(当系统以某种形式降级时可接受的运行模式);
      • 资源利用情况:内存、磁盘、通信等。

    可支持性

    • 定义所有与系统的可支持性或可维护性相关的需求,其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。

    设计约束

    • 设计约束代表已经批准并必须遵循的设计决定,其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。

    词汇表

    词汇表主要用于定义项目特定的术语,它有助于开发人员对项目中所用的术语有统一的理解和使用,它也是后续阶段中进行对象抽象的基础。

    调整用例模型

    关系描述

    参与者与用例

    参与者与参与者

    • 泛化
    • 继承

    用例与用例

    • 包含(include)
    • 扩展(extend)
    • 泛化(generalization)

    包含

    • 包含关系是通过在关联关系上应用<< include>>构造型来表示的,如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion),具体地讲,就是将被包含用例的事件流插入到基础用例的事件流中。
    graph LRA(基础用例) -->|include| B(被包含用例)

    在ATM机中,如果查询、取现、转帐这三个用例都需要打印一个回执给客户,我们就可以把打印回执这一部分内容提取出来,抽象成为一个单独的用例"打印回执",而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时,就只需要改动一个用例,而不用在每一个用例都作相应修改,这样就提高了用例模型的可维护性。

    graph LRA(银行客户) --> B(查询)A --> C(提款)A --> D(转账)B -->|include|E(打印回执)C -->|include|ED -->|include| E

    扩展

    • 扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。

    • 对于包含关系而言,子用例中的事件流是一定插入到基础用例中去的,并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流,并且插入点可以有多个。

    graph TBA(扩展用例) --> B(打电话) C(呼叫等待) --> |extend|BD(呼叫转移) --> |extend|B

    例如对于电话业务,可以在基本通话(Call)业务上扩展出一些增值业务如:呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。

    graph LRA(电话用户) -->|extend| B(基础用例)

    20190717201745.png

    泛化

    • 当多个用例共同拥有一种类似的结构和行为的时候,我们可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。
    graph BTA(子用例1) --> B(父用例)C(子用例2) --> B
    • 在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。
    展开全文
  • 一种多进程系统用例模型的逆向生成方法,邬丽红,陈平,用例模型是展现程序系统级行为的有效手段。本文针对具有并发特征的面向对象软件系统提出了一种多进程系统用例模型的逆向生成方法
  • 需求分析与用例模型(扩展阅读)_用例和用例图,面向对象的分析方法
  • 软件工程课设资源,基于web的网上书店 利用rational rose 制作的用例模型 包括用例图,类图 时序图,活动图
  • 用例模型:从用户或业务的角度解决一个系统所应该拥有的相对独立和完整功能需求及需求之间的相互关系,以及功能与角色之间的对应关系。 用例图:主要元素包括参与者、用例、以及元素之间的关系。描述了系统中功能与...
    1. 用例模型:从用户或业务的角度解决一个系统所应该拥有的相对独立和完整功能需求及需求之间的相互关系,以及功能与角色之间的对应关系。
    2. 用例图:主要元素包括参与者、用例、以及元素之间的关系。描述了系统中功能与行为。
    3. 解决用户的需求,使计划合理优化,要引入具体的办法或过程。
      1.做WBS:把复杂的项目通过利用工艺把他分解成若干个具体活动或作业,并定义清楚每一个作业的所包含的含义要求及相互关系。
      2.计划:利用网络计划原理,利用顺排或倒排来做计划。
      3.控制:完善保证体系来保证整个计划顺利实施。如检查表,看板。
      4.分析:大数据分析工具:用来反应计划的合理性和问题,及时做出反应,并吸取经验教训。
    4. 用例模型的图例符号:
      1.系统边界:
      定义系统的范围;
      2.用例:
      相对完整的功能单位,一个用例模型可能包含多个。
      3.关系:
      用例和角色之间的关系:用一条直线表示;
      用例与用例之间的关系有包含关系、扩展关系两种;
      包含关系:一个用例必须把另外一个用例所具有的功能完整包含进来;A是包含用例,B是被包含用例;被包含用例所具有的功能使包含用例里不可或缺的;
      扩展关系:A是被扩展的用例,箭头指向的B是扩展用例,扩展用例的功能可以选择不实施;

    4.角色(Actor):
    (1)用例的执行者或使用者,具有相同功能的人或设备的总体;
    (2)位于系统边界之外,而不是系统的一部分;
    (3)确定参与者可以从以下几个方面来考虑:
    a.为系统提供输入的人或事;
    b.接受系统输出的人或物;
    c.需要接入的第三方系统或设备;
    d.时间是否会触发某些事件;
    e.负责支持或维护系统中信息的人;
    (4)角色分类:
    a.主要业务参与者;
    b.主要系统参与者;
    c.外部服务参与者;
    d.外部接受参与者;
    (5)角色的泛化关系:
    在这里插入图片描述

    在这里插入图片描述

    1. **用例:**系统中划分出的相对独立的完整的功能单位,从业务的角度考虑,而不是软件的单位。即一个一个的业务流程包含的活动(活动是相对独立的)
      1.识别用例:通过参与者入手来寻找用例。
      在这里插入图片描述
      2.用例的特征:
      a.用例是动宾短语,比如“入库管理”;
      b.用例是相对完整独立的;
      c.用例是由参与者启动的,但不完全是,也有是系统自动启动的;
      d.用例要有可观测的执行结果;
      e.一个用例是一个单元;
      3.用例的粒度:指用例组织信息的方式和细化程度。
      一般来讲,管理水平高的企业用例会更细,粒度会更多。
      在这里插入图片描述
    展开全文
  • 用例模型实例

    2014-03-22 20:00:50
    用例模型实例
  • 具有活动图的用例模型 具有活动图的用例模型模式将创建元素和用例图,以描述用户角色希望从系统中实现的目标。用例全部包含在系统边界内,而参与者均位于边界外。活动图(图形)是根据“场景构建器”中定义的“用例...

    具有活动图的用例模型
    具有活动图的用例模型模式将创建元素和用例图,以描述用户角色希望从系统中实现的目标。用例全部包含在系统边界内,而参与者均位于边界外。活动图(图形)是根据“场景构建器”中定义的“用例”和“场景步骤”自动生成的,允许涉众可视化这些步骤并将其用作UX设计和系统实现的基础。
    在这里插入图片描述

    如图,显示了用例图,其中包含Actor和许多用例,这些用例包含在系统边界中。用例A具有定义的步骤,这些步骤指定用户之间的交互和系统。
    在这里插入图片描述
    如图:显示了场景构建器,其中定义了用例和场景的步骤。 这些步骤可用于生成许多行为模型,包括活动图和状态机图。
    在这里插入图片描述
    如图:显示了根据用例A在“场景构建器”中定义的步骤自动生成的活动图(图)。可以在图上从“决策”元素分支看到替代场景。

    目的:是允许业务分析师和其他利益相关者描述与系统交互时Actor(用户扮演的角色)希望实现的价值。
    时机:该模式通常用于计划的分析阶段。
    绘制过程:
    在这里插入图片描述

    符号说明:
    在这里插入图片描述

    应用场景:可用于实现任何数量的需求,并为实施团队提供规范。 它可以用于:可视化用例及其场景中的步骤。提供一种将工作分配给UX设计团队的机制(“活动”图中的“用户步骤”最终将需要用户界面)。提供一种将工作分配给实施团队的机制(“活动”图中的“系统步骤”将需要在系统中实施)
    图例
    图例功能对于手动或自动更改图上元素和连接器的外观很有用。 可以从“通用工具箱”中添加图例,并将其配置为编码填充和线条颜色以及线条粗细。 这是一种在图表上添加含义和表达的强大方法,当根据元素或连接器属性自动应用时,尤其具有表现力。它可以与许多特殊用途一起用作路线图,以创建强大的可视化效果。

    展开全文
  • 如何建立用例模型

    千次阅读 2018-01-29 14:56:07
    建立用例模型   用例的定义:用例实例是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果,一个用例定义一组用例实例。 用例模型如何产生:采用现有的需求捕获技术从客户、原有系统、文档中...

    建立用例模型 

    •  用例的定义:用例实例是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果,一个用例定义一组用例实例。 
    •  用例模型如何产生:采用现有的需求捕获技术从客户、原有系统、文档中找到需求,然后进行整理、提炼,从而建立用例模型 
    •  识别参与者:参与者是同系统交互的所有事物,不仅可以由人承担,还可以是其他系统、硬件设备等。参与者一定在系统之外,不是系统的一部分。 
    • 合并需求获得用例:将参与者找到之后,仔细检查参与者,为每一个参与者确定用例。 
    •  绘制成用例图:将识别到的参与者及生成的用例通过用例图的形式整理出来,获得用例模型的框架 
    •  细化用例描述:用例描述包括:用例名称、简要说明、事件流、非功能要求、前置条件、后置条件、扩展点、优先级 
    展开全文
  • UML 业务用例模型.doc

    2020-06-14 02:28:51
    业务用例模型 业务用例模型业务用例模型描述一个业务的流程以及它们与外部各方如客户和合作伙伴之间的交互 解释 由业务用例和主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的直接与客户或合作伙伴...
  • 软件系统分析与设计 | 用例模型

    千次阅读 2019-05-26 00:41:04
    一、用例相关概念 1、什么是用例? use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. 用例(use case),或使用案例、用况,是软件...
  • 需求分析之用例模型UML图

    千次阅读 2018-09-16 16:26:15
    用例控制与包含用例的关系,以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用,也就是定义中说的情景。...
  • 酒店管理系统 用例模型图 主要是对各各子系统进行描述,包括13各子系统
  • 在软件设计中,由用例模型构造特征模型的方法有多种,有正交化的方法、有在基于UML用例模型基础上经过变换得到特征模型的方法。本文提出了基于公理设计的构造方法,利用公理设计矩阵来分析用例模型中的功能,利用功能的...
  • UML中构建用例模型的四个阶段

    千次阅读 2019-02-12 13:30:33
    识别参与者 合并需求获得用例 细化用例描述 调整用力模型
  • 2.2UC1用例模型(用例图和详述文本) 图用例图 关于销售开单的详述文本: 前置条件:收银员必须经过确认和认证。 后置条件:存储销售信息。准确计算税金。更新账务和库存信息。记录提成。生成票据。记录支付...
  • 第4章 建立用例模型;第4章 建立用例模型;第4章 建立用例模型;4.1 需求获取;4.1 需求获取;4.1 需求获取;4.1 需求获取;4.1 需求获取;4.2 分析需求;4.2 分析需求;4.2 分析需求;4.2 分析需求;4.3 用例在需求分析中的使用...
  • 3构建用例模型 2仓库管理员能够通过该系统进行如下活动 处理盘点每天需要对库存产品信息进行盘点 产品入库当产品生产后将产品进行入库 产品出库当产品销售发货后进行出库处理 管理设置仓库管理员负责供应商信息产品...
  • 具有状态机图的用例模型 具有活动图的用例模型模式将创建元素和用例图,以描述用户角色希望从系统中实现的目标。 用例全部包含在系统边界内,而参与者均位于边界外。 状态场景图(StateTransition)已从“场景创建器...
  • 结构化用例模型

    2020-11-10 00:16:12
    结构化用例模型模式创建结构化用例模型的元素和用例图,在结构化用例模型中,使用Includerelationship排除公共文本,并使用Extendrelationship删除扩展功能并建模。 专用功能也使用通用关系建模。 如图,显示一个用...
  • 实验一 基于UML的用例模型实验.ppt
  • 提出一种利用动态信息叠加生成用例模型的方法。该方法可以利用多次收集到的动态信息,叠加生成目标系统的用例模型并以UML用例图的形式呈现。通过实验测试,使用该方法恢复出来的用例模型接近于实际模型,证明了该...
  • 火龙果软件工程技术中心 本文内容包括:背景业务用例模型与系统用例模型有什么相似之处?业务用例模型与系统用例模型之间究竟有怎样的差别呢?我应该为业务建模使用哪些UML图?业务用例模型和系统用例模型之间的...
  • 业务分析模型可能有以下属性: 简介:文本描述,作为模型的简要简介。 业务系统:模型中的组件,表示层次结构。 业务工作者:模型中的业务工作者类,为业务系统所有。 业务实体:模型中的业务实体类,为业务...
  • 分布式温控系统 用例模型说明书 学院 计算机科学与技术学院 班级 2012211313 班级 13班A组 姓名 胡卓 杨明 李梦玉 叶子龙 赵博 2015年5月1日 . 版本修订记录 编号 日期 版本号 章节 编写者 说明 1 2015.5.1 V1.0 ...
  • 用例模型与概念模型的区别和联系

    千次阅读 2014-05-19 16:32:39
    二十世纪八十年代中期Jacobson花了很多精力来思考过去...但当用英文出版的时候,他发现“useage case”在英语里说不通,所以写作用例“use case” 1.首先研究它究竟是什么(what),三者的定义: 用例:即us
  • ATM系统的用例模型

    千次阅读 2018-11-24 13:39:08
    作业还要求写一个用例描述和一个系统顺序图,用例描述太长不放了而且被批改出了错误,系统顺序图我自知画的不好...
  • 谈谈用例模型的那些事儿 之 用例图

    千次阅读 2013-03-05 11:15:12
    ——对用例模型及其应用的一次有益的探讨 前言:这是一次对用例模型的探讨。怎样建立用例模型,怎样编写用例说明,它与需求规格说明书有什么区别,它能替代需求规格说明书吗?也许在这里可以找到你要的答案。 ...
  • 具有测试用例的基本用例模型 带有测试用例的基本用例模型模式创建元素和用例图,描述用户角色希望从系统中实现的目标。用例全部包含在系统边内,而参与者都位于边界外。测试用例已定义,显示了如何测试用例中指定的...
  • UML核心模型——用例模型

    千次阅读 2015-05-13 09:59:32
     用例模型是需求工作的结果, 用例模型有业务用例模型,概念用例模型和系统用例模型。他们拥有软件开发的不同生命周期阶段,它们三者是在不同的抽象层次上的,它们之间是一种精化关系。  业务用例模型  业务...
  • 本文由艾孜尔江撰稿。 软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 98,347
精华内容 39,338
关键字:

用例模型