第5讲需求分析与验证.

需求分析与验证教材P117第5章先思考几个问题？需求获取涉及的UML图形？（回顾）需求获取过程模型？（回顾）2019/12/182阅读书的第五章回答下列问题？需求分析使用的UML图形有哪些？需求分析的过程模型包括哪些活动？如何确定需求的优先级？10分钟2019/12/183第五章需求分析与验证5.1分析模型的表示顺序图、通信图、状态图5.2需求分析的过程模型5.3需求优先级分析5.4用例分析5.5利用快速原型辅助需求分析5.6评审分析模型5.7需求规约5.8需求验证2019/12/184第五章需求分析与验证5.1分析模型的表示5.1.1顺序图5.1.2通信图5.1.3状态图2019/12/1855.1分析模型的表示在用例模型已成的情形下为何还要构建分析模型？2019/12/186分析模型的表示构建分析模型的两点理由：⑴分析模型比用例模型更加结构化、更加清晰直观。⑵分析模型是用例模型与软件设计模型之间的“桥梁”。2019/12/187分析模型的表示参与者：需求工程师。软件架构师、利益相关方，以及项目软件经理、质量保证工程师。输入与输出：输入制品与需求获取活动的输出制品相同。在所有这些输入制品中，用例模型最重要。输出制品主要是软件需求的分析模型。该模型是需求规约的主要组成部分，同时也是后续软件设计、构造和测试活动的工作基础。2019/12/1885.1分析模型的表示2019/12/189需求分析顺序图类图活动图状态图通信图顺序图分类：交互图包括顺序图和通信图两种。前者强调消息传递的时间序，后者突出交换消息的对象之间的合作关系。虽然它们各有侧重，但从语义上讲基本等价，可从一种图自动转换为另一种图。2019/12/1810顺序图交互图的作用：业务分析及需求分析人员？软件设计及实现人员？测试人员？课程注册管理系统中“制订选课计划”用例的顺序图2019/12/1811图5.1课程注册管理系统中“制订选课计划”用例的顺序图2019/12/1812ScheduleManager1:addCourseOfferingsTimeConflictChecker1.2:checkConflictSchedule1.3:*[对所有无冲突的课程设置]addCourseOfferings获取当前计划中已有的所有课程设置1.2.1:getCourseOfferings1.2.2:*[对所有待添加的课程设置][对每门已有的课程设置]checkTimeConflictBetween2CourseOfferingsDataPersistenceService1.3.1:insertCourseOffering1.4:*[对所有无冲突的课程设置]addStudent1.4.1:insert如果计划已确认，则报错并返回1.1:create5.1.2通信图通信图是顺序图的另一种表现形式。如，图5.5是与图5.1所示的顺序图等价的通信图（除注解外）2019/12/18132019/12/1814图5.5课程注册管理系统中“制订选课计划”用例的通信图ScheduleManager1:addCourseOfferingsTimeConflictChecker1.1:create1.2:checkConflictSchedule1.2.1:getCourseOfferings1.2.2*[对所有待添加的课程设置][对每门已有的课程设置]:checkTimeConflictBetween2CourseOfferings1.3*[对所有无冲突的课程设置]:addCourseOfferingsDataPersistenceService1.3.1:insertCourseOffering1.4*[对所有无冲突的课程设置]:addStudent1.4.1:insert（三）顺序图与通信图之间的选取顺序图和通信图互为派生视图，建模者往往面临选用顺序图还是通信图的困惑。建议读者依次考虑以下规则（前面的规则优先级较高）：⑴当需要强调消息传递的时间序时采用顺序图；当需要强调对象之间的交互、协作关系时采用通信图。⑵当刻画用例的动作序列时，采用顺序图；当刻画软件内部等某项功能的实现构想时，采用通信图。⑶在业务分析和需求建模阶段，优先考虑顺序图；在设计和实现阶段，优先考虑通信图。2019/12/18155.1.3状态图定义：状态图描述一个实体在事件刺激下的反应式动态行为。构成：状态、事件以及响应动作。实体可以是对象，软件系统（或其子部分）或其中一个软构件，整个大系统。作用：状态图可用来描述实体的行为。2019/12/1816图5.6课程注册管理系统中“课程设置”类的典型对象的状态图2019/12/1817初始开放关闭取消学生注册[注册人数最大值]学生注册[注册人数=最大值]取消课程设置取消课程设置取消课程设置[当前时间到达第二周星期一凌晨2:00][当前时间尚未到达第二周星期一凌晨2:00]5.2需求分析的过程模型如何展开需求分析？应该遵循何种过程模型来展开需求分析？需求分析的主要任务是：建立比用例模型更完整、更精细的分析模型，以期获得对软件需求的更深入理解，提高软件需求的质量，为软件设计奠定更坚实的基础。2019/12/1818需求分析的过程模型用例驱动的需求分析过程的主要活动如下⑴需求优先级分析。⑵用例分析。⑶分析模型评审。⑷为辅助需求分析而构建快速原型。这些活动可按序组织为需求分析工作流。图5.12需求分析工作流2019/12/1819需求优先级分析用例分析构建快速原型分析模型评审5.3需求优先级分析主要任务：确定每项需求优先级。三种不同的诠释方法：⑴基于实现紧迫度的优先级(其他两个略)高优先级必须实现的需求项；中优先级最终必须实现的需求项，至下一软件版本再实现；低优先级“锦上添花”式的需求项，趋于完美。2019/12/1820表5.1家庭保安系统的需求优先级序号用例/质量需求项名称优先级说明1开关机及复位处理高必须完整实现2系统配置高同上3传感器监测高同上4日志查询中应该实现其中大部分功能5性能：Req-Performance-001~002高对产品可接受度的影响最大6可靠性：Req-Reliability-001~003高同上7安全性：Req-Authentication-001和Req-Authorization-001高同上8可配置性：Req-Config-001高同上9安全性：Req-Audit-001中对产品可接受度有一定影响10易用性：Req-EasyUse-001~002中同上11可扩展性：Req-Extend-001中同上12可伸缩性：Req-Scalability-001中同上13兼容性：Req-Compatibility-001低可以不予实现，但其实现可以增强产品可接受度14本地化与国际化：Req-Intl-001低同上2019/12/1821用例分析用例分析的子活动归纳如下：⑴精化领域概念模型；⑵设置分析类；⑶构思分析类之间协作关系；⑷导出分析类图。2019/12/1822图5.13家庭保安系统的领域概念模型（精化）2019/12/1823检测器+时间+位置+类别+内容异常事件警报器+号码+重拨延迟+最大重拨次数报警电话+编号+安装位置传感器+烟雾浓度阈值烟雾传感器+灵敏度门窗传感器*1+时间+动作执行者+动作描述日志1*1*11115.4.2设置分析类分析类：是指直接服务于软件的功能性需求的概念层面的类，它与待开发软件系统的具体实现技术无关。从功能需求的角度看，用例的业务逻辑处理功能主要由边界类、控制类和实体类三种分析类协同完成。2019/12/1824边界类：负责目标软件系统与外部执行者之间的交互。控制类：用例任务的责任承担者，负责协调、控制其他类共同完成用例规定的功能或行为。实体类负责保存目标软件系统中具有持久意义的信息项并向其他类提供信息访问的操作。2019/12/18255.4.2设置分析类5.4.3构思分析类之间的协作关系将用例模型中的用例描述转化成UML交互图构造交互图的关键在于将用例的各项功能分解并分派至合适的分析类交互图有助于需求工程师更深入地理解、分析软件需求，剔除用例描述中的模糊性、不一致性、不完整性，同时也为后续的软件设计奠定基础。2019/12/1826图5.16“传感器监测”用例的顺序图2019/12/1827：显示面板:传感器接口1.接收传感数据：监测类:系统配置管理器0.获取传感器配置数据(灵敏度、阀值)：异常事件：日志管理器：警报器接口：报警电话接口：显示面板接口：警报器：报警电话1.1.1bNormal:=isNormal(...)1.1.2[!bNormal]exEvent:=create(...)1.1.3[!bNormal]alarm()1.1.3.1alarm()1.1.4记录异常事件1.1.5[!bNormal]报告异常事件1.1.5.1dialUp(...)1.1.5.2[已接通]reportEvent(...)1.1.6showCurStatus(...)1.1.6.1showCurStatus(...)Loop[报警电话未接通且重拨次数最大重拨次数]：传感器1.1分析传感数据5.4.4导出分析类图将消息的响应对应到分析类的职责，从而推动分析模型的建立和精化，持续迈向软件设计和编程实现。从用例描述中的事件及动作序列，到交互图中的消息，再到分析类的职责，最后演变为设计元素的功能或方法，这个进化过程是面向对象分析与设计过程的关键2019/12/1828（一）创建初始的分析类图比较并研究领域概念模型和交互图，以领域概念模型为基础创建初始的分析类图。如果交互图中出现了某个对象，其所属的分析类未在领域概念模型中出现，则应在分析类图中添加此分析类；反之，针对领域概念模型中的类，如果其对象未在任何交互图中出现，则需求工程师必须判断该类是否对用户需求的实现有所贡献。2019/12/1829图5.18家庭保安系统的分析类图（初步）2019/12/1830control监测器boundary警报器接口boundary报警电话接口+编号+安装位置entity传感器+烟雾浓度阈值entity烟雾传感器+灵敏度entity门窗传感器+时间+动作执行者+动作描述entity日志boundary传感器接口boundary输入键盘接口boundary显示面板接口警报器+号码+重拨延迟+最大重拨次数entity报警电话control配置管理器1*control日志管理器control命令处理器1*1**1+时间+位置+类别+内容entity异常事件1*（二）根据消息确定分析类的职责（三）根据消息传递确定分析类之间的连接（四）根据交互图确立分析类的属性（五）整理分析类图2019/12/1831图5.21家庭保安系统的分析类图2019/12/1832+开始监测()+停止监测()+系统复位()+分析传感数据()control监测器+时间+位置+类别+内容entity异常事件+报警()+关闭()boundary警报器接口+报告异常事件()+电话复位()boundary报警电话接口+编号+安装位置entity传感器+烟雾浓度阈值entity烟雾传感器+灵敏度entity门窗传感器*+时间+动作执行者+动作描述entity日志+开启传感器()+关闭传感器()+传感器复位()+接收传感数据()boundary传感器接口+转发用户命令()boundary输入键盘接口+显示信息()boundary显示面板接口警报器+号码+重拨延迟+最大重拨次数entity报警电话+用户身份验证()+修改配置信息()+查询配置信息()-