对象设计精要.ppt

1、对象设计精要,对象建模语言UML和对象设计方法的概要介绍,吴铭 ,内容提要,UML介绍 分析和设计 对象编程 开发过程概述 UML精要,UML与Java程序设计 UML与设计模式 UML与J2EE,UML的由来,Unified Modeling Language(UML)是八十年代后期和九十年代早期出现的，面向对象的分析和设计方法的潮流的延续。它主要是合并了Booch, Rumbaugh和Jacobson三位大师的方法，同时也通过了OMG的标准化过程，成为OMG的正式标准。 UML被称为建模语言，而不是方法。至少从理论上来说，大多数方法由建模语言和过程组成。建模语言是用来表达设计的符号表示，而

2、过程是建议的做设计的步骤。,UML是什么？,是一种捕获知识和表达知识的语言 是用来对系统建模的语言 是以可视化方法建立模型并文档化的工具 是汇集了最好的经验而得到的 是用于产生一组能够交付的制品的 是已经得到了广泛的支持的,UML不是什么？,不是可视化的编程语言 不是工具或文档库的模板和规约 不是过程,为什么需要分析和设计,沟通的需要，UML比自然语言让我们之间就某些概念进行沟通 学习对象分析设计的需要，OO设计方法有非常陡峭的学习曲线。对象设计语言是易于学习的，但对象设计语言仅仅允许先进性，但并没有提供该先进性，而UML从某种程度来说能够帮助我们得到这种先进性。 同领域专家交流的需要，软件开

3、发的过程中最大的挑战是开发正确的系统。隔行如隔山，即便是都讲同样的母语，我们同领域专家之间都会讲不同的术语，同样的词汇可能会有不同的理解，UML能够帮助我们捕获用户的需求和用户领域中的概念,各开发阶段的软件项目费用比例,资料来源C+面向对象开发P1，机械工业出版社,软件开发方法,结构化方法。以功能为组织的软件开发方法 数据建模方法。捕获称为实体的数据项的集合作为其构造块 面向对象方法。以互相协作的对象来构造软件的方法,软件的抽象机制,函数和过程 模块 抽象数据类型 类/对象,类/对象抽象机制的主要概念,消息传递。动作由发送给特定对象的服务请求所激发 泛化/特化。使得类共享同样的代码 多态。允许

4、为特定的类对共享的代码进行剪裁。 关系。对象通过这种机制知道彼此 关联。对象间的一种关系 聚合。一个对象由其他对象组成 行为。对象提供的服务 静态行为。独立于对象当前状态的行为。 动态行为。按对象状态而发生变化的行为。 规则。表达全局控制描述和业务规则的说明性机制。,传统开发方法的弱点,结构化分析与设计帮助开发者以功能组织软件，但是在企业应用中，功能是人定义的，在任何时候都会发生改变，而功能的改变又需要专业软件开发人员不停的改变其内在的模块 基于实体关系的数据建模方法的弱点与结构化方法相反。数据是相对稳定的，但数据建模方法却不能帮助开发者管理功能。 面向对象方法是目前我们所知道的唯一向软件开发

5、者提供同样好的支持系统所有视角的方法,为什么需要对象分析和设计,随着企业对信息系统依赖程度的增加，软件的功能，规模和复杂度也逐步增加，传统的开发方法自身的缺憾造成维护成本居高不下 在软件开发的过程中，越是在早期识别错误，就越能更大的节省费用。面向对象方法具有减少费用、开发产品所需时间和错误的优势，并在开发过程中提供了灵活性。,对象编程介绍1,封装。即包含数据，又包含改变该数据的方法 信息隐藏。包含数据的对象定义可被其他对象访问的服务。 消息传递。对象只能借助消息传递机制才能够同其他对象通讯。 后期连接。能够在运行的时候对一个消息决定接受者和接受方法,对象编程介绍2,委托。借助消息传递，工作可以

6、从一个对象传递到另一个对象，一直到能够完成这项工作的对象。 类/实例/对象。所以的对象都是类的实例。实例能够在运行时被产生或销毁 泛化。可以用层次继承关系来组织类 关系。向客户提供服务的对象之间的协作通常由关联关系捕获。,鸽笼式计算模型,计算机是一种数据处理器，它具有一套操作内存的指令，从内存中把值抽取出来，并以某种方式转换它们，然后将结果存入另一个内存地址。这种模型能够相当精确的反映目前的计算机体系结构和工作方式，但并不能反映大多数人解决问题的方式。,复杂系统的视图鸽笼式模型,数据/实体视图：实体关系图，数据建模方法基于该视图 功能视图：系统功能分解（结构化技术），结构化分析和设计基于该视图

