第二部分 软件需求分析与建模(5-7)-jiang2.ppt

Sample Requirements Definition Outline Sample Requirements Definition Outline Sample Requirements Definition Outline 关联按逻辑关系分类： 聚集关系 1. 共享聚集 2．组合聚集 继承关系 依赖和细化关系 UML模型视图 UML主要是用来描述模型的。它可以从不同视角为系统建模，形成不同的视图（View）。每个视图是系统完整描述中的一个抽象，代表该系统一个特定的方面；每个视图又由一组图（Diagram）构成，图包含了强调系统某一方面的信息。 两类图： 静态图：包括用例图、类图、对象图、构件图和部署图 动态图：包括状态图、时序图、协作图和活动图 五种视图： 用例视图从用户角度表达系统功能； 结构视图主要使用类图和对象图描述系统静态结构； 行为视图展示系统动态行为及其并发性； 实现视图展示系统实现的结构和行为特征； 部署视图展示系统的实现环境和构件是如何在物理结构中部署的 用例建模 需求捕获的目标： 发现真正的需求 以适用于用户、客户和开发人员的方式加以表示 系统用户表示为一个参与者 参与者在与用例进行交互时使用系统 用例向参与者提供某些有价值结果而执行一些动作序列 编写用例 用例着眼于为用户增加价值，提供了一种捕获功能需求的系统且直观的方法，可驱动整个开发过程。 用例从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。 要开始开发用例，应列出特定参与者执行的功能或者活动。 用例模型帮助客户、用户和开发人员在如何使用系统方面达成共识。 用例图描述部分用例模型，显示带有联系的用例和参与者的集合 POS机系统部分用例图 用例图 用例图包括：参与者、用例、关联和边界四个要素。 参与者：用小人形表示 用例：用椭圆表示 关联：用直线表示说明参与者驱动某个用例 边界：用矩形框表示，说明系统关注点。 开发用例 用例使用非正式的描述性风格编写，也可以使用某个结构化的格式编写，有些格式更强调描述的直观性。 用例不同部分 说明 用例名称 以动词开始描述用例名称 范围 要设计的系统 级别 “用户目标”或者是“子功能” 主要参与者 调用系统，使之交付服务 渋众及其关注点 关注该用例的人，及其需要 前置条件 开始前必须为真的条件 成功保证 成功完成必须满足的条件 主成功场景 典型的、无条件的、理想方式的成功场景 扩展 成功或失败的替代场景 特殊需求 相关的非功能性需求 技术和数据变元素 不同的I/O方法和数据格式 发生频率 影响对实现的调查、测试和时间安排 杂项 未决问题等 POS机系统中处理销售的场景 用例名称：处理销售 范围：POS机应用 级别：用户目标 主要参与者：收银员 涉众及其关注点： 收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。 售货员：希望自动更新销售提成 顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。 公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即便在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。 经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。 前置条件：收银员必须经过确认和认证。 成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付授权的批准。 主成功场景 1.顾客携带所购商品或服务到收银台通过POS机付款。 2.收银员开始一次新的销售交易。 3.收银员输入商品条码。 4.系统逐步记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复3~~4步，直到输入结束。 5.系统显示总额和计算折扣。 6.收银员告知顾客总额，并请顾客付款。 7.顾客付款，系统处理支付。 8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。 9.系统打印票据。 10.顾客携带商品和票据离开。 开发活动图 UML活动图通过提供特定的场景内交流的图形化表示来补充用例。 活动图符号： 两端为半圆形的矩形表示一个特定的系统功能 箭头表示通过系统的流 判定菱形表示判定分支 水平线、分叉点和连接表示并发活动 对象节点表示活动对象 活动图通常能够既表示控制流又表示数据流。 UML活动图代替传统的数据流图（Data Flow Diagram）表示法 处理销售用例中的UML活动图 泳道图 UML泳道图（swimlane）是活动图的一种有用的变形 可以让建模人员表示用例所描述