图书管理系统-OOD-设计模式精要.pptVIP

* 分析办理借书用例的业务流程 细化办理借书业务流程： 图书管理员点击“图书借阅”启动该用例； 输入借阅证编号。 输入图书登录号。 点击“借阅” 显示当前借阅信息（书名,ISBN，借阅时间，应归还时间） 办理借阅的步骤可细化为： 登记借阅信息； 修改图书状态 修改书目在馆数量 * 识别其中的边界类、控制类和实体类 识别其中的边界类、控制类和实体类 * 办理借阅用例 边界类 控制类 实体类 根据分析及时序图，完善类的设计 借阅信息类： 加上登记借阅信息、读取借阅图书信息方法 图书信息类： 加：图书状态属性，修改图书状态方法 书目类： 加馆藏册数、在馆数量两个属性，修改在馆数量方法 借阅者类 加入借阅者类型属性 借阅约束类： 加入读取借阅册数方法 * 完善后的类图 * 课后任务(Task After Class) 各组对本组项目中的主要系统用例运用BCE模式，完善类图。 要求： 1、至少每人做一个用例 2、主要用例完成后系统的最基本的功能能够实现。 比如图书管理系统，至少要完成图书的增删查改、借阅者的增删查改，办理借书、办理还书 * ☆ 迪米特法则，又叫最少知识原则，就是说，一个对象应当对其他对象有尽可能少的了解。 ξ 11.1 迪米特法则的各种表述① 只与你直接的朋友们通信；② 不要跟“陌生人”说话；③ 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。 迪米特法则可以简单说成：talk only to your immediate friends。?对于面向OOD来说，又被解释为下面几种方式：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。 迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。 * * * 3 Sept. 2008 Confidential ? 3 Sept. 2007 ? Neusoft Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 3 Sept. 2008 Confidential 图书管理系统-设计模式 * 计科系 段恩泽 email:duanenze@126.com * 主要内容(Contents) BEC模式 目前我们所得到的类图 * * BEC模式(BEC Pattern) 软件设计的最终结果要完成以下模型的设计： 静态结构设计 类设计 包设计 接口设计 动态结构设计（行为和交互建模） 对象如何进行交互的 关注 设计原则(Design Principles) 1、“开－闭”原则：对扩展开放，对修改关闭 2、里氏代换原则：一个软件实体如果使用的是一个基类的话，那么一定适用于其子类 3、依赖倒转原则：要依赖于抽象，不要依赖于具体 4、接口隔离原则：使用多个专门的接口比使用单一的总接口要好 5、合成/聚合原则：要尽量使用合成/聚合，尽量不要使用继承 6、迪米特法则：一个对象应该对其它对象有尽可能少的了解 * 抽象，信息隐蔽，模块独立，高内聚，低耦合 * 还记得“春晓”吧？ 设计1 设计2 设计3 设计4 设计5 同样的需求，可以采取不同的设计方式来完成。 设计的好坏会影响系统的可重用性、可维护性和可扩展性。 设计原则(Design Principles) * 设计模式(Design Pattern) 设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。 提高代码复用 提高可维护性 按照良好的设计原则进行设计 ？ ？ 使用设计模式 * BEC模式(BEC Pattern) 先看一下图书管理系统的登录 * 验证通过 验证未通过 * 一种设计(One Solution) 将用户名和密码的验证，放在登录界面的“进入系统”按钮中进行。 * 存在的问题(Prolems) 问题1：扩展性差。目前这个系统只有一个图书馆工作人员使用，因此用户名和密码都是admin，这样验证可行，但是如果以后维护期间，需要增加工作人员或者增加学生、教师等使用角色，系统的扩展性就受到了限制。 问题2：重用性不好。并且不同的角色需要写入不同的