软件架构是有关软件整体结构与组件的抽象描述 软件架构是什么

软件架构是对相关软件整体结构和元件的抽象描述,以指导大型系统软件的各个方面的设计 。软件架构包括软件组件、组件之间的关系、组件特征及其组件之间的关联特征 。软件架构可以与建筑架构相比 。软件架构是构建计算机技术、开发系统及其计划的前提,可以列出开发团队必须完成的任务 。

软件架构是有关软件整体结构与组件的抽象描述 软件架构是什么

文章插图
软件架构应该在软件的系统架构中做出决定 。一旦做出决定,修改就要花很多钱 。软件架构中的决策包括软件开发中的一些特殊结构选项 。例如,控制太空船登陆艇的软件必须快速可靠,因此需要选择适合实时计算的语言 。为了满足可靠性的需要,程序需要多个冗余的复制,每个复制操作在不同的硬件上,以便于检查每个程序的结果 。
软件架构文档有利于与项目关系人的沟通,可以在高层设计中提前做出决策,也可以在项目之间重用设计部件 。
介绍软件系统结构是构建计算机技术实践的基础 。与建筑师设置工程项目的设计原则和目标作为绘图员绘图的前提一样,软件架构师或系统架构师阐述了软件架构作为满足不同客户需求的具体系统设计方案的前提 。在与目的、主题、材料和结构的联系方面,软件架构可与建筑架构相比 。软件架构师需要广泛的软件理论知识和相应的经验来实施和管理软件项目的高级设计 。软件架构师定义和绘图软件模块化,模块之间的互动,操作界面风格,外部接口模式,创新的设计特点,以及高层事物的对象操作、逻辑和步骤 。
软件架构师与客户讨论概念,与主管讨论广泛的设计问题,与开发工程师讨论创新的结构特点,与程序员讨论完成方法、外观和风格 。
软件架构是一个系统的手稿 。软件架构描述的对象是直接组成系统的抽象组件 。每个组件之间的连接清晰而相对详细地描述了组件之间的通信 。在实现阶段,这些抽象组件被优化为特定组件,如实际类别或目标 。在面向对象的领域中,部件之间的连接通常是通过接口来实现的 。
范畴软件架构的范畴有许多不同的定义:
巨型系统架构:这是指高端系统软件的抽象,包括很多部件(component),它描述了模块之间关系的“连接器”(connector) 。重要的事情,无论是什么:这意味着软件架构师必须根据项目来判断哪些决策对系统及其项目关系人有很大的影响 。掌握系统环境的前提 。一些人认为不容易改变的事情:设计架构应该在软件生命周期开始时进行,软件架构师应该专注于一些“一开始就正确”的决策 。根据这个想法,如果一些关键是可逆的,软件架构上的问题可以转化为非架构性问题 。许多架构模式决策:软件架构不仅要考虑许多模型和结构,还要考虑这些特殊结构的决策及其背后的原因 。这一观点引起了对软件架构知识管理的大量探索 。软件架构、设计和要求工程之间没有明显的界限 。这些是“一系列意图的整合”,从高端设计意愿到低端设计细节 。
特性软件架构具有以下特点:
很多人:软件架构需要配合很多人(stakeholder),例如,业务经理、部门主管、用户和运营商 。每个关系人都有自己的关心 。在设计系统中,如何平衡这些关注,展示他们关注的信息也是一个关键 。因此,软件架构涵盖了解决许多关心和关系人的问题,所以它本质上是跨领域的 。
关注点分离:减少架构师复杂性的可行途径是分离驱动设计的关注点 。架构文档将显示相关者关心的所有内容,并以创建的形式显示 。此外,还将从相关者关心的角度描述软件的架构 。这种分离显示被称为架构视图,例如 4 1 架构视图 。
质量导向:传统的软件开发模式(如杰克逊结构化编程)是由系统中所需的功能和材料流动的形式驱动的,但目前的观点是系统软件的架构和质量属性(如故障容忍度、向下兼容性、可扩展性、可扩展性、可扩展性、易用性、材料安全等) 。相关者的注意力可以转化为这些质量属性的相关要求,一般称为非功能需求、附加功能需求、行为需求或质量属性需求 。
重复风格:软件架构类似于建筑,在处理一些重复的事情时会发展出标准化的做法 。标准化实践有许多不同的名称,其中也有一定程度的抽象性 。常见的术语有结构风格,tactic、参照架构和架构模式 。
概念完整性:这是佛里德·布鲁克斯在写《人月神话》一书时提到的,系统软件的架构是相关系统软件应该做什么,不应该做什么的实体观点 。这些观点应该与软件的完成分开 。架构师的角色是“观点的守护者”,确定系统的改进部分符合该架构,因此可以保持概念的完整性 。
认知约束:程序员马尔文·康威 1967 2000年的论文发表了康威定律,其中提到了一个组织开发的软件,它的结构将反映其组织结构 。弗里德·布鲁克斯在写《人月神话》时提到了这个例子,被命名为“康威定律” 。
动因软件架构是一个复杂的系统,“能理解智商”(intellectually graspable)抽象,这种抽象有以下优点:
在系统实现之前,软件架构应分析系统软件行为的前提 。无需完成系统,就可以确定一个系统软件符合相关人员的追求,这有助于降低成本和缓解风险 。这种分析已经开发了很多技术,比如软件架构分析方法(SAAM)、架构衡量分析方法(ATAM),或者以可视化的方式展示系统软件 。软件架构是软件重用及其决策的基础 。无论是软件的软件架构,还是软件架构上的一些对策和决策,如果关系人必须在其他软件中具有相似的特性或功能,它都可以重复使用,从而降低设计成本和设计错误的风险 。提前进行会影响系统开发、部署和维护的设计决策 。如果你想防止时间过期或花费过多,提前做出正确的决定是非常重要的 。有利于与关系人的沟通,能够生产出更符合多方需求的系统 。在与复杂系统的沟通中,与关系人的观点沟通有助于他们理解他们的需求与设计决策之间的关系 。通过架构,设计决策沟通可以在系统实现之前(也容易调整)进行 。有利于风险控制 。软件架构可以降低风险及其失败的风险 。能降低成本 。软件架构是一种复杂的管理 IT 规划风险和成本形式 。【软件架构是有关软件整体结构与组件的抽象描述 软件架构是什么】