OOAD

StarUML汉化

StarUML 中文汉化版语言翻译包 Chinese Language Translation Package (github.com)

各种图总结

定义

用况图：对一个系统的参与者、用况以及它们之间的关系进行可视化表示的模型图

类图：描述了系统中各对象的类型和它们之间的关系，在OO方法中，类图是最重要的图，注重表达系统的静态结果

顺序图是强调消息时间顺序的交互图

通信图是强调接收和发送消息的对象的结构组织的交互图

活动图描述了在一个过程中，顺序的/并行的活动及其之间的关系

状态机图，描述单个对象的动态行为

包图就是用来描述包及其关系的图

构件图展现构件类型的定义，偏向于描述构件之间的相互依赖

部署图表现构件实例，偏向描述构件在节点中运行时的状态，描述构件运行的环境

组成元素

用况图的组成元素：系统边界，参与者，用况，用况之间的关系（继承，包含，扩展）

类图的组成元素：类名，属性名，方法名，类之间的关系（继承，关联，聚合，组合，依赖，实现）

顺序图的组成元素：由对象（参与者）、消息、生命线和激活组成；生命线是垂直虚线；激活是矩形条，表示一个对象直接或者通过从属例程执行一个行为的时期

通信图的组成元素：对象，链接，链接上的消息

活动图的组成元素：开始节点和结束节点：开始节点是实心圆，结束节点是同心圆；动作和活动：就是图中的矩形框；箭头：表示从一个动作或活动到下一个动作或活动的转移；同步条：表示并发控制流的分岔和汇合，即图上的黑色长条；分支与合并：就是图上的菱形；控制流：一系列的动作和活动的执行构成了一个控制流；对象流：从开始到结束一系列下来；有的图也会有泳道

状态机图的组成元素：初始状态：实心圆，与活动图的初始状态一样；结束状态：同心圆，与活动图的结束状态一样；一般状态：圆角矩形；状态转换：实线的叉形箭头；事件：依附于表示迁移的箭头

构件图和组件图组成元素相同：构件、接口、构件实例；构件向外界提供的服务（实现接口）；构件向外界要求的服务（依赖接口）

画法

用况图：

类图：

顺序图：

通信图：

活动图：

状态机图：

包图：

构件图：

部署图：

OOAD概述

OOM

面向对象方法（OOM）

80年代，出现面向对象方法（OOM）

OOM基本思想

客观世界中的事物都是对象，对象间存在一定关系，复杂对象由简单对象组成

具有相同属性和操作的对象属于一个类，对象是类的一个实例

类之间可以有层次结构，子类继承父类的全部属性和操作，且可有自己的属性和操作

类有封装性，隐藏或公开自己的属性或操作；对象只能通过消息请求其他对象或自己的操作

强调运用人类日常思维方法

对象，属性，操作，类

类间关系

继承（泛化），关联，聚合（是关联的一种），组合，依赖，实现

OOM的优点

与人们认识世界的方法相对应：对象对应问题域中的事物，继承、聚合、依赖和关联关系如实反映问题域事物之间的关系

使客观世界到计算机语言的鸿沟变窄：面向对象语言比非面向对象语言更接近问题域

易于维护和复用

提高软件质量和生产效率

面向对象方法发展史

雏形阶段

完善阶段

繁荣阶段

面向对象基本特征

封装

多态

接口/实现

抽象

分类

消息通信

OOA

面向对象分析（Object Oriented Analysis）

OOM的三个阶段

OOA（面向对象分析，Analysis）

OOD（面向对象设计，Design）

OOP（面向对象编程，Programming）

OOA和OOD的界限有时是模糊的

OOA

不考虑实现，只找出所需对象及对象间关系，一般会确定对象有哪些属性和操作

OOD

根据与实现有关的因素，定义对象中操作的实现，对OOA模型修改和补充，得OOD模型

OOP

按OOD模型，进行编程实现

OOA面临的主要问题

问题域和系统责任的复杂性日益增长

问题域：被开发系统的应用领域，即系统的业务范围

系统责任：所开发的系统应该具有的功能

交流问题

开发人员与领域专家交流

开发人员之间的交流

开发人员与管理人员交流

需求的不断变化
软件复用的要求

OOA模型

去年考了这个

OOA过程

