【基础架构】 01 | 架构到底是什么? - 图1

系统与子系统

系统 子系统
英文 System Subsystem
概念定义 关联个体,规则运作,新的能力 更大系统中的一部分
举例(微信) 微信本身是系统 聊天,朋友圈等是子系统

模块与组件

模块 组件
英文 Module Component
概念定义 一套一致而互相有紧密关联的软件组织。 自包含的、可编程的、可重用的、与语言无关的软件单元。
拆分角度 逻辑 物理
划分目的 职责分离 单元复用
同义词 - 零件
特点 完整 独立且可替换
举例(个人信息管理系统) 登录模块,个人信息模块 Nginx,Web 服务器,Mysql

框架与架构

框架 架构
英文 Framework Architecture
概念定义 实现业界标准的组件规范或实现组件规范的软件产品 软件系统的顶层结构
关注点 规范 结构
举例 组件规范:MVC,J2EE
软件产品:Spring MVC
RUP 的 4+1 视图

架构定义图

image.png

业务逻辑角度分解学生管理系统的架构:
image.jpeg

物理部署的角度分解学生管理系统的架构
image.jpeg

从开发规范的角度分解,“学生管理系统”可以采用标准的MVC框架来开发,因此架构又变成了MVC架构:

image.jpeg

IBM RUP 的 4+1 视图

image.png

中文可以称为用例视图。即4+1中的1。从上图可以看到,4+1中的4个视图都是围绕着用例视图为核心的。

Logical View

逻辑视图:当采用面向对象的设计方法时,逻辑视图即对象模型。()职责划分,逻辑元素的关系

除了对系统职责进行划分,逻辑视图通常还要求对各逻辑元素间的关系,也就是接口进行描述。增加逻辑元素的接口进行描述对系统的设计和实现非常重要。因为软件设计最重要的原则就是高内聚、低耦合,一个满足此原则的系统不应该存在不合理的依赖关系,比如下层与上层间的反向依赖,或是循环依赖等。

一般,逻辑架构元素决定了开发组织(根据康威定律,反之亦然)。因此,逻辑元素的边界和接口也是后续多个开发组织之间进行接口控制的关系依据。设计合理的逻辑架构,可以提升团队的沟通效率,进而提升整个系统的交付效率和质量。

Implementation View

实现视图:描述软件在开发环境下的静态组织。 逻辑元素和代码和二进制交付件的映射

Deployment View

部署视图:描述软件如何映射到硬件,反映系统在分布方面的设计。(安装和部署)

开发出的软件系统,最终是要运行在物理或软件环境上。物理环境可能是服务器、PC机、移动终端等物理设备;软件环境可以是虚拟机、容器、进程或线程。部署视图就是对这个部署信息进行描述,包括:

  • 二进制交付件,与软件环境的部署关系
  • 软件环境与物理环境的部署关系

通过逻辑视图、开发视图加部署视图,我们已经可以知道系统中每一个逻辑架构元素、每一份代码,最终会运行在什么位置上。反向也可以通过运行环境上,找到所有其上运行的逻辑架构元素和代码。

Process View

过程视图

逻辑视图、开发视图和部署视图,描述的都是系统的静态信息,到现在为止我们还缺少对系统动态行为的描述,而运行视图就是用来描述系统中的动态信息的。运行视图最常见的设计工具就是UML的序列图。

运行视图的设计,最常见的是逻辑架构元素之间的交互关系,比如消息交互、服务调用或API调用。

在运行视图中,除了要关注组件间的交互关系,通常还需要考虑并发、抢占、关键资源(比如锁)访问等。

通过4+1视图,我们可以形成一个系统的抽象描述,组织中的所有成员,都要围绕着这个抽象进行设计、实现、验证,并在系统演进中不断完善修正它们。

当然,4+1视图并不能覆盖系统的所有内容,比较系统中使用了哪些关键的技术,或是系统中关键的数据结构和表的设计,在这里都没能体现出来。这需要我们再结合其它的设计技术来完善补充,才能让我们的系统设计更加完整。