7、 行为视图：状态转换图 控制视图：基于规则的系统（计算机是执行一套规则的推理机）,模拟式计算模型,通过定义帮助我们解决问题的各种对象，并定义它们是如何彼此交互的，然后借助一些具体的事件，将元素置于运动中。我们将面向对象的编程看作是使用模拟式计算模型，以此来取代鸽笼式计算模型。当我们用服务和方法思考的时候，我们能够从日常生活中得到经验、理解、思想和直觉。,复杂系统的视图模拟式模型,选题并做练习 分成多个小组，每组不超过6人，作出提案。 从多个小组的众多提案中选定一个，由各个小组分别做出分析，并上台讲解。,软件开发过程同UML,经过剪裁的RUP过程,软件开发过程介绍,UML是建模语言，其中不包括过

8、程达到目的需要步骤。 不把UML同过程结合起来，建模不会有任何用处。 过程的使用不是遵循一个已经公开发表的过程严格去遵循，而是用公开发表的过程作为参考，开发出适应自己团队的过程。,RUP的四个阶段,Inception,Elaboration,Construction 1,2,.n,Transition,初始阶段,大概的投资回报分析 项目的边界分析 决定是否进入后续阶段,细化阶段,对问题活动更好的理解：构建什么，如何构建 风险驱动，管理风险,细化阶段风险,需求风险最大的风险，做了错误的系统，不是用户需要你做的。 技术风险所选择的技术是否能够工作，各个组成部分能否集成在一起。 技能风险员工是否有足

9、够的项目需要的技能。 政治风险是否有政治力量干扰项目的行事方式，并严重影响项目。,细化阶段应对需求风险,采用UML的用况图应对需求风险。用用况捕获用户的需求，作为同用户交流和计划和估算的基础。 用领域概念模型捕获用户理解的概念。类图用来定义同领域专家交流的词汇，活动图用来对工作流建模。 系统原型对克服需求风险有非常大的作用。,细化阶段应对技术风险,用所选择的技术构建原型 最大的技术风险来自于整合不同的模块和不同的技术实现手段 化时间评估和熟悉所使用的工具 使用UML工具 类图，用来表现部件之间如何通讯 包图，展示现阶段的组件图 部署图，提供部件如何部署的概览。,细化阶段应对技能风险,培训，培训

10、，再培训 培训只能让员工知道需要知道些什么，而不是真正知道如何做 好的导师值得投资，让有经验的导师伴随者项目，在项目的进展过程中由导师安排培训，学用结合。 多读书，读好书,细化阶段应对政治风险,我也为此头痛，这方面的问题需要另请专家:- 可能有益的建议是：研究一些有关组织行为模式方面的知识；努力获得理解和尊重；获得高层领导的支持，打通直接汇报的渠道。等等,细化阶段的结束,大约完成了项目的15，并由如下两个关键点标识 开发人员能够自如的估算 所有的风险都已经标识出来，并都已经有了应对的策略,计划构造阶段,有很多的计划构造阶段的方法，这里我们采用XP方法来计划 共分四步 对用况进行分类，按照业务和

11、风险两个条件，业务分类优先 估算每个用况的花费，包括分析，设计，编码，单元测试，集成测试和文档 用你的开发人员的数量，乘迭代的长度，然后除负载因子。比如：给定8个开发人员，三个星期的迭代周期，负载因子是2，你将得到12个理想开发周（831/2）每迭代。 将你的所有的用况的开发时间加起来，除以每迭代的速度，然后加一个幸运1。结果就是你的第一次的估算的完成你的项目的迭代次数。,计划构造阶段,将用况赋给每个迭代，高风险，高优先级的先处理 增加1035，分配给打包，调优和测试，作为移交阶段的计划时间 增加1020的时间给构造阶段，作为不可预见时间，按照包括了不可预见时间的计划做承诺，按照不包括不可预见

12、时间的计划安排工作。,构造阶段,系统是在一系列迭代中构建的。每个迭代是一个子项目，通过分析，设计，编码，测试并并集成到前一迭代阶段完成的用况中。 以用户演示和系统测试确认用况已经被正确的构建了，并以此结束该迭代阶段。 持续集成以规避集成风险，用重构来维持代码的灵活性。,管理计划,计划不如变化快，管理计划就是如何适应这些变化 划定时间段，养成守时的习惯 两到三个迭代调整一下计划,在构造阶段使用UML,所有的UML技术在该阶段都是有用的 用况图和概念领域模型用来同领域专家交流 类图，协作关系图，交互图探询和验证设计 状态图详细描述复杂生命周期的了的状态 Etc,移交阶段,改进性能，优化系统 错误修

13、正,何时使用迭代开发,当你希望项目成功的时候！,参考资料,快速软件开发有效的控制与完成进度计划McConnell 2002.1 电子工业出版社 Alistair Cockburn:Surviving Object-Oriented Projects.Addison-Wesley,1998 统一软件开发过程机械工业出版社The Unified Software Development Process.Ivar Jacobson, Crady Booch, and James Rumbaughthree amigos,UML图形工具介绍,用况,由一个用户目标联系起来的一系列场景。 包含如下几个概念

