图书馆管理面向对象分析与设计解读

《图书馆管理面向对象分析与设计解读》由会员分享，可在线阅读，更多相关《图书馆管理面向对象分析与设计解读（165页珍藏版）》请在金锄头文库上搜索。

1、软件工程 第五章 面向对象分析与设计 5.1 5.1 需求获取需求获取 5.2 5.2 面向对象分析面向对象分析 5.3 5.3 面向对象设计面向对象设计 5.4 5.4 系统设计系统设计 5.5 5.5 对象设计对象设计 1 5.1 需求获取 n需求获取的目标是确定用户“需要”什么样的软 件产品，就是说，新的软件必须能够做什么。 n没有专业的系统分析人员，用户很难了解到需 要开发什么相关信息和功能；另一方面，没有 与用户的交流，系统分析人员也很难弄清客户 真正需要什么。 n发现用户需求的过程称为需求获取。一旦提出 了最初的需求，进一步推敲、细化和扩充的过 程称为分析。 2 n需求获取的第一步

2、是理解应用领域，即目标软 件的应用环境。如银行、电信公司、书店等。 n一旦系统分析人员对该领域有了充分了解，就 可以建立一个业务模型，描述用户的业务过程 ，确定用户的初始需求。然后通过迭代，更深 入了解应用领域，回过头来推敲业务模型。 n这种迭代过程直到双方对需求的理解达到共识 。 n需求获取的结果是导出用户可理解的系统规格 说明。 3 开发用户需求的典型过程 1. 识别用户需求 2. 访谈用户代表 识别各种需要与要求 使用工具帮助表达用户需求 绘制GUI草图 确定硬件环境 3. 用标准文档格式撰写客户需求 4. 核查用户需求 请用户评审 用户批准后 5. 构建详细需求（分析建模） 4 5.1

3、.1 与用户交互 1) 需求的来源 n不同类型应用能从人员处获取需求的比例: 相对低的 相对高的从人群获取需求的大概百分比 应 用 的 类 型 高度受限的 不受限制的 导弹制导系统 航班控制系统 公司财务系统增强版 制造控制系统 公司财务系统 Encounter视频游戏 军事战略决策支持系统 5 n所谓限制，是指受客观物理规律的限制。如导 弹制导系统更多地受物理运动定律的限制，而 非人的决策。视频游戏的大部分需求依赖人， 因为它是一个相像出来的产品。 n应用受到的限制越少，能从人们那里获得的需 求比例越大。 2) 识别利益相关者（stakeholder） n对项目承担风险和享有利益的人即为利益

4、相关 者。他们是应用的“客户”。如公司高层、项目 经理、最终用户、系统开发人员等。 6 n不同利益相关者之间的利益冲突会导致需求不 一致。如果需求冲突不能调和，项目就会陷入 困境，最后往往会被取消。 n即使所有利益相关者的需求一致，也可能由于 实现代价高昂，需求不能得到完全满足。 3) 了解客户的需求 n一般客户希望得到一个产品，他们需要系统开 发人员帮助，明确自己的需要。 n例如，有一个客户愿望框架：“Encounter是一 个角色扮演游戏，它能模拟被扮演人物的全部 或部分活动，应对人们具有相当吸引力。” 7 n完整的客户要求应当记录在需求文档的“概述” 部分。但需求中还有一些问题需要由系统

5、分析 人员与客户商量，以明确这些需求。 n例如游戏是否只允许玩家扮演一个角色还是可 以同时控制多个人物？当两个人相遇时会发生 什么事情？游戏是否可以联网对战等。 4) 访谈和文档记录 n大部分需求获取是人与人沟通的活动，这些活 动经过精心组织，以准确获得最好的效果。 n准备和访谈客户的过程如下： 8 访谈之前 n 列出访谈的“客户”对象，并划分客户优先级 最有可能决定项目成败的人 n 安排访谈日程，设定开始和结束时间 系统开发人员至少有两人参加访谈 准备录音设备 访谈中 n 注意倾听 不要处于被动状态：启发和鼓励 理解客户的需要并探索要求 采用用例？或数据流图？状态图？ 9 记录全部访谈内容

