第5章 静态图.ppt

5.4 包图 * * 包：把模型元素组织成组的通用机制 实质：分组（包是一个容器） 分块组织和管理系统众多的模型元素 目的 ①便于理解和管理（有利于分工开发） ②能够对软件系统的逻辑结构建模（体系结构） 如何分组：高内聚、低耦合 功能相近、可能一起变化的元素组织在一起 符号 5.4.1 包的概念 * 包中的元素 类、接口、组件、节点、协作、用例、图以及其他包 包和其元素之间的关系 一个包由一个或多个元素组成 每个元素在该包中声明 一个元素只能属于一个包 一个包消失了，包中的所有元素也随之消失 5.4.2 包中的元素 * P92 5.4.3 包的可见性 * 输出 包中public的元素 引入 允许一个包中的元素单向访问另一个包输出的元素 UML表示：依赖关系 5.4.4 引入与输出 * 5.5 实例 * 什么是静态结构？ 静态结构有什么用？最终的类图：实现层次的类图，可以指导编程人员的编码 用OO观点观察软件系统 1）由各式各样的对象组成，每种对象都具有各自的属性和操作 即要说明系统由哪些对象组成，对象的内部结构及外部关联?类图，系统的静态结构 2）当根据某种规律把一些对象联系起来，就能够提供多样化的服务?用例，序列图，系统的行为 按照规律把对象联系起来，提供服务，这实际上就是用对象来实现并替代了某个原先由人来完成的业务流程 即用例叙述通过说明执行过程，隐含了其中要满足的规律，即展现了规律 但用例叙述中并没有显式地说明对象，而序列图则说明了对象之间是如何组织，共同配合完成系统的功能 可以把系统用例的这种实现方法，即对象共同配合完成系统功能这种方法（序列图），认为是系统的行为，即动态的行为 而类图看成是系统的静态结构 每个对象是相互独立的， 只有在某个外力的驱动下，对象之间才会依据某种规律相互传递信息，这些交互构成了这个生动世界的一个“过程”?用例 在没有外力的情况下，对象则保持“静止”的状态 * * 从OO的观点来看，确定系统的静态结构，也是一个很重要的问题 首先第一步是如何通过分析来识别有哪些类 然后识别类的属性和操作 最后确定类之间的关系 简单介绍类图中的UML元素 类图的三个层次 要一步到位地设计出可以用于直接指导编程人员编码的类图是不太可能的 我们需要经过逐步地分析设计后，才能得到最终的类图 然而，这个逐步分析设计的过程，我们仍然可以用类图来记录，只是抽象的级别不同 最终的类图：实现层次的类图，可以指导编程人员的编码 关于类图的三个层次，实际上对应类的三个层次 要为软件系统设计类，也是一个逐步求精的抽象过程 首先是直接从问题领域获取关键概念 其次是关注What的分析过程中产生的软件类 最后是关注具体实现平台与技术的实现类 这三个层次的类，在RUP中又称为业务实体、分析类、设计类 用Rose不好绘制 用StarUML绘制简单 StarUML中线条的样式有两种选择：Rectlinear（用矩形线条）、oblique（用非直角的折线），并且在选择关联后，在属性窗口中显示关联的各种属性，操作简便 * Depart：离开 Copilot：副驾驶 * 第5章 静态图 现实世界 由各式各样的事物组成 每种事物都有它特有的结构和行为 当根据某种规律把一些事物联系起来，就展现出丰富多彩的世界 软件系统 由各式各样的对象组成 每种对象都具有各自的属性和操作 当根据某种规律把一些对象联系起来，就能够提供多样化的服务 5.1 系统的静态结构 * 静态结构 动态行为（与其他类协同工作） 类图例1： * 类图例2： * 类图例3： * 类图所包含的信息 系统由哪些类组成 每个类的内部结构，即属性和操作 类之间的关系 类图的三个层次 概念层－－概念类－－业务实体 说明层－－软件类－－分析类 实现层－－实现类－－设计类 UML用类图来表示系统的静态结构 * 例：航班信息系统 Plane tailNumber public class Plane { private String tailNumber; public List getFlightHistory(){…} } 分析： 真实世界的重要概念?飞机 设计： 软件对象，来源于真实世界 实现： 用具体的编程语言 来实现软件对象 5.2.1 类图的概念和内容 5.2.2 类图的用途 5.2.3 类图的元素----类 5.2.4 类图的元素----接口 5.2.5 类图的元素----关系 5.2.6 类图建模技术 5.2 类图 * 类图表示系统的静态结构 类图中包含的元素 类、接口、协作 依赖关系、泛化关系、实现关系、关联关系 图5-1 5.2.1 类图的概念和内容 * 系统分析师以支持软件系统的功能需求为目的设计静态图 对系统词汇建模（概念模型