建立用况图，发现对象，定义属性和服务，建立结构和连接，建立交互图、状态图、活动图

旁边写详细说明和原型开发

每一个都会往前指箭头

我就猜今年考这个

建立需求模型——用况图

对一个系统的参与者、用况以及它们之间的关系进行可视化表示的模型图，称为用况图

以直观形式展示了系统的用户需求

是系统的需求模型

示例

系统边界

注意：已开发的软件系统，位于边界外

参与者

是在系统之外（透过系统边界）与系统进行交互的任何事物

定义了一组在功能上密切相关的角色

向系统发出请求，系统以某种形式响应

系统也可向参与者发出请求，参与者予以响应

参与者之间会有继承关系

用况

一个用况描述系统级的一项功能

强调参与者和系统彼此为对方做了什么，不关心怎么做，也不关心间接做了什么

用况之间关系

包含

扩展

继承

包含

包含，箭头为虚线，箭头上写<<include>>

扩展

扩展，箭头为虚线，箭头上写<<extend>>

继承

看不明白是吧？我也看不明白

还是看看远方的例子吧

例子

在面向对象分析与设计（OOAD）中，用例图是一种常见的工具，用于描述系统的功能和用户与系统的交互。在用例图中，用例之间的关系主要有两种：包含关系和扩展关系。

包含关系：当一个用例（基础用例）的行为包含另一个用例（被包含用例）的行为时，就形成了包含关系。例如，如果我们有一个“购物”用例，这个用例可能包含“浏览商品”和“结账”等子用例。在这种情况下，“购物”用例就包含了“浏览商品”和“结账”用例。

扩展关系：扩展关系是在基础用例之上添加新的行为，基础用例必须声明某些特定的扩展点，扩展用例只能在这些扩展点上扩展新的行为。例如，我们有一个“购物”用例，可能在某些情况下，用户想要使用优惠券。这时，我们可以创建一个“使用优惠券”用例来扩展“购物”用例。扩展关系通常用于在基础用例上添加新的功能或行为。这些新的功能或行为并不总是需要的，只有在满足特定条件时，才会被执行。

总的来说，包含关系强调的是用例之间的必要性，即基础用例必须包含被包含用例的行为。而扩展关系强调的是用例之间的可选性，即在特定条件下，基础用例可以扩展新的行为。

让我们通过一个在线购物系统来详细解释一下包含关系和扩展关系。

包含关系：假设我们有一个名为“在线购物”的用例。在这个用例中，用户可能需要执行一系列的步骤，如“浏览商品”，“添加商品到购物车”，“结账”。这些步骤本身也可以被视为独立的用例，因为它们各自都有完整的功能。但是，它们是“在线购物”用例的一部分，因此，我们说“在线购物”用例包含了“浏览商品”，“添加商品到购物车”，“结账”这些用例。又比如，如果你想在用况图中表示“登录后才能购买商品”，你可以使用包含关系来表示这个逻辑。具体来说，你可以创建一个名为“购买商品”的用例，并让它包含一个名为“登录”的用例。这样，就表示用户必须先执行“登录”用例，然后才能执行“购买商品”用例。

扩展关系：现在，假设我们的在线购物系统想要添加一个新的功能，即“应用优惠券”。这个功能并不是每次购物都会用到，只有在用户拥有优惠券并且想要使用它时，才会用到。因此，我们可以创建一个新的用例“应用优惠券”，并将其作为“在线购物”用例的扩展。这样，只有在满足特定条件（用户有优惠券并想要使用）时，“在线购物”用例才会包含“应用优惠券”用例的行为。

我感觉这个例子比上面图好理解多了，用了20年的PPT含金量确实低

建立基本模型——类图

在OO方法中，类图是最重要的图

它描述了系统中各对象的类型和它们之间的关系

注重表达系统的静态结果

比如这个类图

分成三个部分：类名，类中属性，类中方法

属性可见性对应的符号：

公有的（+）

受保护的（#）

私有的（-）

类之间的关系

继承

关联

聚合/组合

依赖

泛化

就是继承

单继承

多继承

抽象类

画图如下：

关联

如果一个类的对象与另一个类的对象之间有语义连接关系，则这两个类之间的语义关系称为关联

关联的画法，有三种，分别对应了三种关联类型

