搜索
信息系统分析与设计InformationSystemAnalysisandDesign1/41内容8信息系统分析与设计InformationSystemAnalysisandDesign2/41设计对象和类简介类图交互图信息系统分析与设计InformationSystemAnalysisandDesign3/41简介详细设计设计活动包括类、类之间关系和类交互的详细定义。模型应该包括足够的信息，使得它们能被用作程序的定义。对类图重新审视，以便讨论在本阶段我们可能需要增加的类，例如管理界面和控制执行序列的类。在分析阶段没有特别关注的类的事情，如类之间的关联、类的可见性、属性和操作等技术细节，现在需要详细地确定。我们重新审视交互图来讨论如何建模对象的产生和删除，以及如何规定条件和控制。信息系统分析与设计InformationSystemAnalysisandDesign4/41类图-1设计类图vs.分析类图区别之一是模型的详细程度在分析中，交付的模型保持简洁和避免实施的决定；这使得图形不混乱，因此容易阅读和同客户讨论。同时也避免了不成熟的实施决定。在分析中，焦点是在组织做什么，以及它要新系统做什么。在分析类图中，大多数的类是实体类，即它们对问题域中的特征进行建模。在分析中可以开始确定边界和分析类，但对这些类的详细考虑主要是设计和实施的活动。信息系统分析与设计InformationSystemAnalysisandDesign5/41类图-2设计类随着我们逐渐接近编码，我们需要作出和记录关于实施的决定。详细地设计活动包括：增加类，诸如界面、控制和容器类，以便帮助交付解决方案详细定义类之间的联系定义属性和操作的可见性详细定义属性详细定义操作将控制和界面功能从实体类的信息和表现中分离开来的原因之一是孤立变化的影响。例如，对界面如何工作地改变不应该影响实体类。信息系统分析与设计InformationSystemAnalysisandDesign6/41类图-3边界和控制类边界类处理系统同用户的界面；例如它们被用来将用户的菜单选择转换成发送给一个对象的消息。一般地，每个用例有一个界面类和一个控制类。控制类处理在用例执行中的事件的序列。图8.1表示了‘Maintainbikelist’用例中‘Addbike’场景的协作图。我们已经添加了一个控制对象:MaintainBike，和一个界面对象:MaintainBikeUI到‘Maintainbikelist’的协作中。在这个场景执行中的事件序列是被用户发送给控制类的消息（通过高层次的:MainMenuUI对象）所激活，然后通过控制类来完全控制的。信息系统分析与设计InformationSystemAnalysisandDesign7/41类图-4边界和控制类（续1）在参与者和对象之间的交互是：管理者从欢迎屏幕（主界面）上选择增加自行车选项这一选择传送到（通过一个:MainMenuUI对象）控制对象:MaintainBike“MaintainBike”类产生一个新的界面对象:MaintainBikeUI管理者在界面对象的屏幕显示上输入他要增加的自行车的细节。界面对象将这些细节传送到控制对象。控制对象将自行车的细节传送到Bike对象。图8.7用序列图表示了这一交互过程。信息系统分析与设计InformationSystemAnalysisandDesign8/41类图-5边界和控制类（续2）实体、边界和控制类被建模成实例（stereotypes）被用来表示实例，见图8.2。注意，在图中显示一个类的实例是非常有帮助的。因为具有许多高进的建模特性，我们可以使用实例标识来增加附加的信息到交互图中。实际上，Wheels系统是如此之下，当我们实现它时，我们将控制类和边界类的功能合并到一个类中，见图8.11。然而，为了讨论边界和控制类的用途，我们将它们分别建模。信息系统分析与设计InformationSystemAnalysisandDesign9/41类图-6设计关联当我们设计时，我们需要决定类之间的关系如何实现。在早期的分析类图中，在类Customer、Payment、Hire和Bike之间的关系简单地反映了现实中的顾客租车交易和付款的关系，租车交易和自行车之间的关系，等等。利用CRC卡片来确定类的职责和协作给我们提供了这些关联应该如何的更多的概念。到我们进入设计时，从交互图中，我们准确地知道哪个对象需要通讯，以及消息的内容和方向。在类之间的关联定义了实现这些类的对象之间导航路径的需要。我们如何实现一个关联取决于关联的多重性和通讯是单向的还是双向的。信息系统分析与设计InformationSystemAnalysisandDesign10/41类图-7一对一关联在Wheels系统中没有一对一关联图8.3表示了在School类和SchoolLibrary类之间一对一的关联School对象需要能传送消息给SchoolLibrary对象，但反之则不能。这种消息传送的方向被称为关联的导航性。一个方向的关联被称为单向的导航的方向被箭头所表示。两个方向的导航性既可以用关联两端的箭头表示，又可以都不标注箭头来表示。然而，没有箭头也能意味着导航性还没有规定，如在分析模型中的例子。因此，标识箭头更清楚些。信息系统分析与设计InformationSystemAnalysisandDesign11/41类图-8一对一关联（续）为了实现一对一关联，School有一个属性library来用于存放它需要通讯的SchoolLibrary对象的对象标识符（或者称为一个指针或引用）。在双向关联中，每个类都需要存放一个对于对方的引用。如果在School和SchoolLibrary之间的关联是双向的，School需要存放对SchoolLibrary的引用，而SchoolLibrary也需要存放一个对School的引用。图8.4表示了在界面类MaintainBikeUI和Bike类之间的单向关联。信息系统分析与设计InformationSystemAnalysisandDesign12/41类图-9一对多关联一个MaintainBikeUI类的对象必须同Bike类的对象通讯，反之不然。一个MaintainBikeUI对象必须能发送消息到一个以上的:Bike对象，有时，它发送消息到一个由bike#确定的特定:Bike对象，有时发送到同一品牌的:Bikes对象，有时发送到所有的:Bikes对象。为了做到这点，:MaintainBikeUI必须知道所有Bike对象的标识符。它能利用一个简单的数组来存放这些标识符；然而，它需要操作来管理这个数组：要易于增加、删除、以及发现自行车的标识符。问题是这不是一个UI类的任务，并且其它的类（例如，IssueBikeUI类）也需要同样的功能，它们也需要一组:Bike标识符，以及操作它的代码。因此，产生一个专门存放并操作这些标识符的类将更加有效，这个类被称作集合类（collectionclass）。信息系统分析与设计InformationSystemAnalysisandDesign13/41类图-10一对多关联（续1）图8.5表示了一个集合类BikeList，其能根据bike#来发现一个特定的自行车，增加，以及删除自行车，等等。MaintainBikeUI同BikeList有一对一的关联。因此，这一关联能通过在MaintainBikeUI中对BikeList的引用来实现。一个:BikeList将包含一个:Bike引用的表-bike[0..599]（在数组中我们从0开始）。访问一个特定的:Bike将实现如下：:MaintainBikeUI发送一个getBike(bike#)消息到:BikeList，要求它找到一辆编号为bike#的自行车；:BikeList将在:Bikes的表中反复查找看哪个自行车的编号同输入的编号相匹配；找到的:Bike的标识符（identifier）然后返回给:MaintainBikeUI，然后，:MaintainBikeUI就能直接发送消息到这个:Bike。这个重复过程被建模，如图8.6中的序列图所示。信息系统分析与设计InformationSystemAnalysisandDesign14/41类图-11一对多关联（续2）换言之，如果一个对象需要发送一个消息，它必须知道如何使消息到达消息接受者。这意味着它必须知道接受对象的标识符。它能按各种不同的方法来做此事：通过在关联中的直接联接。例如在图8.3中，School的属性library保存了SchoolLibrary对象的对象标识符，这在School对象和一个SchoolLibrary对象之间建立了直接的联接。调用对象能够通过另一个已经同目标对象建立联接的对象来发送目标对象的标识符。在图8.6中，属性bikeID被设置成所要求的自行车的对象标识符，即，:BikeList找到:Bike的标识符，然后将它返回到:MaintainBikeUI。一个对象标识符可以作为参数由构造器传递给它所产生的对象。例如，在图8.11中，界面对象:IssueBikeUI产生一个新的Payment对象，并将相关的Customer对象的标识符作为参数传递给它。:IssueBikeUI也产生一个新的Hire对象，并将Bike和Customer对象引用传递给它。信息系统分析与设计InformationSystemAnalysisandDesign15/41类图-12设计属性和操作属性定义在设计中，我们需要制定每个属性的定义。一个属性定义的UML形式是：visibilityname:type-expression=initial-value例如，#deposit:Integer=0操作的定义.我们也需要定义操作操作可以有参数和返回值一个操作定义的UML形式是：visibilityname(parameterlist):return-type例如，+findBike(bike#:Integer):Bike信息系统分析与设计InformationSystemAnalysisandDesign16/41类图-13设计操作在详细设计阶段，我们更加关注操作或更加严格考虑实现操作operations的方法。我们设计将要使用的算法。我们的决策可以用一个活动图来记录，或描述过程的技术（结构化英语、决策表、决策树）之一来记录，或者用契约描述来记录。一般，当设计（以及在编程时），保持算法尽可能简洁是最好的。当你想利用最时髦的技术时，考虑一下系统以后维护的难度有助于你的选择决策。信息系统分析与设计InformationSystemAnalysisandDesign17/41交互图-1分析vs.设计在分析中，我们使用交互图的目的是要发现一组对象在用例场景所表示的过程中是如何协作的。在这个阶段，我们仍忽略了类的职责的确定，以及类的操作和对象之间消息的内涵。在设计中，我们关注编码；我们利用交互图主要是给出在程序运行时将会发生什么的一个抽象的视图。为了实现这点，我们需要增加更多的细节到模型中：如何规定对象的产生和删除如何定义条件性行为和重复性行为如何在不同的使用多对象和包的细节层次上使用交互图然而，记住序列图最大的诱惑是其简洁性，因此要慎重地使用额外的标注。如果你在一个序列图中表示了太多的细节，则它失去了它主要的吸引力。信息系统分析与设计InformationSystemAnalysisandDesign18/41交互图-2对象产生和删除在一个用例场景的执行过程中，对象没有必要是固定的；新的对象能被产生，已有的对象能被删除。在一个交互中被产生或删除的对象被称短暂transient对象。不是出现在图形的顶部，这种对象的图标在其产生的地方出现。对象析构的表示是在该对象