UML学习资料ppt课件

1、课程目标掌握UML建模语言掌握使用UML进行面向对象的分析与设计掌握使用PowerDesigner工具绘制业务系统的各种UML图软件开发过程软件开发过程q RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论q 瀑布模式q 试图在编程之前详细定义所有或大部分需求q 通常于编程之前创建出完整的设计q 试图在开始前定义“可靠的”计划或时间表q 需求分析-架构设计-详细设计-编码-单元测试-集成测试-系统测试 其他开发模式q 增量及迭代开发q 极限编程(extreme programming,xp)。q 测试驱动开发(te

2、st-driven development)q 重构(refactoring)q 持续集成(continuous integration)q每天都要有一个可运行的版本，用于用户确认q问题及早提出，返工越少面向对象分析与设计q UML(统一建模语言)不是OOAD，也不是方法，它仅仅只是一种图形表示法q 如果不掌握对象思想，那么UML或PD将毫无意义q 设计原则：单一职责，开放封闭，接口隔离，里氏替换，依赖倒置 q 我们需要一种用于OOAD的语言，这既是一种思考的工具，也是一种沟通的形式，因此，我们将在OOAD中应用UMLq OOA(object-oriented analysis)：在问题域内发

3、现和描述对象 OOD(object-oriented design)：如何定义软件对象以及他们之间如何协作以实现需求面向对象分析与设计q 最大的优点在于创建更具模块化的方法 - 帮助传递信息并降低复杂性q 提供单个统一的方法q 优点：在生命周期的每个阶段使用相同的对象模块什么是什么是UMLq标准定义：统一建模语言(unified modeling language) 是描述，构造和文档化系统制品的可视化语言qUML是一个庞大的图形化表示法体系q应用UML的三种方式q草图q蓝图q编程语言UML相关概念正向工程：从UML图形生成代码逆向工程：从代码生成UML图形MDA 模型驱动架构(建模人员) P

4、latform independentModels(pims)和platform specific models(psms) MOF(UML元模型元-元模型)UML实现效果“一图胜过千言万语”创建模型的原理选择创建什么样的模型对如何解决问题和如何形成解决方案具有深刻影响单个模型是无法满足要求的。每个完美的系统都是通过为数不多的一系列近乎独立的模型以最合理的方式实现的每一种模型可以在不同的精度级别上表示最佳模型与现实情况是紧密相连的UML画图软件开发生命周期 (SDLC) 的各阶段都需要使用UML图。UML 使用不同的图展示系统的各个方面。常见的图包括： 用例图 类图 时序图 协作图 活动图 状

5、态图范例骰子游戏q 软件模拟游戏者投掷两个骰子，如果总点数是7为赢，否则为输q 过程：定义用例-定义领域模型-定义交互图-定义设计类图q 定义用例：q 骰子游戏：q1.游戏者请求骰子q2.系统展示结果：如果骰子的总点数是7，游戏者赢，否则游戏者输范例骰子游戏q 定义领域模型(ooa) 识别问题中的概念，它是对现实世界中概念和想像的可视化，与具体软件技术无关。q 游戏者q 骰子q 骰子游戏骰子游戏-OOA投掷玩骰子游戏包含121112游戏者骰子游戏骰子骰子游戏-OODSequenceDiagram_1返回输赢计算总点数返回获取点数返回投掷返回获取点数返回投掷开始玩游戏者骰子游戏骰子1骰子2返回输

6、赢计算总点数返回获取点数返回投掷返回获取点数返回投掷开始玩用例用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。用例是文本形式的情节描述，用于需求的发现和记录，用例会影响后续的OOAD工作银行客户查询账户信息提款转账用例最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。实际上，把

7、用例解释为某个参与者(actor)要做的一件事可能更为合适。这样的一件事有以下几个特征 ： 这件事是相对独立的 这件事的执行结果对参与者来说是可观测的和有意义的 这件事必须由一个参与者发起。不存在没有参与者的用例 这件事必然是以动宾短语形式出现的 用例用例的编写 用例编号 用例名 用例描述 参与者 前置条件：前置条件是执行用例之前必须存在的系统状态， 后置条件：后置条件是用例一执行完毕后系统可能处于的一组状态。 基本事件流通过基本事件流与备选事件流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性用

8、例用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的提款 用例可以用事件流表述如下： 提款-基本事件流 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡但是这只描述了提款用例中最顺利的一种情况，作为一个实用的系统，我们还必须考虑可能发生的各种其他情况，如信用卡无效、输入密码错、用户帐号中的现金余额不够等，所有这些可

9、能发生的各种情况（包括正常的和异常的）被称之为用例的场景(Scenario)，场景也被称作是用例的实例(Instance)。在用例的各种场景中，最常见的场景是用基本流(Basic Flow)来描述的，其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的提款用例，我们可以得到如下一些备选流： 提款-备选事件流 备选流一：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。 备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。 备选流三：在基本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三