6、n 安排补充会议 访谈之后 n 根据标准模版撰写软件需求规格说明（SRS）， 打客户需求草稿 n 通过电子邮件征求客户意见 n对于不同类型的应用，用例方法是一种获取和 表达需求的有效方法。 n某些需求需要通过数据流图或状态图与用户沟 通。 10 5.1.2 描述客户需求 n需求可以看成是应用与应用的外部代理（如用户 ）之间的交互。可利用用例作为表达工具。 n用例描述了系统外的参与者（Actor）与应用之 间的交互情况。主要注重用户对系统的看法。 n描述客户需求的过程如下： 1) 标识参与者 标识目标系统将支持的不同类 型的用户，可以是人、事件或其他系统。 2) 标识场景 用场景描述目标系统典型

7、功能的 活动细节，并与用户沟通，加深开发人员对应 用领域的理解。 11 3) 标识用例 当双方确定了一组场景后，开发人 员从该场景抽象出一组用例，描述所有可能的 情况。用力表达了系统的范围。 4) 求精用例 细化每一个用例。引入带有出错处 理或带有异常处理的用例，描述系统的行为， 保证需求的描述是完全的。 5) 标识用例之间的关系 描述用例之间的依赖关 系，提取相同功能，建立用例模型。 6) 标识非功能需求 包括系统性能上的约束、文 档、使用资源、安全性和质量等需求。 12 n需求获取期间，开发人员需要访问一些不同的信 息资源： 客户提供的与应用领域相关的文档和手册。 将被目标系统替代的遗留系

8、统的技术文档。 最终用户和客户本人。 n以“图书管理系统”为例，首先标识参与者： Librarian 图书管理员：创建、修改、删除借 阅者信息；添加、编辑、删除馆藏图书信息； 添加、编辑、删除流通图书信息。 Borrower 借阅者：借阅、预约、归还流通图 书，以及取消图书预约。 13 n流通图书（Book）是指某种馆藏图书（Title）的 某一流通中的复本。例如“数学分析教程第二册” 的 5 本馆藏复本中的第 3 本。 n识别用例： BorrowBook：借阅流通图书 ReturnBook：返还流通图书 RecerveTitle：预约某种馆藏图书 CancelReservation：取消预约

9、 MaintainBorrowerInfo：维护借阅者信息，包 括创建、修改、取消借阅者账户 MaintainTitleInfo：维护馆藏图书信息，包 14 括添加、修改、删除馆藏图书信息 MaintainBookInfo：维护流通图书信息，包括 添加、修改、删除流通图书信息 Login：登录 n识别参与者与用例之间的关系（场景） Borrower执行BorrowBook、ReturnBook、 ReserveTitle、CancelReservation等用例。 Borrower是通过Librarian完成上述用例的工作 。则Borrower与Librarian存在依赖关系。 Librari

10、an还与MaintainBorrowerInfo、Main- tainTitleInfo、 MaintainBookInfo交互。 15 Librarian还需要与用例Login交互。 n画出用例图 Borrower Librarian BorrowBook ReturnBook ReserveTitle CancelReservation Day Year ButtonBoundary 。 n每个接口要指定一个名字，以区分不同的接口。 接口的名字就是类的名字，用字符串表示。 n构件的接口有两种类型： n导入接口（import interface）：访问服务的构 件使用导入接口； n导出接口（

11、export interface）：由提供操作的 构件提供。 132 部署图（Deployment Diagram） n部署图展现了在软件过程中存在的运行处理 节点以及其中的构件的配置。 n部署图给出了体系结构的静态实施视图。它 描述系统硬件的物理拓扑结构（包括网络布 局和构件在网络上的位置），以及在此结构 上执行的软件（即运行时软构件在节点中的 分布情况）。 n它与构件图相关，通常一个节点包含一个或 多个构件。 133 部署图的事例 Registration Database Dorm Library Main Building 主排课 数据库库 宿舍 图书馆 注册 134 （1）将子系统映