注意，关联的三种画法都是实线

关联类型

双向：双向关联就是双方各自持有对方类型的成员变量

单向：比如用户类和地址类，用户类里有地址类的属性，但是地址类里没有用户类的属性

自关联：比如链表的Node*，指向下一个Node的指针，即类的属性对象类型为该类本身

聚合

是表示整体的类和表示部分的类之间的“整体-部分”关系

聚合也是一种关联

聚合的画法，整体的部分有一个菱形，然后指向部分

至于空心还是实心，应该问题不大，我看都有

组合

是聚合的一种，且整体管理部分的生存期

依赖

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联

在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责

在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类

依赖，箭头是虚线

实现关系

是用来规定接口和实线接口的类或者构建结构的关系，接口是操作的集合，而这些操作就用于规定类或者构建的一种服务

在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作

和继承有区别：用的虚线

六种关系紧密程度

泛化=实现>组合>聚合>关联>依赖

类关系画图总结

继承：实线，用的三角箭头

关联：实线，对应三种关联关系：双方各自持有对方类型的成员变量；用户类里有口令类的属性，但是口令类里没有用户类的属性，单向箭头；链表的指针，类的属性对象类型为该类本身

聚合：实线，并且总体的地方有一个小菱形，指向部分

组合就是聚合

依赖：虚线箭头

实现：类似继承，但用的是虚线箭头

建立辅助模型

交互图是顺序图和通信图的统称

顺序图

顺序图是强调消息时间顺序的交互图

是一种详细描述对象间以及对象与参与者之间交互的图

组成元素

一个顺序图只描述一个控制流

由对象（参与者）、消息、生命线和激活组成

生命线是垂直虚线

激活是矩形条，表示一个对象直接或者通过从属例程执行一个行为的时期

同步消息用实线箭头，同步消息返回用虚线箭头

通信图

通信图是强调接收和发送消息的对象的结构组织的交互图

显示绕着对象以及对象之间的链而组织的交互

通信图和顺序图可以相互转换

组成元素

矩形：对象

链：链接

链上的字：链接上的消息

通信图和顺序图的区别与联系

顺序图和通信图都是交互图

顺序图：强调按时间顺序的对象间动态交互关系

协作图：强调接受和发送消息的对象的结构组织

顺序图的组成：对象(参与者)/消息/生命线/激活

通信图的组成：对象/链接/链接上的消息

活动图

活动图描述了在一个过程中，顺序的/并行的活动及其之间的关系

活动图显示从活动到活动的流

组成元素

开始节点和结束节点：开始节点是实心圆，结束节点是同心圆

动作和活动：就是图中的矩形框

箭头：表示从一个动作或活动到下一个动作或活动的转移

同步条：表示并发控制流的分岔和汇合，即图上的黑色长条

分支与合并：就是图上的菱形

控制流：一系列的动作和活动的执行构成了一个控制流

对象流：从开始到结束一系列下来

有的图也会有泳道

状态图

状态机图，描述单个对象的动态行为

描述了一个对象在其生命期内响应事件所经历的状态序列，以及对这些事件所做的反应

组成元素

初始状态：实心圆，与活动图的初始状态一样

一般状态：圆角矩形

结束状态：同心圆，与活动图的结束状态一样

状态转换：实线的叉形箭头

事件：依附于表示迁移的箭头

包图

包图就是用来描述包及其关系的图

两种画法：

设计模式

设计模式不是“创建”出来的，而是在大量软件中“提炼”出来的

设计模式的特点

描述了一个反复出现的问题

描述了核心的解决方案

其他人可以无数次地使用这个方案解决类似的问题

策略

策略（Strategy）模式，定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户

把变化的部分，封装起来（用一个接口存储对应的方法集合，需要用到哪个就用哪个实例化）

面向接口设计（编程），而不是面向实现

能用组合的地方，不要用继承

比如这个，就用的两种Behavior接口，每种接口对应了多种实现方法

下面用哪个，就用哪个来初始化

完美支持开闭原则

工厂

工厂模式定义了一个创建产品对象的工厂接口，将实际创建工作推迟到子类中

把构造函数放在具体的函数里

抽象工厂

抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式