10、次输入密码错误后，信用卡被系统没收，用例结束。用例真实项目中如何发现用例 系统开发完成之后，有哪些人会使用这个系统？ (调研需求时最先弄清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？（参与者目标）这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？（用例粒度）) 系统需要从哪些人或其他系统中获得数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统相关联？ 系统是由谁来维护和管理的？用例用例核心是以参与者为中心（区别于以计算机系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的

11、方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作了。 例如 某企业要求开发一个企业管理系统，并与原来的财务系统相连接，谁是actor？ 以下关于登录的用例编写，请考虑其是否合理，如果不合理，应该如何修改？ 1.系统显示输入用户名和密码界面 2.会员输入用户名和密码，并提交 3.如果正确，系统根据用户名从数据库中”会员“表查询该会员信息，系统显示会员定制界面 如果用户名不存在。用例的检查用例模型完成之后，可以对用例模型进行检查，看看是

12、否有遗漏或错误之处。主要可以从以下几个方面来进行检查：功能需求的完备性现有的用例模型是否完整地描述了系统功能，这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么我们就需要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。 模型是否易于理解用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。 是否存在不一致性系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特别注意不同工件之前是否

13、存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。 避免二义性语义好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。类图类图的分类 实体类(领域模型)-entity 属性 普通数据类型表示为属性 不要把复杂的领域概念建模为属性 控制类(复杂业务)-manager 边界类(与用户交互)-action类图1.1拥有0.*属于部门+部门编号部门名称: int: java.lang.String人员+员工编号员工姓名: int: java.lang.String状态图概念 状态图

14、(statechart diagram):用来描述一个特定的对象所有可能的状态，以及由于各种事件的发生而引起的状态之间的转移和变化 范例：订单状态的变化状态图点击后台管理登录首页登录页面后台管理页入财务库调整退回过帐审核填写未审核订单已审核单据凭证状态图出厂报损报损报损初始化注销注销初始化发卡挂失回收白卡初始化正常冻结损坏回收注销时序图概念 时序图用于按时间顺序模拟控制流程。它显示了在对象生命线上各点之间的对象传递的消息，演示了在时间序列中对象之间的交互 范例时序图SequenceDiagram_1Message_16Message_15Message_14Message_13method3m

15、ethod2method1请求开店审核页面Message_8Message_7Message_6Message_5method3method2method1请求开店页面申请开店页面开店ACTION开店Manager开店数据层业务员经理Message_16Message_15Message_14Message_13method3method2method1请求开店审核页面Message_8Message_7Message_6Message_5method3method2method1请求开店页面活动图概念 活动图(activity diagram)：用来描述事物或对象的活动变化流程 范例 开店申

16、请：填写开店申请(客户信息，销售渠道，报价单) -经理审核业务员经理填写客户信息填写报价单填写销售渠道经理审核审核存档活动图构件图概念 构件图(component):是一个相对独立的可装配的物理块，一般作为一个独立的文件存在。src/main/java/src/main/java/demosrc/main/java/com.systopsrc/main/resource部署图概念： 部署图(depoyment diagram):用来描述系统中计算结点的拓扑结构和通信路径与结点上运行的软件构件等。DB1DB2DB3IEComponentInstance_1TOMCAT1TOMCAT2TOMCAT

17、3ComponentInstance_2数据模型概念数据模型 (CDM) 信息系统的概念设计工具，即实体-联系图（E-R图），CDM就是以其自身方式来描述E-R图。此时不考虑物理实现的细节，只表示数据库的整体逻辑结构，独立于任何软件和数据存储结构。如下列职员和部门两实体的E-R图： dept_emp拥有属于部门部门编号部门名称 IntegerCharacters (10)部门编号 人员员工编号员工姓名 IntegerCharacters (10)员工编号 概念数据模型CDM新建数据项 使用“Model”- Data Items 菜单，在打开的窗口中显示已有的数据项的列表，点击 “Add a R

18、ow”按钮，创建一个新数据项数据项的唯一性代码选项和重用选项 使用Tools-Model Options-Model Settings。在Data Item组框中定义数据项的唯一性代码选项(Unique Code)与重用选项（Allow Reuse）。概念数据模型CDM概念数据模型CDM有关联系的基数有关联系的基数 举例，“系”与“学生”两个实体之间的联系是一对多联系，换句话说“学生”和“系”之间的联系是多对一联系。而且一个学生必须属于一个系，并且只能属于一个系，不能属于零个系，所以从“学生”实体至“系”实体的基数为“1,1”，从联系的另一方向考虑，一个系可以拥有多个学生，也可以没有任何学生，即零个学生，所以该方向联系的基数就为“0,n”,如图所示物理数据模型PDM物理数据模型(PDM) PDM考虑了数据库的物理实现，包括软件和数据存储结构。 PDM的对象：表（Table）、表中