第3章 类图、对象图和包图.pptVIP

3. 授权依赖 表达一个事物访问另一个事物的能力，包括： 　　 依赖类型 说明 访问（《access》） 是包间的依赖，允许一个包（客户）引用另一个包（提供者）内的元素，但客户包必须使用路径名称。 导入（《import》） 允许一个包访问另一个包的内容并为被访问包的组成部分增加别名。《import》将提供者的命名空间整合客户的命名空间。可以使用路径名或增加别名来解决户包中的元素与提供者中的元素同名时发生的冲突。 友元 （《friend》） 允许一个元素访问另一个元素，不管被访问的元素是否可见，这大大的便利了客户类访问提供者的私有成员。 类Memento和类Originator建立了友元依赖关系， 以便Originator使用Memento的私有变量state 4. 绑定依赖 较高级的依赖类型，用于绑定模板以创建新的模型元素。 绑定（《bind》） 　规定了客户用给定的实际参数实例化提供者的模板。 模板类StackT定义了栈相关的操作； IntStack将参数T与实际类型int绑定， 使得所有操作都针对int类型的数据 3.2.4 实现关系 对应于类和接口之间的关系 。 客户必须至少支持提供者的所有操作。 一个元素完成另外一个元素的操作功能。 接口没有属性，只有声明的操作方法（对方法没有实现部分），而由实现类具体定义实现部分。 3.2.4 实现关系 泛化和实现都可以将一般描述与具体描述联系起来： 泛化将同一语义层上的元素连接起来，并且通常在同一模型内。 实现将不同语义层内的元素连接起来，并且通常建立在不同的模型内。 类Circle、Rectangle实现了 接口Shape的操作 3.3 构造类图模型 通过分析用例模型和系统的需求规格说明，可以初步构造系统的类图模型。类图模型的构造是一个迭代的过程，需要反复进行，随着系统分析和设计的逐步深入，类图会越来越完善。 1、类图的抽象层次 概念类 描述应有领域中的概念，仅包含类名，不考虑细节； 分析类 分析不针对具体语言，包含一些类的细节特性； 设计类 针对具体的语言，考虑类的实现细节； 2、绘制类图 步骤 分析问题域，确定需求 寻找类，确定类的含义和职责 定义类的属性和操作 确定类之间的关系 精化类和类间的关系 绘制类图 3、寻找类 类的识别是一个需要大量技巧的工作，一些技巧包括：名词识别法；根据用例描述确定类；使用CRC分析法；参考设计模式确定类；对领域进行分析或利用已有领域分析结果得到类。 1）名词识别法： 这种方法的关键是识别系统问题域中的实体。对系统进行描述，描述应该使用问题域中的概念和命名，从系统描述中标识名词及名词短语，其中的名词往往可以标识为对象，复数名词往往可以标识为类。 3、寻找类 2）从用例中识别类： 用例图实质上是一种系统描述的形式，自然可以根据用例描述来识别类。针对各个用例，可以提如下的问题辅助识别： 用例描述中出现了那些实体？ 用例的完成需要哪些实体合作？ 用例执行过程中会产生并存储哪些信息？ 用例要求与之关联的每个角色的输入是什么？ 用例反馈与之关联的每个角色的输出是什么？ 用例需要操作哪些硬设备？ 在面向对象应用中，类之间传递的信息数据要么可以映射到发送方的某些属性，要么该信息数据本身就是一个对象。综合不同的用例识别结果，就可以得到整个系统的类，在类的基础上，我们又可以分析用例的动态特性来对用例进行动态行为建模。 例：图书管理系统 1、寻找类：可从描述中的名词开始。 需求描述中可以发现借阅者（Borrower）、图书（Book）、图书标题（Title）、借阅信息（Loan）等重要名词，可以认为它们都是系统的候选对象，是否需要为它们创建类可以通过检查是否存在与它们相关的身份和行为进行判断。 例：图书管理系统 2、根据用例模型和系统需求确定类的属性和操作，以及类之间的关系。 例：图书管理系统 3、用户使用系统时需要与系统进行交互，所以需要创建用户接口类。 例：图书管理系统 系统管理员登录系统后，ManageWindow类将为其提供主操作界面。 借、还书界面类与实体类之间的关系 例：图书管理系统 练习：演出售票系统 在用例驱动的开发过程中，通过分析各个用例及参与者得到类图。分析用例图的过程中需要根据面向对象的原则设计类和关系，根据用例的细节设计类的属性和操作 信息亭 Clerk Buy tickets Buy Subscription 信用卡服务商 Make charges 监督员 Survey sales 参与者 include include 用例 Box Office 关系 在这里只考虑以下三个用例： Buy