逻辑模型

逻辑模型描述系统的逻辑功能模块分解，将系统分解为相应的逻辑功能元素，并描述各逻辑功能元素之间的关系。

元素介绍

表1 逻辑模型元素介绍
元素名	图标	含义
System		广义上，系统是指提供给市场，被客户注意、获取、使用或者消费，并能满足客户某种需求的载体，包括各种有形的物品、无形的电子产品、服务及观念。狭义上，系统指能独立满足客户某种需求、并符合客户的理解及业界划分习惯的实体。
SubSystem		子系统是一个独立的能够满足特定功能的组合，通过一个或多个它所实现的接口来提供行为。完全封装自己的内容，通过接口提供行为。可由组件/模块或更小的子系统组成。是平台或更大的子系统的组成部分，与其他子系统相对独立。必须是交付件（能够支持异步开发和外包）。
Module		系统中一个逻辑上可分离的部分。系统设计中模块特指系统设计阶段输出的系统最小分解部件，系统设计阶段将模块当作黑盒、不涉及模块的内部结构，但要明确给出模块的功能、模块之间的接口。
Service		服务，是指具备明确的业务特征，由一个或多个关联紧密的微服务组成，可直接面向客户/用户进行打包、发布、部署、运维的软件单元。用户可以从业务特征、安装部署、监控运维的角度感知到服务的存在。规模上介于Subsystem与FM（Function Module功能模块）之间的逻辑架构模型元素。Service的功能更加内聚，对外依赖少，接口稳定。
Component		组件，可独立加载、部署和运行的二进制代码，采用轻量级通讯机制、松耦合高内聚的软件架构单元，部署时不能跨节点类型部署（计算机百科全书：组件是软件系统中具有相对独立功能、接口由契约指定、和语境有明显依赖关系、可独立部署、可组装的软件实体）。
SDK		Software Development Kit，软件开发工具包。
Layer		层，辅助图形，不属于架构元素，一般是分层设计，例如网络层、应用层，常见的7层网络模型。
Plane		面，同Layer属于辅助图形，不属于架构元素，在嵌入式系统里常见用户面、管理面等。
MS		MicroService，微服务，是指可独立设计开发部署测试、粒度较小、采用轻量级通讯机制、松耦合高内聚的软件单元。一般来说，用户感知不到微服务的存在。
Domain		域，用于在架构表达、开发管理、对外介绍的过程中，表达系统的层次关系或内部分组，一般由多个服务组成，可以是一级（域）或多级（域/子域，或者域/1级子域/2级子域…）。域和子域不对应实际的设计开发实体，可以根据需要灵活调整。域这个概念，来自于云化产品。以前逻辑架构的实体，这个实体一般指的是子系统，但这个架构实体，带有比较严重嵌入式情节。为此云化产品，习惯用域来表示逻辑架构的实体。
SubDomain		子域，用于在架构表达、开发管理、对外介绍的过程中，表达系统的层次关系或内部分组，域和子域交互使用。
Interface		接口，可以是单个接口，也可以是抽象的一组接口的组合。圆形接口与矩形接口意义相同，仅形状不同。
Provided Interface		暴露接口。提供接口动作，和Required Interface之间建立Association，表明一个组件提供另外一个组件需要的接口。
Required Interface		请求接口。和Provided Interface之间建立Association，表明一个组件需要的接口是由另外一个组件提供的。
Composition		组合，是整体与部分的关系，但部分不能离开整体而单独存在。
Aggregation		聚合，是整体与部分的关系，且部分可以离开整体而单独存在。
Realization		实现，是一种类与接口的关系，表示类是接口所有特征和行为的实现。
Dependency		依赖，是一种使用的关系，即一个类的实现需要另一个类的协助。
Usage		使用，是一种使用的关系。表明一个模块在运行的时候，需要使用另外一个模块。
Association		关联，是一种拥有的关系，它使一个类知道另一个类的属性和方法。

建模规范

逻辑模型至少应建模到组件或微服务粒度
 在4+1视图阶段的逻辑模型应该能够反映系统的真实结构，并达到指导开发及开发分工的详细程度。逻辑模型得到的对象应该是可以构建的软件对象，而不能只是一个概念或功能集合。在4+1视图阶段，不宜进行过于详细的设计，所以也不适合建模到过于详细的程度。
1. 组件化系统
   对于组件化的系统，要求至少建模到组件级别，也可以选择建模到更底层的模块级别。但是由于架构模型主要从宏观上反映系统的全景，因此不建议建模到比模块更底层的级别。
  
  组件化示例。
