《软件工程原理》讲义-05

《《软件工程原理》讲义-05》由会员分享，可在线阅读，更多相关《《软件工程原理》讲义-05（148页珍藏版）》请在金锄头文库上搜索。

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

2、电信公司、书店等。 一旦系统分析人员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入了解应用领域，回过头来推敲业务模型。 这种迭代过程直到双方对需求的理解达到共识。 需求获取的结果是导出用户可理解的系统规格说明。,软件工程,148-4,开发用户需求的典型过程,软件工程,148-5,5.1.1 与用户交互,1) 需求的来源 不同类型应用能从人员处获取需求的比例:,相对低的,相对高的,从人群获取需求的大概百分比,应用的类型,高度受限的,不受限制的,导弹制导系统,航班控制系统,公司财务系统增强版,制造控制系统,公司财务系统,视频游戏,软件工程

3、,148-6,所谓限制，是指受客观物理规律的限制。如导弹制导系统更多地受物理运动定律的限制，而非人的决策。视频游戏的大部分需求依赖人，因为它是一个想象出来的产品。 应用受到的限制越少，能从人们那里获得的需求比例越大。 2) 识别利益相关者（stakeholder） 对项目承担风险和享有利益的人即为利益相关者。他们是应用的“客户”。如公司高层、项目经理、最终用户、系统开发人员等。,软件工程,148-7,不同利益相关者之间的利益冲突会导致需求不一致。如果需求冲突不能调和，项目就会陷入困境，最后往往会被取消。 即使所有利益相关者的需求一致，也可能由于实现代价高昂，需求不能得到完全满足。 3) 了解客

4、户的需求 一般客户希望得到一个产品，他们需要系统开发人员帮助，明确自己的需要。 例如，有一个客户愿望框架：“Encounter是一个角色扮演游戏，它能模拟被扮演人物的全部或部分活动，应对人们具有相当吸引力。”,软件工程,148-8,完整的客户要求应当记录在需求文档的“概述”部分。但需求中还有一些问题需要由系统分析人员与客户商量，以明确这些需求。 例如游戏是否只允许玩家扮演一个角色还是可以同时控制多个人物？当两个人相遇时会发生什么事情？游戏是否可以联网对战等。 4) 访谈和文档记录 大部分需求获取是人与人沟通的活动，这些活动经过精心组织，以准确获得最好的效果。 准备和访谈客户的过程如下：,软件工

5、程,148-9,访谈之前 列出访谈的“客户”对象，并划分客户优先级 最有可能决定项目成败的人 安排访谈日程，设定开始和结束时间 系统开发人员至少有两人参加访谈 准备录音设备 访谈中 注意倾听 不要处于被动状态：启发和鼓励 理解客户的需要并探索要求 采用用例？或数据流图？状态图？,软件工程,148-10,记录全部访谈内容 安排补充会议 访谈之后 根据标准模版撰写软件需求规格说明（SRS），打客户需求草稿 通过电子邮件征求客户意见对于不同类型的应用，用例方法是一种获取和表达需求的有效方法。 某些需求需要通过数据流图或状态图与用户沟通。,软件工程,148-11,5.1.2 描述客户需求,需求可以看成

6、是应用与应用的外部代理（如用户）之间的交互。可利用用例作为表达工具。 用例描述了系统外的参与者（Actor）与应用之间的交互情况。主要注重用户对系统的看法。 描述客户需求的过程如下： 1) 标识参与者 标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。 2) 标识场景 用场景描述目标系统典型功能的活动细节，并与用户沟通，加深开发人员对应用领域的理解。,软件工程,148-12,3) 标识用例 当双方确定了一组场景后，开发人员从该场景抽象出一组用例，描述所有可能的情况。用例表达了系统的范围。 4) 求精用例 细化每一个用例。引入带有出错处理或带有异常处理的用例，描述系统的行为，保证需求

7、的描述是完全的。 5) 标识用例之间的关系 描述用例之间的依赖关系，提取相同功能，建立用例模型。 6) 标识非功能需求 包括系统性能上的约束、文档、使用资源、安全性和质量等需求。,软件工程,148-13,需求获取期间，开发人员需要访问一些不同的信息资源： 客户提供的与应用领域相关的文档和手册。 将被目标系统替代的遗留系统的技术文档。 最终用户和客户本人。 以“图书管理系统”为例，首先标识参与者： Librarian 图书管理员：创建、修改、删除读者信息；添加、编辑、删除书目信息；添加、编辑、删除图书信息。 Borrower 读者：借阅、预约、归还图书，以及取消书目预约。,软件工程,148-14

8、,图书（Book）是指某种书目（Title）的某一流通中的复本。例如“数学分析教程第二册”的 5 本馆藏复本中的第 3 本。 识别用例： BorrowBook：借阅图书 ReturnBook：返还图书 RecerveTitle：预约某种书目 CancelReservation：取消预约 MaintainBorrowerInfo：维护读者信息，包括创建、修改、取消读者账户 MaintainTitleInfo：维护书目信息，包括添加,软件工程,148-15,修改、删除书目信息 MaintainBookInfo：维护图书信息，包括添加、修改、删除图书信息 Login：登录 识别参与者与用例之间的关系

9、（场景） Borrower执行BorrowBook、ReturnBook、ReserveTitle、CancelReservation等用例。 Borrower是通过Librarian完成上述用例的工作。则Borrower与Librarian存在依赖关系。 Librarian还与MaintainBorrowerInfo、Main- tainTitleInfo、 MaintainBookInfo交互。,软件工程,148-16,Librarian还需要与用例Login交互。 画出用例图,软件工程,148-17,用例BorrowBook的规格说明 1.1 前置条件：在此用例开始之前，Libraria

