《UML学习资料ppt课件》由会员分享，可在线阅读，更多相关《UML学习资料ppt课件（39页珍藏版）》请在金锄头文库上搜索。
1、课程目标掌握UML建模语言掌握使用UML进行面向对象的分析与设计掌握使用PowerDesigner工具绘制业务系统的各种UML图软件开发过程软件开发过程qRUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论q瀑布模式q试图在编程之前详细定义所有或大部分需求q通常于编程之前创建出完整的设计q试图在开始前定义“可靠的”计划或时间表q需求分析-架构设计-详细设计-编码-单元测试-集成测试-系统测试 其他开发模式q增量及迭代开发q极限编程(extreme programming,xp)。q测试驱动开发(test-driven
2、 development)q重构(refactoring)q持续集成(continuous integration)q每天都要有一个可运行的版本，用于用户确认q问题及早提出，返工越少面向对象分析与设计qUML(统一建模语言)不是OOAD，也不是方法，它仅仅只是一种图形表示法q如果不掌握对象思想，那么UML或PD将毫无意义q设计原则：单一职责，开放封闭，接口隔离，里氏替换，依赖倒置 q我们需要一种用于OOAD的语言，这既是一种思考的工具，也是一种沟通的形式，因此，我们将在OOAD中应用UMLqOOA(object-oriented analysis)：在问题域内发现和描述对象 OOD(objec
3、t-oriented design)：如何定义软件对象以及他们之间如何协作以实现需求面向对象分析与设计q最大的优点在于创建更具模块化的方法 - 帮助传递信息并降低复杂性q提供单个统一的方法q优点：在生命周期的每个阶段使用相同的对象模块什么是什么是UMLq标准定义：统一建模语言(unified modeling language) 是描述，构造和文档化系统制品的可视化语言qUML是一个庞大的图形化表示法体系q应用UML的三种方式q草图q蓝图q编程语言UML相关概念正向工程：从UML图形生成代码逆向工程：从代码生成UML图形MDA模型驱动架构(建模人员)Platform independentMo
4、dels(pims)和platform specific models(psms)MOF(UML元模型元-元模型)UML实现效果“一图胜过千言万语”创建模型的原理选择创建什么样的模型对如何解决问题和如何形成解决方案具有深刻影响单个模型是无法满足要求的。每个完美的系统都是通过为数不多的一系列近乎独立的模型以最合理的方式实现的每一种模型可以在不同的精度级别上表示最佳模型与现实情况是紧密相连的UML画图软件开发生命周期 (SDLC) 的各阶段都需要使用UML图。UML 使用不同的图展示系统的各个方面。常见的图包括： 用例图类图时序图协作图活动图状态图范例骰子游戏q软件模拟游戏者投掷两个骰子，如果总点
5、数是7为赢，否则为输q过程：定义用例-定义领域模型-定义交互图-定义设计类图q定义用例：q骰子游戏：q1.游戏者请求骰子q2.系统展示结果：如果骰子的总点数是7，游戏者赢，否则游戏者输范例骰子游戏q定义领域模型(ooa) 识别问题中的概念，它是对现实世界中概念和想像的可视化，与具体软件技术无关。q游戏者q骰子q骰子游戏骰子游戏-OOA骰子游戏-OOD用例用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。用例是文
6、本形式的情节描述，用于需求的发现和记录，用例会影响后续的OOAD工作用例最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。实际上，把用例解释为某个参与者(actor)要做的一件事可能更为合适。这样的一件事有以下几个特征 ：这件事是相对独立的 这件事的执行结果对参与者来说是可观测的和有意义的 这件事必须由一个参与者发起。不存在没有参与者的用例 这件事必然是以动宾短语形式出现的 用例用例的编写用例编号用例名用例描述参与者前置条件：前置条件是执行用例之前必须存在的系统
7、状态，后置条件：后置条件是用例一执行完毕后系统可能处于的一组状态。基本事件流通过基本事件流与备选事件流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性用例用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的提款 用例可以用事件流表述如下：提款-基本事件流1. 用户插入信用
8、卡2. 输入密码3. 输入提款金额4. 提取现金5. 退出系统，取回信用卡但是这只描述了提款用例中最顺利的一种情况，作为一个实用的系统，我们还必须考虑可能发生的各种其他情况，如信用卡无效、输入密码错、用户帐号中的现金余额不够等，所有这些可能发生的各种情况（包括正常的和异常的）被称之为用例的场景(Scenario)，场景也被称作是用例的实例(Instance)。在用例的各种场景中，最常见的场景是用基本流(Basic Flow)来描述的，其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的提款用例，我们可以得到如下一些备选流：提款-备选事件流备选流一：用户可以在基本
9、流中的任何一步选择退出，转至基本流步骤5。备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。备选流三：在基本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。用例真实项目中如何发现用例系统开发完成之后，有哪些人会使用这个系统？ (调研需求时最先弄清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？（参与者目标）这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？（用例粒度）)系统需要从哪些人或其他系
10、统中获得数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统相关联？ 系统是由谁来维护和管理的？用例用例核心是以参与者为中心（区别于以计算机系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作了。 例如某企业要求开发一个企业管理系统，并与原来的财务系统相连接，谁是actor？以下关于登录的用例编写，请考虑其是否合理，如果不合理，应该如何修改？1.系统显
11、示输入用户名和密码界面2.会员输入用户名和密码，并提交3.如果正确，系统根据用户名从数据库中”会员“表查询该会员信息，系统显示会员定制界面如果用户名不存在。用例的检查用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：功能需求的完备性现有的用例模型是否完整地描述了系统功能，这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么我们就需要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。 模型是否易于理解用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就
12、是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。 是否存在不一致性系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。 避免二义性语义好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。类图类图的分类实体类(领域模型)-entity属性普通数据类型表示为属性不要把复杂的领域概念建模为属性控制类(复杂业务)-manager边界类(与
13、用户交互)-action类图状态图概念状态图(statechart diagram):用来描述一个特定的对象所有可能的状态，以及由于各种事件的发生而引起的状态之间的转移和变化范例：订单状态的变化状态图状态图时序图概念时序图用于按时间顺序模拟控制流程。它显示了在对象生命线上各点之间的对象传递的消息，演示了在时间序列中对象之间的交互范例时序图活动图概念活动图(activity diagram)：用来描述事物或对象的活动变化流程范例开店申请：填写开店申请(客户信息，销售渠道，报价单) -经理审核活动图构件图概念构件图(component):是一个相对独立的可装配的物理块，一般作为一个独立的文件存在。
14、部署图概念：部署图(depoyment diagram):用来描述系统中计算结点的拓扑结构和通信路径与结点上运行的软件构件等。数据模型概念数据模型 (CDM)信息系统的概念设计工具，即实体-联系图（E-R图），CDM就是以其自身方式来描述E-R图。此时不考虑物理实现的细节，只表示数据库的整体逻辑结构，独立于任何软件和数据存储结构。如下列职员和部门两实体的E-R图： 概念数据模型CDM新建数据项 使用“Model”- Data Items 菜单，在打开的窗口中显示已有的数据项的列表，点击 “Add a Row”按钮，创建一个新数据项数据项的唯一性代码选项和重用选项 使用Tools-Model O
15、ptions-Model Settings。在Data Item组框中定义数据项的唯一性代码选项(Unique Code)与重用选项（Allow Reuse）。概念数据模型CDM概念数据模型CDM有关联系的基数有关联系的基数 举例，“系”与“学生”两个实体之间的联系是一对多联系，换句话说“学生”和“系”之间的联系是多对一联系。而且一个学生必须属于一个系，并且只能属于一个系，不能属于零个系，所以从“学生”实体至“系”实体的基数为“1,1”，从联系的另一方向考虑，一个系可以拥有多个学生，也可以没有任何学生，即零个学生，所以该方向联系的基数就为“0,n”,如图所示物理数据模型PDM物理数据模型(PDM)PDM考虑了数据库的物理实现，包括软件和数据存储结构。PDM的对象：表（Table）、表中的列（Table column）、主码和外码（Primary & Foreign key）、参照（Reference）、索引（Index）、视图（View）等。物理数据模型PDM生成数据库脚本Database - Generate Database估算数据库大小DataBase-Estimate Database Size生成测试数据DataBase-Generate Test Data接口隔离原则