2. 服务化系统
   对于服务化的系统，要求至少建模到微服务级别。也可以选择建模到更底层的模块级别。但是由于架构模型主要从宏观上反映系统的全景，因此不建议建模到比模块更底层的级别。
3. 模块化系统
   对于模块化的系统，要求至少建模到模块级别。但是由于架构模型主要从宏观上反映系统的全景，因此不建议建模到比模块更底层的级别。

逻辑模型中必须既对架构对象建模，也对关系建模。
逻辑模型必须能够体现出系统的结构，即要体现系统由哪些架构对象构成，也要体现出这些架构对象之间的相互关系。
1. 0层（顶层）架构模型
   “0层”架构图主要是用来进行技术与非技术人员之间的交流，所以他更强调从全局视角展现出系统由哪些主要部分构成，可以不体现关系。
2. 1层架构模型
   其他层架构建模时，即对关键的架构对象进行建模，也对架构对象间的关系进行了建模。只有这样，才能充分说明架构对象在整个系统中所处的位置以及架构对象的职责。

建模示例

示例一
 面向设计人员，描述系统分解及技术方案
1. 逻辑视图描述系统的逻辑分解，以及分解出的逻辑元素间的关系。
2. 逻辑模型划分的服务、组件等元素，是后续其他视图的基准，必须与后续各视图中的相应元素，如开发视图中的实际代码仓、目录以及编译构建工程；部署视图中的交付单元，可部署单元等建立对应关系。
3. 在逻辑视图部件划分时，通常会有用于描述业务功能的业务部件，以及作为技术支撑的技术部件（如数据库，Cache，中间件等），对于这两种类型的部件应采用不同的模型表达，以便支持业务与技术的解耦以及技术部件的替换。
  通过逻辑模型和数据模型描述业务功能，在其中不包含技术元素，以及各部件的具体实现技术方案。逻辑模型和数据模型在本领域中重用。
  
  通过技术模型描述具体的技术方案和技术选型，包括支撑性的技术元素（数据库、Cache，中间件，框架等）。

示例二
 参考建议步骤是按逐层分解的方式绘图设计，示例步骤分解顺序为：System > Subsystem > Component > Module，其它的分解顺序结构可参考该方式调整即可，如果产品线有统一的分解规范要求，以产品线要求规范步骤为准。

实现一个由0层到1层、2层依次展开各层级结构的一个分解逻辑模型图。

0层逻辑模型。

1层逻辑模型。

2层逻辑模型。

创建0层逻辑模型图。
1. 工程初始化创建时会在“逻辑视图 > 逻辑模型”包目录下默认创建一个逻辑模型图，可当作0层逻辑模型，如果是非初始化结构建目录，则选择要创建图的包节点，单击包后的菜单，选择“新建图”。
2. 图类型选择“4+1视图 > 逻辑视图 > 逻辑模型”，输入图名称，单击保存即可。
创建0层模型逻辑元素。

在0层模型图创建完后，从工具箱中拖入System、Subsystem元素到0层逻辑模型图中。
创建1层逻辑模型和逻辑元素。
1. 在Subsystem元素下创建子图，子图即为1层逻辑模型，从工程树上将Subsystem元素拖入到1层逻辑模型图中，选择link方式，然后在该Subsystem元素下添加Component元素，建立逻辑关系。
2. 在0层模型上选中Subsystem元素右键“新增图”或者在工程树上的Subsystem元素节点右键“新增图”，在新增图界面图类型仍为逻辑模型。
3. 元素创建完子图后，在所有图中元素图形右下角有一个眼镜图标，双击该图标可快速打开这个元素的子图，如下图所示：
4. 将Subsystem1以Link的形式拖入1层逻辑模型，如下图所示：
5. 新增的Component组件元素再从工具箱中拖入到图中的Subsystem元素内部，构成包含的父子关系，如下图所示：
创建2层逻辑模型。
1. 参考1层模型创建方式，2层逻辑模型是基于Component1创建子图，如下图所示。
2. 在Component1的子图中引用该父Component1元素到图中，再到图中的从工具箱中创建Module元素到组件下，构成包含的父子关系，在2层模型中会对Module定义对外接口，和使用的接口。
3. Module1暴露实现的接口，提供给外模块调用，连线关系使用Realization。
4. Module2使用其他模块实现提供的接口，以引用的方式拖入图中，连线关系为Usage，如下图所示：