一、用例图

用例图的基本概念

用例图描述一组用例、参与者及它们之间的关系，它以用户为中心，关注用户对系统的使用需求和期望。

1. 参与者：我们所理解的client

2. 用例：是系统中一个完整的功能单元，每个用例对应系统的一项特定功能。例如，“新增书籍信息”、“查询书籍信息”、"登记外借信息"等都是用例，每个用例都代表系统为用户提供的一个完整功能。

 

1. 用例模型建立的系统化流程

建立用例模型是一个系统化的过程，需要按照特定的步骤进行，确保模型的完整性和准确性。

第一步：识别参与者

1. 用户：是使用系统功能的人，如普通使用者、管理员等。在识别用户参与者时，需要考虑不同角色的用户，他们可能有不同的权限和需求。例如，在图书管理系统中，除了图书管理员，还可能有普通读者、系统管理员等不同角色的用户。

2. 组织是以集体形式与系统交互的机构，例如企业、学校等。当系统需要与外部组织进行交互时，这些组织也可以作为参与者。例如，图书管理系统可能需要与出版社系统进行数据交换。

3. 外部系统：是与本系统进行数据交互或功能协作的其他系统。在现代软件系统中，系统间的集成越来越重要，识别外部系统参与者有助于理解系统的边界和接口需求。

4. 时间也可作为参与者，例如系统在特定时间触发某些自动任务，像定时备份、定时统计等。此外，传感参数（如温度、湿度、速度）也可能作为特殊参与者，当系统根据这些参数变化触发相应功能时，它们就扮演了参与者角色。

 

第二步：合并需求获得用例

将收集到的各种需求进行梳理、整合，从中提炼出系统的功能单元，即确定用例。

这个过程需要从用户的需求描述中提取出具体的功能点，然后将相关的功能点合并成一个完整的用例。例如，从用户对系统操作的需求中，确定"查询信息"、"修改数据"等用例。每个用例应该代表一个完整的、对用户有价值的功能。

 

第三步：细化用例描述

对每个用例进行详细说明，包括用例的前置条件、后置条件、基本事件流、扩展事件流等。

• 前置条件：描述了用例执行前系统必须满足的条件，例如"用户登录"用例的前置条件可能是"用户已注册"。

• 后置条件：描述了用例执行后系统应该达到的状态，例如"新增书籍信息"用例的后置条件可能是"书籍信息已保存到数据库"。

• 基本事件流：描述了用例的正常执行流程，例如"查询信息"用例的基本事件流包括：用户输入查询条件、系统验证输入、系统执行查询、系统返回结果。

• 扩展事件流：描述了异常情况的处理，例如查询条件无效、数据库连接失败等情况的处理。
   

第四步：调整用例模型（可选步骤）

分析用例之间的关系，根据分析结果对用例模型进行调整优化，确保模型的合理性和准确性。

这个步骤包括分析包含关系（一个用例包含另一个用例的功能）、扩展关系（一个用例在特定条件下扩展另一个用例功能）、泛化关系（用例之间的继承关系）等。

 

2. 用例之间的关系类型

 

二、类图与对象图

概念

类图的关键元素

• 类名、方法名、属性名：类名标识类的名称；方法名是类中定义的操作；属性名是类所具有的特征。例如，“书籍”类有书号、书名等属性，以及新增、修改等方法9。
• 多重度：表示关联关系中对象的数量关系。例如，“书籍列表”与“书籍”之间是一对多（1对0…*）关系10。
• 关系：类与类之间存在多种关系，如继承关系（如“非计算机类书籍”“计算机类书籍”继承自“书籍”）和关联关系（如“书籍”与“借阅记录”相关联）。

多重度（Multiplicity）是在类图等建模工具中用于表示关联关系中对象数量对应关系的概念 ，图中几种常见多重度含义如下：

• “1” 表示一对一关系。
• “0…*” 代表一对零个或多个的关系。例如在“班级 -学生”关系中，一个班级可以没有学生（新组建未招生的班级 ），也可以有多个学生 。
• “1…*” 表示一对一个或多个的关系 。比如“订单 - 商品”关系中，一个订单至少会包含一种商品，也可能包含多种商品 。
• “*” 表示一个集合中的一个对象对应另一个集合中的多个对象 。例如在“老师 - 学生”关系中，一位老师通常会对应多个学生 。

 

类之间的关系

