餐馆系统的分析

1、餐馆系统的餐馆系统的分析分析领域建模n领域模型：显示最重要的业务概念和它们之间的关系的类图n领域模型用关联和泛化显示了这些概念之间的关系。领域模型通常不包含操作领域模型通常不包含操作n有时很难决定是应该将一个特殊的信息作为一个类还是作为一个属性包含在领域模型中规定关联的重数，每个预定是由一个顾客进行的，这个人的姓名和电话由系统记录，但是每个顾客可以进行多个预定CustomerReservationMakes1*namephoneNumber顾客和预定建模CustomerReservationMakes1*namephoneNumbercoversdatetimeTableplaces1* Re

2、servations for the same table must not overlap.包含预定特性的领域模型CustomerMakes1*coversReservationWalk-inBookingdatetimeplacesTable*1 Bookings for the same table must not phoneNumber包含未预约的领域模型领域模型的正确性n要证明一个模型的正确性或者即使是一个模型优于另一个模型，要更困难一些n建立领域模型的目的是确定一组对象，他们能够以有效地支持整个系统必须交付的功能的方式进行交互。因此，要评价领域模型中可供选

3、择的方式，可以从实现这一点的程度来进行n而且不能通过孤立地检查领域模型而简单地评定，还必须通过观察领域模型中类的实例之间的交互实际上是如何支持需要的功能，考虑模型实际上表达了什么一 分析的目的 n用例描述的形式所陈述的需求是定义系统外部行为非常有价值的工具，但是它们对系统的内部结构，或如何提出一组交互的对象来支持所要求的功能并没有给出任何指导n可以把分析的任务描述为是构造一个模型分析的任务描述为是构造一个模型，来说明这些交互的对象如何能够交付用例中规定的行为n分析活动的典型输入是用例和领域模型输入是用例和领域模型n用例描述通过用户与系统的交互来表示从外部看到的系统功能n领域模型定义了重要业务概

4、念之间的关系n实化：对每个用例，应当开发一个高层交互，来说明如何通过适当类的实例的交互，产生所需要的系统行为n领域模型中的类构成用例实化的起点n分析模型：源于领域模型的一个类图，但并入了为使其能够支持用例中规定的功能而增加和修改的内容n用交互图(协作图和顺序图)定义用例实化n协作图描述关联角色和类元角色。为了阐明消息的先后次序，必须使用层次编号方案n顺序图清晰地说明了各种事件的发生次序分析和设计的区别n分析最重要的任务分析最重要的任务是产生用例实化，并以此为基础，使领域模型进化为一个更全面的类图n由于分析和设计自始至终可以使用相同的技术和表示法，因此要给出一个清晰的界限作为分析结束而设计开始的

5、形式定义就非常困难n分析的重点集中在系统需求上，而在设计中重点转移到了要产生的软件的结构上用例实化n系统消息：从外部用户到系统的消息n领域模型常常并不包括一个适合于接收系统消息的类n统一过程将边界对象定义为接收来自用户的消息的对象，所以，使用边界对象好像是一个合理的选择。n但是，边界对象属于系统架构中的表示层：如果试图分析应用层中对象的行为，使用边界构造型是一种误导n一个用例中可能涉及若干系统消息，检查用户以合理的次序发送这些正确的消息、协调系统产生的响应都是必要的。这正是一个控制对象适合承担的责任:Staff:BookingSystem一个系统消息display(date)存取预约n细化上图

6、，以说明系统实际上如何检索和显示用户请求的数据。n检索相关日期的预约和更新显示器以展现这些预约来替换已有预约，这需要某些简单的控制以确保这些动作能够以正确的次序发生。n控制这个用例流程的责任已经分配给了预约系统对象，因此要由它来初始化这两个动作n必须决定预约系统对象如何能够得到所需要的预约。这可以通过向负责维护餐馆全部预约的对象，发送一个请求给定日期的所有预约的消息来实现n领域模型中的预约类(Booking)负责存储的是单个预约的信息，但是我们需要一种方法重复与系统所知道的所有预约相接触n有必要定义一个新的类来维护预约集合n在应用领域中，进行的预约可以看作是餐馆自身的一个属性。因此，一个可能的