产品族：在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品，如海尔电器工厂生产的海尔电视机、海尔电冰箱，海尔电视机位于电视机产品等级结构中，海尔电冰箱位于电冰箱产品等级结构中，海尔电视机、海尔电冰箱构成了一个产品族

产品等级结构：产品等级结构即产品的继承结构，金椅子，银椅子，木椅子

工厂的工厂

观察者

观察者（Observer）模式又叫做发布-订阅（Publish/Subscribe）模式

定义对象之间的一对多依赖关系，当一个对象改变状态时，所有依赖于它的对象都会自动获得通知

Monitor类把Observer添加到登记列表，然后检测对应事务

如果更新，就调用提醒函数notify，会遍历注册列表，调用全部update函数进行更新

PPT的例子太啥b了，书上例子清晰明白

适配器

适配器模式(Adapter Pattern)：将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)

适配器模式既可以作为类结构型模式，也可以作为对象结构型模式

对象适配器

Adapter（适配器类）：适配器可以调用另一个接口，作为一个转换器，对Adaptee和Target进行适配，适配器类是适配器模式的核心，在对象适配器中，它通过继承Target并关联一个Adaptee对象使二者产生联系

Adaptee（适配者类）：适配者即被适配的角色，它定义了一个已经存在的接口，这个接口需要适配，适配者类一般是一个具体类，包含了客户希望使用的业务方法，在某些情况下可能没有适配者类的源代码

Target（目标抽象类）：目标抽象类定义客户所需接口，可以是一个抽象类或接口，也可以是具体类

如图，Adapter实现了Adaptee和Target的适配：Adapter的函数与Target函数名一致，功能实现上调用了Adaptee的函数

类适配器

本质是一样的

都是用Adapter，函数名为需要适配的Target的函数，函数执行里面调用Adaptee的函数

外观

外观（Facade）模式用于为子系统中的一组对象提供统一接口，使系统更易于使用

通过“量身定做”来建立提供所需功能的接口

外观角色（Facade）：是模式的核心，他被客户client角色调用，知道各个子系统的功能。同时根据客户角色已有的需求预订了几种功能组合

子系统角色（Subsystem classes）：实现子系统的功能，并处理由Facade对象指派的任务。对子系统而言，facade和client角色是未知的，没有Facade的任何相关信息；即没有指向Facade的实例

客户角色（client）：调用facade角色获得完成相应的功能

例子

优缺点

优点

1）对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少

2）实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可

3）降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象

4）只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类

缺点

1）不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性

2）在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”

OOD

面向对象设计原则

OCP，开-闭原则，系统对扩展开放，对修改封闭

依赖倒置原则，程序要依赖于抽象接口，不要依赖于具体实现

能用组合的地方，不要用继承

面向接口设计/编程，而不要面向实现设计/编程

把变化的部分，封装起来（隔离变化）

OOD模型框架

正面的4个东西就是张宏鸣只花了一节课40分钟讲的

真不算重点吧

物理建模

物理建模：描述组件和节点之间的关系

构件图和部署图都是物理建模

构件图（组件图）

组成元素

构件和接口

端口

构件和类

部署图（配置图）

组成元素

画图的问题

用况图

对一个系统的参与者、用况以及它们之间的关系进行可视化表示的模型图，称为用况图

以直观形式展示了系统的用户需求，是系统的需求模型

画用况图碰到的问题

我在“购买商品”这个用况引出来了3个包含，分别是：登录、修改购买数量、清除购买操作

根据bing的回答，购买商品前必须登录，要用到<<include>>：

在用况图中，如果你从“购买商品”这个用例引出一条箭头，指向“登录”这个用例，并在箭头上标注<<include>>，那么这就表示“购买商品”用例包含了“登录”用例的行为。也就是说，用户必须先登录，然后才能购买商品。

如果你从“购买商品”这个用例引出另外两条箭头，分别指向“修改购买数量”和“清除购买操作”这两个用例，并在箭头上标注“<<include>>”，那么这就表示“购买商品”用例包含了这两个子用例的行为。也就是说，用户在购买商品时，可以修改他们购买的商品数量，或者在某些情况下，他们可以清除购买操作。

那为什么对于“登录”是必须的，但是对于“清除购买操作”是在某些条件下，这两个同样都是用<<include>>

这是因为“登录”和“清除购买操作”在购物过程中的角色不同。

