搜索
第五章需求分析与验证5.1分析模型的表示顺序图、通信图、状态图、扩充机制5.2需求分析的过程模型5.3需求优先级分析5.4用例分析5.5利用快速原型辅助需求分析5.6评审分析模型5.7需求规约5.8需求验证2020/1/291第五章需求分析与验证5.1分析模型的表示5.1.1顺序图5.1.2通信图5.1.3状态图5.1.4扩充机制2020/1/2925.1分析模型的表示需求分析的任务：在需求获取阶段的输出制品的基础上，获得对软件需求的更深入、更完整的理解，并且将软件需求表示为面向软件设计人员、易于修改和维护的分析模型。基于用例模型建立软件需求的分析模型是需求分析活动的焦点。►在用例模型已成的情形下为何还要构建分析模型？2020/1/293分析模型的表示构建分析模型的两点理由：⑴分析模型比用例模型更加结构化、更加清晰直观，所以分析模型的构建过程实际上也是不断深入理解用例模型的过程，同时也是剔除用例的自然语言描述中可能存在的模糊性和不一致性的过程。⑵分析模型是用例模型与软件设计模型之间的“桥梁”，它比用例模型更接近于设计模型，更适合于软件设计师设计软件系统的结构、构思软件求解算法，更易于为不太熟悉业务的软件设计师所理解，换言之，理解分析模型对业务知识的要求远低于理解用例模型。2020/1/294分析模型的表示需求分析活动参与者：主要完成者是来自软件开发方的需求工程师。其他参与者包括软件架构师、利益相关方，以及项目软件经理、质量保证工程师。需求分析输入与输出：输入制品与需求获取活动的输出制品相同。在所有这些输入制品中，用例模型最重要。输出制品主要是软件需求的分析模型。该模型是需求规约的主要组成部分，同时也是后续软件设计、构造和测试活动的工作基础。2020/1/295分析模型的表示分析模型的表示主要采用UML的类图、活动图、交互图与状态图。2020/1/2965.1分析模型的表示用于表示分析模型的UML图形机制主要是类图、活动图、交互图与状态图。除此以外，分析模型及设计模型等可能还需要引入UML的扩充机制来表达其标准语法设施无法表达的语义。本节主要内容：顺序图通信图状态图UML的扩充机制。2020/1/2975.1.1顺序图交互图描述一组对象通过消息传递而形成的协作行为。交互图的应用：经常用于描述单个用例的功能的实现方式，软件系统在某种给定的使用场景下对象之间的交互协作流程，软件系统的某个复杂操作的逻辑实现模型。通过交互图可清晰地了解对象在软件系统中扮演的角色以及对象之间的交互协作。2020/1/298顺序图分类：交互图包括顺序图和通信图两种。前者强调消息传递的时间序，后者突出交换消息的对象之间的合作关系。虽然它们各有侧重，但从语义上讲基本等价，可从一种图自动转换为另一种图，所以没有必要针对同一建模目标同时创建顺序图和通信图，这样反而容易引起语义上的冗余和冲突。2020/1/299顺序图交互图的作用：业务分析及需求分析人员借助交互图可分析、表述业务处理过程或与软件相关的处理流程；软件设计及实现人员根据交互图确定对象的操作及操作实现方法；测试人员可从交互图了解软件处理过程并据此设计测试用例。图5.1是课程注册管理系统中“制订选课计划”用例的顺序图，该图表示将一些课程设置添加至学生选课计划时软件系统内多个对象之间的交互协作过程。2020/1/2910图5.1课程注册管理系统中“制订选课计划”用例的顺序图2020/1/2911ScheduleManager1:addCourseOfferingsTimeConflictChecker1.2:checkConflictSchedule1.3:*[对所有无冲突的课程设置]addCourseOfferings获取当前计划中已有的所有课程设置1.2.1:getCourseOfferings1.2.2:*[对所有待添加的课程设置][对每门已有的课程设置]checkTimeConflictBetween2CourseOfferingsDataPersistenceService1.3.1:insertCourseOffering1.4:*[对所有无冲突的课程设置]addStudent1.4.1:insert如果计划已确认，则报错并返回1.1:create（一）顺序图概览顺序图是一张二维图。其纵向代表时间轴，时间沿垂直方向向下延伸；其横向由多个参与交互的对象构成，这些对象之间无顺序关系。一般情况下，时间轴上的两点只有相对时序的差异，但在实时应用中，可以使用带时间刻度的时间轴以度量两点之间的绝对时差。一张基本的顺序图由以下图形元素构成：对象及其生命线与活跃期，消息传递，注解。2020/1/2912顺序图概览⑴顺序图中的对象表示为嵌于矩形框内形如“[对象名]:[类名]”的文本，其中对象名、类名分别可省略，但不能同时省略。当同一类有多个对象参与同一张顺序图所示的交互时，或者当对象将作为参数出现在本图中的某条消息时，对象名就不能省略。⑵对象之下的垂直虚线称为对象的生命线，表示对象在始于对象表示图元所处的时间起点、止于对象生命终结符（见图5.1中TimeConflictChecker对象的生命线）之间的时间段内在软件系统中存在。如果对象生命线的下方没有终结符，则表示对象在顺序图所代表的时间段之后仍然存在。2020/1/2913顺序图概览⑶对象中操作的执行期（包括等待同步调用返回的时间）称为对象的活跃期，它由覆盖于对象生命线之上的长条形矩形表示。如果对象发出传向自身的消息（见图5.1中TimeConflictChecker对象的生命线），或者作为消息接收方的对象在处理消息的过程中又向消息发送方对象传递另一消息，则会导致活跃期的嵌套。2020/1/2914顺序图概览⑷对象间的消息传递表示为对象生命线之间的有向边，边上可标注“[*][监护条件][返回值:=]消息名[(参数表)]”其中“*”为迭代标记，表示同一消息对同一类的多个对象发送。当出现迭代标记时，监护条件表达式表示迭代条件，例如图5.1中的“*[对所有无冲突的课程设置]”；否则，它表示消息传递实际发生的条件。返回值表示消息被接收方对象处理完成后回送的结果。消息名的命名规则应与类图中操作的命名规则相一致。在消息的条件表达式和参数表中可以使用关键字“self”表示发出消息的源对象。2020/1/2915顺序图概览建模者勿需考虑消息发送与接收之间的时延，确需考虑时（例如，在实时应用中，或者当消息通过网络传输时），可以用斜向下方的消息边来表示，见图5.2（c）。顺序图中的消息分为同步、异步两种，分别用实心三角形箭头和普通箭头表示，见图5.2（a）和（b）。同步消息的发送者等待消息接收对象将消息处理完成后再继续，异步消息的发送者在发送完消息后不等待接收方即继续自己的处理。同步消息会指向作为消息接收目标的对象的活跃期的顶端。2020/1/2916顺序图概览UML中有四种特殊的消息：自消息、返回消息、创建（create）消息、销毁（destroy）消息。自消息是指一个对象传向其自身的消息。如果一条消息从对象a传向对象b，那么其返回消息是一条从b指向a的虚线有向边，它表示原消息的处理已经完成，处理结果（如果有的话）沿返回消息传回。2020/1/2917顺序图概览创建消息、销毁消息的名称分别为create、destroy，或在消息边上标注构造型create、destroy，分别表示对消息传递的目标对象的创建和删除。对于创建消息，目标对象的矩形表示图元的纵向位置应位于消息接收点（因为在此之前此对象并不存在）。对于销毁消息，其目标对象的生命线应恰在消息接收点之下显示终结符。2020/1/2918⑸可以在对象生命线上嵌入状态符，它表示对象在状态符所处的时间点上必定进入相应的状态。还可以用状态符来表示来自其他对象的某条消息将导致对象状态的改变，此时状态符应在时间轴方向上靠近那条消息。如，图5.3表示，Schedule对象在收到“confirm”消息后将进入“confirmed”状态。2020/1/2919顺序图概览⑹在顺序图的左侧，可加注解以阐释消息的意义、有关的约束以及消息传递时间点之间的延时约束。注解处的位置应在水平方向上与对应的消息相齐。为精确地描述延时约束，可以在对象的生命线或活跃期上标注时间标签，见图5.2（c）。当用例图中的执行者的实例出现在顺序图中时，它与软件系统内部对象之间的交互消息不同于两个内部对象之间的交互，仅依靠消息名、参数表来描述此类消息往往过于形式化，也难以完整、详尽地表达交互的内容，因此应该在注解中以自然语言予以阐述。2020/1/2920图5.2同步、异步及带时延的消息（b）异步消息2020/1/2921Obj1Obj2someMsgObj1Obj2someMsgObj1Obj2时延小于10ms（a）同步消息（c）带时延的消息图5.3嵌入状态符的对象生命线2020/1/2922ScheduleManager1:confirmScheduleSchedule1.1:confirmDataPersistenceService1.1.1:update如果计划已处于confirmed状态，则报错并返回confirmed（二）主动对象与被动对象考察整张顺序图（而非局部），在该图表示的时间段内，如果有多个对象同时处于活跃期，其中某些对象的活跃是直接或间接地起因于某个对象A传出的消息，则称A为主动对象，称由A直接或间接激活的对象为被动对象。被动对象在响应、处理消息时接受消息源对象的控制，在消息处理完毕后将控制权交还，其活跃期的顶部位于消息接收点，底部位于消息处理完成时刻点。如，在图5.1和图5.3中，ScheduleManager对象为主动对象，其他对象为被动对象。主动对象在顺序图中以带双竖线的矩形表示，也可以采用约束特性{active}来表示，见图5.4。2020/1/2923主动对象与被动对象在一张顺序图中，可能存在多个主动对象。此时，这些主动对象所掌控的控制流将并发执行。两个主动对象之间的消息传递应该是异步的。由于多个主动对象引起的上述语义复杂性，所以建模者应尽量避免这种情形，仅在确需强调多个主动对象所掌控的控制流的并发性及它们之间的异步消息时，才在一张顺序图中引入多个主动对象。如，在图5.3所示的场景中，单个主动对象就已足够；但在刻画协同工作场景时，需要强调任务负责人及多个子任务承担者之间的并行处理，就必须引入多个主动对象，见图5.4。2020/1/2924图5.4多个主动对象构成的顺序图2020/1/2925Manager1:doTaskemployee1：Employee1.2a:doSubTask1employee2：Employee1.2b:doSubTask2分派子任务，并且自行完成部分任务1.1:decomposeTask1.2c:doSubTask3completedcompleted1.3:finishTask（三）建模规则在进行顺序图建模过程中，建议读者遵循以下经验规则：⑴在业务分析和需求分析阶段，建模者并不需要过于精细地刻画顺序图的所有图形元素。消息名和消息传递条件均可采用业务术语及自然语言描述，消息的参数表可以省略。2020/1/2926建模规则⑵无论是在分析阶段还是在设计阶段，建模者均应聚焦于对象间关键的、主要的交互，避免因过多的细节而使顺序图含混不清、复杂不堪。如①作为业务分析或需求分析模型的顺序图不必考虑用户界面对象与业务对象之间的交互、数据的持久存储等问题。②除非特别必要，一般应尽量避免显式表示返回、创建、销毁消息及对象生命终结符，也不需要显式区分同步、异步消息。③勿需过多考虑对象的活跃期图元，也不需显式表示活跃期的嵌套，一般利用建模工具自动生成的活跃期图元即可。2020/1/2927建模规则⑶在设计和实现模型中，如果消息的参数与顺序图表