软件工程2-8.建模示例.ppt

软件工程第五章 面向对象分析与设计 5.1 需求获取 5.2 面向对象分析 5.3 面向对象设计 5.4 系统设计 5.5 对象设计 5.1 需求获取 需求获取的目标是确定用户“需要”什么样的软件产品，就是说，新的软件必须能够做什么。 没有专业的系统分析人员，用户很难了解到需要开发什么相关信息和功能；另一方面，没有与用户的交流，系统分析人员也很难弄清客户真正需要什么。 发现用户需求的过程称为需求获取。一旦提出了最初的需求，进一步推敲、细化和扩充的过程称为分析。 需求获取的第一步是理解应用领域，即目标软件的应用环境。如银行、电信公司、书店等。 一旦系统分析人员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入了解应用领域，回过头来推敲业务模型。 这种迭代过程直到双方对需求的理解达到共识。 需求获取的结果是导出用户可理解的系统规格说明。 开发用户需求的典型过程 5.1.1 与用户交互 1) 需求的来源 不同类型应用能从人员处获取需求的比例: 所谓限制，是指受客观物理规律的限制。如导弹制导系统更多地受物理运动定律的限制，而非人的决策。视频游戏的大部分需求依赖人，因为它是一个相像出来的产品。 应用受到的限制越少，能从人们那里获得的需求比例越大。 2) 识别利益相关者（stakeholder） 对项目承担风险和享有利益的人即为利益相关者。他们是应用的“客户”。如公司高层、项目经理、最终用户、系统开发人员等。 不同利益相关者之间的利益冲突会导致需求不一致。如果需求冲突不能调和，项目就会陷入困境，最后往往会被取消。 即使所有利益相关者的需求一致，也可能由于实现代价高昂，需求不能得到完全满足。 3) 了解客户的需求 一般客户希望得到一个产品，他们需要系统开发人员帮助，明确自己的需要。 例如，有一个客户愿望框架：“Encounter是一个角色扮演游戏，它能模拟被扮演人物的全部或部分活动，应对人们具有相当吸引力。” 完整的客户要求应当记录在需求文档的“概述”部分。但需求中还有一些问题需要由系统分析人员与客户商量，以明确这些需求。 例如游戏是否只允许玩家扮演一个角色还是可以同时控制多个人物？当两个人相遇时会发生什么事情？游戏是否可以联网对战等。 4) 访谈和文档记录 大部分需求获取是人与人沟通的活动，这些活动经过精心组织，以准确获得最好的效果。 准备和访谈客户的过程如下： 访谈之前 列出访谈的“客户”对象，并划分客户优先级 最有可能决定项目成败的人 安排访谈日程，设定开始和结束时间 系统开发人员至少有两人参加访谈 准备录音设备 访谈中 注意倾听 不要处于被动状态：启发和鼓励 理解客户的需要并探索要求 采用用例？或数据流图？状态图？ 记录全部访谈内容 安排补充会议 访谈之后 根据标准模版撰写软件需求规格说明（SRS），打客户需求草稿 通过电子邮件征求客户意见 对于不同类型的应用，用例方法是一种获取和表达需求的有效方法。 某些需求需要通过数据流图或状态图与用户沟通。 5.1.2 描述客户需求 需求可以看成是应用与应用的外部代理（如用户）之间的交互。可利用用例作为表达工具。 用例描述了系统外的参与者（Actor）与应用之间的交互情况。主要注重用户对系统的看法。 描述客户需求的过程如下： 1) 标识参与者 标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。 2) 标识场景 用场景描述目标系统典型功能的活动细节，并与用户沟通，加深开发人员对应用领域的理解。 3) 标识用例 当双方确定了一组场景后，开发人员从该场景抽象出一组用例，描述所有可能的情况。用例表达了系统的范围。 4) 求精用例 细化每一个用例。引入带有出错处理或带有异常处理的用例，描述系统的行为，保证需求的描述是完全的。 5) 标识用例之间的关系 描述用例之间的依赖关系，提取相同功能，建立用例模型。 6) 标识非功能需求 包括系统性能上的约束、文档、使用资源、安全性和质量等需求。 需求获取期间，开发人员需要访问一些不同的信息资源： 客户提供的与应用领域相关的文档和手册。 将被目标系统替代的遗留系统的技术文档。 最终用户和客户本人。 以“图书管理系统”为例，首先标识参与者： Librarian 图书管理员：创建、修改、删除借阅者信息；添加、编辑、删除馆藏图书信息；添加、编辑、删除流通图书信息。 Borrower 借阅者：借阅、预约、归还流通图书，以及取消图书预约。 流通图书（Book）是指某种馆藏图书（Title）的某一流通中的复本。例如“数学分析教程第二册”的 5 本馆藏复本中的第 3 本。 识别用例： BorrowBook：借阅流通图书 ReturnBook：返还流通图书