语义相关性：语义强度越强相关性越强。

关系类型	定义及示例	图示
依赖关系	定义：若一个事物发生变化会影响另一个事物，二者存在依赖关系。是一种较弱的关系，体现一个类使用另一个类的对象作为局部变量、方法参数等情况。 示例：类A的方法中使用了类B的对象作为参数，此时类A依赖类B。	用带箭头的虚线表示，箭头指向被依赖的类
关联关系	定义：描述对象之间的连接，是一种结构化关系，表明类之间存在某种语义联系。 示例：“学生-课程”关系中，学生和课程之间存在关联。	用实线表示
聚合关系	定义：整体与部分的关系，且整体与部分生命周期不同，部分可以脱离整体独立存在。 示例：“汽车-轮胎”，轮胎可单独存在，即便汽车报废，轮胎可能还能使用。	用带空心菱形的实线表示，菱形指向整体类
组合关系	定义：整体与部分的关系，但整体与部分生命周期相同，部分不能脱离整体单独存在。 示例：“人和心脏”，心脏不能脱离人体单独存活。	用带实心菱形的实线表示，菱形指向整体类
实现关系	定义：用于描述接口与类之间的关系，类实现接口中定义的操作。 示例：类A实现接口B，类A需实现接口B中定义的所有抽象方法。	用带箭头的虚线表示，箭头指向接口
泛化（继承）关系	定义：表示特殊与一般的关系，子类继承父类的属性和方法，同时可添加自己特有的属性和方法。 示例：“猫”类继承“动物”类，“猫”类拥有“动物”类的基本属性和方法，还可定义自己特有的行为。	用带空心三角形的实线表示，三角形指向父类

 

三、顺序图与通信图的交互建模

1. 顺序图

顺序图的基本概念与组成部分

顺序图是一种交互图，它强调对象之间消息发送的顺序，同时显示对象之间的交互关系，为理解系统的动态行为提供了直观的视角。

1. 对象（参与者）：是顺序图中的主要参与者，用矩形表示，代表参与交互的实体。 在ATM交易系统中，对象包括CardReader（读卡器）、ATM（自动取款机）、CustomerConsole（客户控制台）、Session（会话）和Transaction（交易）等。这些对象通过生命线连接，形成交互的基础。

2. 生命线：是对象存在的时间轴，用虚线表示，从对象向下延伸。 生命线表示对象在交互过程中的存在时间，当对象被创建时生命线开始，当对象被销毁时生命线结束。
   在ATM系统中，Session和Transaction对象都有明确的创建和销毁过程，体现了对象的生命周期管理。

3. 激活条：是生命线上的（纵向）矩形框，表示对象正在执行操作的时间段。 当对象接收到消息并开始处理时，激活条开始；当处理完成时，激活条结束。
   激活条清楚地展示了对象的活跃状态，帮助理解对象在交互过程中的参与程度。

 

顺序图中的消息类型

1. 同步消息：是最常用的消息类型，用实心箭头表示，表示发送者等待接收者的响应。这种同步机制确保了交互的顺序性和可靠性。

2. 异步消息：用空心箭头表示，表示发送者不等待接收者的响应。异步消息适用于不需要立即响应的场景。

3. 返回消息用虚线箭头表示，表示从同步调用返回的结果。

4. 参与者销毁消息用生命线底部的"X"标记表示，表示对象的销毁。当Session和Transaction对象完成其使命后，它们的生命线以"X"结束，表示对象的生命周期结束。

 

顺序图中的组合片段

组合片段是顺序图中的重要控制结构，用于表示复杂的交互逻辑，包括循环、条件分支和可选执行等。

1. 循环片段（Loop）：用于表示重复执行的交互序列。
   在ATM交易流程中，当客户希望继续执行交易时，系统会重复执行交易相关的操作。循环片段用矩形框包围，并标注循环条件"while customer wants to perform transaction"，清楚地表达了重复执行的条件。

2. 条件分支片段（Alt）：用于表示基于条件的不同执行路径。
   在ATM密码输入流程中，系统根据密码是否正确选择不同的处理路径。如果密码不正确且未超过两次输入，系统会要求重新输入；如果密码输入超过两次，系统会吞卡；如果密码正确，系统会显示菜单。

3. 可选片段（Opt）：用于表示条件满足时才执行的交互序列。

 

2. 通信图

