UML 第2版 书号9787030569141 邹盛荣 08 需求分析 ---201803.pptVIP

Thank you ! 素材天下 UML面向对象需求分析与建模教程 ----基于UML2.5标准 (第二版) 第8章 需求分析 邹盛荣 目录 8.1确定客户需要什么 1 8.2 需求分析方法 8.3 需求分析路线图 3 2 8.4 分析案例 4 8.1 确定客户需要什么 分析？分而析之？合理吗 整体论 系统论 复杂网络的必要性 分析阶段主要考虑所要解决的问题，可用 UML 的逻辑视图和动态视图来描述，类图描述系统的静态结构，协作图、状态图、序列图、活动图和状态图描述系统的动态特征 在分析阶段，只为问题领域的类建模，不定义软件系统的解决方案的细节：如用户接口的类、数据库等。 -*- 分析模型与用例模型 用例：外观 类/协作：内部机理 -*- 从用例开始分析迭代 UP方法中最重要的思想就是迭代，而迭代的基础就是用例 从用例开始分析基本思路 根据用例图和用例文档来确认需求定义是可靠的、一致的 用例分级：根据风险、重要性以及项目组的能力确定用例以及用例相关路径的优先级 8.2 需求分析方法 面向对象分析的目的是对客观世界的系统进行建模。 分析模型有三种用途：用来明确问题需求；为用户和开发人员提供明确需求；为用户和开发人员提供一个协商的基础，作为后继的设计和实现的框架。 4+1 视图方法 “4+1”视图是对逻辑架构进行描述，最早由 Philippe Kruchten 提出，他在1995年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》（架构的4+1视图模型）的论文，引起了业界的极大关注，并最终被 RUP 采纳，现在已经成为架构设计的结构标准。 逻辑视图、开发视图主要是用来描述系统的静态结构，而处理视图、物理视图主要描述系统的动态结构。并非每个系统都必须把5个视图都画出来，它们各有侧重点，例如信息管理系统（MIS）系统侧重于逻辑视图、开发视图，而实时控制系统则侧重于处理视图、物理视图。 -*- 构架：4+1视图(from RUP) Process View Deployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance Scalability Throughput System integrators System topology Delivery, installation communication System engineering Analysts/Designers Structure （1）用例视图。用例视图强调从系统的外部参与者看到的或需要的系统功能。用例是系统的一个功能单元，可以认为用例是参与者与系统之间的一次交互。 （2）逻辑视图。逻辑视图从系统的静态结构和动态行为角度显示如何实现系统的功能。它主要是为设计和开发人员准备的，主要关注系统内部的具体实现。 （3）组件视图。组件视图显示代码组件的组织结构。组件是封装良好的、定义了接口的代码模块。使用组件视图的主要是开发人员。 （4）并发视图。并发视图显示系统的并发性，解决在并发系统中存在的通信和同步问题。 （5）配置视图。配置视图显示系统的具体部署。部署是指将系统配置到硬件设备上。 帮助建模者定义类: z 有没有一定要存储或分析的信息 如果存在需要存储 分析或处理的信息 那么 该信息有可能就是一个类 这里讲的信息可以是概念 该概念总在系统中出现 或事件或事务 它发生在某一时刻 z 有没有外部系统 如果有 外部系统可以看作类 该类可以是本系统所包含的类 也可以是本系统与之交互的类 z 有没有模版 类库 组件等 如果手头上有这些东西 它们通常应作为类 模版 类库 组件可以来自原来的工程 或别人赠送或从厂家购买的 z 系统中有被控制的设备吗 凡是与系统相连的任何设备都要有对应的类 通过这 些类控制设备 z 有无需要表示的组织机构 在计算机系统中表示组织机构通常用类 特别是构建 商务模型时用得更多 z 系统中有哪些角色 这些角色也可以看成类 比如 用户 系统操作员 客户等 类图的建模分析步骤 （1） 寻找出需求中的名词(候选对象)。 （2） 合并含义相同的名词，排除范围以外的名词，并寻找隐含的名词。 （3） 去掉只能作为类属性的名词。 （4） 剩下的名词就是要找的分析类（候选类)。 （5） 根