软件系统架构是关于软件系统的结构、行为和属性的高级抽象。在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的交互关系。在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定软件系统的组织和拓扑结构，而且显示系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。
有3个由大到小的层次：
软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。
软件架构设计与系统需求是直交的，两者并无必然联系。
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素：
架构描述语言，Architecture Description Language，ADL是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、连接件和架构配置。ADL对连接件的重视成为和其他建模语言区分的重要特征之一。
软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。即，能否在不同的软件系统中，使用同一架构。基于这个目的，学者们开始研究和实践软件架构的风格和类型问题。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义用于描述系统的术语表和一组指导构件系统的规则。
软件架构复用是指在不改变软件功能的情况下，将已有的软件架构直接或进行微调后复用到新的软件或系统中，从而加快软件开发进程，提高软件生产效率。
软件架构复用包括软件产品复用和软件过程复用两部分的内容。其中，软件产品复用是指将已有的软件组件（如函数、模块、组件等）直接或进行适应性修改后复用到新的软件或系统中；软件过程复用是指将已有的软件生产过程中的各种劳动成果（如设计文档、测试案例、源代码等）直接或进行适应性修改后复用到新的软件或系统中。
复用：开发过程中，只要发现有可复用的资产，就对其进行复用；
计划复用：开发之前就要进行规划，以决定哪些需要复用；
软件架构复用可以分为以下几种类型：
软件架构复用的实现方式主要包括以下几种：
失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设（assumption）与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：
要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。
软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。
应用架构建模中要绘制的第一个物理数据流图（PDFD）是网络架构DFD，它们不显示单位时间的数据流量，需要显示的信息包括服务器及其物理位置；客户端及其物理位置；处理器说明；传输协议。
软件架构贯穿于软件的整个生命周期，但在不同的阶段对软件架构的关注力度并不相同。其中需求分析阶段主要关注问题域；设计阶段主要将需求转换为软件架构模型；软件实现阶段主要关注将架构设计转换为实际的代码；软件部署阶段主要通过组装软件组件提高系统的实现效率。其中设计与实现阶段在软件架构上的工作最多，也最重要，因此关注力度最大。
软件架构风格是描述某一特定应用领域中的系统组织方式和惯用模式，反映领域中众多系统所共有的结构和语义两个方面的特征，主要包括架构定义、架构词汇表和架构约束，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格描述一类软件架构的特征，它独立于实际问题，强调软件系统中通用的组织结构选择。
Garlan和Shaw对通用软件架构风格进行分类：
| 架构风格大类 | 架构小类 | 构件 | 连接件 |
|---|---|---|---|
| 数据流风格 | 批处理序列 | 计算单元 | |
| 数据流风格 | 管理过滤器 | 过滤器 | 数据流传输的管道 |
| 调用/返回风格 | 主/子程序 | 主子程序 | 过程调用 |
| 调用/返回风格 | 面向对象 | 对象 | 对象间的交付方式 |
| 调用/返回风格 | 层次结构 | 每一层 | 层间的交付方式 |
| 独立构件 | 进程通信 | 独立的进程 | 消息传递 |
| 独立构件 | 事件驱动 | 模块 | 隐式调用 |
| 仓库风格 | 黑板系统 | 知识源 | 黑板系统或数据库系统 |
定义：构建为一序列固定顺序的计算单元，构建之间只通过数据传递进行交付，每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式进行传递
特点：强调整体性，无交互
定义：
特点：不适合处理交互式应用
定义：
构件为主程序和子程序，连接件是过程调用
定义：建立在数据抽象和面向对象的基础上，数据的表示和它们的相应操作被封装起来。
构件是对象，对象是抽象数据类型的实例，对象之间通过消息机制进行通信，连接件是对象间的交付方式。
定义：每层为上层提供服务，并使用下层提供的服务，一般中间层只对相邻层可见。
构件组成一个层次结构，连接件通过层间交互的协议来定义。
定义：构件通常是命名过程，消息传递可以是点对点、异步或同步方式、以及远程过程调用等。
构件是独立的进程，连接件是消息传递
定义：构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发，系统自动调用在这个事件上注册的所有过程。
构件是一些模块，这些模块可以是过程或事件。连接件以过程之间的隐式调用来实现。
优点：增加架构的灵活性
缺点：
在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。
对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，通常会采用黑板架构风格，以知识为中心进行分析与推理。
对于因数据而驱动，数据到达某个构件，经过内部处理，产生数据输出的系统通常采用管道-过滤器体系结构风格。
某软件开发公司负责开发一个Web服务器服务端处理软件，其核心部分是对客户端请求消息的解析与处理，包括HTTP报头分离、SOAP报文解析等功能。该公司的架构师决定采用成熟的架构风格指导整个软件的设计，以下（）架构风格，最适合该服务端处理软件。
解析：
Web服务器服务端的核心功能是数据处理，Web服务在数据传输方面具有协议分层的特征，即底层协议会包装上层协议（HTTP协议体中包含整个SOAP消息内容），因此需要数据内容的逐步分解与分阶段处理。由于管道-过滤器的架构风格支持分阶段数据处理，因此特别适合该服务端处理软件的要求。
调温器需要实时获取外界的温度信息，与用户定义的温度进行比较并做出动作。根据该系统的应用领域和实际需求，是典型的过程控制架构风格的应用场景。
某公司拟开发一个轿车巡航定速系统，系统需要持续测量车辆当前的实时速度，并根据设定的期望速度启动控制轿车的油门和刹车。采用过程控制架构风格最为合适。
用户会注册自己的兴趣，系统也会把新闻按兴趣分类，如果某个新闻事件发生，可以通过事件来触发推送动作，将新闻推送给对其感兴趣的用户。事件驱动系统应用场景。
Windows操作系统在图形用户界面处理方面采用的是典型的事件驱动架构风格，首先注册事件处理的是回调函数，当某个界面事件发生时，系统会查找并选择合适的回调函数处理该事件。
某公司欲开发一个基于图形用户界面的集成调试器，该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时，编辑程序可以自动卷屏到断点，变量监视器刷新变量数值。采用隐式调用的架构风格最为合适。回调机制。
某企业内部现有的主要业务功能已封装成Web服务。为拓展业务范围，需要将现有的业务功能进行多种组合，形成新的业务功能。针对业务灵活组合这一要求，采用解释器架构风格最为合适。
公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和对象之间的关系。针对该需求，公司应该采用（ ）架构风格最为合适。解释器题目中提及“支持玩家自行创建战役地图”这说明系统要能应对“自定义”内容的解析，这需要用到解释器风格。
某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用隐式调用架构风格最为合适。解析： 漫步者机器人需要根据自身状态和外界环境进行自动调整，这是一个典型的根据外部事件进行响应的场景。
解释器是一个用来执行其他程序的程序，解释器可针对不同的硬件平台实现一个虚拟机，将高抽象层次的程序翻译为低抽象层次所能理解的指令，以消除在程序语言与硬件之间存在的语义差异。作为一种体系结构风格，解释器已经被广泛应用在从系统软件到应用软件的各个层面，包括各类语言环境、Internet浏览器、数据分析与转换等；LISP，Prolog、JavaScript、VBScript、HTML、Matlab、数据库系统（SQL解释器）、各种通信协议等。
Java是一种解释型语言，在JVM上运行，从架构风格上看是典型的虚拟机风格，即通过虚拟机架构屏蔽不同的硬件环境。
规则系统体系结构风格是一个使用模式匹配搜索来寻找规则并在正确的时候应用正确的逻辑知识的虚拟机，其支持把频繁变化的业务逻辑抽取出来，形成独立的规则库。这些规则可独立于软件系统而存在，可被随时地更新。它提供一种将专家解决问题的知识与技巧进行编码的手段，将知识表示为条件-行为规则，当满足条件时，触发相应的行为，而不是将这些规则直接写在程序源代码中，规则一般用类似于自然语言的形式书写，无法被系统直接执行，故而需要提供解释规则执行的解释器。扫地机器人系统适用于规则系统体系结构风格。
现代编译器主要关注编译过程和程序的中间表示，围绕程序的各种形态进行转化与处理。这种情况下，可以针对程序的各种形态构建数据库，通过中心数据库进行转换与处理，数据共享风格最符合要求。
某公司为其研发的硬件产品设计实现一种特定的编程语言，为了方便开发者进行软件开发，公司拟开发一套针对该编程语言的集成开发环境，包括代码编辑、语法高亮、代码编译、运行调试等功能。针对上述描述，该集成开发环境应采用（ ）架构风格最为合适。
答案：数据仓储（数据共享）。
解析：现代编译器的集成开发环境一般采用数据仓储（即以数据为中心的架构风格）架构风格进行开发，其中心数据就是程序的语法树。
客户机/服务器系统开发时可以采用不同的分布式计算架构：
分布式系统开发分为5个逻辑计算层：
物联网属于层次型架构，分为：
特定领域软件架构，Domain Specific Software Architecture，以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。
特定领域的架构可以分为：
DSSA通常是一个具有三个层次的系统模型：领域开发环境、领域特定应用开发环境和应用执行环境，其中应用工程师主要在领域特定应用开发环境中工作。
基本活动包括：
参与DSSA的人员可以划分为4种角色：
C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。
C2风格中的系统组织规则如下：
基于软件架构的开发，Architecture Based Software Development，强调由商业、质量和功能需求的组合驱动软件架构设计，视角和视图来描述软件架构，用例和质量属性场景来描述需求。用例描述的是功能需求，质量属性场景描述的是质量需求（或侧重于非功能需求）。
ABSD方法有三个基础：
ABSD方法主要包括架构需求等6个主要活动：
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，并且设计活动的开始并不意味着需求抽取和分析活动可以终止，而是应该与设计活动并行。ABSD方法是一个自顶向下递归细化的过程，软件系统的架构通过该方法得到细化，直到能产生软件构件的类。
架构设计、文档化和复审是一个迭代的过程。在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。架构复审过程中，通常会对一个可运行的最小化系统进行架构评估和测试。
最常见的质量属性：可用性（Availability）、可修改性（Modifiability）、性能（Performance）、安全性（Security）、可测试性（Testability）、易用性（Usability）。
软件质量特性包括6个方面，每个方面都包含若干个子特性：
软件质量属性通常需要采用特定的设计策略实现，设计策略会对其他质量属性产生影响。
改善（提高）软件质量属性的常见策略：
可用性（可靠性）
安全性
可修改性
性能
可测试性
刻画质量属性的手段由六部分组成：刺激源、刺激、环境、制品、响应、响应度量；
基于场景的架构分析方法，Scenarios-based Architecture Analysis Method。卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。
在进行体系结构（架构）评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般从三方面来对场景进行描述：
SAAM的主要输入：问题描述、需求说明和架构描述；
其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。
架构权衡分析方法，Architecture Tradeoff Analysis Method。主要关注系统的需求说明。该方法强调对软件的质量属性进行分析、分类和优先级排序等工作，在此基础上构建质量属性效用树对质量属性描述进行刻画和排序，并对风险点、非风险点、敏感点和权衡点进行识别和分析。
效用树从根部到叶子节点依次是：树根、质量属性、属性分类、质量属性场景。
在SAAM基础之上发展起来的一种系统架构评估方法，主要对软件体系结构的设计结果进行评估。评估是软件系统详细设计、实现和测试之前的阶段工作，因此评估不涉及系统的实现代码和测试，因为评估是考査软件体系结构是否能够合适地解决软件系统的需求，并不对软件需求自身是否准确进行核实，而软件需求是否准确是需求评审阶段的工作。不是一种精确的评估方法，主要形式是评审会议。
主要包括：场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型（架构决策）折中等4个阶段。
ATAM方法要求在系统开发之前，首先针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。
整个评估过程强调以属性作为架构评估的核心概念。
识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程:
例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
【改变业务数据编码方式会对系统的性能和安全性产生影响】是对权衡点的描述；
【改变加密的级别可能会对安全性和性能都产生显著的影响】是对系统权衡点的描述；
【假设用户请求的频率为每秒1个，业务处理时间小于30毫秒，则将请求响应时间设定为1秒钟是可以接受的】是对非风险的描述
【系统需要支持的最大并发用户数量直接影响传输协议和数据格式】描述敏感点
本文发布于:2024-01-31 20:52:25，感谢您对本站的认可！
本文链接：https://www.4u4v.net/it/170670555031278.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
