皇家汽车服务站系统的需求来自客户的自然语言.PPT

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 通过将上述图6.18所示的设计方案与原始需求定义进行对比, 发现的若干问题及改进措施(得到图6.20): (1). 可以增加一个message(消息)类. (2). 从业务关系与逻辑上, 应该将燃料(Fuel)与库存(Inventory)类连接起来. (Inventory类须追踪燃料数量,数量下降到一定值时, 将启动另外的燃料订购系统) (3). 应该删除Account类, 并将其唯一属性添加到Customer类中(因为按业务处理及语义逻辑上应该这样归类). (4). 应该从燃料类中删除价格这个属性,并将其加入到Refuel类中(目的:使Fuel类只追踪数量,而Refuel类处理与特定销售相关的加仑数和价格使类的功能单一化). (5). 等等问题. * Fig 6.20 Second cut at Royal Service Station design. * 将图6.20所示的设计方案进一步与原始需求定义进行对比, 发现的问题及改进措施(得到图6.21): (1). Station Manager类与其他类皆无关联,删除之. (2). 增加新的类Service Station, 以处理对休眠帐户的跟踪. (3). 在每个类中加入操作(方法), 以完成具体的功能. 例如: Bill类需要有一个操作来计算总价,另一个操作来计算 购买税(交易税) Parking Space(停车位)类需要一个操作来指示是否某 个车位可用. (4). 加入基数. (5). 等等问题. * Fig 6.21 Third and final cut at Royal Service Station design * 备注：图6.21所示的并非是真正意义上的最终方案，它只是 本阶段的“最终方案”。应该还要结合其他需求文档或设计 文档，将该设计方案加以综合考虑以图进一步改进，例如： (1). 考虑或兼顾用例图的各种功能，需要进一步调整该类图，使之满足实现用例所示功能的方便性和系统效率等诸多因素要求。(部分非功能性需求) (2). 兼顾包图所示的模块或构件间的依赖性等设计初衷，进一步调整类图中的属性与方法的基本分布。(体现部分系统设计的思想) 6.4 Representing OO Designs in the UMLFinal Cut at Royal Service Station Design * Chapter 6 Considering Object ? suggestion for using class diagram（使用类图的建议） A: don’t try to use all symbols B: drawing class diagram in a right way at difference stages analysis stage: conceptual class diagram design stage: illustrated class diagram implementation stage: implemental class diagram C: only draw critical diagrams D: consider the model itself when you meet trouble in two ways: X: reality Y: the size of diagram/elements * Chapter 6 Considering Object 3. Other UML Diagrams ? class description template (类描述模板) （见6.4.3） A: meaning: lay the groundwork for the program design(类的层次, 操作描述, 各种状态等等) B: private interface: (a mechanism ) C: publi