7、策略是引入一个表示餐馆的新类，让这个类负责维护到所有预约的链接，并在请求时查找和返回特定的预约n下图说明了系统做了什么来响应来自员工成员的请求。过程消息调用具有嵌套控制流的特征n发送一个消息更新当前的显示。根据系统的架构，这个消息应该从预约系统发送到表示层中的某个类，请求更新显示。updateDisplay消息对应了一个将这传达到表示层的方法:Staff:BookingSystem检索预约以供显示display(date):RestaurantgetBookings(date)Return BookingsupdateDisplay()检索预约细节n要决定餐馆对象如何识别返回的预约。逻辑上，需

8、要获得每个预约对象的日期，并返回与来自参与者的消息中提供的日期相匹配的预约。ngetDate消息前面的星号是一个重数，标志这个消息在这个交互中一般会多次发送给不同的预约对象n对于交互的每件事都没有详细说明。例如没有指定用于返回检索到的预约的集合的数据结构，也没有指定在预约对象集合上的反复操作进行的方式。这个细节层面会留到详细设计阶段:Staff:BookingSystem显示预约：基本事件路径的实化display(date):RestaurantgetBookings(date)return BookingsupdateDisplay():Booking*getDate()return dat

9、e细化领域模型n开发“显示预约”用例的实化的过程确定了两个新的类和许多在类的实例之间传递的消息n可以把这些信息加入到领域模型，因而开始了将领域模型变成一个更全面的类图的细化过程，这个类图用文档记录了这个分析活动的结果n下图包括了新类和两个新的关联：n从餐馆类到预约类关联，反映了规定餐馆类负责登记系统已知的所有预约细节的事实n预约系统和预约类之间的关联，记录当前显示在屏幕上的是哪些预约的责任n在顺序图中出现的消息要作为属于各种类的操作再次出现在类在顺序图中出现的消息要作为属于各种类的操作再次出现在类图中图中。n发送一个消息的目的通常是为了调用接收该消息对象中的一个方法，而这是通过在接收消息的类中

10、包含一个操作表示的。为了清晰起见，给操作和调用它的消息以相同的名字n只要从一个对象向另一个对象发送消息，那么类图中就记录有一个关联，可以作为该消息的通信信道n领域模型可以用文档记录下对现实世界应用重要的关系，但是这些关系并不是用来支持设计中的消息传递的。在很多情况下不需要实现这样的关联，或者只需要在消息发送的方向上给以支持BookingSystemdatedisplay()updateDisplay()RestaurantgetBookings()Bookingcoversdatetime1*currentgetDate()分析模型中的一些类记录新预约n假定创建一个新预约所需的详细资料是由用户

11、界面的某些适当的元素收集的n例如一个对话框，而用例的逻辑结构可以由一个来自用户的单个系统消息表示，该消息请求创建一个新预约，并将需要的数据作为参数传递n必须决定应该将创建新预约对象的责任分配给什么对象n仅有的两个可行的选择是预约系统对象和餐馆对象。n因为餐馆对象已经具有维护系统已知的全部预约对象集合的责任，所以看来将创建新预约的责任也指定给它能够维持高度的内聚性:Receptionist:BookingSystem记录预定：初始交互make Reservation(details):Restaurantmake Reservation(details)updateDisplay()创建新对象n

