静态图(类+对象).ppt

静态图 类、接口和包的基本表示方法 依赖关系 关联关系 泛化关系 实现关系 正向工程和反向工程 类图的使用 类的基本表示方法 类（Class）的组成 名称（符合命名规范） 属性（属性名，类型 ，初始值，可见性，版型） 操作（操作名，参数表，返回类型，可见性，版型） 两种添加和编辑的方法 New Xxxxx Open Specification 删除和从模型中删除 可见性 接口的基本表示方法 接口（Interface） 标签表示法 装饰表示法 图标表示法 包的基本表示方法 包（Package）的作用 组织各种内容 表示层次结构 版型(StereoType)扩展 文档说明(Documentation) 包的嵌套 包可以拥有其他包作为元素（即：子包） 包可以添加自身所包含的类 依赖关系（Dependency） Rational Rose帮助文档中的定义 依赖描述了两个模型元素之间的关系，如果被依赖的模型元素发生变化就会影响到另一个模型元素。 典型的，在类图上，依赖关系表明客户类的操作会调用服务器类的操作。 模块A依赖于模块B 模块A调用模块B提供的方法 模块A访问模块B中的某些数据成员 依赖关系 依赖是好事还是坏事？ 依赖意味着耦合(一个模块的变化会造成一个或多个其他模块也同时发生变化)，过强的耦合关系会对软件系统的质量造成很大的危害。 系统的模块之间必须以某种方式交换信息，因此也必定会有这样或那样的依赖关系，永远不要幻想消除所有依赖！ 想尽办法来控制和消解不必要的耦合，特别是降低与不稳定模块之间的依赖关系 面向过程与面向对象 面向过程的开发： 上层调用下层，上层依赖于下层 当下层剧烈变动时上层也要跟着变动 导致模块的复用性降低，大大提高了开发的成本 面向对象的开发： 让用户程序依赖于抽象，实现的细节也依赖于抽象 一般情况下抽象的变化概率很小，即使实现细节不断变动，只要抽象不变，客户程序就不需要变化 大大降低了客户程序与实现细节的耦合度 降低依赖的方法一 依赖倒置原则（Dependence Inversion Principle ） 1）上层模块不应该依赖于下层模块，他们都应该依赖于抽象 2）抽象不应该依赖于具体，具体应该依赖于抽象 具体对策：分离接口和实现 依赖倒置 依赖倒置 依赖倒置 总结： 1）一切依赖于接口（或抽象类） 应用程序调用类库的抽象接口，依赖于类库的抽象接口 具体实现类派生自类库的抽象接口，也依赖于类库的抽象接口 2）应用程序和具体类库实现完全独立 由于没有直接的依赖关系，只要保持接口的稳定，应用程序和类库的具体实现都可以独立地发生变化 3）提高应用程序和类库的重用性 应用程序可以和任何一个实现了相同抽象接口的类库协同工作 依赖倒置 在依赖关系中 尽量依赖抽象类或接口 不要依赖与具体的类 降低依赖的方法二 控制反转（Inversion of Control ） 如果说依赖倒置主要解决应用程序和具体类库之间的依赖关系 那么，控制反转主要解决应用程序和框架系统之间的控制权关系 类库和框架的区别 类库：只包含一系列可被应用程序调用的类，总是被动地响应用户的调用请求。 框架：一个‘半成品’的应用程序，包含了应用程序从启动到运行的主要流程，程序运行时，框架系统自动调用用户实现的功能组件。 控制反转 控制反转 总结： 1）应用程序和框架系统之间实际上是双向调用，双向依赖的关系。 2）依赖倒置原则可以减弱应用程序到框架之间的依赖关系。 3）控制反转及具体的模板方法可以消解框架到应用程序之间的依赖关系。 4）也可以把“控制反转”看作是“依赖倒置”的一个特例：应用程序对框架系统的依赖被“倒置”为二者对抽象接口的依赖 降低依赖的方法三 依赖注入（Dependency Injection ） 同一个应用程序（类库实现/框架系统）内部存在多个对象，这些对象之间经常相互调用。 在传统程序设计过程中，当某对象(调用者)需要另一对象(被调用者)的协助时，通常由调用者创建被调用者的实例，两者由此产生依赖 依赖注入：程序运行过程中，如果需要调用另一个对象协助时，无须在调用者的代码中创建被调用者，而是依赖于外部的注入。 降低依赖的方法三 举例：一个人(调用者)需要一把斧子(被调用者) 1）原始社会：几乎没有社会分工 需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。 结论：抽象接口貌似隔离了调用者和被调用者之间的依赖关系，但由于调用者需要亲自创建被调用者的实例，必然要求被调用者出现在调用者的代码里，所以仍然无法彻底实现二者之间的松耦合。 降低依赖的方法三 举例：一个人(调用者)需要一把斧子(被调用者) 2）工业社会：出现工厂 工厂专门负责生产斧子，需要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。 结论：该