EA介绍与UML建模入门课件.pptx

Enterprise Architect 介绍与 UML 建模入门PAM 方向张云贵 2009.10.20内容提要引言需求分析视图业务用例图、业务场景活动图系统用例图、需求图、用例实现序列图系统设计视图架构图、组件图、类图状态图、活动图、序列图EA实用功能一、引言UML建模的核心思想UML=词汇+语法，建模=写作文，按需选用结构化分析/面向对象分析SA：理出全部流程，然后逐步分解OOA：找出各种对象，按规则组装范围和目的是什么/如何画/什么时候用/在哪里用/为什么以案例分析作主线，介绍各种UML图的运用UML建模工具常用的建模工具Enterprise Architect 特点Rational RoseEnterprise ArchitectMicrosoft Office VisioSybase PowerDesignerBorland TogetherSmartDrawVisual Studio 2008简单易用体积小、占内存少、速度快、稳定发展迅猛、更新迅速，数千家用户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 绘制，更商业化要领抓住输入、输出、处理过程、事件及参与者粒度要粗，处理过程为黑盒子三、系统设计视图架构图组件图类图状态图活动图序列图1. 架构图2. 组件图3. 类图4. 状态图5. 活动图6. 序列图四、EA 实用功能大小、对齐、排列颜色、字体、复制注释、文档、网页删除、替换、导包链接、代码反向工程-VS2008五、推荐读物《大象——Think in UML 》经验之谈，讲述UML建模的思想和做法《 UML风格》如果你想让UML图更专业《用例分析技术》:9081/doc/RationalUnifiedProcess.zh_cn/啄木鸟开源社区:9081/doc/RationalUnifiedProcess.zh_cn/RUP谢谢！ 核心思想：服务于软件开发过程，站在软件过程的立场，掌握UML视图的选用SA：例如传统需求规格说明书的功能划分1、缺点：不同人做的原型不一样，是具体的一种解决方式；是先假设有了一个具体的系统，然后再让用户来假想系统能帮他做什么。2、软件能做什么不是用户关系的，很可能开发了一些没人用的功能；不要期望用户像研究DOS命令那样来研究我们的系统。3、连需求是什么都不明确，问题自然多；4、没有使用用户语言，描述的不是用户实际业务情况，用户自然不懂；你不去学习语言，自然体会不到好处，不能把自己贬低为小公司。5、容易变成是需求人员或开发人员想使用这个系统，而且两人理解的不是一个东西。用例建模不是画圈圈，而是要我们站在用户立场，想用户所想，体现以人为本。1、返回，2、新建、3、删除、4、片段1、状态语言（正、已、未、待）2、有一