对于“登录”，这是一个必要的步骤，因为用户需要验证他们的身份才能进行购买。这就是为什么我们说用户必须先登录。

然而，“清除购买操作”并不总是必要的。只有在用户决定他们不想购买已经添加到购物车的商品时，才需要执行这个操作。这就是为什么我们说“清除购买操作”只在某些条件下发生。

总的来说，这两个用例都是“购买商品”用例的一部分，但它们在购物过程中的角色和重要性是不同的。

在用况图中需要考虑到类图吗？比如我在用况图中画了“购买商品”这个用况但没说怎么实现，我在类图里定义了一个叫“购物车”的类用来实现购买商品这个功能，我需要修改用况图吗

用况图和类图是两种不同的UML图，它们关注的是不同的方面。

用况图主要关注的是系统的功能和用户与系统的交互，它描述的是“系统可以做什么”，而不是“系统是如何做的”。因此，你在用况图中定义的“购买商品”用例，只需要描述用户可以进行购买商品这个操作，而不需要具体说明这个操作是如何实现的。

类图则主要关注的是系统的结构，它描述的是系统的各个部分以及它们之间的关系。在你的例子中，“购物车”类就是类图中的一个部分，它可能会有一些方法（如添加商品、删除商品等）来实现购买商品这个功能。

总的来说，你不需要因为在类图中定义了“购物车”类就去修改用况图。用况图和类图是相互独立的，它们各自描述了系统的不同方面。

类图

在OO方法中，类图是最重要的图

它描述了系统中各对象的类型和它们之间的关系，注重表达系统的静态结果

画类图碰到的问题

我在用户类里有一个购物车属性，在购物车类里有一个用户ID属性，那么购物车类和用户类是双向关联吗

在你的情况下，“用户”类和“购物车”类之间的确存在双向关联。在“用户”类中，有一个“购物车”属性，表示用户拥有一个购物车；在“购物车”类中，有一个“用户ID”属性，表示购物车属于一个特定的用户。这种关系在UML类图中通常表示为双向箭头。

即使购物车类里没有“用户”这个类本身，只需要有“用户”类里的“用户ID”这一属性，就算是双向关联？

是的，你理解得很对。在UML类图中，如果“购物车”类有一个属性是“用户ID”，并且“用户”类有一个属性是“购物车”，那么这两个类之间就存在双向关联。即使“购物车”类中没有包含整个“用户”类，只有“用户ID”，这仍然被视为双向关联，因为“用户ID”提供了足够的信息来识别特定的“用户”。这种关系在UML类图中通常表示为双向箭头。

“管理员”类和其他类的关系：

管理员
+用户信息审核()
+查看用户信息()
+删除用户信息()
+查看商品信息()
+修改商品信息()
+增加商品()
+删除商品()
+查看订单()
+修改订单状态()
+售后服务处理()

管理员可以修改用户、商品、订单的信息，所以管理员类对用户、商品、订单是依赖关系，虚线从管理员类开始，箭头指向这三个类

关于“购物车”类和“商品”类

一个购物车可以包含多个商品，但是一个商品只能属于一个购物车

这样可以表示出购物车是一个整体，而商品是它的一部分

所以应该是“聚合”关系

聚合的画法，整体类处是空心菱形，实线连到部分类

通信图

通信图也称作“协作图”

是一种强调发送和接收消息的对象结构组织的交互图，显示绕着对象以及对象之间的链而组织的交互

一张通信图只描述一个控制流

顺序图和通信图可互相转换

画通信图碰到的问题

如果在功能设计中用到了数据库，需要在类图里画数据库类吗

在UML类图中，通常会将数据库表示为一个或多个类。这些类代表了数据库中的表，类的属性对应于表的列，而类的实例对应于表的行。

例如，如果你的系统中有一个用户数据库，那么你可能会在类图中创建一个名为“User”的类。这个类的属性可能包括“username”，“password”，“email”等，这些属性对应于用户数据库表中的列。

然而，这并不意味着你需要在类图中为数据库本身创建一个类。数据库通常被视为存储类的实例的持久化机制，而不是类图的一部分。

另外，如果你的系统中使用了特定的数据库操作（如查询、更新或删除操作），你可能需要为这些操作创建相应的方法。这些方法可以被添加到与数据库交互的类中，或者可以被封装在一个专门的“数据库访问对象”（Data Access Object, DAO）类中。

