信息系统分析与设计案例2010-8.ppt

内容 8 设计对象和类 简介 详细设计 设计活动包括类、类之间关系和类交互的详细定义。 模型应该包括足够的信息，使得它们能被用作程序的定义。 对类图重新审视，以便讨论在本阶段我们可能需要增加的类，例如管理界面和控制执行序列的类。 在分析阶段没有特别关注的类的事情，如类之间的关联、类的可见性、属性和操作等技术细节，现在需要详细地确定。 我们重新审视交互图来讨论如何建模对象的产生和删除，以及如何规定条件和控制。 类图 -1 设计类图 vs. 分析类图 区别之一是模型的详细程度 在分析中，交付的模型保持简洁和避免实施的决定；这使得图形不混乱，因此容易阅读和同客户讨论。同时也避免了不成熟的实施决定。 在分析中，焦点是在组织做什么，以及它要新系统做什么。在分析类图中，大多数的类是实体类，即它们对问题域中的特征进行建模。 在分析中可以开始确定边界和分析类，但对这些类的详细考虑主要是设计和实施的活动。 类图 -2 设计类 随着我们逐渐接近编码，我们需要作出和记录关于实施的决定。 详细地设计活动包括： 增加类，诸如界面、控制和容器类，以便帮助交付解决方案 详细定义类之间的联系 定义属性和操作的可见性 详细定义属性 详细定义操作 将控制和界面功能从实体类的信息和表现中分离开来的原因之一是孤立变化的影响。例如，对界面如何工作地改变不应该影响实体类。 类图 -3 边界和控制类 边界类处理系统同用户的界面；例如它们被用来将用户的菜单选择转换成发送给一个对象的消息。 一般地，每个用例有一个界面类和一个控制类。 控制类处理在用例执行中的事件的序列。 图8.1表示了 ‘Maintain bike list’ 用例中‘Add bike’ 场景的协作图。 我们已经添加了一个控制对象:MaintainBike，和一个界面对象 :MaintainBikeUI到 ‘Maintain bike list’的协作中。 在这个场景执行中的事件序列是被用户发送给控制类的消息（通过高层次的 :MainMenuUI对象）所激活，然后通过控制类来完全控制的。 类图 -4 边界和控制类（续1） 在参与者和对象之间的交互是： 管理者从欢迎屏幕（主界面）上选择增加自行车选项 这一选择传送到（通过一个 :MainMenuUI 对象）控制对象 :MaintainBike “MaintainBike”类产生一个新的界面对象 :MaintainBikeUI 管理者在界面对象的屏幕显示上输入他要增加的自行车的细节。 界面对象将这些细节传送到控制对象。 控制对象将自行车的细节传送到Bike对象。 图8.7用序列图表示了这一交互过程。 类图 -5 边界和控制类（续2） 实体、边界和控制类被建模成实例（stereotypes） 被用来表示实例，见图8.2。注意，在图中显示一个类的实例是非常有帮助的。 因为具有许多高进的建模特性，我们可以使用实例标识来增加附加的信息到交互图中。 实际上，Wheels系统是如此之下，当我们实现它时，我们将控制类和边界类的功能合并到一个类中，见图8.11。然而，为了讨论边界和控制类的用途，我们将它们分别建模。 类图 -6 设计关联 当我们设计时，我们需要决定类之间的关系如何实现。 在早期的分析类图中，在类Customer、Payment、Hire和Bike之间的关系简单地反映了现实中的顾客租车交易和付款的关系，租车交易和自行车之间的关系，等等。 利用 CRC 卡片来确定类的职责和协作给我们提供了这些关联应该如何的更多的概念。 到我们进入设计时，从交互图中，我们准确地知道哪个对象需要通讯，以及消息的内容和方向。 在类之间的关联定义了实现这些类的对象之间导航路径的需要。 我们如何实现一个关联取决于关联的多重性和通讯是单向的还是双向的。 类图 -7 一对一关联 在 Wheels系统中没有一对一关联 图8.3 表示了在 School类和 SchoolLibrary类之间一对一的关联 School 对象需要能传送消息给 SchoolLibrary对象，但反之则不能。 这种消息传送的方向被称为关联的导航性。 一个方向的关联被称为单向的 导航的方向被箭头所表示。 两个方向的导航性既可以用关联两端的箭头表示，又可以都不标注箭头来表示。 然而，没有箭头也能意味着导航性还没有规定，如在分析模型中的例子。因此，标识箭头更清楚些。 类图 -8 一对一关联（续） 为了实现一对一关联，School有一个属性library来用于存放它需要通讯的SchoolLibrary对象的对象标识符（或者称为一个指针或引用）。 在双向关联中，每个类都需要存放一个对于对方的引用。 如果在School和SchoolLibrary之间的关