EA与建模试题.ppt

常用的建模工具 北京北大方正电子有限公司 核心思想：服务于软件开发过程，站在软件过程的立场，掌握UML视图的选用 SA：例如传统需求规格说明书的功能划分 1、缺点：不同人做的原型不一样，是具体的一种解决方式； 是先假设有了一个具体的系统，然后再让用户来假想系统能帮他做什么。 2、软件能做什么不是用户关系的，很可能开发了一些没人用的功能； 不要期望用户像研究DOS命令那样来研究我们的系统。 3、连需求是什么都不明确，问题自然多； 4、没有使用用户语言，描述的不是用户实际业务情况，用户自然不懂； 你不去学习语言，自然体会不到好处，不能把自己贬低为小公司。 5、容易变成是需求人员或开发人员想使用这个系统，而且两人理解的不是一个东西。 用例建模不是画圈圈，而是要我们站在用户立场，想用户所想，体现以人为本。 1、返回，2、新建、3、删除、4、片段 1、状态语言（正、已、未、待） 2、有一个开始和一个结束，转换流程要通畅 1、返回，2、新建、3、删除、4、片段 EA与建模 内容提要 引言 需求分析视图 业务用例图、业务场景活动图 系统用例图、需求图、用例实现序列图 系统设计视图 架构图、组件图、类图 状态图、活动图、序列图 EA实用功能 一、引言 UML建模的核心思想 UML=词汇+语法，建模=写作文，按需选用 结构化分析/面向对象分析 SA：理出全部流程，然后逐步分解 OOA：找出各种对象，按规则组装 范围和目的 是什么/如何画/什么时候用/在哪里用/为什么 以案例分析作主线，介绍各种UML图的运用 UML建模工具 Rational Rose Enterprise Architect Microsoft Office Visio Sybase PowerDesigner Borland Together SmartDraw Visual Studio 2008 Enterprise Architect 特点 简单易用 体积小、占内存少、速度快、稳定 发展迅猛、更新迅速，数千家用户 VC++、BCG 10.3、GDI+、美观易用 功能强大 支持 UML2.1，交互功能强 多样发布、VSS、DB、基线、反向工程、项目管理… 会使用建模工具，更要领会UML建模背后的思想 UML常用视图分类 模型视图 需求分析 系统设计 详细设计 1 用例图 ★ 2 需求图 ☆ 3 活动图 ★ ★ ★ 4 序列图 ★ ★ ★ 5 状态图 ★ ★ 6 类图 ★ ★ 7 组件图 ★ ☆ 8 协作图 ☆ 9 部署图 ☆ 二、需求分析视图 用例建模的疑惑 快速原型，让用户先认同原型，再不断开发 软件就是设计很多功能，最终能满足需求 前期无法确定需求，先尽快完成再调整 用户不懂用例，我们也不懂，也没时间建模 直接告诉程序员要做什么，更准确快捷 用例建模的实质 以人为本，从参与者角度规定要做的事/规则 二、需求分析视图 业务流程分析图 业务用例图 业务场景活动图 系统用例图 需求图 用例实现序列图 （演示） 1. 业务用例图 1. 业务用例图 使用场合 来源于访谈，表达业务目标，按需定做 多角色、业务流程复杂、长期发展 要领 找出业务参与者、关心的问题 站在客户角度看，忘掉系统，不要急于实现 禁忌 从里往外看、硬套解决方案 1. 业务用例图 建模步骤 根据业务目标界定边界，和计算机实现无关 业务主角 边界之外、对系统有明确期望和回报、主动要求 不是系统强加的角色，是实际的岗位或人员 业务用例 由参与者主动发起、可观测、完整的业务目标 粒度：边界要清楚，用例数在10~50个之间 用例≠功能，不是能做什么，而是要做什么 2. 业务场景活动图 2. 业务场景活动图 使用场合 描述复杂、核心的业务流程的各种场景 要领 按角色划分泳道，明确职责和联系 活动为业务用例或关键概念用例 禁忌 强加系统流程、涉及用户不可见的内容 非用户语言 3. 系统用例图 3. 系统用例图 使用场合 描述应实现哪些任务，系统范围 要领 从业务用例场景中获取，排除、合并、补充 粒度为操作者与计算机的一次完整交互为宜 参与者：系统之外、直接与系统交互、人或物、有责任和目标 用例：执行者可见、有意义的目标、业务语言、动宾、用户视角、交互完整 3. 系统用例图 禁忌 急于加入细节、具体的技术实现方法 功能分解 不适合的场合 不是功能密集型，而是技术密集型，单用户 4. 需求图 5. 用例实现序列图 5. 用例实现序列图 人/事/物/规则 参与者/边界/实体/控制 将参与者与边界类隔离，边界与控制类分离 边界类不直接访问实体类 根据可变性和领域，拆分控制类 6. 业务流程分析图 6. 业务流程分析图 使用场合 描述高层业务流程、系统集成方案 通常使用 Visio 绘制，更商业化 要领 抓住输入、输出、