概念:系统体系结构
系统体系结构是对系统的说明,在系统中有功能与硬件和软件组件的映射,软件体系结构和硬件体系结构的映射以及人与这些组件的交互。
关系
主要描述

简介

如今,术语体系结构的使用已经大大超出了它的传统构建含义,并且有许多关于“体系结构”(系统环境中)和“系统体系结构”的定义,例如:

“系统体系结构:根据系统元素、接口、流程、约束和行为定义的基本的、统一的系统结构。” 
[INCOSE Systems Architecture Working Group 在波士顿认可的基线定义,麻省,1996 年 7 月 8 日]

“系统体系结构由系统的主要物理属性、样式、结构、交互和目的组成。”
Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

“体系结构:定义结构、语义行为和系统各部件间的关系的概念和规则;构造某些事物的计划。它包含构成事务的元素、元素间的关系、影响这些关系的约束、事务各部分的重点和整个事务的重点。
Architecting with RM-ODP,Janis Putman,Prentice Hall PTR 2001,出自 ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations]

“体系结构:程序/系统中组件的结构、它们的相互关系以及用来指导其设计和随时间推移的演进的原理和指南。”
[DoD 5000.59-P, "Modeling and Simulation Master Plan", October 1995]

体系结构是“组件的结构、它们之间的关系以及用来指导其设计和随时间推移的演进的原理和指南。”
[IEEE STD 610.12,由 DoD Architecture Framework V1.0 中 C4ISR Integration Task Force(ITF)的 Integrated Architectures Panel(IAP)略加扩展]

使用了不同的词和构造,而且并非所有的定义都涵盖了完全相同的方面,但是却出现了严重的重叠。这些定义揭示了系统体系结构是关于下列方面的:

  • 元素、组件和部件组成的系统结构
  • 这些元素之间的关系
  • 影响元素和元素间关系的约束
  • 系统表现出的行为和发生在元素之间的可导致此行为的交互
  • 使系统保持原样(并控制它的演进)的原理、规则理由
  • 系统的物理和逻辑特征属性
  • 系统的目的

因此,要完整地表达所有的方面需要丰富的并且可能是复杂的信息集,但是需要注意的是并非所有的项目干系人都需要同时理解所有的方面。 视点的提出可将这些不同方面的问题与为实现有效参与而仅需出现的这一类项目干系人分离开来。从特殊视点的角度出发,也可以用不同的“解决方案”查看系统,从与高抽象级别对应的低级别解决方案到与实施的具体规范(部件的规范等)对应的高级别解决方案。

视点

视点(在系统上)是“使用一组选定的体系结构概念和构造规则实现的抽象形式,目的在于关注系统内的特定问题” [ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations。该表列出了为捕获不同问题而选定的某些视点。这些视点与在“ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview”中发现的视点一致。

视点 问题 影响
工作者 组织和系统工作者的角色和职责(以及影响这些因素的策略)。 工作者活动,人员/系统交互。人员性能规范和人员因素。
信息 由系统处理的信息种类和对该信息的使用和解释的约束。 信息完整性,容量限制。
信息辅助功能选项,及时性。
逻辑 分为一组在界面上交互的子系统的系统分解,用于协助提供系统服务。 系统展示所需的行为。
系统是可扩展的、适用的并且是可维护的。
资产可重用。
分布/物理 需要用来支持系统功能和分布的基础结构。 系统物理特征的充足性(用来主管功能和满足非功能需求)。
进程 并行型、可伸缩性、性能、吞吐量、可靠性。 系统响应性、吞吐量、容错的充足性。

公共系统视点。

这些视点是软件密集型系统某些最普遍的视点。许多系统体系结构也需要其他的,特定于域的视点。示例包括安全、安全性和机械视点。视点代表问题的不同领域,这些问题必须在系统体系结构设计中解决。如果系统项目干系人或专家的问题对于总体体系结构很重要,就有可能需要一组视点工作产品来获取它们的设计决策。 

建立系统体系结构团队(其工作人员有能力管理各种视点)就很重要了。 团队可能由系统分析人员、对工作者视点负主要责任的用户、负责逻辑视点的软件架构设计师、负责物理视点的工程师以及负责特定于域的视点的专家组成。

抽象级别

除了视点,系统体系结构还需要规范级别。随着体系结构的开发,它从一般的、抽象的规范发展为更具体、更详细的规范。 RUP 确定了四个体系结构级别,如下表所示。

模型级别 表达
环境 系统和参与者。
分析 建立概念方法的系统初始分区。
设计 硬件、软件和人员的分析模型的实现。
实施 特定配置中设计模型的实现。

RUP 体系结构级别

通过这些级别,设计从抽象设计演变为物理设计。环境模型捕获与系统交互的所有外部实体(参与者)。这些参与者对于部署系统的企业来讲可能是处于企业之外的,或者对于企业来讲是处于企业之内的。两种情况下,参与者可能是人类工作者或是其他系统。在分析级别,分区不会反映对硬件、软件和人员的选择。相反,它们反映的是关于分割系统任务和如何分布这些工作的设计方法。在设计级别,针对所需的硬件和软件组件以及工作者角色的种类作出决策。在实施级别,对硬件和软件技术的特定选择是用于实施设计的。例如,在设计级别,可能会指定数据服务器。在实施级别,作出决策是为了使用运行特定数据库应用程序的特定平台。

模型和图

模型是对系统的说明,通常用于处理某些特殊区域的问题。因为有多个关于系统开发或使用的问题,所以系统通常由一组模型表示。可使用不同抽象级别(这些级别从更普通地隐藏或封装详细信息到更具体地给出更多详细信息和明确的设计决策)构造每个模型。

视点正如它的名称所示,是概念上的“位置”,从这里可看到有关系统某些方面或问题,这意味着应用一组概念和规则来形成概念上的过滤器。通常,只检验实际系统(出于了解目的)是不够的 - 将构建模型(或必须这么做)以表示和描述问题。

视图是模型的投影,它从特定的视点展现相关的实体。 这些投影通常由某些类型的说明。

在抽象级别,视点交叉与抽象或特性模型级别包含了(或至少确定了)与视点或关注点相关的一个或多个模型的视图。

然后在一组从不同视点和级别描述体系结构的模型(和使模型可视化的图)中获取了系统体系结构。正如在下面的模型框架表中所示的,不是每个视点级别组合都有模型/图。在实施级别,单个模型获取每个系统配置的硬件和软件组件的实现。

模型级别 视点
工作者 逻辑 信息 分布/物理 流程
环境 UML 组织视图 系统环境图 企业数据视图 企业位置视图 业务流程视图
分析 泛化系统工作者视图 子系统视图 系统数据视图 系统位置视图 系统流程视图
设计 系统工作者视图 子系统类视图

软件组件视图

系统数据模式 描述符节点视图 详细的流程视图
实施 工作者角色规范和指示信息 配置:带有软件和硬件系统组件的部署图。

在表中指定的许多视图都源于标准 UML 模型。例如,在逻辑视点的分析级别中,可将系统分解为通过协作来满足用户需求的子系统。使用子系统时所用的语义与在 UML 标准中使用的语义一样。随后,将这些子系统再分解为子系统或(最终的)类。逻辑视点的设计级别是详细类模型的视图。流程模型也是标准 UML 类模型,它的重点在系统中的活动类上。特定于域的视点也需要一个或多个级别的适当的工作产品视图。需要将该框架中项目工作产品的集合作为项目开发案例的一部分。