14、： 目标通常是引起与系统交互的“用户”的商业价值 系统将被用户使用的应用及其所有的相关硬件 参与者与系统交互的外部实体 用况是对交互的描述，该交互要达到参与者的某种目的,用况举例,客户浏览产品目录并将感兴趣的项目添加到购物篮。当客户准备付款的时候，告知系统送货信息和信用卡信息，并确认交易。系统同时立刻检查信用卡授权和确认交易，同时发送邮件。,用况描述,购买产品 客户浏览产品目录，选择拟购买的项目 客户去结帐 客户填写送货信息（地址；隔日或三日内） 系统显示全部价格信息，包括送货信息 客户填写信用卡信息 系统授权购买 系统立即确认交易 系统发确认邮件给客户,用况描述（续）,分支：授权失败 第六步

15、，授权失败，允许用户重新输入信用卡号码并重新尝试 分支：老客户 系统显示当前送货信息，价格信息和信息卡号的最后四位数字 客户可以接受或修改这些缺省值 回到主场景的步骤6,用况图,Generalization,Include,用况图角色（Actors）,用户同系统交互时所扮演的角色。 一个人可以有多个角色。 角色驱动用况，一个角色可执行多个用况，一个用况也可以被多个角色执行。 在实践中，角色对找到用况非常有帮助，先找到角色，就很容易找到角色关联的用况。 角色不是必须的，有用就好。某些用况根本不会清晰的关联到某个特定的角色。,用况图用况间的关系,当你希望在一个或多个用况之间避免重复时，使用关系 当

16、你希望描述一个一般行为的变体，并希望减少描述量时，使用 当你描述一个一般行为的变体，同时希望使用更可控的形式，可以使用,并在你的基础类上申明扩展点。,使用用况图,用况是捕获需求，计划和控制迭代项目的必要工具，捕获用况是细化阶段一个主要任务 用况表示系统的外部视图，从而，不要期待用况之间或用况和系统的类之间有任何交互 用况的数量和用况的大小取决于使用者的喜好，每个用况可能会有许多场景。,用况捕获的信息集,参与者：注明用况的所有参与者，不能识别参与者的，需要标明没有参与者 与其他用况的关系：泛化/特化，包含和扩展关系 前置条件：能够成功调用用况需要满足的前提条件 细节：用况交互的步骤 后置条件：用

17、况完成后的结果或状态,用况捕获的信息集（续）,异常：可能的错误和应对的措施 约束：用况执行过程中不变的条件 变体/选择：可能应用到用况的变化,类图基本,类图的使用,Conceptual 概念视图在领域层绘制待研究的概念，独立于语言和实现的概念表示。 Specification 规格视图设计软件的接口，而不是实现。 Implementation 实现视图与实现的类对照起来，是最常见的用法,类图的使用,理解前面提到的视图对于阅读和绘制类图都是非常重要的。 将规格视图和实现视图分开对理解和使用类图非常重要。 一般我用来表示实现视图的类，而用表示规格和概念视图的类。,类图的使用关联关系,关联关系 As

18、sociations表示的是类的实例之间的关系，比如：一个人为一个公司工作；一个公司有多个办公室。每个关联有两个端点，可以在关联上表示角色名，关联名和数量关系。,何时使用类图,任何时候，不论是在做分析，设计还是在实现的时候，只要是在用对象设计方法，类图就总是有用的,使用类图的一点忠告,不要使用所有的记号。从简单的开始，根据你的需要逐步引入其他记号。 绘制适合你的项目状态的视图： 如果处于分析阶段，绘制概念模型 当用软件工作的时候，专注在规格模型 仅仅当你需要表明特定的实现技术的时候，绘制实现模型 不要为任何事情都绘制模型，专注在关键的领域,交互图,描绘一组对象在某个行为下如何协作的模型 有两种

19、类型的交互图：序列图（sequence diagrams）和协作关系图（collaboration diagrams）,序列图（Sequence Diagrams）,序列图（Sequence Diagrams）,协作关系图,序列图同协作关系图的比较,对于交互图形的选择，不同的开发者有不同的喜好。 序列图更容易看到事情发生的顺序，而协作关系图更容易表示出对象之间的静态联系。 探询交互过程并做响应分配时，CRC Cards会是非常有用的工具。,类图高级,在90的情况下，前面介绍的基本类图已经足够我们使用了。 然而高级类图在剩下的10的情况下也是非常有用的，虽然高级概念不经常使用，但知道在什么时候需

