第5章_需求建模景信息与类分析.pptVIP

CRC建模 类的分类方法可以通过如下分类扩展。 实体类是从问题的说明中直接提取出来的，也被称作模型或业务类。这些类一般代表保存在数据库中的和贯穿应用程序的事物。 边界类用于创建用户可见的和交互的接口（例如交互屏幕或打印的报表）。实体类包含对用户来说很重要的信息，但是并不显示这些信息。边界类被设计成负责管理实体对象对用户的表示方式。例如，一个被称作CameraWindow的边界类可能负责显示SafeHome系统的监视摄像头输出。 控制类自始至终管理“工作单元”。即控制类可以管理(1)实体类的创建或更新；(2)边界类从实体对象获取信息后的实例化；(3)对象集合间的复杂通信；(4)对象间或用户和应用程序间交换的数据的确认。通常，直到设计开始时才开始考虑控制类。 CRC建模 职责（属性和操作）。[WIR90]在给类分配职责时建议了以下5个指导原则： 智能系统应分布在所有类中以求最佳地解决问题的需求。 每个职责的说明应尽可能具有普遍性。 信息和与之相关的行为应放在同一个类中。 某个事物的信息应局限于一个类中而不要分布在多个类中。 必要时，职责应由相关类共享。 CRC建模 协作。类有一种或两种方法实现其职责：(1)类可以使用其自身的操作控制各自的属性，从而实现特定的职责；(2)类可以和其他类协作。 协作从客户职责实现的角度表现从客户到服务器的请求。协作是客户和服务器之间契约的具体实现……如果为了实现某个职责需要发送任何消息给另一个对象，我们就说这个对象和其他对象有协作。单独的协作是单向流——表示从客户到服务器的请求。从客户的角度看，每个协作都和服务器的某个职责实现相关。 CRC建模 协作识别类之间的关系。当一组类相互协作以实现某个需求时，这些类可以组织为子系统。 通过确认类本身是否能够实现自身的每个职责，可以识别协作。如果不能实现每个职责，那么需要和其他类交互，因此就存在协作。 为识别协作者，分析师可以检查类之间三种不同的通用联系：(1)is-part-of(是……一部分)联系；(2)has-knowledge-of(有……的知识)联系；(3)depends-upon(依赖……)联系。 CRC建模 属于某个聚合（整体部分）类一部分的所有类通过is-part-of联系和聚合类连接，如课本图5-12所例。 当一个类必须从另一个类中获取信息时，就建立了has-knowledge-of关联。 depends-upon关联意味着两个类之间具有has-knowledge-of和is-part-of不能实现的依赖关系。 所有情况下，协作类的名称记录在CRC模型索引卡上，紧靠在职责旁边。因此，索引卡包含一个职责列表以及相关的能够实现这些职责的协作。 聚合类 图5-12 聚合类 CRC建模 当一个完整的CRC模型被开发出来时，客户代表和软件工程组织的代表可以使用如下方法评审模型： 所有参加CRC模型评审的人员拿到一部分CRC模型索引卡，卡片按照协作分开（即每个评审员不得有两张存在协作关系的卡片）。 所有的用例场景将被分类管理。 评审组长细致地阅读用例。当评审组长看到一个已命名的类时，给拥有相应类索引卡的人员一个令牌。 当令牌传递时，该类卡的拥有者需要说明卡上所记录的职责。评审组确定职责是否满足用例需求。 如果记录在索引卡上的职责和协作不能满足用例，就需要修改卡片。修改可能包括定义新类，或在已有的卡上说明新的或修改的职责、协作。 该过程将持续进行直到用例编写结束。当评审完所有的用例，将继续分析建模。 关联和依赖 在很多例子中，两个分析类以某种方式相互关联，如两个数据对象可能相互关联。在UML中，这些联系被称作关联(associations)。 在某些情况下，关联可以更进一步地指出多样性。多样性限制实例如课本图5-10所示，其中“一个或多个”使用1..*表示，“0个或多个”使用0..*表示。在UML中，星号表示范围无上界。 多样性 图5-13 多样性 关联和依赖 在很多情况下，两个分析类之间存在客户-服务器联系。此时，客户类在某些方面依赖于服务器并且建立了依赖联系。依赖由一个构造型定义。在UML中，构造型是一个“可扩展机制”，允许软件工程师定义特殊的建模元素，这些建模元素的语义是由用户自定义的。在UML中，构造型由双尖括号表示。 SafeHome实例[24] 分析包 分析建模的一个重要部分是分类，也就是将分析模型的各种元素（如用例，分析类）分组打包，并为其取一个有代表性的名称。 一个分析包的实例如课本图5-15所示。 每个包中分析类名字前的加号表示该类是公共可见的，因此可以从其他包访问。包中的任何元素之前可以添加其他符号。负号表示该元素对其他包是隐藏的，#号表示该元素只能由指定包中的类访问。 小结 课本109页 作业 P109页 5.5 （b,d) 5.6