12、射到构件和处理器 选择硬件配置和平台 许多系统运行在网络上。使用多台计算机，可 以满足高性能计算需求和多个互联的分布式用 户需求。确保将子系统分布到多台计算机上， 设计基础设施来支持子系统之间的通信。 选择硬件配置包括选择虚拟机，系统将在其上 运行。虚拟机包括操作系统和所需软件构件， 如数据库管理系统和通信包。构件提供的功能 越多，所需的开发工作量越少。 虚拟机的选择还受客户约束和成本限制影响。 135 例如，在车辆路程规划系统中，规划子系统和 路由子系统运行在两个不同的节点上。硬件分 配的情况如下： 将对象和子系统分配到节点上 :OnBoardComputer Routing subsyst

13、em :WebServer Planning subsystem 将路由子系统分配到 车载计算机上 规划子系统分配到基于 Web的网络服务器上 136 将对象和功能分配到各个节点上时，为了在节 点之间传输数据，需对新加入的对象和子系统 进行标识。 例如，在车辆路程规划系统中，路由子系统和 规划子系统共享了行程类、目的地类、交差口 类、路段类和方向类的实例，它们需采用一些 通信协议，可通过无线调制解调器进行通信， 可创建一个通信子系统来支持该通信。 旅途规划的内容分布在路由和规划子系统中， 在路由子系统中创建路段代理类和行程代理类 为规划子系统中的路段和行程提供代理服务。 137 当司机需要重新

14、规划行程路线时，行程类对象 会向通信子系统发出请求，检索规划子系统中 有关路段的信息。最后，通信子系统将一个完 整的旅途线路从规划子系统转移到路由子系统 中。 通信子系统 消息 连接 规划子系统 规划服务 行 程 路 口 方 向 目的地 行程段 路由子系统 线路助手 位 置 行程代理 路段代理 138 将某一子系统分配到硬件节点上，意味着能够 将功能和处理能力分配到最需要这些子系统的 地方。随之而来的问题就是子系统中的数据存 储、数据转移、数据复制和同步数据等问题。 n持久性数据的生存周期要长于系统的一次执行周 期。例如，在图书管理系统中将借阅者借阅的图 书信息和借阅者信息记入借阅记录并存储在

15、数据 库相应文件中，该文件以后可以再次打开。 n数据在系统中的存储位置和存储方式将会影响到 （2）标识并存储持久性数据 139 系统的分解。特定数据库管理系统的选择也会影 响全局控制策略和并发管理。 n例如，在车辆路程规划系统中，把当前行程信息 存储在磁盘文件中是最简单、最有效的。为此， 在系统中添加行程文件存储子系统和映射数据库 存储子系统。 n前者负责将旅程路线信息存储到车载计算机的文 件中。该文件只支持整个旅程数据的快速存储和 载入，以在车辆故障恢复时使用。后者负责将地 图和旅程数据存储到规划子系统的数据库中。该 子系统支持多个并发的的司机和规划代理。 140 标识持久性对象。候选的持久

16、性数据是从分析过 程中标识出的实体类对象，以及边界类对象。通 常可以在系统关闭后，检查所有必须保存的类， 以标识出必须长久保存的持久性对象。这里的系 统关闭可以是受控关闭，也可以是系统崩溃。 行程文件存储 子系统 通信子系统 映射数据库存储 子系统 路由子系统规划子系统 141 选择存储管理策略。决定如何存储这些持久性对 象的决策常常受到如下非功能属性的制约： 对象能否快速检索出来 是否必须执行复杂的查询来检索这些对象 这些对象是否需要大量的内存和磁盘空间 n在多用户系统中，不同参与者对不同的功能和数 据可有不同的访问权限。 n例如，一个普通用户参与者可能仅能访问其所创 建的数据，而一个系统管理员参与者对系统数据 （3）提供访问控制 142 和所有用户数据具有无限的访问权限。 n在需求获取和分析建模过程中，将不同用例关联 到不同的参与者；在系统设计过程中，定义共享 对象、参与者通过访问控制进行访问的权限、数 据加密的方式等。 n例如，在车辆行程规划系统中，在同一数据库中 存储地图信