总的来说，是否在类图中包含数据库类，以及如何表示数据库，主要取决于你的具体需求和设计决策。希望这个答案能帮到你！

如果两个信息的重要程度相同，比如用户查看一个商品的详细信息，和搜索一个商品，这两个信息的重要程度完全一样，我怎么安排这两个信息流的顺序

在通信图中，消息的序号代表了消息发送的顺序，而不是消息的重要性。如果两个消息的重要性相同，那么你可以根据它们在实际操作中出现的顺序来决定它们的序号。

例如，如果一个用户首先需要搜索一个商品，然后查看该商品的详细信息，那么你可以先发送一个搜索请求，然后发送一个查看详细信息的请求。这样，搜索请求的序号将小于查看详细信息请求的序号。

然而，如果这两个操作是独立的，也就是说，用户可以在不进行搜索的情况下查看商品的详细信息，那么这两个消息可以有相同的序号。这表示这两个操作可以在任何顺序下进行。

总的来说，你可以根据实际的使用场景和需求来决定通信图中消息的顺序。

如果在顺序图里定义了1“添加商品到购物车”，2“修改购物车”，3“结账”三个信息，但是我如果进行了1，不进行2的修改操作，能不能直接跳转到3结账

完全可以在执行了“添加商品到购物车”操作后，直接跳转到“结账”操作，而不进行“修改购物车”操作。在这种情况下，“修改购物车”操作可以被视为一个可选的步骤。

在顺序图中，你可以通过在消息序号旁边添加一个星号（）来表示这个消息是可选的。例如，你可以将“修改购物车”的序号标记为“2”，以表示这是一个可选的步骤。

总的来说，顺序图应该能够准确地反映出系统的行为，包括哪些步骤是必需的，哪些步骤是可选的。

在画图时可以用这些方法指明步骤是否是可选的：

一种可能的方法是在消息的标签中明确指出该步骤是可选的。例如，你可以将消息标签为“可选：修改购物车”，以此来表示这是一个可选步骤。

另一种可能的方法是在图的旁边添加注释，解释哪些步骤是可选的。

顺序图

画顺序图碰到的问题

时序图中，我如果平台对数据库发送一个匹配信息，数据库返回一个返回结果，匹配信息和返回结果都用实线吗？还是说返回结果用虚线？

在UML时序图中，平台对数据库发送的匹配信息通常用实线和实心箭头表示，这被称为同步消息。这表示消息的发送者（在这种情况下是平台）在继续下一个消息前，会等待消息的接收者（在这种情况下是数据库）处理消息并返回。

而数据库返回给平台的结果通常用虚线和开放箭头表示，这被称为返回消息1。返回消息表示从过程调用返回。

所以，你可以使用实线和实心箭头来表示平台发送给数据库的匹配信息，然后使用虚线和开放箭头来表示数据库返回给平台的结果。

顺序图是不是每一个信息都要有一个返回信息?

在UML顺序图中，并不是每一个消息都需要有一个返回消息。返回消息通常用于表示从过程调用返回，它通常在同步消息后出现。同步消息是指一个对象向另一个对象发出的消息，发出消息的对象会等待接收消息的对象完成处理并返回。

然而，并非所有的消息都需要返回消息。例如，异步消息就不需要返回消息。异步消息是指一个对象向另一个对象发出的消息，发出消息的对象在发出消息后可以进行其他操作，不需要等待接收消息的对象的响应。

在通信过程中，同步消息通常需要返回消息。同步消息是指，在发出一个功能调用时，在没有得到结果之前，该调用就不返回。也就是说，发送同步消息的一方会等待接收方处理完消息并返回结果。这种机制确保了消息的发送者能够知道消息是否被成功处理。

然而，具体的实现可能会根据你的设计需求和约束有所不同。例如，某些系统可能会选择使用异步消息，这种情况下，消息的发送者在发出消息后不会等待接收者的响应，而是可以立即进行其他操作。

总的来说，同步消息通常需要返回消息，但这并不是绝对的，具体取决于你的系统设计。

即同步消息用实心三角箭头，异步消息用普通箭头

同步消息返回用虚线普通箭头