导图社区 UML大战需求分析
- 265
- 14
- 1
- 举报
UML大战需求分析
UML大战需求分析思维导图，包括UML的定义、作用、特点、UML系统开发中有三个主要的模型、图的种类等内容。
编辑于2021-11-30 15:03:43- 需求分析
- UML
- 相似推荐
- 大纲
UML大战需求分析
UML与软件工程
(一般)在软件的各个开发阶段需要的UML图
定义阶段
需求获取
用例图
整体分析
静态
类图
动态
顺序图
协作图
活动图
状态图
开发阶段
设计阶段
类图
包图
编码
类的实现
集成与交付
构件图
包图
部署图
测试
单元测试
类图
类的规格说明书
集成测试
类图
包图
构件图
协作图
系统测试
用例图
UML使用人员图示
UML 重点知识
定义
UML-Unified Modeling Language 统一建模语言，又称标准建模语言。
作用
(1)为软件系统建立可视化模型 (2)为软件系统建立构件 (3)为软件系统建立文档
特点
1）UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。它实际上是一种通用的建模语言，可以为许多面向对象建模方法的用户广泛使用。 2）UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。 3）UML是一种建模语言，而不是一个开发过程。
UML系统开发中有三个主要的模型
功能模型:从用户的角度展示系统的功能，包括用例图。
对象模型:采用对象、属性、操作、关联等概念展示系统的结构和基础，包括类图、对象图、包图。
动态模型:展现系统的内部行为。 包括序列图、活动图、状态图。
图的种类 截止UML2.0一共有13种图形 (UML1.5定义了9种，2.0增加了4种)
整体分类：
视图角度分法:
用例视图=>用例图
设计视图=>类图、对象图
进程视图=>态图、活动图、协作图、序列图
实现视图=>构件图
拓扑视图=>部署图
静动角度分法:
静态图=>用例图、类图、对象图、包图、构件图、部署图
动态图=>状态图、活动图、协作图、序列图
用例图：从用户角度描述系统功能
用例图（UseCase Diagrams）,主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示这些元素之间的各种关系，如泛化、关联和依赖。它展示了一个外部用户能够观察到的系统功能模型图。 【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。
包含的的元素
1. 参与者(Actor)——与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2. 用例(Use Case)——用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3. 子系统(Subsystem)——用来展示系统的一部分功能，这部分功能联系紧密。
包含的的关系
关联、泛化、包含、扩展
a.关联(Association) 表示参与者与用例之间的通信，任何一方都可发送或接受消息。 【箭头指向】：无箭头，将参与者与用例相连接，指向消息接收方
b.泛化(Inheritance) 就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。 【箭头指向】：指向父用例
c.包含(Include) 包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那添加、修改以及删除都要在用例详述中描述，过于复杂；如果分成添加用例、修改用例和删除用例，则划分太细。这时包含关系可以用来理清关系。 【箭头指向】：指向分解出来的功能用例
d. 扩展(Extend) 扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。 对于一个扩展用例，可以在基用例上有几个扩展点。 【箭头指向】：指向基础用例
e. 依赖(Dependency) 以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。 【箭头指向】：指向被依赖项
包含(include)、扩展(extend)、泛化(Inheritance) 的区别： 条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的； 直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。 对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。 对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系； ●泛化侧重表示子用例间的互斥性； ●包含侧重表示被包含用例对Actor提供服务的间接性； ●扩展侧重表示扩展用例的触发不定性； 另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
类图：描述系统中类的静态结构
类图（Class Diagrams）,用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。 类一般由三部分组成： -类名(Class)：每个类都必须有一个名字，类名是一个字符串。 -属性(Attributes)：属性是指类的性质，即类的成员变量。类可以有任意多个属性，也可以没有属性。 -操作(Operations)：操作是类的任意一个实例对象都可以使用的行为，操作是类的成员方法。
属性和方法之前可附加的可见性修饰符
类的关系 各种关系的强弱顺序： 泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
关联关系(Association)： 通常关联关系用来实现连接有关联的对象所对应的类，即将一个类的对象作为另一个类的属性。 还有就是关联关系可以是单向的也可以是双向的。双向的符号是没有方向标的，只是一条直线。
关联关系-单向
关联关系-双向
关联关系-自己
多重性关联关系 记住上面的表格。是另一个类与该类是什么关系。
在这里要注意，看完此图中1…1以后不要认为一个Form是对应一个Button的。 不是的，应该是一个Button是对应一个Form的。1..1是表示另一个类的一个对象只与一个该类对象有关系。记住上面的表格。是另一个类与该类是什么关系。
聚合关系(Aggregation)： 表示整体与部分的关系。考虑到一个整体类的组成结构。找出成员类。即成员对象是整体对象的一部分，但是成员对象可以队里整体对象独立存在。所以也有人说此关系是一种弱关系，那么强关系是什么后面我们会降到组成关系。 聚合关系有一个特点，那就是可替换。
直观的来看此图Car中必须得有一个Engine，这样才可以认为是一个完整体。 但是这个Engine是可替换的。是以传参的形式给Car赋一个Engine。 再次强调一下聚合是可替换的。Car中必须有一个Engine，但是此Engine可以是一个抽象的具体的Engine是在当你使用Car时可以具体去找一个合适的Engine装到Car上就行，如果没有Engin那么这个Car是跑不了。
组合关系(Composition)： 表示整体与部分的关系。但是与聚合不同此关系是整体与部分是同生共死关系。即如果整体对象销毁了部分也会被销毁。
上图Head是整体Mouth是部分，如果Head没了Mouth也跟着销毁了。如果Mouth没了Head也将是面目全非。在代码中Head中Mouth是直接new出来的。 就是说当你去new Head时Mouth也被new出来。记住一同创建一同销毁关系。也叫强关系。那么有人会问关联，聚合，组合我怎么认为是一样呢。 可以说他们是一样的都可以说是关联关系，是的，但是关联关系的强弱来区分了一下关联关系强度来看组合>聚合>关联。
依赖关系(Dependency)： 是一个使用关系。特定事物的改变有可能会影响到使用该事物的其他事物。简单说在一个类中通过另外一个类来调用其方法的表示。
从图中可以看出Driver中使用了Car的move方法。那么就说明Driver是依赖于Car才能做Driver的职责。那么又有人会问聚合与依赖有区别吗，当然很明显Driver是一个整体，Car也是整体。不是整体与部分关系。
泛化关系(Generalization)： 继承(extends)关系，父类与子类关系。
从图中可以看出Student也是Person，Teacher也是Person。他们有共同的特征name，age。但是也有独自的特征一个是study一个是teach的特征。 子类那么就是Student，Teacher父类是Person。继承了父类那么子类可以直接适用父类的方法或属性（家产）
实现关系(Realization): 类实现（implements）了接口.当多个类有类似的行为方式的时候我们通常会适用接口。
Ship,Car都有move的特征他们都属于交通工具(Vehicle)只是他们move的方式不一样。那么我们就可以适用接口实现的方式去设计。代码中是public class Car implements Vehicle
完整的类图例子
对象图：系统中的多个对象在某一时刻的状态
定义： 对象图(Object Diagram) 是显示了一组对象和他们之间的关系。使用对象图来说明数据结构，类图中的类或组件等的实例的静态快照。
对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
对象图例子
用途 · 捕获实例和连接 · 在分析和设计阶段创建 · 捕获交互的静态部分 · 举例说明数据/对象结构 · 详细描述瞬态图 · 由分析人员、设计人员和代码实现人员开发
与类图的区别
状态图：是描述状态到状态控制流，常用于动态特性建模
定义：状态图（Statechart Diagram）主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件（Event），以及因状态转移而伴随的动作（Action）。一般可以用状态机对一个对象的生命周期建模，状态图用于显示状态机（State Machine Diagram），重点在与描述状态图的控制流。
例子:打电话
状态图元素（State Diagram Elements） 1、状态（States） 2、转移（Transitions） 3、动作（State Actions） 4、自身转移（Self-Transitions） 5、组合状态（Compound States） 6、进入节点（Entry Point） 7、退出节点（Exit Point） 8、历史状态（History States） 9、并发区域（Concurrent Regions）
活动图：描述了业务实现用例的工作流程
活动图（Activity Diagrams）： 是<状态图的一种特殊情况>，这些状态大都处于活动状态。本质是一种流程图，它描述了活动到活动的控制流。 交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流。 活动图是一种表述过程基理、业务过程以及工作流的技术。 它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。
例子:ATM取款
顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互
定义：顺序图也称序列图（Sequence Diagrams）： 交互图的一种，描述了对象之间消息发送的先后顺序，强调时间顺序。 序列图的主要用途是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。同时序列图更有效地描述如何分配各个类的职责以及各类具有相应职责的原因。
例子：ATM Time Constraint
包含的元素
*生命线 生命线名称可带下划线。当使用下划线时，意味着序列图中的生命线代表一个类的特定实例
*同步消息 同步等待消息
*异步消息 异步发送消息，不需等待
*注释
*约束
*组合 组合片段用来解决交互执行的条件及方式。它允许在序列图中直接表示逻辑组件，用于通过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。常用的组合片段有：抉择、选项、循环、并行。
协作图：描述对象之间的协助关系
协作图（Collaboration/Communication Diagrams）： 又作“通信图”。即Communication Diagram,交互图的一种，描述了收发消息的对象的组织关系，强调对象之间的合作关系。时序图按照时间顺序布图，而协作图按照空间结构布图
例子
构件图：一种特殊的UML图来描述系统的静态实现视图
构件图（Component Diagrams）： 构件图是用来表示系统中构件与构件之间，类或接口与构件之间的关系图。其中，构建图之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系。
例子
部署图：定义系统中软硬件的物理体系结构
部署图（Deployment Diagrams）： 描述了系统运行时进行处理的结点以及在结点上活动的构件的配置。强调了物理设备以及之间的连接关系。
例子
例子
部署模型的目的： 描述一个具体应用的主要部署结构，通过对各种硬件，在硬件中的软件以及各种连接协议的显示，可以很好的描述系统是如何部署的；平衡系统运行时的计算资源分布；可以通过连接描述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统运行模型。
包图：对构成系统的模型元素进行分组整理的图
包图(Package Diagrams)是在 UML 中用类似于文件夹的符号表示的模型元素的组合。系统中的每个元素都只能为一个包所有，一个包可嵌套在另一个包中。使用包图可以将相关元素归入一个系统。一个包中可包含附属包、图表或单个元素。
例子
时序图：表示生命线状态变化的图
时序图(Timing Diagrams),是用来显示交互的UML交互图，当图的主要目的是为了解释时间。时序图关注条件的变化在时间轴中沿直线的生命线。时序图描述个体量词和量词行为相互作用，注重在模拟条件下的生命线事件引起变化的时间。
例子
组合结构图：表示类或者构建内部结构的图
组合结构图(Composite Structure Diagram)用来显示组合结构或部分系统的内部构造，包括类、接口、包、组件、端口和连接器等元素，是UML2.0的新增图 组合结构图侧重复合元素的方式展示系统内部结构，包括与其他系统的交互接口和通信端口，各部分的配置和协作，组件相关的服务，以及各服务之间的通信和调用
组合结构图建模步骤:
- 确定系统中的主要组合结构、重要类以及与外部的连接或调用关系 - 分析主要组合结构在系统中所起的作用以及与系统中其他组件的调用关系 - 将重要类分解为复合元素，并确定其部件、接口以及需要对外暴露的端口 - 确定类复合元素与其内部成员之间的比例关系、成员与成员之间的连接关系、接口的种类以及该类元与其他类之间的关系 - 将需要进行紧密合作共同完成一项功能的一系列角色定义为协作，并确定协作的角色与连接器类型- 确定系统中的主要组合结构、重要类以及与外部的连接或调用关系 - 分析主要组合结构在系统中所起的作用以及与系统中其他组件的调用关系 - 将重要类分解为复合元素，并确定其部件、接口以及需要对外暴露的端口 - 确定类复合元素与其内部成员之间的比例关系、成员与成员之间的连接关系、接口的种类以及该类元与其他类之间的关系 - 将需要进行紧密合作共同完成一项功能的一系列角色定义为协作，并确定协作的角色与连接器类型
组合结构图主要元素
· 类元与成员
- 类元：类元素在类图中和组合结构图中的表示形式不同 类元素在组合结构图中以复合元素的方式展示内部结构，比如对外暴露接口、端口或部件
示例
- 成员：成员指与类元具有组成关系的其他类，一般把成员放到类元的内部结构中描述 如所示，CPU、Memory等与Computer类元有组成关系
示例
- 类元与成员的数量关系：一对一或一对多
示例
- 成员与成员的连接关系：成员之间如果依赖、泛化、关联或调用关系可以用连接符连接。用不带箭头的直线标识连接符
- 类元与关联类的连接关系：在类元中用边框为虚线的矩形标识关联类
示例
· 组件(Component)： 承担具体功能单元的实际文件，一般为lib, jar, dll, exe等格式，遵循接口定义并提供具体的接口实现
· 部件(Part)：代表属于类元的一个元素，该元素可能包含一个或多个实例。常用在类或组件内部用不加修饰的矩形框标识
示例
· 接口(Interface)：一组操作的集合，声明了组件提供或请求的服务契约，这个契约由实现和使用这个接口的组件共同遵守
- 提供接口：也叫供接口，是指组件给其他组件提供服务时实现的特性和约束。用带棒球体标识
示例
- 需求接口： 也叫需接口，是指组件像其他组件请求服务时要遵循的接口。用带棒杯体标识
示例
· 端口(Port)：类元与外部部件交互的连接处。用类元边框线上的小矩形框标识 类元一般都是以封闭的结构体，在组合结构图中通过端口与外部交互。
示例
组合结构图元素关系
· 委托与委托连接器(Delegate Connector)：委托用来定义组件外部接口和端口的工作方式。用带关键字<<delegate>>的实线箭头标识委托连接器
示例
· 协作(Collaboration)：定义了共同完成一项功能的一系列角色，包括这些角色相应的实体和实体间的关系。用虚线框椭圆标识协作
示例
· 绑定与角色绑定连接器(Role Binding Connector)：绑定用来连接从协作到完成该角色任务的类元。 用带关键字Role的虚线箭头标识角色绑定连接器，并在类元端显示角色名称。
示例
· 表现与表现连接器(Represents Connector)：表现用来连接从协作到使用该协作的类元。用带关键字<<represents>>的虚线箭头标识表现连接器
示例
· 发生与发生连接器(Occurrence Connector)：发生用来连接从协作到描绘该协作的类元。用带关键字<<occurrence>>的虚线箭头标识
示例
组合结构图示例
*组合结构图示例*
组合结构图注意事项
- 侧重类的整体特性，就使用类图；侧重类的内部结构，就使用组合结构图 - 注意区分端口和接口，端口主要是类元对外可视的部分、负责类元与外部环境的交互，接口主要是类元自身的供需定义 - 注意区分组件和部件，组件一般是指系统中独立的组成部分，部件一般指类元内部的组成部分 - 对于合作紧密完成意向功能的一系列角色建议组合为协作，对外作为独立的整体操作 - 注意区分不同的连接器类型及适用场景
交互概览图：用活动图来表示多个交互之间的控制关系的图
一、定义 1，交互概览图(Interaction Overview Diagram)是交互图与活动图的混合物，可以把交互概览图理解为细化的活动图，在其中的活动都通过一些小型的顺序图来表示；也可以将其理解为利用标明控制流的活动图分解过的顺序图。 2，交互概览图用于将一些零散的顺序图组织在一起，它采用了活动图的构造方式，利用了活动图的各种控制节点，并把活动图的每个活动结点替换为一个交互或者交互使用。每个交互或者交互使用都使用一个顺序图表示。
二、绘制步骤 1，选择策略（对工作流建模或对操作建模） 2，理清主线（绘制活动图） 3，表述细节（用顺序图来表述详细细节）
三、绘制技巧 1，在交互概览图中，使用活动图描述主线，使用顺序图描述细节。 2，交互概览图包含顺序图的表示法及活动图的判断和分支表示法。 3，交互概览图试图将活动图中活动结点之间的控制流机制和顺序图中的生命线间的消息序列混合在一起，很多人认为并没有加入多少新特性。因此，一般情况下很少绘制交互概览图。 4，不要盲目地使用交互概览图，对于规模稍大的场景，它并不是一个很好的选择，它将使模型的可读性大大降低，且不便于文档化。
四、实例 使用交互概览图描述从“登录”到“借书”的流程......................
示例
常用UML建模工具
Rational Rose
PowerDesigner
Visual Paradigm for UML
StarUML
SystemArchitect
VISIO
Jude
CMMI是 什么东西
1.CMMI
-Capability Maturity Model Integration -能力成熟度模型集成--用来衡量软件研发水平的模型 -CMMI是美国军方采购软件的标准之一
2.SEI
-Software Engineering Institute -美国的软件工程学院 -CMMI是SEI搞出来的
3.CMMI是通过多个Process Area(过程域)来描述对软件研发各方面的要求 CMMI将能力成熟度分为5个级别：初始级，已管理级，已定义级，量化管理级，优化级
1. 第2级 已管理级 7个过程域
2.
3.
4.
5.
6.
7.
8. 第3级 已定义级 11个过程域
9.
10.
11.
12.
13.
14.
15.
16.
17.
18. 第4级 量化管理级 2个过程域
19.
20. 第5级 优化级 2个过程域
21. 需求管理
22. 项目规划
23. 项目监控
24. 供应商协议管理
25. 度量分析
26. 过程和产品质量保证
27. 配置管理
28.
29. 需求开发
30. 技术方案
31. 产品集成
32. 验证
33. 确认
34. 组织过程焦点
35. 组织过程定义
36. 组织培训
37. 集成化项目管理
38. 风险管理
39. 决策分析与解决方案
40.
41. 组织过程绩效
42. 定量项目管理
43.
44. 组织革新与推广
45. 原因分析与解决方案
46. Requirements Management
47. Project Planning
48. Project Monitoring and Control
49. Supplier Agreement Management
50. Measurement and Analysis
51. Process and Product Quality Assurance
52. Configuration Management
53.
54. Requirements Development
55. Technical Solution
56. Product Integration
57. Verification
58. Validation
59. Organizational Process Focus
60. Organizational Process Definition
61. Organizational Training
62. Integrated Project Management
63. Risk Management
64. Decision Analysis and Resolution
65.
66. Organizational Process Performance
67. Quantitative Project Management
68.
69. Organizational Innovation and Deployment
70. 工程
71. 项目管理
72. 项目管理
73. 项目管理
74. 支持
75. 支持
76. 支持
77.
78. 工程
79. 工程
80. 工程
81. 工程
82. 工程
83. 过程管理
84. 过程管理
85. 过程管理
86. 项目管理
87. 项目管理
88. 项目管理
89.
90. 过程管理
91. 项目管理
92.
93. 过程管理
94. Causal Analysis and Resolution
95.
96. 支持
4.每个过程域通过Goals(目标)来描述该方面的总体要求