图书馆管理面向对象分析与设计课件

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

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

2、有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入了解应用领域，回过头来推敲业务模型。 这种迭代过程直到双方对需求的理解达到共识。 需求获取的结果是导出用户可理解的系统规格说明。,3,软件工程,开发用户需求的典型过程,4,软件工程,5.1.1 与用户交互,1) 需求的来源 不同类型应用能从人员处获取需求的比例:,5,软件工程,所谓限制，是指受客观物理规律的限制。如导弹制导系统更多地受物理运动定律的限制，而非人的决策。视频游戏的大部分需求依赖人，因为它是一个相像出来的产品。 应用受到的限制越少，能从人们那里获得的需求比例越大。 2) 识别利益相关者

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

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

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

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

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

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

9、系。 Librarian还与MaintainBorrowerInfo、Main- tainTitleInfo、 MaintainBookInfo交互。,15,软件工程,Librarian还需要与用例Login交互。 画出用例图,16,软件工程,用例BorrowBook的规格说明 1.1 前置条件：在此用例开始之前，Librarian必须登录到系统中。,Librarian,Login,MaintainTitleInfo,MaintainBookInfo,MaintainBorrowerInfo,17,软件工程,18,软件工程,19,软件工程,1.2 后置条件：如果此用例执行成功，在系统中建立并存

10、储一条借阅记录，必须时需要删除预约记录。如果执行不成功，系统状态不变。 1.3 事件流 基本流 当Borrower借阅馆藏图书，且Librarian选择“借书”，则此用例启动。 提供馆藏图书和借阅者信息。 检索馆藏图书（E-1）。 确定该馆藏图书的物理复本（流通图书）是否在架（E-2）。,20,软件工程,检索借阅者（E-3）。 将流通图书交给借阅者。 创建并存储借阅记录。 删除预约记录。 候补流 E-1：若该种图书不存在，系统显示提示信息，用例终止。 E-2：若该种图书都已解出，系统显示提示信息，用例终止。 E-3：系统中不存在该借阅者，系统显示提示信息，用例终止。,21,软件工程,5.1.3

11、 与用户沟通的其他工具,1) 数据流图 某些需求可以很自然地表述为处理元素之间的数据流。 顶层图即为系统与外部实体的交互。 2) 状态图 有时把应用看作是几个状态下的应用，而在某一确定时刻的应用始终明确地处于某个状态中。这种状态划分对理解系统比较有益。 状态的具体内容到实现阶段会有确切的定义。,22,软件工程,借书过程的数据流图,外部实体、数据流和数据存储都为候选对象,23,软件工程,还书过程的数据流图,系统与外部实体、系统与数据存储的交互，构成系统的接口。相应数据流构成接口数据。,检验错误,还书信息,图书,24,软件工程,馆藏图书（对象）的状态图,25,软件工程,图书管理员借书操作的状态图,

12、26,软件工程,27,软件工程,28,软件工程,29,软件工程,活动图（Activity Diagram）,一个活动是一个在状态机内部正在进行的非原子（即可中断的）动作。 活动图是一种特殊的状态图。其中， 大多数的或者全部的状态都是动作状态或者活动状态 大多数的或者全部的迁移都是由于源状态中活动的完成而被触发的。 一个活动图着重于描述计算过程或工作流的顺序的和并发的执行步骤。,30,软件工程,活动图的两种使用方式,31,软件工程,泳道（swimlanes）,活动图描述发生了什么，但没有说明该活动由谁来完成。泳道描述了这种关系。 泳道用矩形框表示，属于某个泳道的活动放在该矩形框内，将对象名放在矩

13、形框的顶部，表示泳道中的活动由该对象负责。 两个泳道中活动的各自由不同的对象负责，活动之间控制权的转移表明对象之间的协作关系。 所以泳道可以将活动图的逻辑描述与顺序图、写作图的责任描述结合起来。,32,软件工程,5.1.4 草拟用户界面和其他接口,建立初始用户界面，是原型方法的一种，目的是快速与客户沟通。 客户通常在看到应用的图形用户界面（GUI）才能相像到这个应用未来的样子。 开发用户界面的步骤如下： 1) 了解客户 深入了解最终用户的想法。根据用户的层次，提供多种用户界面。 知识和经验层次：计算机素养、系统经验、使用类似应用的经验、教育水平、阅读水平、打字技能等。,33,软件工程,用户的生

14、理特征：年龄、性别、左右手习惯、生理障碍等。 2) 理解业务功能 根据应用的整体意图来理解特定用户界面的目的。功能界面出现的顺序通常可以反映用户处理日常业务的方式。 用户的任务和工作特征：应用的使用方式、使用频率、雇员的流动率、任务的重要性、任务的重复性、对培训的期望、工作类型等。 用户的心理特征：工作态度、能动性、认知方式等。,34,软件工程,3) 理解优秀界面设计的原则 目的是加强视觉效果。 确保应用的各个界面之间风格的一致性：习惯、步骤、视觉和感觉、位置等。 揣测用户通常开始操作的地点 导航系统尽量简捷 使用分组和分层来强调重要性级别 4) 选择合适的窗口类型 五类窗口： 属性窗口：展示

15、实体的属性 对话窗口：完成特定任务或命令的信息,35,软件工程,消息窗口：提供信息 面板窗口：展示一组控件 弹出窗口：突出显示信息 5) 制作系统菜单 为用户提供一个稳定的、易于理解的使用环境，可以方便地搜寻需要的选项。 提供一个主菜单 显示所有相关选择（仅局限于此） 将菜单结构与应用要完成的任务对应起来 尽量减少菜单的级数,36,软件工程,6) 选择合适的基于设备的控件 提供给用户，向系统发送指示的实际手段，包括鼠标、键盘、触摸屏、绘图板、轨迹球、麦克风等。 7) 选择合适的基于界面的控件 即出现在屏幕上的符号。用户通过这些符号向系统提出他的输入和操作意图，包括图标、按钮、复选框、单选框等。

16、 8) 组织和安排窗口布局 多窗口的排列规则，如平铺、层叠等。 9) 选择合适的颜色 尽量保持简捷和低调。颜色需要和谐。,37,软件工程,5.2 面向对象分析,分析建模的目的是对来自客户的需求形式化。形式化可以导致新的洞察和发现需求错误。 1999年NASA损失了一颗价值数亿美元的气象卫星，据调查是因为列在度量表中的控制数据出了问题。不巧的是这个缺陷在灾难发生几天之前才刚发现，如果在需求分析阶段就被识别出来就可避免损失了。 避免需求错误或遗漏的第一道防线就是把所有的需求细化，建立分析模型。,38,软件工程,分析模型由三个独立的模型构成：由用例和场景表示的功能模型；用类和对象表示的分析对象模型；由状态图和顺序图表示的动态模型。 在需求获取阶段得到的用例模型就是功能模型。据此可导出分析对象模型和动态模型。 需要注意，这些模型代表的是来自客户的概念，而非实际软件类或实际构件。如数据库、子系统、会话管理器、网络等，不应出现在分析模型中，因为这些概念仅与实现相关。 分析中的类可以看作是高层