下载文档原格式
软件工程之用例模型总结一、用例模型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用例建模的一些基本知识，主要包括基本文档，用例模型，用例规约和补充规约等内容，相信通过本节的学习你对UML用例建模一定会有所了解。
下面就让我们一起来看一下详细介绍吧。
UML用例建模基本知识基本文档：用例模型：记录功能性需求用例图：描述参与者和用例之间的关系用例规约：描述每一个用例的细节信息补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等词汇表：记录一些系统需求相关的术语------------------------------用例模型：用例图比较简单，主要有参与者和用例组成；参与者之间可以有泛化(Generalization)关系用例之间有包含(include)、扩展(extend)和泛化(generalization)关系。
包含是子函数，扩展是备选流泛化比较少用，也是备选流；UML用例建模中用例规约：简要说明(BriefDescription)简要介绍该用例的作用和目的。
事件流(FlowofEvent)包括基本流和备选流，事件流应该表示出所有的场景。
用例场景(Use-CaseScenario)包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
特殊需求(SpecialRequirement)描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
前置条件(Pre-Condition)执行用例之前系统必须所处的状态。
后置条件(Post-Condition)用例执行完毕后系统可能处于的一组状态。
UML用例建模的补充规约补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。
功能性功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。
有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。
第四章用例建模什么是需求？需求包括哪几个方面？需求：客户可接受的、系统必须满足的条件或具备的能力需求包括：功能性、使用性、可靠性、性能、可支持性五大方面。
2、什么是需求分析?需求分析有何重要意思？需求分析可以分为哪几个步骤？答："需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输“做什么”。
意义：需求分析是一个重要的一个阶段。
软件需求分析的质量对软件开发的影响是深远的、全局性的，质量需求对软件开发往往起到事半功倍的效果，所谓“磨刀不误砍柴功。
在后续阶段改正需求分析阶段产生的错误将付出高昂的代价需求分析大致可分为以下步骤：绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
同时它也明确了通过接口的信息流和物质流。
2）创建开发原型：创建用户接口原型。
当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。
用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
注意要找出需求文档与原型之间所有的冲突之处。
3）分析可行性：分析需求可行性。
在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
4）确定需求优先级：确定软件工程需求的优先级别。
应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。
以优先级为基础确定产品版本将包括哪些特性或哪类需求。
当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5）为需求建立模型：为需求建立模型。
需求的图形分析模型是软件需求规格说明极好的补充说明。
它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6）编写数据字典：创建数据字典。
五．用例模型（Use-Case Model）⒈内容概述用例模型是以专门术语描述实际系统功能需求的原型。
在用例模型中，一个实际系统功能需求被表示为一个到多个系统行为（System Behavior）。
为便于描述系统行为的动态过程，在用例模型中还使用活动图（Activity Diagram）来描述系统内部状态的变化过程（还配套状态图和事件流图）。
激发一个系统行为的第一信息来源和目标被称为角色（Actor），而当系统行为发生后会对第一信息来源产生反应。
角色只能在系统边界以外，用例模型实际上表现了系统内外的作用与反作用的信息交流过程。
UML中的用例模型分别用表示实际系统功能和与其相关的环境的图形符号体系所构成。
角色是与系统信息交互的源点与终点。
用例是系统与角色交互的一个系统行为的总和，与其他系统行为不同的是用例要特别描述出与其相关的角色、作用约束、响应性能等重要的系统数据。
在用例模型中用带有简要文字说明的箭头将用例和角色连接到一起。
可视化建模语言UML由五类模型视图和九种图所组成。
⒉创建步骤转DEV475_02_Requirements.PDF文档，直到DEV475_05_Requirements.PDF讲后返回本文档。
⒊问题的陈述的结构陈述的主要内容·问题的范围；·分别陈述要求解的必须部分的问题内容和可选择部分的问题内容；·叙述应用的背景情况；要注意下述问题：–不要涉及系统内部的内容；–阐明系统应用背景的各种假设前提；–阐明系统应用的性能要求；⒋建立用例模型的步骤①内容与目的依据问题的陈述而描述出现实世界中的对象类极其相互间的关系。
②建立用例模型所需的必要信息材料·问题的陈述；·应用领域内的专业经验和知识；·对现实生活的广泛了解和多门类的经验；·多多的交流；③建立用例模型的步骤·标记对象与类；·制作数据字典；·标记对象间的关联关系和包容关系；·标记对象的属性和连接；·提取对象间的继承关系；·测试对象间的访问路径；·反复审核用例模型并归纳同类对象；·在模型中使用类组；上述步骤可由下图体现：⒌通过用例模型标记对象与类这一步由下述步骤组成：·从问题陈述中抽取名词；·生成静态系统交互图；·用静态系统交互图修改初始化表；·依据应用领域内的专业经验和知识可能提交扩展的问题陈述；·标记附加的对象；在本步的应用中应注意下面两点：⑴生成静态系统交互图（Context Diagrams）静态系统交互图（在UML中称为用例图）用来描绘系统的范围。
1.实验环境及设备要求⑴每人需要有可接入Internet的计算机一台，并可登录网络化实验管理域跟踪系统。
⑵计算机安装有Microsoft Visio 2003。
2.实验目的⑴掌握用例模型的设计与创建方法。
⑵掌握如何使用Microsoft Visio 2003建立用例图模型。
3. 实验（设计）任务某汽车配件公司，向顾客供应汽车配件，顾客是汽车用户或是汽车修配厂，配件公司的货源来自各种不同的配件制造工厂或批发商。
顾客可以当时购买，也可以预先订货，公司负责托运。
汽车配件公司管理系统由销售、采购和会计三个系统组成。
系统的主要逻辑功能和基本目标如下：⑴顾客的订货要求有三种形式，一是邮寄订货单，二是打电话，三是直接到汽车配件公司营业部来办理。
⑵不管用哪种方式，都以一种标准的订货单格式输入到系统内。
⑶对每一张订货单必须首先加以验证，是否填写正确。
验证的内容包括汽车配件名称、规格、编号、顾客名称、地址、电话、开户银行、帐号等信息。
⑷如果正确无误才能给以处理。
⑸如果有错误、应当输出错误信息，通知业务人员加以纠正。
⑹按订货项目检索配件库存，确定是否能够满足顾客的要求。
⑺如果当前的库存量能够完全满足顾客的要求，销售子系统开出发货单给顾客提货，并记入应收款明细帐以备会计收款，同时记入，销售历史存档，还要修改该配件库存量。
⑻如果这项配件的当前库存量不能全部满足顾客的订货要求，只能暂时提供一部分，那么对这部分配件办理销售业务(同第7条)；同时还要把暂时不能满足的部分记录到暂存订货单文件中，通知采购子系统向供应商订货。
⑼如果这项配件现在一件也没有，就要把这张订货单记录到暂存订货单文件中，并通知采购子系统向供应商订货。
⑽采购子系统根据要求，按订货配件汇总，再按供应商汇总，分别填写向供应商的订货单，一式两联。
第一联寄给供应商，第二联保存，以便到货后核对。
⑾当收到来自供应商的发货单(即配件已经到货)以后，采购子系统要根据订货单核对验收。
