统一建模语言(Unified ModelingLanguage，UML)是用于系统的可视化建模语言，它将OMT、OOSE和Booch 方法中的建模语言和方法有机地融合在一起，是国际统一的软件建模标准。虽然它源于O0软件系统建模领域，但由于其内建了大量扩展机制，也可以应用于更多的领域中，例如工作流程、业务领域等。
UML（Unified Modeling Language）是软件工程的"通用语言"，用于可视化、设计、构建和文档化软件系统。它像建筑行业的蓝图，帮助开发团队在编码前理清思路，确保所有人对系统有统一的理解。
UML的核心价值
可视化沟通：用标准图形取代模糊的文字描述
提前发现问题：在编码前发现设计缺陷
文档化架构：为后续维护提供路线图
支持敏捷开发：通过迭代建模适应需求变化
SvSML是一种用干系统工程应用程序的通用系统体系结构建模语言，支持各种系统和系统中系统的规范、分析、设计、验证和验证。
这些系统可能包括硬件、软件、信息、过程、人员和设施。
SySML中定义了4大类图--结构图、需求图、参数图和行为图，
结构图可再细分为类图和装配图:
行为图可再细分为用例图、状态机图、活动图、顺序图和时间图。
SySML中包含以下9种主要的图种:用例图、需求图、块定义图、内部块图、参数图、活动图、序列图、状态机图、包图。
- 需求图用干捕获系统需求
- 块定义图和内部块图用干建模系统结构
- 参数图用干约束系统参数
- 活动图、序列图和状态机图用干建模系统行为
- 包图用于组织和管理模型元素。
UML（统一建模语言）的组成部分确实可以分为构造块、公共机制和架构三个部分，但需注意这些术语在标准UML规范中的定位。
1. 构造块（Building Blocks）
构造块是UML的基础元素，用于构建模型，分为四类：
结构事物（Structural Things）：表示系统的静态部分。
类（Class）：描述对象属性和方法。
接口（Interface）：定义操作的契约。
组件（Component）：可替换的模块化部分。
节点（Node）：物理部署单元（如服务器）。
用例（Use Case）：系统的功能需求。
行为事物（Behavioral Things）：描述动态交互。
交互（Interaction）：对象间的消息传递（如顺序图）。
状态机（State Machine）：对象的状态变化。
活动（Activity）：工作流程或算法。
分组事物（Grouping Things）：组织模型元素。
包（Package）：逻辑分组机制。
注释事物（Annotational Things）：添加说明。
注释（Note）：解释性文本。
此外，构造块还包括关系（如关联、依赖、泛化）和图（如类图、时序图、部署图）。
2. 公共机制（Common Mechanisms）
公共机制提供一致的建模规则和扩展能力，包括：
规格说明（Specifications）：元素的详细描述（如类的属性和操作）。
修饰（Adornments）：图形符号的附加信息（如箭头表示方向性）。
通用划分（Common Divisions）：分类原则（如类与对象的区别、接口与实现分离）。
扩展机制（Extensibility）：
构造型（Stereotype）：自定义元素类型（如
<<service>>）。标记值（Tagged Value）：添加额外属性。
约束（Constraint）：限制条件（如
{ordered}）。3. 架构（Architecture）
架构指通过UML描述的系统整体结构，通常对应不同视角的视图：
逻辑视图（Logical View）：功能需求与静态结构（类图、对象图）。
进程视图（Process View）：并发与同步机制（活动图、状态机图）。
实现视图（Implementation View）：组件与代码组织（组件图）。
部署视图（Deployment View）：物理部署（部署图）。
用例视图（Use Case View）：用户与系统交互（用例图）。
需注意的差异
用户问题中的“架构”：实际是UML用于描述系统架构的视图，而非UML自身的组成部分。根据OMG标准，UML的官方结构为：
构造块（元素、关系、图）
规则（语法、语义）
公共机制（扩展、修饰等）
用户可能将“架构”理解为UML支持的系统建模视角，而非UML本身的构成部分。不过，这种分类方式在实际应用中较为常见，用于强调UML的多视角建模能力。
总结
构造块提供建模的基本元素。
公共机制确保灵活性与一致性。
架构通过多视图描述系统结构。
在UML中，有两种类型的图：结构图和行为图。
- 结构图用来描述事物之间的关系；包括类图、对象图、组件图和部署图。
- 行为图用来描述参与者和用例之间的交互，或者描述参与者如何使用系统；行为图包括用例图、顺序图、活动图、状态图和通信图。
UML（统一建模语言）通过10种图形从不同视角描述软件系统
用例图（Use Case Diagram）
从外部用户的角度描述系统的功能需求，展示参与者（Actor）与用例（Use Case）之间的交互。
（1）参与者。参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。
（2）用例。用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
（3）通信关联。通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者。如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。
用例是用户价值驱动的需求分析工具，通过场景化的交互描述，架起业务需求与技术实现的桥梁。其核心在于回答三个问题：
谁（参与者）通过系统做什么（用例）？
为什么要做（价值目标）？
如何完成（流程与规则）？
掌握用例建模，能有效避免“开发人员觉得做完了，用户觉得没实现”的经典矛盾，是软件工程中需求管理的核心技能。
在用例（Use Case）的层次划分中，Essential Use Cases（本质用例，也叫 “抽象用例”） 和 Real Use Cases（实际用例，也叫 “具体用例”） 是从 “用户目标本质” 到 “系统实现细节” 的两个核心层级，二者的核心区别在于是否包含技术实现细节，以及关注焦点是 “用户意图” 还是 “系统操作流程”。核心是为了在不同项目阶段选择合适的用例类型，避免需求与设计脱节：
- Essential Use Cases（本质用例）：聚焦于用户的 “意图” 和 “目标”，描述 “用户想做什么”，完全剥离任何技术实现细节（如界面按钮、输入方式、系统交互载体），只保留 “用户与系统的核心价值交互逻辑”。它是用例的 “抽象层”，不依赖具体的系统设计或技术选型。需求分析阶段（早期）：优先使用本质用例。本质用例能帮助团队（产品、开发、用户）达成 “需求共识”，避免因技术选型争论（如 “先做 APP 还是网页”）而延误需求确认。
- Real Use Cases（实际用例）：聚焦于 **“如何通过具体系统实现用户目标”**，在本质用例的基础上，加入了完整的技术实现细节（如界面操作、输入格式、系统反馈方式、第三方集成步骤），描述 “用户在特定系统中具体做什么、怎么做”。它是用例的 “具体层”，直接对应最终系统的操作流程。系统设计 / 开发 / 测试阶段（中后期）：优先使用实际用例。
用例之间的四种关系（包括泛联）
关联关系（Association）
作用：表示参与者与用例之间的基础交互
表示方法：直线连接（无箭头）
何时使用：当参与者直接参与/触发某个用例时
是最基础的关系类型
不涉及方向性（双向交互）
包含关系（Include）
定义：表示一个用例必须包含另一个用例的行为。
特点：
被包含的用例是基础功能，通常不可独立执行。
包含关系用于提取公共行为，避免重复。
UML表示：用一条带箭头的虚线表示，箭头指向被包含的用例，线上标注
<<include>>。示例：
用例A：
登录用例B：
验证用户关系：
登录必须包含验证用户的行为。
扩展关系（Extend）
定义：表示一个用例可以在特定条件下扩展另一个用例的行为。
特点：
扩展用例是可选的，只有在满足特定条件时才会执行。
扩展关系用于描述可选或异常行为。
UML表示：用一条带箭头的虚线表示，箭头指向被扩展的用例，线上标注
<<extend>>。示例：
用例A：
支付用例B：
使用优惠券关系：
支付可以扩展使用优惠券的行为（如果用户选择使用优惠券）。
泛化关系（Generalization）
定义：表示一个用例是另一个用例的特化（子用例继承父用例的行为）。
特点：
子用例继承父用例的行为，并可以扩展或重写父用例的行为。
泛化关系用于描述用例之间的继承关系。
UML表示：用一条带空心箭头的实线表示，箭头指向父用例。
示例：
父用例：
支付子用例：
信用卡支付、支付宝支付关系：
信用卡支付和支付宝支付是支付的特化形式。
| 关系类型 |
描述 |
特点 |
UML表示 |
|---|---|---|---|
| 包含关系 |
一个用例必须包含另一个用例的行为 |
被包含用例是基础功能，不可独立 |
虚线 + |
| 扩展关系 |
一个用例可以扩展另一个用例的行为 |
扩展用例是可选行为 |
虚线 + |
| 泛化关系 |
一个用例是另 |
最低0.47元/天 解锁文章
扫一扫
991
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
