下载文档原格式
软件工程之用例模型总结一、用例模型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)泛化关系，在参与者和用例中都能泛化。
用例建模法
用例建模是一种分析和设计软件系统的方法，它将系统看作一系列用例，每个用例描述了系统与用户之间的一个交互场景。
用例建模的步骤如下：
1. 确定系统的边界和参与者：确定系统与外部世界的交互范围，并确定参与系统的各种角色。
2. 鉴别用例：识别系统中的主要功能点和用户需求，每个功能点对应一个用例。
3. 描述用例：详细描述每个用例的功能特点，包括前置条件、主要场景、预置条件、异常场景等。
4. 绘制用例图：用例图是用例建模的核心图。
它通过图形的方式展示出各个用例之间的关系，包括参与者、用例和它们之间的关联关系。
5. 完善用例：根据需求分析的结果，不断完善用例的描述，使其更加准确和完整。
通过用例建模，可以清楚地了解系统的功能需求，识别系统中的主要功能点，帮助系统分析师和设计师更好地理解系统的需求，从而设计出更好的系统。
同时，用例建模也可以帮助开发人员和测试人员更好地理解系统的功能点，从而更好地开发和测试系统。
简述用例模型的组成元素以及建模步骤用例模型是软件开发中重要的一环，它是对软件系统功能需求的描述，是从用户的角度出发，描述系统应该具有的功能和行为。
用例模型的建立对于系统开发和维护非常重要，因此，本文将对用例模型的组成元素和建模步骤进行简述。
二、用例模型的组成元素用例模型是由用例、参与者、系统边界和关系图等组成的。
1.用例用例是描述系统功能需求的一种方式，它描述了系统中某个功能或一组功能的行为和交互。
用例是从用户的角度出发，描述了用户与系统之间的交互过程。
用例可以分为主用例和子用例，主用例是整个系统中最重要的用例，而子用例是主用例的拓展和细化。
2.参与者参与者是使用系统的人或其他系统。
参与者可以是人类用户、硬件设备、其他软件系统等。
参与者与系统之间的交互是通过用例进行的。
参与者可以分为主要参与者和次要参与者，主要参与者是对系统设计和实现有重要影响的参与者，次要参与者是对系统设计和实现没有重要影响的参与者。
3.系统边界系统边界是用例模型中的一个重要概念，它定义了系统的范围。
系统边界将系统与外部环境分开，系统内部的所有用例和参与者都在系统边界内部。
4.关系图关系图是用例模型的另一个重要组成部分，它描述了用例之间的关系。
关系图可以分为三种类型：包含关系、泛化关系和依赖关系。
包含关系表示一个用例包含另一个用例，泛化关系表示一个用例是另一个用例的特殊情况，依赖关系表示一个用例依赖于另一个用例。
三、用例模型的建模步骤用例模型的建模步骤可以分为以下几个步骤：1.确定系统的范围和边界在建立用例模型之前，需要先确定系统的范围和边界。
系统的范围和边界定义了系统的功能和行为，同时也决定了用例模型的规模和复杂度。
2.识别参与者和用例在确定系统的范围和边界之后，需要识别参与者和用例。
参与者是使用系统的人或其他系统，用例是描述系统功能需求的一种方式。
3.编写用例规约用例规约是用例模型的核心，它描述了用例的输入、输出和行为。
用例规约包括用例的前置条件、后置条件、基本流程和异常流程。
第05课建立用例模型教学目的：掌握查找活动者、用例方法•可行性分析是要决定“做还是不做”。
•需求分析是要决定“做什么，不做什么”。
•可行性分析结果：《项目可行性报告》•需求分析结果：《系统需求说明书》需求分析步骤•获取用户需求•分析用户需求•编写需求文档•评审需求文档•管理需求变更获取用户需求•1)从与用户交流开始需求分析•2)做大规模的市场调查•3)聘请行业专家•4)借助于网络•5)试用同类产品获得经验•6)果断地结束需求分析（时机）软件需求分析的目标是准确理解用户的要求，进行细致的调查分析，将用户的非形式的要求转化为完整的需求定义，再将需求定义转换为相应的形式的规格说明。
用例模型描述系统做什么，相当于传统开发过程中的需求分析。
用例模型是开发过程的起点。
它象引擎一样驱动系统持续开发过程。
系统中其它新建模型都依赖、服从用例模型。
用例模型包括系统的用例图和用例描述。
建立用例模型的全部工作：为用例路径画出用例图对用例进行描述系统描述确立项目票据报销项目报销数据检索与汇总打印项目报销数据检索与汇总结果票据报销流程：找出活动者活动者是系统分析员与用户交流的起点，也往往是找出新用例的基础。
通常情况下活动者是指使用系统功能的人。
但也可以是其它外部的系统，包括软件系统或硬件设备。
总之，凡是与系统进行信息交换的外部事物都可以是系统的活动者。
找出活动者的前提条件是与系统用户进行广泛深入的交流，进而明确以下内容：系统的范围系统的作用与系统交互的外部事物了解活动者的询问方式：读或写方面：谁要使用本系统只读方面：谁对系统运行产生的结果感兴趣谁要从系统中得到信息只写方面： 谁会改变系统中的数据本系统中与系统交互的外部实体只有用户（人）按不同功能或身分又分为报销人、审核人和公司领导找出用例成功开发一个项目，在很大程度上取决于能够采取一种对于项目组人员和用户都非常直观的方式，来定义系统的需求。
用例就是目前定义系统需求的最佳方式。
实验一：基于UML的用例模型试验实验目的：1、掌握使用visio绘制用例模型2、掌握Ration Rose绘制用例模型的方法实验内容：1、使用vise绘制用例模型2、使用Ration Rose绘制用例模型的方法实验步骤：1、使用Visio绘制用例模型（1）启动Visio中的UML模型绘制开始时需要新建一个文件存放用例模型，首先选择“开始” 一“程序” -Microsoft office visio 2003选项进入Visio启动页面，在“类别”选项区域中才、选择“软件”项：然后在“模板”选项区域中选择UML模型图，即可打开制作UML模型的全部对彖图集，Vise提供了关于制作UML模型所需要的全部图表，支持开发人员进行面向对彖的分析和设计工作。
（2）保存UML模型通过选择菜单File…Save选项或者单机工具栏的Save按钮，来保存系统模型，保存的文件类型是-VSdo(3)新建立用例图(4)建立用例中的角色(5)建立用例(6)建立角色与用例、用例与角色之间的联系(7)建立活动图2、使用Rational Rose绘制用例模型（1）Rational Rose 的启动：选择"开始"---"程序” ---Rational Software---Rational Rose Enterprise Edetion选项，弹出对话框。
这个对话框用来设置本次启动的初始动作，分为New （新建模型）Existing （打开现有模型）和Recent （最近打开模型）三个标签。
（2）新建用例图在Browser窗I I内的树形列表中选中UseCase包并右击，在弹出的快捷菜单中选择New一UseCase Diagram选项。
此时出现New Diagram用例图名称并允许修改，将NewDiagrain更名为“医疗器材管理系统用例图”双击Biowgram窗I I内树形列表中的“医疗器材管理系统用例图”，在Diagram窗I I中出现“Use CaseDiagiain： Use CaseView/医疗器材管理系统用例图”，可以在该窗1 1中绘制用例图。
实验一熟悉ROSE并建立用例模型一、实验目的1）掌握Rational Rose的特点、运行环境及获取方法；2）掌握Rational Rose基本使用方法；3）掌握使用Rational Rose绘制用例图的步骤；二、实验内容根据《简单的学生选课管理系统》采用面向对象分析方法给出系统的用例模型（用例图及课程注册用例描述）。
三、建模思路1、系统角色分析学生选课管理系统主要满足三方面的需求，分别是学生用户、教师用户和管理员用户，也即三类用户角色（1）学生用户是主要需求者，主要功能需求是查询新学期将开设的课程和讲课教师情况，选择自己要学习的课程进行“课程注册”，并可以查询成绩单；（2）教师用户主要功能需求是查询新学期将开设的课程和选课学生情况，并可以登记成绩单；（3）管理员的功能需求较复杂，进行教师信息、学生信息和课程信息的维护，开启和关闭“课程注册”。
2、rose建模步骤2.1.环境简介2.1.1 Rational Rose可视化环境组成Rose界面的五大部分是浏览器、文档工具、工具栏、框图窗口和日志。
1、浏览器：用于在模型中迅速漫游。
2、文档工具：用于查看或更新模型元素的文档。
3、工具栏：用于迅速访问常用命令。
4、框图窗口：用于显示和编辑一个或几个UML框图。
5、日志：用于查看错误信息和报告各个命令的结果。
2.1.2浏览器和视图浏览器是层次结构，用于在Rose模型中迅速漫游。
在浏览器中显示了模型中增加的一切，如参与者、用例、类、组件等等。
浏览器中包含四个视图：Use Case视图、Logical视图、Component视图和Deployment 视图。
点击每个视图的右键，选择new就可以看到这个视图所包含的一些模型元素。
2.1.3框图窗口我们可以浏览模型中的一个或几个UML框图。
改变框图中的元素时，Rose自动更新浏览器。
同样用浏览器改变元素时，Rose自动更新相应框图。
这样，Rose就可以保证模型的一致性。
软件工程中的软件需求建模方法与实践技巧软件需求建模是软件工程中最重要的阶段之一，它的目的是准确理解和描述用户对软件系统的需求。
在软件需求建模过程中，我们使用一系列的方法和技巧来收集、分析和描述需求。
本文将介绍一些常用的软件需求建模方法和实践技巧，以帮助软件工程师更好地完成需求分析工作。
一、用例建模方法用例建模是一种以用户的角色和行为为基础的需求建模方法。
它通过描述用户与系统的交互场景来帮助分析和理解系统的需求。
用例建模通常包括以下步骤：1. 识别参与者：确定所有与系统交互的参与者，如用户、管理员等。
2. 确定用例：识别并描述参与者与系统之间的交互场景，即用例。
3. 编写用例描述：使用简洁明确的语言来描述用例场景，包括前提条件、主要步骤和预期结果。
4. 画出用例图：以图形化的方式表示用例和参与者之间的关系。
用例建模方法有助于软件工程师深入了解用户需求，并将其转化为系统功能的规格说明。
同时，通过分析用例，可以发现和解决系统设计中的不足之处。
二、状态图建模方法状态图建模方法用于描述系统的不同状态以及状态之间的转换。
它适用于描述系统中复杂的状态变化。
状态图建模通常包括以下步骤：1. 确定关键对象：识别出与系统状态相关的关键对象。
2. 确定状态：确定对象可能具有的状态。
3. 描述状态之间的转换：使用转换条件和动作来描述状态之间的转换。
4. 画出状态图：以图形化的方式表示关键对象的状态以及状态之间的转换。
状态图建模方法能够帮助软件工程师理清系统的状态变化过程，从而更好地满足用户的需求。
三、数据流图建模方法数据流图建模方法用于描述系统中数据的流动。
通过数据流图，软件工程师可以清楚地了解系统的信息交互流程，并分析数据流向以及数据处理过程。
数据流图建模通常包括以下步骤：1. 确定主要过程：识别出系统的主要过程或功能模块。
2. 定义数据流：确定数据流的来源和去向，以及数据的属性。
3. 描述过程逻辑：定义过程的输入和输出，描述过程的处理逻辑。