通信图强调对象之间的链接关系，展示消息的收发顺序。例如，在订单处理系统中，订单与订单项之间的交互可以通过通信图表示。

这是一张通信图，属于交互图的一种，重点展示对象之间消息的收发关系 ，以下是对图中内容的解读：

• 对象：图中存在:aOrder:Order（订单）、:OrderItem（订单项）、dispatchForm:Form（调度表单）、:DeliverOrder（交付订单）、:Product（产品）等对象 。对象名前的冒号表示实例对象，“:”前是对象名，“:”后是类名 。
• 消息：消息用带有编号和名称的箭头表示，编号用于标识消息顺序，名称表示消息操作 。例如：
  • “1: dispatch()” 是aOrder:Order对象发送的调度消息 。
  • “1.1: getPeddleryId()” 是aOrder:Order对象向:OrderItem对象发送的获取货号消息，“*[for each orderItem]” 表示针对每个订单项循环执行 。
  • 消息有实线箭头（表示正常消息传递）和虚线箭头（表示返回消息）之分 ，如“1.2: PeddleryId” 是:OrderItem对象返回给aOrder:Order对象的货号消息 。
• 条件和循环：“[PeddleryId Not Exist]” 是条件判断，当货号不存在时，执行“1.3: create(PeddleryId)” 创建货号的操作 。“*[for each orderItem]” 表示循环操作，针对每个订单项执行相关消息交互 。

 

四、状态图与活动图的动态行为建模

1. 状态图

状态图是对类描述的补充，用于展现此类对象所具有的可能状态，以及某些事件发生时其状态转移情况。通过状态图，我们可以清楚地理解对象在其生命周期中的行为变化。

状态图的基本概念

1. 状态：是对象在某个时刻的特定条件或情况，用圆角矩形表示。
   在热水器的例子中，“Off”（关闭）和"On"（开启）是两个主要状态，分别表示热水器的不同工作状态。

2. 初始状态：用实心圆表示，表示对象生命周期的开始点。从初始状态出发的箭头指向对象的第一个状态，例如热水器从初始状态进入"Off"状态。

3. 终止状态：用实心圆外包围一个圆圈表示，表示对象生命周期的结束或不可逆的条件。在热水器例子中，"烧坏"状态就是终止状态，表示热水器损坏后无法继续工作。

 

状态转换的组成要素

状态转换是状态图的核心要素，它描述了对象从一个状态到另一个状态的变化过程，包含触发事件、监护条件和动作三个重要组成部分。

1. 触发事件：是引起状态转换的外部刺激或内部条件变化。在热水器例子中，“turnOn”（开启）和"水开了"（水沸腾）都是触发事件。触发事件可以是用户操作、系统事件或时间条件等。

2. 监护条件：是用方括号表示的布尔表达式，决定转换是否能够发生。
   当热水器处于"Off"状态时，如果触发"turnOn"事件，系统会检查监护条件"[有水]“（有水）或”[没水]"（没水）。只有当监护条件为真时，转换才会发生。

3. 动作：是用斜杠"/“表示的操作，在状态转换发生时执行。当热水器从"Off"状态转换到"On"状态时，会执行”/烧水"（烧水）动作，开始加热过程。

 

2. 活动图

活动图是一种特殊的状态图，它描述一个操作中要进行的各项活动的执行流程，同时，也常被用来描述一个用例的处理流程或者某种交互流程。

活动图的基本概念

活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它强调对象间的控制流程，是描述业务流程和工作流的重要工具。

1. 活动：是活动图中的基本元素，用圆角矩形表示，代表一个具体的操作。
   在在线订单处理流程中，“用户下订单”、“生成送货单”、"用户选择支付方式"等都是具体的活动。每个活动都代表一个可执行的工作单元。

2. 初始节点：用实心圆表示，表示活动的开始点。

3. 终止节点：用实心圆外包围一个圆圈表示，表示活动的结束点。

 

活动图的控制流元素

活动图通过多种控制流元素来描述复杂的业务流程，包括分支、合并、分叉和汇合等。

1. 决策节点：用菱形表示，用于表示条件分支。

2. 分叉节点：用粗横线表示，用于表示并行活动的开始。
   当用户下订单后，系统会同时执行"生成送货单"和"用户选择支付方式"两个并行活动。分叉节点允许多个活动同时进行，提高了流程的执行效率。

