第四章 用例建模

第四章用例建模
什么是需求？需求包括哪几个方面？
需求：客户可接受的、系统必须满足的条件或具备的能力
需求包括：功能性、使用性、可靠性、性能、可支持性五大方面。

2、什么是需求分析?需求分析有何重要意思？需求分析可以分为哪几个步骤？
答："需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输
“做什么”。

意义：需求分析是一个重要的一个阶段。

软件需求分析的质量对软件开发的影响是深远的、全局性的，质量需求对软件开发往往起到事半功倍的效果，所谓“磨刀不误砍柴功。

在后续阶段改正需求分析阶段产生的错误将付出高昂的代价
需求分析大致可分为以下步骤：
绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。

同时它也明确了通过接口的信息流和物质流。

2）创建开发原型：创建用户接口原型。

当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。

用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。

注意要找出需求文档与原型之间所有的冲突之处。

3）分析可行性：分析需求可行性。

在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

4）确定需求优先级：确定软件工程需求的优先级别。

应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。

以优先级为基础确定产品版本将包括哪些特性或哪类需求。

当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

5）为需求建立模型：为需求建立模型。

需求的图形分析模型是软件需求规格说明极好的补充说明。

它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。

这样的模型
包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

6）编写数据字典：创建数据字典。

数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。

在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。

分析和设计工具通常包括数据字典组件。

7）应用质量功能调配：使用质量功能调配。

质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。

该技术提供了一种分析方法以明确那些是客户最为关注的特性。

它将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。

3、业务模型如何映射到系统模型？
业务用例→ ✗← ✗←✆ → ✗← ↙ →
✗← ↙ ④ ☐✆ → ✗←☎⓿ ∙ ♈ →
∙ ∙ ⇳④♦✗→ ∙ ⇳④♦✗ 4、从业务模型中如何去发现用例？
用例要考虑如下要点来寻找
参与者的工作是什么
参与者的角色(作用)是什么
参与者是否生成、参照、删除系统信息
参与者是否需要把外部变更通知给系统
系统是否需要把内部事情通知给参与者
是否存在进行系统维护的用例
用例数量的参考基准
1个系统中存在十几个用例(或更少)
1个用例中有多个用例实例(场景)
5、什么是用例，什么是场景？用例和场景之间的关系是怎样的？
答：用例是外部可见的系统功能单元，这些功能由系统单元提供，并通过一系列系统单元与一个或是多个参与者之间交换的消息所表达。

场景是是帮助系统分析员发现和定义业务实体。

通过对场景的分析，给了我们重要的线索去发现业务实体。

而我们发现了业务实体之后，又通过用例场景来验证这些实体是否支持了用例的实现。

6、用例图中有哪些组成元素？在UML中是如何表示的？
用例图包含6个元素，分别是：参与者、用例、关联关系、包含关系、扩展关系、以及泛化关系
参与者用例关联关系
包含关系扩展关系
泛化关系
7、总结用例图的重要作用，讨论并指出哪些场合下可以使用用例图？
答：用例图显示多个外部参与者的角色以及他们与系统提供的用例之间的联接。

通过用例建模可以对外部的角色以及他们所需要的系统功能建模，用例图用于系统分析阶段。

8、在使用用例图的时候应该如何确定用例，应注意哪些问题？
答：如何确定用例： a 参与者需要从系统中获取哪种功能？及参与者要系统做什么？b 参与者是否需要读取、产生、删除、修改或存储系统中的某种信息？c 系统的状态改变是是否通知参与者？
d 是否存在影响系统的外部事件？
e 系统需要什么样的输入、输出信息？需要注意的是：一定不要再用例图中使用两种命名方法。

即在椭圆之外和椭圆之内。

9、为了满足物业中介行业的信息化要求，甲公司基于详尽的需求调研与分析，准备研发一套符合市场需要的、实用的信息管理系统。

主要将实现客户资料信息管理、客户委托（出租、出售、租赁、购买）信息管理、业务线索生成与管理、房源状态自动更新、权限管理、到期用户管理、房源组合查询等功能。

该公司小王，通过多次的与潜在客户的交流与沟通，完成了最初的用例模型的开发，下是一个用例模型的局部：
小李认为该模型不符合“用例建模”的思想，存在明显的错误。

请用200字以内说明错误所在，并说明应该如何修改。

答：用例模型的准则有：首先确定系统的边界。

确保关注参与者。

每个用例必须给用户提供何时价值。

关联用例和参与者。

记住用例是非形式化的。

用例可以结构化。

首先这个用例违背了“每个用例必须给用户提供价值”。

用例应该表示成给用户提供价值的完整事务，不应该被定义得过于狭窄。

上面的用例不是一个系统交互的完整过程，还有就是太过于细节化。

其次这个用例还违背了“确何关注参与者”每个参与者都应该有单一的，一致的目地。

如果某个真实世界的对象体现了多种目地就要分别用单一的参与者来分解他们。

上面的房产经纪人做的事情目地性不够明确。

改进后的用例图：
10、如何理解“参与者与涉众”？
涉众是与当前用例存在利益关系的人或组织
参与者是启动或参与用例执行过程的人或外部事物
12、用例与用例之间的包含关系、扩展关系和泛化关系各代表什么含义？它们之间有何区别？对以上三种关系各举一例，画出用例图，并进行说明。

包含关系：。

包含关系本质上是比较特殊的依赖关系。

它比一般的依赖关系多了一些语义。

在包含关系中箭头的方向是从基本用例到包含用例。

简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。

泛化关系：代表一般于特殊的关系。

它的意思和面向对象程序设计中的继承的概念是类似的。

不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。

在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含
义。

扩展关系：扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。

与包含关系一样，扩展关系也是依赖关系的版型。

区别：各个关系中箭头的方向不同
13、何时使用用例建模？
用例模型（Use-Case Model）是系统既定功能及系统环境的模型，它可以作为客户和开发人员
之间的契约。

用例是贯穿整个系统开发的一条主线。

同一个用例模型即为需求工作流程的结果，可当作分
析设计工作流程以及测试工作流程的输入使用。

14、阅读下面的用例图，说明该图所表达的信息。

答：答：参与者是客户和总台服务人员。

主要关系是包含和扩展。

首先有客户来预定座位，如果，前面有别的客户，他就等待，进入处理等待队列.服务人员进行座位。

总台服务人员安排座位，然后进行办理结账功能。

有两种方式可供客户选择，要不现金结帐要不就是银行卡结帐，如果选择处理银行结账，则转入银联POS系统。

以上便是该用例图所表示的整个意思。