云南大学软件学院软件工程课件第五章 面向对象需求分析.pptVIP

行为分析法 行为分析法是从需求描述中搜寻动词，识别出系统行为。然后找出系统行为的主动对象和被动对象作为候选对象。在找出候选对象之后，就按照对象的含义进行对象的确定。针对确定后的对象，以其发起行为的组合作为特征描述，并以特征的相似性进行归纳分类，产生类。 名词分析法 名词分析法是一种运用语言分析的实用方法。名词分析从需求文本描述中识别出有关的名词和名词短语，将它们作为候选对象。根据类的定义对候选对象进行归纳、筛选，最后形成类。 建立类之间的关联 在得到孤立的类之后，要建立它们之间的关联，把它们联系起来。发现类之间的关联可以从两个方面着手： （1）分析问题域内的静态结构关系，发现概念类之间的整体部分关系和明显的语义联系。 （2）分析概念类之间的协作，协作能够体现概念类之间明显以及不明显的语义联系。 筛选候选关联 已删去类之间的关联：如果在分析确定类与对象的过程中已经删掉了某个候选类，则与这个类有关的关联也应该删去，或用其他类重新表达这个关联。 与问题无关的或应在实现阶段考虑的关联：应该把处在本问题域之外的关联或与实现密切相关的关联删去。 瞬时事件：关联应该描述问题域的静态结构，而不应该是一个瞬时事件。 三元关联：三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。 派生关联：应该去掉那些可以用其他关联定义的冗余关联。 建立类之间的关联原则 保证类之间协作所必需的可见性。 适当使用问题域内的关联，增强领域模型的可理解性。 不要在关联的识别上花费太多的时间。 避免显示冗余和导出的关联。 ATM系统类图 添加类的属性 属性是对象的性质，借助于属性我们能对类与对象有更加深入的认识。一般说来确定属性的过程包括分析和选择两个步骤： 分析 选择 5.5 建立行为模型 对象的行为可以用三类模型进行建模： 交互图 状态图 活动图 建立交互图 交互图建模一般采用顺序图作为载体。建立交互图的一般步骤如下： 确定交互图的上下文环境。 找出参与交互的对象。 根据发现的对象（和关联）建立交互图框架。 添加消息，描述交互行为。 进行消息标识、特化图示等详细信息的描述，将交互图的信息补充完整。 启动ATM系统顺序图 取钱用例顺序图 建立状态图 确定上下文环境。状态图是立足于状态迁移而进行行为描述的。因此建立状态图时首先要搞清楚状态的主体，确定状态的上下文环境。常见状态主体有：类、用例、多个用例和整个系统。 识别状态。状态主体会表现出一些稳定的状态，它们需要被识别出来，并且标记出其中的初始状态和结束状态集。在有些情况下，可能会不存在确定的初始状态和结束状态。 建立状态图 建立状态转换。根据需求所描述的系统行为，建立各个稳定状态之间可能存在的转换。 补充详细信息，完善状态图。添加转换的触发事件、转换行为和监护条件等详细信息。在有些情况下也可能会需要建立状态图的层次结构或者进行其他更加复杂的工作。 状态转换表 取钱类状态图 建立活动图 确定活动图的上下文环境； 识别参与者； 分析业务流程中的主要处理步骤； 分析业务流程中的主要数据流； 进行职责分配； 添加活动图的详细信息，完善活动图描述。 关闭ATM系统活动图 钥匙开关 ATM机 银行信息系统 识别服务 应借鉴同类系统的面向对象分析结果加以复用，研究问题域和系统责任以明确各个对象应该设立哪些服务以及如何定义这些服务。特别要考虑以下几个问题： 系统责任 问题域 分析对象的状态 追踪服务的执行路线 服务的命名和定位 5.6　需求验证 需求规约作为需求分析阶段的阶段性成果，如果没有经过验证，则最终用户、需求分析师、系统设计师和投资商均难以确定其分析结果的正确性。因此，验证活动普遍存在于需求开发活动中。在需求验证过程中主要解决以下两个方面的问题： 在需求分析中建立的分析模型是否正确地反映了问题域特性和需求？细化的系统需求是否充分和正确地支持用户需求？ 需求规约文档是否组织良好、书写正确？需求规约文档内容是否充分和正确地反映了最终用户的意图？需求规约文档是否可以作为后续开发工作（设计、实现、测试等等）的基础？ 需求评审 评审(Review)又被称为同行评审(Peer Review)，指由作者之外的其他人来检查产品问题的方法。在需求验证中，评审属静态分析手段。原则上，每一个需求都应该经过评审。 参与评审的人员 组织者(Organizer) 仲裁者(Moderator) 作者(Author) 阅读人员(Reader) 记录人员(Recorder) 收集人员(Collector) 审查人员(Inspector)，包括领域专家和用户代表 评审的过程 评审的类型