3. 汇合节点：用粗横线表示，用于表示并行活动的结束。
   在订单处理流程中，当"生成送货单"和"收款"两个并行活动都完成后，流程会在汇合节点处合并，然后继续执行"供应商送货"活动。

4. 转换：用箭头表示，用于连接各个活动节点，表示控制流的转移。转换上可以标注监护条件，如"[Yes]“和”[No]"，用于表示条件分支的不同路径。

 

泳道

泳道（Swimlane）是活动图中的一个重要概念，它将活动图划分为不同的区域，每个区域代表一个特定的参与者、部门或系统组件的职责。

在在线订单处理流程图中，清晰地划分了"客户"、"系统"和"供应商"三个泳道，这使得每个参与者负责的活动一目了然，极大地增强了流程的可读性和职责的明确性。通过泳道，我们可以直观地看到不同角色之间的协作和交互，从而更好地理解整个业务流程的协作模式。

 

3. 定时图

定时图（也叫计时图）是一种交互图，用于展示交互过程中的真实时间信息，具体描述对象状态变化的时间点以及维持特定状态的时间段。

定时图的基本概念

定时图是UML中专门用于描述时间相关行为的图，它通过二维坐标系统清晰地展示对象在时间维度上的状态变化，是分析实时系统和时间敏感系统的重要工具。

1. 时间轴：是定时图的横轴，表示时间的流逝。在"标准洗"定时图中，时间轴从0到75，展示了整个洗衣过程的完整时间线。

2. 状态轴：是定时图的纵轴，表示对象可能处于的不同状态。在洗衣机的例子中，状态轴从上到下依次为：浸泡、洗涤、脱水、漂洗，这些状态代表了洗衣机在洗衣过程中的不同工作模式。

3. 状态变化曲线：是定时图的核心元素，用阶梯状的折线表示对象状态的变化过程。水平线段表示对象在某个状态的持续时间，垂直线段表示状态的瞬间改变。

 

定时图的建模价值

定时图在系统建模中具有独特的价值，特别是在需要精确控制时间行为的系统中：

1. 实时系统设计，定时图帮助设计师理解系统的时间约束和性能要求，确保系统能够满足实时性要求。在工业控制系统中，定时图可以指导控制算法的设计，确保各个控制步骤在正确的时间点执行。

2. 性能分析，定时图为系统性能分析提供了直观的工具，通过观察状态持续时间的分布，分析师可以识别性能瓶颈和优化机会。

3. 系统验证，定时图可以作为系统验证的参考标准，通过比较实际系统的行为与预期行为，验证系统是否按照设计要求正确运行。

4. 用户界面设计，定时图帮助界面设计师理解用户操作的时序要求，优化界面的响应时间和用户体验。

 

五、构件图与部署图的系统架构建模

1. 构件图

构件图

构件图是UML中用于描述系统物理结构的重要工具，它展示了系统的各个构件以及它们之间的依赖关系，是大型系统构建和管理的重要基础。

1. 构件：是构件图中的基本元素，用带有两个小矩形的矩形表示，代表系统中可替换的物理部分。在"机房收费系统"的例子中，机房收费系统.exe是主执行文件构件，机房收费系统源代码是源代码构件，而报表、选项卡、窗体、表格等是功能构件。

2. 接口：定义了构件对外提供的服务规范，描述了构件如何与外部环境交互。构件通过接口暴露其功能，其他构件通过接口使用这些功能。

3. 依赖关系：用虚线箭头表示，描述构件之间的使用关系。

 
构件图的实际应用示例：机房收费系统

1. 核心应用构件：包括主执行文件机房收费系统.exe和源代码机房收费系统源代码。主执行文件是整个系统的入口点，而源代码构件包含了系统的核心逻辑和业务规则。

2. 功能构件：包括报表、选项卡、窗体、表格等，这些构件分别负责不同的功能模块。报表构件负责生成各种统计报表，选项卡构件提供标签页界面，窗体构件处理用户界面，表格构件负责数据展示。

3. 外部依赖库：包括gregn50.dll、tabctl32.dll、msconmct2.ocx、mshflexgd.dll等。这些外部库为系统提供了特定的功能支持，如报表生成、标签控制、ActiveX控件和表格显示等。

4. 依赖关系链：清晰地展示了系统的构建层次：主执行文件依赖于源代码，源代码依赖于各个功能构件，功能构件依赖于相应的外部库。这种层次化的依赖关系确保了系统的模块化和可维护性。

 

