文章目录
在软件开发中,架构设计是指对系统的整体结构和行为进行规划和设计的过程。架构设计是系统设计中最重要的环节之一,它将对系统的后续开发、测试、部署和维护产生重大影响。
1. 架构设计的原则
架构设计的原则主要包括以下几个方面:
- 抽象性: 架构设计应该从系统的整体角度进行,关注系统的结构和行为,而不需要考虑具体的实现细节。
- 可扩展性: 架构设计应该考虑系统未来的扩展需求,使系统能够随着需求的变化而进行扩展。
- 可维护性: 架构设计应该考虑系统的维护需求,使系统能够在需要时进行修改和升级。
2. 架构设计的视图
架构设计可以从不同的角度进行,常见的架构设计视图包括:
- 领域视图: 关注系统的不同功能区或领域,如何组织和定义这些领域以及它们之间的关系。
- 子系统或构件视图: 涉及如何将系统进一步分解为子系统或构件,这关系到模块化、重用性及系统的灵活性。
- 并发视图: 关注系统中的并发处理和线程管理,如何有效地在多线程或多处理器环境中管理任务和资源。
- 分布视图: 涉及分布式系统中对象的通信和管理,特别是在不同物理位置或处理器之间的对象交互。
- 安全和可靠性视图: 专注于设计中的安全性和可靠性因素,确保系统在各种情况下都能稳定运行,防止事故发生。
- 部署视图 关注软件体系结构如何映射到物理设备上。
2.1 领域视图
领域视图是架构设计中的一个重要视图,它关注系统的不同功能区或领域,如何组织和定义这些领域以及它们之间的关系。
-
领域的定义:
在软件工程中,领域指的是特定的业务、技术或知识领域,具有自己的术语和专业知识,定义了一组相关的功能、数据和规则,共同描述了一个特定领域的问题或需求。领域角色代表着一组具有共同语义和功能的模型元素。在系统设计中,领域作为分类和组织信息的一种方式,帮助管理庞大而复杂的类结构(子系统 > 构件(组件)> 类)。 -
领域建模:
在建模中,领域被视作包的一种特例,这意味着它们是对包的一种特殊化,用于表示特定主题或功能领域。系统中的所有类几乎都会定义在某个领域中,而每个泛化的分类体系几乎都位于单一领域内。 -
领域的组织:
为了方便管理和开发,领域本身可能被细分为更小的子包,这些子包可以分配给不同的开发人员或团队。这样的组织结构形成了系统的逻辑模型,这个模型关注于类和它们之间关系的逻辑正确性,由子系统和构件模型负责实例化。 -
领域的实际应用:
对象协作通常跨越多个领域以满足特定用例。尽管如此,每个类都被定义在一个单独的领域内,并且当类属于相同的主题内容时,它们被组织到同一个领域中。嵌入式系统中常见的领域示例包括:用户界面、硬件抽象、数据管理、数据通信和报警管理。应用领域会增加更具体的领域,如:导航和引导、姿态控制、麻醉输送、病人监控、飞机瞄准等。 -
领域与子系统的关系:
领域通常定义了可以在许多或所有子系统中实例化的类。例如,所有子系统可能都需要进行总线通信,那么负责管理、发送和接收总线消息的类会在通信领域中定义,并可能在所有子系统中实例化。而有些在特定领域中定义的类可能仅在单一子系统内实例化。例如,尽管航天器的姿态控制子系统可能包含来自多个领域的类实例,但在姿态控制领域中定义的特定类可能仅在姿态控制子系统中实例化。
2.2 子系统或构件视图(简称子系统视图)
子系统或构件视图是架构设计中另一个重要视图,它关注如何将系统进一步分解为子系统或构件,旨在识别系统的主要组成部分及其相互交互,这关系到模块化、重用性及系统的灵活性。
-
子系统或构件的定义:
与领域不同,子系统或构件不是一个逻辑结构,而是一个运行时构件。领域更多地关注于系统的逻辑分割和功能区域,而子系统则关注于实现这些功能的实体。
在实际的系统设计中,子系统通常是指那些实现特定业务逻辑或功能的较大模块。这些子系统可能就是由一组密切相关的构件组成,共同协作以实现更复杂的业务功能。构件在这里充当构建子系统的基本块,每个构件处理子系统中的一部分任务,而整个子系统则负责将这些构件整合在一起,形成完整的业务逻辑或功能。 -
子系统或构件的组成:
子系统或构件是由多个对象组成的,这些对象基于系统运行时,多个对象共同的行为目的进行实例化,而非主题内容进行实例化。这意味着子系统或构件在运行时包含了来自不同领域的类的实例,这些对象在系统运行时协同工作,实现特定的行为或功能。 -
子系统或构件的物理模型:
子系统或构件模型是物理模型的一个组成部分。物理模型不仅包括了子系统或构件本身,还包括部署视图,后者详述了系统在运行时各个构件如何映射到具体的硬件上。
在子系统内部,通常会定义一些特定的类,这些类负责协调和管理领域类实例的运作,包括管理复合对象及其接口。这些类通过确定如何在运行时组织和协调各个领域类实例,从而确保系统按预定方式运作。复合对象及其接口类通常是为了实现特定的功能或行为而设计的,它们结合了多个领域类的能力,以满足更复杂或特定的系统需求。 -
子系统与构件的区别:
子系统通常由构件组成,而不是直接由类实例组成。在UML中,构件是运行时构件,代表系统或子系统中可替换的部分。构件包含各种类型的对象实例,包括作为线程根的活动类(«active» classes)。
活动类对象作为线程的起点或“根”,在这里线程开始执行。活动类对象通常负责启动和管理它们所控制线程的生命周期和执行过程,包括执行特定的任务、处理并发和同步等
2.3 并发视图
并发视图是架构设计中的一个重要视图,它关注系统中的并发处理和线程管理,如何有效地在多线程或多处理器环境中管理任务和资源。
- 线程的识别
- 对象到线程的映射
- 管理线程执行和共享公共资源的规则
2.4 分布视图
分布视图是架构设计中的一个重要视图,它关注分布式系统中对象的通信和管理,特别是在不同物理位置或处理器之间的对象交互。
- 对象的通信协议
- 对象的通信方式
- 对象的部署
2.5 安全和可靠性视图
安全和可靠性视图是架构设计中的一个重要视图,它专注于设计中的安全性和可靠性因素,确保系统在各种情况下都能稳定运行,防止事故发生。安全性和可靠性视图探讨了如何在系统中定义和管理冗余,以提高系统的可靠性和安全性。安全和可靠性体系结构涉及到存在故障和错误的情况下,系统功能是否正确。冗余可以以多种方式使用,以获得不同程度和类型的安全性和可靠性。
- 安全性要求
- 可靠性要求
- 实现安全性和可靠性的设计
2.6 部署视图
部署视图关注软件体系结构如何映射到物理设备上,例如处理器、显示器等。UML 使用“节点”的概念来表示物理设备。这些节点通常会被“赋予角色”以指示它们代表的硬件类型。
3. 架构设计的模式
架构设计模式是指在架构设计中反复使用且经过验证的解决方案。架构设计模式可以帮助设计者快速和有效地解决复杂的架构设计问题。
架构设计是系统设计中最重要的环节之一,它将对系统的后续开发、测试、部署和维护产生重大影响。架构设计需要考虑系统的各种需求,包括功能需求、性能需求、可扩展性需求、可维护性需求、安全性需求和可靠性需求。
通过了解架构设计的概念、原则、视图和模式,设计者可以更好地进行架构设计,设计出满足系统需求且具有良好可靠性和可扩展性的系统。
常见的架构设计模式包括:
- 分层模式(Layered Pattern):将领域组织成抽象层次。
- 五层模式(Five-Layer Pattern):针对中小型系统的特定分层领域集。
- 微内核架构模式(Microkernel Architecture Pattern):将系统组织成一组核心服务及其可选服务。
- 通道架构模式(Channel Architecture Pattern):将系统组织成一系列顺序的转换元素。
- 递归容纳模式(Recursive Containment Pattern):将系统组织成几层抽象。
- 层次控制模式(Hierarchical Control Pattern):在不同的抽象层次分布复杂的控制算法。
- 虚拟机模式(Virtual Machine Pattern):通过构建抽象机器增强系统的可移植性。
- 基于构件的架构模式(Component-Based Architecture Pattern):将系统组织成可替换的单元,具有不透明接口。
- ROOM模式(ROOM Pattern):使用一组具有强封装性的重量级抽象组织系统。
1227



被折叠的 条评论
为什么被折叠?



