第7章GRASP设计实例.docx
《第7章GRASP设计实例.docx》由会员分享，可在线阅读，更多相关《第7章GRASP设计实例.docx（19页珍藏版）》请在冰豆网上搜索。
第7章GRASP设计实例
第七章GRASP设计实例习题
第一题.下面是一个“图书管理信息系统”的用户需求陈述，请按陈述后的小题作答：
读者来图书馆借书，可能先查询馆中的图书信息。
查询可以按书名、作者、图书编号、关键字查询。
如果查到则记下书号，交给流通组工作人员，等待办理借书手续。
如果该书已经被全部借出，可做预定登记，等待有书时被通知。
如果图书馆没有该书的记录，可进行缺书登记。
办理借书手续时先要出示借阅证，没有图书证则去图书馆办公室申办图书证。
如果借书数量超出规定，则不继续借阅。
借书时流通组工作人员登记图书证编号、图书编号、借出时间和应还书时间。
当读者还书时，流通组工作人员根据图书证编号找到读者的借书信息，察看是否超期。
如果已经超期，则进行超期处罚。
如果图书有破损、丢失，则进行破损处罚。
登记还书信息，做还书处理，同时查看是否有预定登记,如果有则发出到书通知。
图书采购人员采购图书时，要注意合理采购。
如果有缺书登记，则随时进行采购。
采购到货后，编目人员进行验收、编目、上架、录入图书信息、发到书通知。
如果图书丢失或旧书淘汰，则将该书从书库中清除，即图书注销。
以上是图书管理系统的基本需求。
经过与图书馆工作人员反复交流，他们提出了下列建议：
a.当图书借阅的图书到期时，希望能够提前用短信或电子邮件方式提示读者。
b.读者希望能够实现网上查询和预定图书。
c.应用系统的各种参数设置最好是灵活的，由系统管理人员根据需要设定。
例如，借阅期的上限，还书提示的时间，预定图书的保持时间等参数。
问题：
1、请你从用户需求陈述中识别出“网上图书销售系统”的参与者和基本用例，并对其进行说明（用例说明应包括编号、名称和简要说明），画出用例图。
2、选出一至两个基本用例，基于所选用例完成：
a）其中一个用例的详述风格的用例说明、活动图、系统顺序图和类图。
b）至少两个系统操作的时序图（须注明所采用的模式）。
3、根据第二题中的类图，用UML类图描述读者、图书、借阅信息的数据模型
4、描述适配器模式和其解决方案，并举例
参考答案：
1请你从用户需求陈述中识别出“网上图书销售系统”的参与者和基本用例，并对其进行说明（用例说明应包括编号、名称和简要说明），画出用例图。
答：
识别出的参与者有：
读者，流通组工作人员，办公室工作人员，编目人员，采购员，系统维护人员。
识别出的用例有：
借书、还书、缺书登记、预定、取消预定、查询、网上查询、通知、读者管理、图书管理、处罚、采购、编目、登陆、网上登陆、系统维护、图书催还。
System
O
X
读者
网上查询
O
A
系统维护人员
2选出一至两个基本用例，基于所选用例完成：
a）其中一个用例的详述风格的用例说明、活动图、系统顺序图和类图
参考答案：
用例名称：
借书
用例描述：
当读者前来图书馆借书时，流通组工作人员启动该用例，该用例检查读者的有效性和图书是否在库,实现读者借书活动。
前置条件：
流通组工作人员要先执行登陆用例，才能启动借书用例。
读者号存在
图书号存在
图书在库
后续条件：
记录了借阅信息
图书库存减少
创建借还书记录。
基本路径：
1.读者前来借书，读者提供读者号和图书号
2.流通组管理员输入读者读者号
3.流通组管理员输入读者图书号
4.验证读者有效/图书在库存中
5.流通组管理员将书借出
扩展路径：
2a读者号不存在，显示读者无效
2b.读者号存在，借书数量已经超限，显示数量超限
3c.读者号存在，图书号无效，显示图书不存在
4d.图书号，读者有效，图书不在库存，转预定处理
用例活动图:
系统顺序图
[morebooktolend]
顺序图:
altCombinedFragmentl
[else]optCombinedFragment2/
[over==true]
<>
7:
GoOverTheTopExcetpion（）:
void
:
ProcessBorrowJFrame
p:
ProcessBorrowHandler
reader:
Reader
book:
Book
1:
borrowBook（booklD,readerlD）:
void
l►rh
2:
book:
=getBook（）
reader:
=getReader（）
4-JModify…■-
5:
borrowedRecord:
=getBorrowedRecord（）
opt
rrowedRecord==null]
6
be
<>
BeokBorrowedRecord（book,reader）:
void:
7:
addRecord（book,reader）:
void
8:
reduceStorageNumber（book）:
void
类图
3根据第二题中的类图，用
UML类图描述读者、图书、借阅信息的数据模型
4.描述适配器模式和其解决方案，并举例。
问题：
如何解决不相容的接口问题，或者如何为具有不同接口的类似构件提供稳定的接口？
解决方案：
通过中介适配器对象，将构件的原来的接口转换为其它接口
如POS系统中，为解决多种税金的计算问题，采用多态模式加适配器模式，为每一种税金都定义一个适配器类,
并让他们实现相同的接口
第二题:
餐馆系统
1.非正式的需求
要开发的意图是，通过改进顾客预订和分配餐桌的过程，支持一家餐馆的日常经营。
'现状：
这家餐馆当前采用一个手工预约系统，使用的是保存在一个大文件夹中的手工预约单。
手工预约单的每一行对应餐馆中一张特定的餐桌。
每个预约中记录有“餐具”的数目，或者预期进餐者的数目，这样就能够分配一个大小适当的餐桌。
这家餐馆在晚间提供三次餐点，称为“简餐”、“正餐”和“夜点”时
段。
但这些时段无需严格遵守，可以预约跨多个时段的时间。
最后，每个预约中要记录联系人的姓名和电话。
为了记录各种事情，要在预约单上加一个注释。
当一行用餐者到来并在他们的餐桌就餐时，就划掉相应的预约登记。
如果他们就座的不是他们预约的餐桌，就画一个箭头从最初预约的餐桌指向新的餐桌。
如果顾客打电话取消预约，并不能从表中真正地擦除，而是做一个预约已经取消的注释。
其他的信息，比如到什么时候餐桌必需空出来，也可以写在预约单上。
如果有空闲的餐桌，用餐者当然也可以不提前预约就进餐馆用餐，这就称为“未预约的顾客（walk-in）”，并
在预约单中作为预约登记以表示餐桌的占用，但不记录顾客的姓名或电话。
滸需求：
开发一个预约单的自动化版本。
新系统应该和现有的预约单显示同样的信息，并且有大致相同的格式，使餐馆员工易于转换到新系统。
当记录了新的预约时，或者对已有的预约进行修改时，应该立即更新显示，使餐馆员工在工作时总能使用可获得的最新信息。
系统必需易于记录餐馆营业时发生的有意义的事情，例如顾客的到来。
系统的操作应当尽可能是直接操作屏幕上显示的数据。
例如，可以简单地将预约拖动到屏幕上一个适当的位置以改变一个预约的时间或者分配的餐桌。
2.用户界面原型
预约系统主屏幕的一个原型
BookingSystem
BookingDate:
10Feb2009
18:
3019:
3020:
3021:
3022:
3023:
3024
1
2
MsBlue123456789
Covers:
3
3
Mr.zhang
123452349Covers:
2
4
MsBlack432456789
Covers:
4
5
Walk-in
Covers:
2
3.用例建模
定义一次迭代，完成基本需求：
餐馆在营业时记录预约和更新预约单信息的能力
（1）确定系统边界、寻找参与者和目标：
-接待员（Receptionist）在预约系统中，接电话并更新预约系统中存储的信息。
-领班（HeadWaiter）在餐馆营业中，记录顾客的到来，以及为了适应不可预料的经营需要从一行用餐者从一个餐桌移到另一个餐桌。
（2）确定用例
-UC1:
记录预约
-UC2:
取消预约
-UC3:
记录到达
-UC4:
调换餐桌
-描述用例
UC1:
记录预约
范围：
餐馆系统
级别：
用户目标
主要参与者：
接待员
涉众及其关注点：
-接待员：
希望能够准确、快速地输入
-领班：
希望能够看到所有预约信息
-公司：
希望能够提高效率
前置条件：
接待员经过身份验证
成功保证：
显示预约信息，记录预约信息
主成功场景：
1.接待员输入要预约的日期；
2.系统显示该日的预约；
3.有一张合适的餐桌可以使用：
接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号；
4.系统记录并显示该预约。
扩展：
3a.没有可用的餐桌，用例中止
3b.餐桌过小
1.发出警告信息询问用户是否想要继续预约。
2.如果回答“否”，中止预约。
3.如果回答“是”，预约将被输入，并附有一个警告标识。
发生频率：
经常发生
未决问题：
UC2:
取消预约
主成功场景：
1.接待员选择要求的预约；
2.接待员取消该预约；
3.系统询问接待员确认取消；
4.接待员回答“是”，系统记录取消并更新显示
UC3:
记录到达
范围:
记录达到
级别:
用户目标
主要参与者：
领班
涉众及其关注点：
-领班：
希望能够快速查看预约信息，记录到达
-公司：
希望能够提高效率
前置条件：
领班经过身份验证
成功保证：
记录到达主成功场景：
1.侍者领班输入当前日期；
2.系统显示当天的预约；
3.侍者领班确认一个选定的预约是否已经到达；
4.系统对此进行记录并更新显示器，将顾客标记为已到达。
扩展：
3a.没有提前预约
1.侍者领班输入预约时间、用餐人数和餐桌号，创建一个未预约登记;
2.系统显示并记录新预约。
发生频率：
经常发生未决问题：
UC4:
调换餐桌
主成功场景：
1.侍者领班选取需要的预约；
2.侍者领班改变该预约的餐桌分配;
3.系统记录改变并更新显示；
-如果存在明显的冗余，单独独立出来形成一个公共功能。
如“显示预约”，然后利用关系一一包含
-“记录未预约顾客”作为一个单独的用例更好一些？
a）为没有预约就来就餐的人触发
“记录未预约顾
个适当地餐桌
b）与记录到达类似，只是记录的细节上不同，细节上有过多的重叠。
他们之间有一种关系：
客”用例只是在“记录到达”的某些情况下被执行，也就是该顾客没有记录的预约，但有空闲着，并且顾客还想在餐馆用餐时才被执行。
利用关系一一扩展
（3）用例图
0
X
Recepionist
HeadWaiter
booking
<>
<>
Cancelbooking
<>
Displaybooking
t—1"
<>
Tabletransfer
<>
Recordarrival
<>
walk-in
4.领域模型
A
5.层次架构
显示层
应用层
1
存储层
6.用例实现
（1）“显示预约”
-系统顺序图:
:
System
A
:
Staff
-顺序图:
o
X
:
Staff
display。
:
BookingSystem
getBookings（）
:
Restaurant
getDate（）
:
Booking
returnDate
returnbookings
（2）记录预约
updateDisplay（）
（1）取消预约
（2）更新预约
（3）调换餐桌
自己做
7.粗略类图:
升级会员 