20、要高级类图，能够看懂高级类图也是必备的技能。 UML同时也提供了丰富的扩展机制，方便我们根据自己的需要定义自己的语义。,Stereotypes,构造型（Stereotypes）是UML的核心扩展机制。当你发现需要一种新的，不在UML中的模型元素，但是，该模型元素同某种已有的模型元素非常类似，我们就可以用构造型来扩展已有的模型元素。 构造型一般用由书名号括起来的字串表示，比如：。但你也可以为构造型定义图标。,对象图（Object Diagram）,对象图是某个时间点上系统中对象的快照，因为对象图表示的是实例而不是类，所以也常常被叫做实例图，你也能够把对象图看作不带消息的协作关系图 对象图同类图非

21、常相似，但是名称下加了下划线，并按照 实例名:类名的方式命名,类级操作和属性,加了下划线的属性或方法，作用到整个类范围，这等同与Java或C+的静态成员,多类型和动态类型划分,类型划分（Classification）指的是对象和其类型之间的关系 在单类型划分中，一个对象属于一个类型，该类型可能继承自超类。在多类型划分中，一个类可能由多个类型描述，而这些类型不需要通过继承连接起来。多类型划分不同与多继承，多继承说的是一个类型可以有多个超类，但是某个对象必须是一个单一类型。多类型划分允许为某个对象有多个类型，而不需要为此定义一个类型,多类型和动态类型划分（续）,动态类型划分允许对象的类型在子类范围

22、内动态的改变，而静态类型划分则不允许这样。 尽管很多方法假定只能进行单类型划分，但是，这样的限制对概念模型来说过于严格了，多类型和动态类型划分对概念模型来说是有用的。,多类型和动态类型划分（示例）,聚集和组成（Aggregation and Composition）,使用UML时最多的混淆就来自与带数量的关联关系，聚集和组成之间的区别。知道他们之间的区别比知道他们的定义更重要,关联和聚集的比较,如果是部分和整体的关联关系，使用聚集。比如：汽车有发动机和车轮。森林有树木。,聚集和组成的比较,组成是一种更强语义的聚集，即：部分对象仅仅属于一个整体；部分一般和整体同生共死，删除整体的时候需要级联删除

23、部分,聚集和组成的比较（示例）,Composition,Aggregation,派生关联和派生属性,能够从其他关联和其他属性计算的来的关联或属性成为派生关联（Derived Association）和派生属性（Derived Attribute） 在关联名称前加斜线或在属性前加斜线的方式表示派生关联和派生属性,派生关联和派生属性（示例）,Derived Attribute,Derived Association,接口和抽象类,对象式开发能够得到高质量的软件的一个重要原因是接口和实现的分离，对象开发的威力就来自与此 接口只定义接口，没有属性和实现的类 抽象类有定义实现和属性，但不能实例化的类,接

24、口和抽象类,引用对象和值对象,具有唯一对象标识的对象称为引用对象，在对象的整个生命周期中，都可以通过该标示唯一的确定该对象。比如：客户（Customer） 可以直接比较对象的值以确定对象是否相等的对象。比如：日期,关联关系的数量值,关联关系两端可以标识数量关系，数量关系大于一的称为多值端。一般来说，多值端为一个无顺序的，每个对象只出现一次的集合，如果要改变该缺省语义，可以采用约束，比如：ordered表示缺省有顺序集合，目标对象在集合中只出现一次；bag表示目标对象可出现多次的无顺序集合；hierarchy表示层次结构等,冻结,表示在整个对象的生命周期中不能改变，即可以用在属性和关联上，又可以

25、用在类上，用在类上时，表示所有的属性和关联在对象的生命周期中都不能改变。,类型划分和泛化,由实例到类的关系成为类型划分，由子类到父类的关系成为泛化,限定关联,限定关联等同于编程概念中的hash，maps, dictionaries,关联类,关联类允许我们为关联添加属性和方法，属性是加在关联上的约束，属性不同，意味者不同的关联。 某些时候，我们可以把关联类提升为一个类来实现。,参数化类,以类型作为参数的类，C+语言中的template机制。目前Java正在实现中。,可见性,一般语言的可见性包括public, private, protected。 不同语言的实现略有不同,包和协作,包（package）用来组织模型，将模型划分为较小的，容易理解的单元。使用带依赖的包图能够让我们对系统有一个高层的理解。 协作包含一个或多个类之间的交互，同时为这个交互命名。,状态图,状态图是用来描述系统动态行为的一族技术。它用来描述某个特定对象的所有的可能状态，对象接受到事件后，对象的状态如何转变。 状态图的转换标记由三部分组成，三个部分都是可选的。EventGuard/Action,状态图（示例）,活动图,我发现初学UML的人很容易，也很喜欢使用活动图，他们经常把活动图当作流程图来使用，也有人把活动图画成了数据流图。 活动图最强的地方是支持并鼓励并发行为，这非常适于工作流建模和多线程程