[计算机软件及应用]UML与用例建模20120423.pptVIP

一.UML与用例建模 建模的实质 一个开发团队首先要关注的不是漂亮的文档、华丽的代码，而是如何满足用户的需要。 为了保证软件满足要求，开发人员必须深入用户，了解系统真实的需求； 为了开发高质量的软件，开发人员必须建立一个富有弹性而又相当稳定的开发组织； 为了能快速开发，开发组织必须具有精干的开发人员，正确的工具和恰当的开发方法。 建模是所有工作的中心。 建模的实质：对现实的简化。 模型提供系统的蓝图：包括了跟项目相关的重要因素，忽略不相干的细节 每一个系统都可以从不同的方面使用不同的模型进行描述 建模的目标 便于开发人员展现系统 允许开发人员指定系统的结构或行为 提供指导开发人员构造系统的模板 记录开发人员的决策 集中到一点：将复杂的问题简单化。 建模的原则 选择建立什么样的模型对如何发现和解决问题具有重要的影响。 正确的模型有助于提高开发者的洞察力，指导开发者找到问题；不正确的模型会误导开发者。 每个模型可以有多种表达方式： 最好的模型总是能够切合实际。 所有的模型都是简化的现实，而又不失系统的核心问题的细节。 孤立的模型是不完整的 任何一个系统都是由一些既相互独立又相互关联的模型所组成的。 面向对象的核心要素 对象： 封装： 消息： 类： 继承： 多态性： 结构与连接： 面向对象的建模、分析、设计、编码 面向对象的建模与UML UML的视图 在UML中，模型是通过视图来描述系统的不同侧面，通过图来描述待建立系统的模块。 UML由4种视图组成： 用例视图 逻辑视图 组件视图 配置视图 （1）用例视图 强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型视图。 包括： 用例图 时序图 协作图 活动图 （2）逻辑视图 展现系统的静态或结构组成及特征。 包括： 类图 状态图 （3）组件视图 描述实现的视图称为组件视图。它对模型中的组件建模，描述应用程序搭建的软件单元以及组件之间的依赖从而可以估计更改的影响。它还对类及其他元素在组件中的分配建模。 （4）配置视图（布局视图） 显示了系统的软件和硬件的物理配置，体现了系 统实现环境的结构和行为特征。 用例图 1.概述 2. 参与者 3. 用例 4. 用例间的关系 5. 用例图 6. 用例的描述 7. 用例建模实例 1 概述 2 参与者（Actor） 定义：是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。 表示法： 如何获取系统参与者？ 谁或什么使用该系统； 交互中它们扮演什么角色； 谁安装系统； 谁启动和关闭系统； 谁维护系统； 与该系统交互的是什么系统； 谁从系统获取信息； 谁提供信息给系统 有什么事发生在固定事件。 建模参与者的要点： 参与者对于系统而言总是外部的，因此他们在你的控制之下； 参与者直接同系统交互，这可以帮助定义系统边界； 参与者表示人和事物与系统发生交互时所扮演的角色； 一个人或事物在与系统发生交互时，可同时或不同时扮演多个角色； 每个参与者需要有一个具有业务一样的名字； 每个参与者必须有简短的描述，从业务角度描述参与者是什么； 像 类一样，参与者可具有分栏，表示参与者属性和它可接受的事件。 3用例 定义:用例是一个叙述型的文档，用来描述参与者使用系统完成某个事件时的事情发生顺序。用例是系统的使用过程，更确切的说，用例不是需求或者功能的规格说明，但用例也展示和体现出了其所描述的过程中的需求情况。 系统需求一般分功能需求和非功能需求两部分，用例只涉及功能性方面的需求 用例是Ivar Jacobson发明的概念，用例驱动的软件开发方法已得到广泛的认同。 用例的表示: 用例命名一般采用动宾结构或主谓结构 注意：一般用例名写在椭圆的内部或下方。 4 用例间的关系 包含关系(include) 1）包含关系使一个用例的功能可以在另一个用例中使用。 2）在两种情况下引入包含用例： 如果两个以上的用例有相同的功能，则可以将这个功能分解到另一个用例中。 一个用例的功能太多时,可以用包含关系建模两个小用例。 3）包含关系是依赖关系的版型，即包含关系是比较特殊的依赖关系。 请画出用例图? 参与者: 银行职员 用例: (1)登录 (2)创建新帐号 (3)修改帐号信息 (4)删除帐号信息 扩展关系(Extend) （1）扩展关系是把新行为插入到已有用例的方法。基础用例提供了一组扩展点，在这些扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基础用例的扩展点。 （2）基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。 （3）一个用例可能有多个扩展点，每个扩展点也可出现多次。 （4）基础用例的执行不会涉及扩展