第2章 类图.pptVIP

2.1 类图 类图是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及到具体的实现细节。 在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责；在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构；在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。 本章将学习UML的类图，并概述标识类的过程，然后对他们进行详细解释。 UML类图是面向对象分析和设计的核心，它显示了系统的各个类、类与类之间的相互关系（包括继承、聚合和关联等）及各个类的操作和属性。类图用途广泛，可用于分析建模和设计建模。 关键抽象 在画出了系统的用例图之后，接下来的重要步骤就是找出系统的关键抽象以及他们的属性，以及介于这些关键抽象之间的业务关系。 关键抽象是在系统范围上的一些重要概念，主要是从需示中得到（例如词汇表、业务规约以及用例模型），这些概念也会涉及到系统所针对的业务领域知识。关键抽象通常表现为系统的实体。 关键抽象是一个类或一个对象，组成问题域词汇的一部分。这意味着将关键抽象呈现给用户时，它们与我们涉及的实体有一一对应关系。例如，凭单、支票簿、传票簿、存折、ATM卡、出纳员和部门等。 关键抽象很重要性在于： 强调与系统设计有关的实体 排除系统外部多余的实体 关键抽象将成为分析为模型中的类 关键抽象的层次至关重要，既不能太高也不能太低。 抽象的层次 在派生关键抽象时，一定要记住抽象的层次不应过高或过低。如果抽象层次过高，就会产生混淆。层次太高的抽象将导致对现有实体的笼统定义。它可被视为实体的宏观视图，通常没有任何作用。例如在银行，不能将“人”当作关键抽象。否则，将被视为较高的抽象层次。 必须将出纳员与客户分开定义，因为二者的职能不同。这和高层次的抽象将使分析人员、设计人员和用户都感到含糊和混乱。现举一个例子来说明高层次抽象的含义，比如某人去银行存钱，另一人来接待他。这个层次的抽象就有点含糊，并且很容易导致混乱，因为“人”这个词重复使用。 类似地，抽象的层次太低也会产生混乱，因为较细粒度的信息与此时的关键抽象毫不相干。 例如，以下信息： 银行的开户单有15个字段。 必须在开户单的右边填写日期字段。 在开户单上填写地址的空间太小。 都是极其微小的细节，可能会导致混乱。在设计界面或报告时需要这类信息，但在此时的关键抽象中它只会导致混乱并使问题复杂化。 如何进行关键抽象 针对一个给定的问题，首先会想到的实体可能就是关键抽象。 每次标识一个新的抽象时，都有必要从问题域的角度考虑。可能会问的问题包括： 可对此实体执行哪些操作？ 什么可导致创建此类型的对象？ 如果找一到恰当的答案，则必须重新考虑此问题。应该给每个抽象指定一个合适的名称，这些名称应表示此抽象的功能。 候选类 在分析的初始过程中，通过关键抽象可阐明一些类。这些类称为候选类，它们代表给定系统中可能有的类。但是，它们不一定是最终的类。其中有一些类可能会因为不适合候选类而被排除，也可能会随着分析过程的展开而增加一些类。 标识候选类 标识候选类的方式有几种： 冗余类 如果有多个类定义一个实体，则这些类称为冗余类。在此情况下，将保留最佳类，而排除其它类。例如，银行系统中有两个类：帐户持有人和客户。二者都表示同一个实体，因此只能保留一个类。 无关类 任何不属于应用程序域的类都需去除。例如，在一个银行系统的例子中，前端柜台类可能就是无关类。 模糊类 没有明确功能的类称为模糊类。系统中有用的类应是具有明确功能的待定类。对于模糊类，应重新定义或将其排除。例如，假设某银行有不同的部门，其中一个标识的部门是行政机构，由于银行的计算机化范围不包括行政部，因此这个类就是一个模糊类。 标识类的角色：例如，银行经理、出纳员和勤杂工这3类都是雇用类的角色。保留雇员类，而排除所有作为角色的类。 2.2.1 如何识别类 发现类是一件富有创建性需要努力尝试的事情。软件系统中的对象在真实世界中并不存在，但可以理解为是研究真实世界中的对象的结构和行为之后派生出来的。类是对象类型的描述。因此，要明确地表达类和对象之间的关系，可以说对象是类的实例，类描述了一类对象的属性和行为。牢记对象定义后，对识别问题领域中的类和对象将会非常有帮助。在分析领域的时候，要注意用来描述业务实体的名词术语，这些名词通常可作为模型中的类。 以下是用于在问题领域中查找类的一些基本提示： 问题陈述中的名词 对问题领域的了解 用例 物理实体 设备 事件 扮演的角色 操作程序 地点 组织单元 类图的地位和作用 类定义 类是一组具有相同属性、相同行为、和其他对象有相同关系、有相同表现的对象描述 类具有属性和操作 图形表示 类名、属性、操作 可以简化表示 类 属性 一般描述类的某个特征，可以确定并区分对象以及对象