包图：系统组织的逻辑视图

包图通过将相关的模型元素组织在一起，为大型系统的建模提供了有效的组织方式，提高了模型的可理解性和可维护性。

1. 包：是包图中的基本元素，用带标签的文件夹图标表示，代表一个逻辑分组单元。在"机房收费系统"构件图中，整个系统被组织在一个大的圆角矩形内，这实际上就是一个概念上的包，将相关的构件组织在一起。

2. 包的层次结构：允许包内包含其他包，形成层次化的组织结构。这种层次结构使得大型系统的模型组织更加清晰，便于管理和理解。

3. 包的依赖关系：用虚线箭头表示，描述包之间的使用关系。包之间的依赖关系反映了系统不同模块之间的耦合程度。

在"机房收费系统"的例子中，整个系统被组织在一个概念包内，这个包包含了所有相关的构件：

1. 系统包：将机房收费系统的所有构件组织在一起，包括主执行文件、源代码、功能构件等。这种组织方式使得系统的边界和范围更加清晰。

2. 功能分组：通过包的组织，可以将相关的功能构件分组管理。例如，可以将所有UI相关的构件（窗体、选项卡、表格）组织在一个UI包中，将业务逻辑相关的构件组织在业务包中。

3. 依赖管理：包图帮助识别和管理系统内外的依赖关系。通过包的组织，可以清楚地看到哪些构件属于系统内部，哪些是外部依赖。

 

包图的设计原则

设计包图时需要遵循一些基本原则，以确保模型的有效组织：

1. 内聚性包内的元素应该具有高度的内聚性，即包内的元素应该紧密相关，共同完成特定的功能。

2. 耦合性包之间的耦合应该尽可能低，减少包之间的依赖关系，提高系统的模块化程度。

3. 层次性包的层次结构应该清晰合理，避免过深的嵌套或过浅的组织，保持适当的抽象层次。

4. 命名规范包的命名应该清晰明确，能够准确反映包的内容和职责。

 

2. 部署图

部署图是UML中用于描述系统物理部署架构的重要工具，它展示了系统的硬件节点、软件构件以及它们之间的部署关系，是系统架构设计的重要组成部分。

部署图的基本概念

1. 节点：是部署图中的基本元素，用矩形框表示，代表运行时的处理单元，如服务器、客户端、数据库服务器等。
   在房地产交易系统的例子中，“Bank Server”、"Real Estate Server"和"a PC"都是节点，分别代表银行服务器、房地产服务器和客户端个人电脑。

2. 构件：是部署在节点上的软件单元，用带有两个小矩形的矩形表示。
   在银行服务器节点中，Mortgage Application（抵押贷款应用）和CustomerDB（客户数据库）都是构件，分别负责业务逻辑和数据存储。

3. 接口：定义了构件对外提供的服务规范，用圆形符号表示。
   IMortgageApplication和IListing都是接口，分别定义了抵押贷款应用和列表应用的服务规范。

4. 连接：表示节点之间的物理连接，用实线表示，通常标注连接协议。在房地产交易系统中，客户端PC与银行服务器和房地产服务器之间都通过TCP/IP协议连接。

 
部署图的实际应用示例：房地产交易系统

1. 银行服务器节点包含两个核心构件：Mortgage Application（抵押贷款应用）和CustomerDB（客户数据库）。抵押贷款应用通过IMortgageApplication接口对外提供服务，同时依赖于客户数据库来存储和检索客户信息。这种设计确保了业务逻辑与数据存储的分离，提高了系统的可维护性。

2. 房地产服务器节点包含Listing（列表应用）和MultipleListings（多重列表存储）两个构件。列表应用通过IListing接口对外提供服务，依赖于多重列表存储来管理房地产信息。这种架构支持房地产信息的集中管理和高效检索。

3. 客户端PC节点包含BuyerInterface（买家界面）构件，该构件通过依赖关系连接到银行服务器的IMortgageApplication接口和房地产服务器的IListing接口。这种设计使得买家可以通过统一的界面访问抵押贷款服务和房地产列表服务。

4. 网络连接通过TCP/IP协议将客户端PC与两个服务器节点连接起来，形成了完整的分布式系统架构。这种网络拓扑确保了系统的可扩展性和可靠性。