标签：软件 nbsp 转移 bubuko 目标 交互图 展示 分享图片 正式
Unified Modeling Language，统一建模语言或标准建模语言，是一种图形表示方法，以对象思想为基础，是OOAD（Object Oriented Analysis Design）的辅助工具。
相关概念
事物：结构（类、接口、构件等）、行为或动作（交互、状态等）、分组（包、子系统等）、注释（未竟事宜）。
关系：依赖、关联（聚合、组合）、泛化、实现。
图形：用例视图（用例图，需要分析阶段）、逻辑视图（类图、顺序图、协作图、状态图、活动图，设计阶段对用例的实现或流程展示）、组件视图（用于封装）、配置视图（软件元素在物理架构上的部署及交互通信）。
扩展机制
通常的项目开发过程：
1定义用例：情节描述。需要干些什么？确定和编写用例是需求分析的重要手段。注意，用例是文本描述，用例图只是表现用例的一种手段。
2定义领域模型：OOA，识别问题中的概念，是对真实世界的概念和想像的可视化，与具体技术无关。需要几个类？
3定义交互图：分配对象职责并绘制交互图（动态建模，比如顺序图、协作图、活动图、状态图）。类有哪些属性、方法？如何交互？
4定义设计类图：定义软件类包括属性、方法等（静态建模，比如类图）。
此外，通常使用活动图或状态图对企业的流程建模。
2大强力工具：
Rational Rose
PowerDesigner
用例视图、逻辑视图、构件视图、部署视图
注意，左侧列表显示的是数据，右边图形的删除与否不影响数据，可以随意拖动图形数据到任意图形显示区域。选择图形Ctrl+D则删除数据+图形。
必要性是画图的重要原则，即使存在某种关系，但用不上或有更简洁的替换方式则可不画。非画不可则需要注意美观。
确定和编写用例是需求分析的重要手段。注意，用例是文本描述，用例图只是表现用例的一种手段。
用例通常包括参与者、场景（参与者和系统的交互）、系统边界。用例就是一组相关的成功和失败场景集合。
用例的编写方式：
1摘要：需求分析早期使用，通常用于主成功场景。
2非正式：需求分析早期使用，覆盖其他场景。
3详述：详细描述所有步骤及变化。
用例强调用户的目标和观点。谁使用系统？使用的典型场景是什么？目的是什么？用例的名称使用动词开始，尽量使用业务（行业）专业名称而非计算机术语。
用例编写样例：
用例编号
用例名
用例描述
参与者
前置条件
后置条件
基本路径：（主成功场景）
1.
2.
3.
扩展点：（异常场景）
2a.（针对基本路径2的异常情形处理，如果出现带下划线的名词是指另外一个用例）
…另外一个用例
补充说明
用例的发现
选择系统边界 -- 确定主要参与者 -- 确定每个主要参与者的目标 -- 定义满足用户目标的用例，据目标为用例命名
通常习惯：
有多少部门？多少岗位？
找到每个岗位的业务代表，问他们类似的问题：平时工作都做什么？谁交办的？做完需要通知或传达给谁吗？做这些事需要填写什么表格？
Tips：
通常用例的基本路径步骤在10以内，而扩展点则多或少都可能。
包含关系：可以避免用例文本的重复编写。当无法确定是否包含关系或扩展关系时，可将可选路径中的场景抽象为扩展关系。注意，重点是编写用例文本，而不是如何关联用例。
多个用例在行为、结构、目的等方面存在共性时，可使用泛化关系。
描述特定对象所有可能状态，以及由于各种事件的发生引起的状态之间的转移和变化。
Activity Diagram，动态视图之一，描述事物和对象的活动变化过程。实际上就是流程图。
相关概念：状态、活动、活动流、活动流的分叉与合并、活动icyq的分劈与汇合、对象流、泳道。
component
构件是相对独立可装配的物理块，通常做为独立的文件存在。构件具有确定的接口，相互间可以调用，存在依赖关系。
描述系统计算节点的拓扑结构。
接口呈现方式：None、Label、Decoration、Icon
标签：软件 nbsp 转移 bubuko 目标 交互图 展示 分享图片 正式
原文地址：https://www.cnblogs.com/dailycode/p/9424530.html
