第7章在需求分析阶段的应用.pptVIP

第7章 在需求分析阶段的应用 7.1 AutoWeight系统 1）系统介绍 P107上部 2）天车称重的工作过程 a. 天车的工作过程 b. 仪表的工作过程 P108，中部 7.2 用户需求 1）找出与AutoWeight系统相关的人员（P109上部） 2）确定这些人员的要求（P109图7.3） 7.3 需求分析与描述 1）对每位人员的每条需求，逐条分析，以判断： a. 确定功能性需求、非功能性需求； b. 确定软件系统的需求、不属于软件系统的需求； c. 确定目前要实现的、将来再实现的。 分析过程见P110-111 分析结果见P111表7.1 2）用例分析 a. 确定系统的边界 看哪些设备或部件属于系统的一部份： i. 称重仪表不属于 所以边界定在计算机系统和数据库服务器之间。 ii.数据库服务器也不属于 所以边界定在计算机系统和数据库服务器之间。 b. 找出系统的执行者 如果把“称重仪表”看作系统外部的执行者，那么，“操作工人”、“传感器”就不再是系统的执行者了。 “数据库服务器”也是外部执行者。 最后得到执行者：见P113中下部。 c. 系统的用例 有了系统的边界、系统的外部执行者，就可以分析这些执行者如何与系统进行交互，以便找出用例。 第1步：列出每位执行者、及其活动、目的；（P113底部） 第2步：根据这些活动、目的，列出系统的用例。（P114上部） 3）画用例模型图 a. 画图（P114图7.4） b. 简单的描述 i. 执行者的活动、目的（P114底部-P115上部） ii. 用例的简单描述（P115上部） 4）用例描述 对每个用例都要有描述，“记录称重数据”用例的描述见P116图7.5。 其中，事件流涉及到多个执行者。 5）非功能性需求分析 a. 按报告的形式列出（见P117图7.6） b. 给出每条非功能性分析的含义（见P115中下部） 7.4 领域模型分析 即建立领域模型，绘制系统顺序图，进一步描述系统的静态结构、行为和执行的结果。 1）领域概念 a. 找出所有的名词、动词（包括动词词组） b. 名词为领域模型中的类、或类的属性；动词为类的方法、或类之间的关联。 见P118表7.2、7.3。 2）确定类的步骤 步骤1：对所有名词进行分类，删除重复项。 步骤2：从系统边界内来确定类：物理上的“物体”、概念上的“对象”，即思维、感受或动作所作用的物质或精神体。如“键”这种名词要拿掉。 步骤3：对同义词进行分组，从每个同义词的分组中选择一个最合适的作为类。如分析重量、重量记录，输入的数据、称重数据等等。 不能使用对象之间角色所形成的名词，如：系统存储称重数据，“存储”功能不能作为类；又如教授指导学生，教授的角色是“导师”，不能以“导师”为类。 步骤4：区分类和属性。 步骤5：要找出域类（domain class），避免使用实现类（implementtation class） 步骤6：不要使用关联类。如：student、section类的关联类：waitlist不列出。 得出类，见P119表7.4。 步骤7：检查是否有遗漏的类。如“天车”曾出现过，应该是一个类。得到概念类图7.7。 步骤8：对所有的类进行分组，即泛化。 最后得到泛化后的类图，见P120图7.8。 3）确定属性的办法： a. 已发现的名词。 b. 凭借设计者的社会常识，如操作员的姓名、身份证号等。 c. 外部执行者系统如何表示类似信息？如：远程数据库系统对称重数据的存储，涉及到物质名称、单位、重量等。 4）类间的关联 (1) 所有的动词是最可能的类间关系； (2) 逐个分析每个类的活动，从中确定类与类之间的关联； (3)使用辅助工具：关联矩阵： (4) 画类-类之间的关联关系图； a.从Driver类入手，如P121图7.9 b.再从ActualMeter入手，见图7.10 c.然后从WeightData入手，见图7.11 4）增加属性和方法 a. 名词作为类的属性； 动词、类间关联作为类的方法。 见P122底部 b. 给出领域模型图，包括：类间关联、类的主要属性和方法。见P123图7.14 7.5 工作流程分析