(软件工程理论、方法与实践)第5章面向对象的分析.ppt

　　　　　5.1 面向对象分析的概念　　在面向对象的软件工程方法中，将软件系统问题看作是现实世界应用域问题的映射。客观世界中的系统依赖于实体和它们之间的协作，面向对象的软件系统则依赖于类和对象之间的协作。因此面向对象的分析方法的目标是将客观世界的实体转　换为软件系统中的类和对象以及对象之间的协作模型。　　面向对象的分析过程是找出分析类、分析包，构建它们之间的静态关系和动态协作模型的过程。 5.1.1 分析类　　在对象分析模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象。在分析阶段，分析类直接与应用逻辑相关，而不关注纯粹的技术实现问题。分析类代表了系统设计中的一个或几个类或若干个子系统的抽象。 　　这种抽象具有如下特点：　　(1) 分析类侧重于处理功能性需求，而把非功能性需求推迟到后续的设计与实现活动中再实现。这使得分析类在问题域语境中更加突出、更加“概念化”，而且与其对应的设计与实现类相比具有更大的粒度。　　(2) 分析类很少根据操作及其特征标记来定义或提供接口，而是通过较高的、非形式化层次的职责来定义其行为。职责是对由类定义行为的内聚子集的文本描述。 　　(3) 分析类定义属性，但这些属性还处于较高的层次。通常这些属性的类型是概念性的，而且应从问题领域来考虑；而设计和实现类的属性类型通常就是程序设计语言的类型。而且分析期间定义的各种属性通常在设计和实现阶段对应各种类。　　(4) 分析类涉及到关系，这些关系和设计与实现阶段的对应部分相比更加概念化。例如，关联的导航性在分析中并不十分重要，但在设计时却是必需的。又如，可以在分析中使用泛化，但在设计阶段如果得不到程序设计语言的支持就无法使用泛化。 　　(5) 从软件的功能需求来看，分析类可以划分成实体类、边界类和控制类三种类型。　　● 实体类：表示系统存储和管理的永久信息。　　● 边界类：表示参与者与系统之间的交互。　　● 控制类：表示系统在运行过程中的业务控制逻辑。　　分析类在UML中可以用一般的类符号来表示，也可以用简化的形式。在UML语言中，使用构造型entity、boundary和control分别表示实体类、边界类和控制类。图5.1给出了UML构造型表示的三种分析类。这三种构造型在UML中已经标准化，并已用来帮助开发人员区别对待不同的类。每种构造型都有自己的符号。 图5.1 三种分析类 　　在图5.2中，ATMCard是一个实体类，表示用户的ATM卡信息；DisplayScreen，表示ATM的界面显示类；CardScanner是一个控制类，表示控制银行卡操作的业务逻辑类。 图5.2 实体类、边界类和控制类实例 　　1．边界类　　图5.3为“取款用户界面”的边界类，用于支持“银行客户”参与者和“现金取款”用例的交互。　　“取款用户界面”允许银行客户输入取款的金额，验证金额数目是否大于银行客户账户的当前金额数目，然后由系统向用户支付现金。 图5.3 “取款用户界面”边界类 　　2．控制类　　图5.4引入一个ATM系统中“打印调度程序”的控制类，它负责控制和协调“取款账单打印用户界面”边界类和“取款账单”实体类之间的打印。　　“打印调度程序”接受打印请求和要打印的当前账单，然后完成打印任务。 图5.4 “打印调度程序”控制类及它与边界类、实体类的关系 　　3．实体类　　实体类用于对长效且持久的信息建模。实体类主要是对客观世界中的个体、实际对象、实际事件的某些现象或概念的信息及相关行为进行建模。　　大多数情况下，实体类可以直接从问题域中客观世界存在的业务实体得到，例如可以将账单、银行账户、学生等实体抽象为实体类Bill、Account和Student。实体类的属性通常是表征该实体的一些特征信息，如对于一个银行Account类来说，银行账号、持有人、密码、联系地址、账户类型等现实世界的账户信息可以被抽取为Account类的属性，而对该账户的相关操作，如刷卡、更改密码等，则可抽象为Account操作/方法。 5.1.2 用例实现　　用例实现可以用静态的结构和动态的协作模型来描述。可以是以文本的形式描述事件流的脚本、描述用例实现所涉及的分析类的类图、描述实现用例的对象间的交互协作的顺序图或协作图。如我们在3.5节中给出的关于在线下载的用例实现采用了顺序图。图5.5试图用UML模型给出用例、用例实现之间的关系。 图5.5 用例与用例实现 5.1.3 分析包　　在UML 模型中，包是一种分类事务，分析包是需求分析阶段的另一个产出元素。分析包提供了一种方法，用管理分块的方式对分析模型进行组织。分析包可以包括分析类、用例实现及其他分析包。分析包应该具有强内聚性和弱耦合性，即它们所包含的元素应该紧密相关且彼此间的依赖性应