12、在创建一个新预定对象之前，必须定位表示预定是对之做出的餐桌和顾客对象。根据领域模型，每个预定对象被恰好链接到一个餐桌对象和一个顾客对象n假定从用户传来的数据中包含有这些对象的文本标识符，例如餐桌号码以及顾客的姓名和电话号码。这些数据应该由用户在指定新预定的详细信息时输入。但是在创建预定之前，需要定位由这些数据标识的对象，以便在创建新预定时可以获得适当的对象引用n假定参数tno、name以及phone可以从伴随makeReservation消息传递的未详细说明的details中提取创建一个新预定make Reservation(details)t:Tablec:=getCustomer(name

13、,phone):Restaurantc:CustomergetTable(tno)return tReservation(date,t,c):Reservation记录未预约顾客的预约n未预约顾客的预约在一个顾客没有提前预定而进入餐馆用餐时创建。它们在系统中记录的方式和预定相同，但是因为它们不和顾客关联，所以在创建时需要较少的信息取消预约n要取消一个预约，用户必须首先选择要取消的预约，然后取消它，并在最后系统提示时确认取消n下图通过一个来自用户的selectBooking消息实现选择需要的预约n为了查找需要的预约对象，必须检查每个当前显示的预约。由于预约系统对象已经有了维护这组预约的责任，所以

14、能够直接在这些预约上遍历。用户界面检查所有当前预约的详细信息以查看哪个和选择标准匹配n角色名用来区分选定的预约和当前的预约。角色名不是为一个单独的对象命名，而是描述在交互中对象能够充当的角色:Staff:BookingSystem取消一个预约selectBooking(id)*getDetails()updateDisplay()/Selected:Booking/Current:Bookingcancel()confirm()return yes细化领域模型n新责任：记住哪个是所选预约n这个责任已经分配给预约系统对象：因为预约系统对象已经负责维护当前显示的预约的集合，所以这与它已有的责任结合

15、得很紧密n当前可以显示多个预约，但至多只能选择其中一个。这些关联还对系统施加了更进一步的约束，也就是选中的预约必须是当前显示的预约中的一个BookingSystemBooking0.1*current记录选中预约selected更新预约n用户首先选择需要的预约，接着向系统表明顾客已经到达n用户很可能选择了一个未预约预约而不是一个预定，然后试图记录到达时间。n如果未预约类(WalkIn)也不支持setArrivalTime操作，但是发给了它这个消息，那么将出现一个运行时错误n第一种可能性需要运行时检查以确定选中的预约属于什么子类n一个更好的方法是为Booking继承层次中的所有类都提供setAr

16、rivalTime操作，但是将记录到达时间的特定责任只赋给那些此举有意义的类:Staff:BookingSystem记录一个顾客的到达selectBooking(id)*getDetails()updateDisplay()/Selected:Booking/Current:BookingrecordArrival()setArrivalTime(now)setArrivalTime()ReservationWalk-inBookingarrivalTimesetArrivalTime()在类层次中分配责任调换餐桌n如果设想调换是通过拖放一个预约完成的，用户将产生一系列相应于各种鼠标事件的消息

17、，这看来应该反映在用例的实化中n然而，让应用层的类承担像鼠标这样的特殊用户界面设备中细节的义务并不是一个好的想法。n在分析层面，这个用例最好用一个单一的系统消息建模，该消息提供一个新餐桌的标识符来与当前选中的预约相关联。这个方法保持了该用例的基本功能，又可以为后面用户界面的设计留下灵活性完成分析模型n本章只是详细考虑了每个用例的基本事件路径。可以应用完全相同的原则实化可选和例外事件路径，给模型增加一些新的东西n一般而言，将每个事件路径实化显示在一个不同的顺序图中会更清楚ReservationWalk-inarrivalTimesetArrivalTime()餐馆预约系统的分析类模型Bookin

18、gSystemdatecance()display()makeReservation()recordArrival()updateDisplay()selectBooking()RestaurantgetBookings()getCustomer()getTable()makeReservation()BookingcoversdatetimegetDate()getDetails()setTable()setArrivalTime()TablenumberplacesCustomernamephoneNumber*1Makes*1 Bookings for the same table must not overlap.1*0.1selectedcurrentMust be one of the current bookings.小结n分析可以定义为用对象模型表示应用领域和系统需求的活动n基本的分析技术是产生用例实化，用例实化示范了用例指定的功能如何通过一组交互的对象来实现n实化可以用UML定义的交互图之一的形式，即协作图或者顺序图，形