10、n必须登录到系统中。,Librarian,Login,MaintainTitleInfo,MaintainBookInfo,MaintainBorrowerInfo,软件工程,148-18,1.2 后置条件：如果此用例执行成功，在系统中建立并存储一条借阅记录，必须时需要删除预约记录。如果执行不成功，系统状态不变。 1.3 事件流 基本流 当Borrower借阅某种书目，且Librarian选择“借书”，则此用例启动。 提供书目和读者信息。 检索书目（E-1）。 确定该书目的物理复本（图书）是否在架上（E-2）。,软件工程,148-19,检索读者（E-3）。 将图书交给读者。 创建并存储借阅记录

11、。 删除预约记录。 候补流 E-1：若该种书目不存在，系统显示提示信息，用例终止。 E-2：若该种图书都已借出，系统显示提示信息，用例终止。 E-3：系统中不存在该读者，系统显示提示信息，用例终止。,软件工程,148-20,5.1.3 与用户沟通的其他工具,1) 数据流图 某些需求可以很自然地表述为处理元素之间的数据流。 顶层图即为系统与外部实体的交互。 2) 状态图 有时把应用看作是几个状态下的应用，而在某一确定时刻的应用始终明确地处于某个状态中。这种状态划分对理解系统比较有益。 状态的具体内容到实现阶段会有确切的定义。,软件工程,148-21,借书过程的数据流图,外部实体、数据流和数据存储

12、都为候选对象,软件工程,148-22,还书过程的数据流图,系统与外部实体、系统与数据存储的交互，构成系统的接口。相应数据流构成接口数据。,检验错误,还书信息,图书,软件工程,148-23,图书（对象）的状态图,软件工程,148-24,图书管理员借书操作的状态图,软件工程,148-25,5.1.4 草拟用户界面和其他接口,建立初始用户界面，是原型方法的一种，目的是快速与客户沟通。 客户通常在看到应用的图形用户界面（GUI）才能相像到这个应用未来的样子。 开发用户界面的步骤如下： 1) 了解客户 深入了解最终用户的想法。根据用户的层次，提供多种用户界面。 知识和经验层次：计算机素养、系统经验、使用

13、类似应用的经验、教育水平、阅读水平、打字技能等。,软件工程,148-26,用户的生理特征：年龄、性别、左右手习惯、生理障碍等。 2) 理解业务功能 根据应用的整体意图来理解特定用户界面的目的。功能界面出现的顺序通常可以反映用户处理日常业务的方式。 用户的任务和工作特征：应用的使用方式、使用频率、雇员的流动率、任务的重要性、任务的重复性、对培训的期望、工作类型等。 用户的心理特征：工作态度、能动性、认知方式等。,软件工程,148-27,软件工程,148-28,3) 理解优秀界面设计的原则 目的是加强视觉效果。 确保应用的各个界面之间风格的一致性：习惯、步骤、视觉和感觉、位置等。 揣测用户通常开始

14、操作的地点 导航系统尽量简捷 使用分组和分层来强调重要性级别 4) 选择合适的窗口类型 五类窗口： 属性窗口：展示实体的属性 对话窗口：完成特定任务或命令的信息,软件工程,148-29,消息窗口：提供信息 面板窗口：展示一组控件 弹出窗口：突出显示信息 5) 制作系统菜单 为用户提供一个稳定的、易于理解的使用环境，可以方便地搜寻需要的选项。 提供一个主菜单 显示所有相关选择（仅局限于此） 将菜单结构与应用要完成的任务对应起来 尽量减少菜单的级数,软件工程,148-30,6) 选择合适的基于设备的控件 提供给用户，向系统发送指示的实际手段，包括鼠标、键盘、触摸屏、绘图板、轨迹球、麦克风等。 7)

15、 选择合适的基于界面的控件 即出现在屏幕上的符号。用户通过这些符号向系统提出他的输入和操作意图，包括图标、按钮、复选框、单选框等。 8) 组织和安排窗口布局 多窗口的排列规则，如平铺、层叠等。 9) 选择合适的颜色 尽量保持简捷和低调。颜色需要和谐。,软件工程,148-31,5.2 面向对象分析,分析建模的目的是对来自客户的需求形式化。形式化可以导致新的洞察和发现需求错误。 1999年NASA损失了一颗价值数亿美元的气象卫星，据调查是因为列在度量表中的控制数据出了问题。不巧的是这个缺陷在灾难发生几天之前才刚发现，如果在需求分析阶段就被识别出来就可避免损失了。 避免需求错误或遗漏的第一道防线就是

16、把所有的需求细化，建立分析模型。,软件工程,148-32,分析模型由三个独立的模型构成：由用例和场景表示的功能模型；用类和对象表示的分析对象模型；由状态图和顺序图表示的动态模型。 在需求获取阶段得到的用例模型就是功能模型。据此可导出分析对象模型和动态模型。 需要注意，这些模型代表的是来自客户的概念，而非实际软件类或实际构件。如数据库、子系统、会话管理器、网络等，不应出现在分析模型中，因为这些概念仅与实现相关。 分析中的类可以看作是高层抽象，在后续阶段将使用更多的细节实现。,软件工程,148-33,在分析对象模型中有实体对象、边界对象和控制对象等三种类型。 实体对象表示系统将跟踪的持久信息；边界对象表示参与者与系统之间的交互（接口）；控制对象负责用例的实现 。,软件工程,148-34,使用实体对象、边界对象和控制对象等概念对系统建模时，常常需要提供一些简单的启发式规则来指导开发人员使用这些概念，可以使用相应的类来跟踪。 这些概念源自需求获取阶段。,