精华内容
下载资源
问答
  • 体系结构设计风格

    千次阅读 2016-04-05 17:28:07
    一、常用的软件体系结构风格数据流风格:批处理和管道/过滤器 调用/返回风格:主程序/子程序、层次结构,客户机/服务器,面向对象风格 独立部件风格:进程通讯、事件驱动 虚拟机风格:解释器、基于规则的系统 ...

    一、常用的软件体系结构风格

    数据流风格:批处理和管道/过滤器
    调用/返回风格:主程序/子程序、层次结构,客户机/服务器,面向对象风格
    独立部件风格:进程通讯、事件驱动
    虚拟机风格:解释器、基于规则的系统
    数据共享风格:数据库系统、黑板系统

    空间效率:存储库>管道-过滤器>隐式调用

    二、管道-过滤器风格(Pipe-Filter Style)

    风格项 描述
    设计决策与约束 保证过滤器的独立性,不能共享任何状态、数据,运行
    模块描述 每个过滤器部件实现为一个单独的模块, 简单的管道连接件建立通用模块 , 复杂的管道连接件建立一个单独的模块
    优点 可复用性、内部可修改性、可扩展性、高性能、支持特定分析(吞吐量、死锁检测)
    缺点 弱控制性、弱交互性;空间效率差;性能浪费、错误处理能力弱
    应用 传统的编译器、Unix shell编程、信号处理、批处理 (ATM机、汽车牌照识别系统等流水线系统)
    不适用于 不能容忍错误的系统,不允许重新启动的系统,交互式应用系统
    变体 流水线

    三、主程序/子程序风格(Main Program/Subroutine Style)

    风格项 描述
    设计决策与约束 不允许逆方向调用、单线程执行、从上层获得控制权,执行完成后控制权还给上层,执行中控制权可以下传
    模块描述 每个子程序实现为一个模块,主程序为起始模块
    优点 流程清晰,易于理解;强控制性
    缺点 程序调用的强耦合使得系统难以修改和复用, 限制了部件之间的数据交互,可能会产生公共耦合
    应用 功能分解多个顺序执行的系统, 编程语言没有模块化支持的系统, 结构化方法建立的系统

    四、面向对象式风格

    风格项 描述
    设计决策与约束 用信息内聚标准建立对象部件、 基于方法调用建立连接件、不同对象之间平等,没有主从、从属、层次关系
    模块描述 每个对象部件实现为一个模块
    优点 内部实现的可修改性。易开发、易理解、易复用的结构组织
    缺点 接口的耦合性、标识的耦合性、 面向对象的副作用
    应用 能够基于数据信息分解和组织的软件系统,基于抽象数据类型建立的软件系统

    五、分层

    风格项 描述
    设计决策与约束 基于程序调用建立连接件,禁止跨层次连接、禁止逆向连接
    模块描述 每个层次部件表示为一个包,内部还有所有实现模块
    优点 设计清晰、易于理解,支持并行开发,可复用性、内部可修改性
    缺点 交互协议难以修改、性能损失(禁止跨层)、难以确定层次数量和粒度
    应用 并行开发的系统,不同抽象层次上进行任务分解的系统,能够容许延迟的系统,网络通信、交互系统、硬件控制系统、系统平台
    变体 松散分层系统(系统性能比可修改性更重要,例如:Unix操作系统)

    六、隐式调用(发布-订阅,基于事件、选择性)

    风格项 描述
    设计决策与约束 使用事件路由建立连接件; 多个部件可以声明同一个事件类型,事件广播有相同调用效果;多个部件可以注册同一事件,事件发生后同时被调用;不能假设事件对部件的影响;部件不能假设对事件的处理顺序,也不能假设事件的处理结果
    模块描述 部件实例实现为模块,事件路由借助程序运行环境提供的支撑模块
    优点 可复用性、可修改性、高性能(多进程并发执行)
    缺点 弱控制性,难以测试和验证(不知道调用程序的上下文)
    应用 以松散耦合部件为基础建立的软件系统,编译环境中的工具集成,数据管理系统中的一致性检查,图形化用户界面
    变体 使用程序调用机制作为补充

    七、存储库(数据为中心、共享数据风格)

    风格项 描述
    设计决策与约束 对系统的功能处理为一系列的知识源部件;对存储区的直接访问建立为连接件; 所有知识源相互独立,活动没有预先确定顺序; 知识源依赖于共享数据;知识源实时检查共享数据的状态,并在必要时做出合理的反应
    模块描述 共享数据部件建立一个存储区、访问机制模块;每个知识源建立一个实现模块
    优点 很好的空间效率,具有潜能的性能优势(进程实现时可多进程并发),知识源的可修改性、容错性和健壮性
    缺点 共享数据的难修改性、共享数据的瓶颈性、弱控制性
    应用 以建立、增强和维护一个复杂信息中心为主要问题的应用系统;数据库系统、现代的编译器
    变体 黑板风格:由共享数据监控状态变化、并在需要时通知知识源、由知识源决定下一步行动(部件类型:知识源、共享数据、控制,连接件类型:数据访问、监控、事件通知)
    应用 专家系统、集成开发环境、聊天室

    八、MVC

    风格项 描述
    设计决策与约束 以程序调用为连接件; 视图只能使用数据查询,只有控制部件可以调用可能修改模型状态的程序
    模块描述 为模型、师徒、控制的每个部件建立模块实现
    优点 易开发性、视图和控制的可修改性、适宜于网络系统开发的特征
    缺点 复杂性、模型修改困难、
    应用 网络系统

    九、客户端/服务器(C/S)

    风格项 描述
    设计决策与约束 服务器端有更高的资源要求、客户端有更多的用户交互;服务器端固定、客户端动态增减,各个客户端之间相互独立
    模块描述 server、client、连接件被实现为socket连接或tcp/ip连接
    优点 易开发、客户端的动态性
    缺点 服务器难以调整、服务器瓶颈、不易更新
    应用 网络系统
    变体 1.浏览器/服务器(B/S) 2.三层 3. 端到端(P2P)每个参与者既是客户端又是服务器,网络交互机制比较复杂
    展开全文
  • 《软件工程》第6章体系结构设计

    千次阅读 2020-06-02 09:33:24
    在敏捷过程中,得到广泛认同的一点是,一个敏捷开发过程的早期阶段应该关注设计一个整体的系统体系结构。体系结构的增量开发通常都不会成功。根据变化重构构件通常相对容易。然而,重构体系结构却很昂贵,因为可能...

        体系结构设计关注理解一个软件系统应当如何组织,以及设计该系统的整体结构。体系结构设计是设计和需求工程之间的关键性衔接环节,因为它会确定组成一个系统的主要结构构件以及它们之间的关系。体系结构设计过程的输出是一个体系结构模型,该模型描述系统如何被组织为一组相互通信的构件。

        在敏捷过程中,得到广泛认同的一点是,一个敏捷开发过程的早期阶段应该关注设计一个整体的系统体系结构。体系结构的增量开发通常都不会成功。根据变化重构构件通常相对容易。然而,重构体系结构却很昂贵,因为可能需要修改大部分系统构件以使它们能够适应体系结构的变化。

        在实践中,需求工程过程和体系结构设计过程之间存在显著的重叠。理想情况下,系统规格说明不应当包含任何设计信息。然而,这个设想是不现实的;因此,作为需求工程过程的一部分,要提出一个抽象的系统体系结构,其中将一组组的系统功能或特征与大规模的构件或子系统关联起来。

        可以在两个抽象层次上设计软件体系结构,分别称为小体系结构和大体系结构。

        1.小体系结构关注单个程序的体系结构。在这个层次上,我们关注单个的程序是如何被分解为构件的。

        2.大体系结构关注包括其他系统、程序和程序构件的复杂企业系统体系结构。这些企业系统可以分布在不同的计算机上,这些计算机可以由不同的公司拥有和管理。

        软件体系结构很重要,因为它会影响一个系统的性能、健壮性、分布性和可维护性。明确地设计并描述软件体系结构有以下3个好处:

        1.利益相关者交流。体系结构是一种可以作为许多不同利益相关者讨论的焦点的系统的高层表示。

        2.系统分析。在系统开发早期阶段明确系统的体系结构要求进行一些分析。

        3.大范围复用。体系结构模型是关于系统如何组织以及构件如何互操作的一个紧凑、可管理的描述。

        系统体系结构经常使用简单的框图进行非正式的建模。可以使用UML的构造型和构件图进行绘制,其中每一个方框表示一个构件。方框中的方框表示该构件被分解子构件。箭头表示数据和控制信号按照箭头的方向从一个构件传到另一个构件。

        程序的体系结构模型有如下两种不同的使用方式:

        1.作为一种鼓励对系统设计进行讨论的方式。一个系统的高层体系结构视图对于与系统利益相关者进行交流以及项目计划都很有用,利益相关者可以接受这种表示并理解系统的抽象视图。体系结构模型识别出了要开发的关键构件,从而使管理者可以开始分配人员规划这些系统的开发。

        2.作为一种文档化已经设计好的体系结构的方式。目的是产生一个显示系统中不同的构件、它们的接口以及连接关系的完整的系统模型,这样一种详细的体系结构描述使得对系统的理解和演化可以更容易。

        对于很多项目,框图是唯一的体系结构描述。理想情况下,如果要详细描述一个系统的体系结构,最好能使用一种更严格的软件体系结构描述的方法。显然,一个更加详细和完整的描述意味着对体系结构构件之间关系误解的可能性会降低,然而其相应的成本就会大大增加,在实践中无法判断待开发的系统使用严格定义体系结构的方法是否合算。

    §6.1体系结构设计决策

        体系结构设计是一个创造性的过程,在这个过程中你会设计一个满足系统功能性和非功能性需求的系统组织结构。具体的体系结构设计过程取决于所开发的系统的类型、系统架构师的背景和经验,以及系统的特定需求,因此也并不存在公式化、形式化的体系结构设计过程。

        在体系结构设计过程中,系统架构师必须做出一系列深刻影响系统及其开发过程的结构决策:

        1.是否存在一个通用的应用体系结构可以用作所设计的系统的模板?

        2.系统将如何分布到各个硬件核或处理器上?

        3.可以使用什么体系结构模式或风格?

        4.用来组织系统的基本方法是什么?

        5.用什么样的策略来控制系统中的构件的运行?

        6.系统中的结构构件将如何分解为子构件?

        7.什么样的体系结构组织是实现系统的非功能性需求的最佳选择?

        8.系统的体系结构应当如何文档化?

        虽然每个软件系统都是独特的,但是同一个应用领域中的系统经常具有相似的、反映领域的基本概念的体系结构。当设计一个系统体系结构时,你必须确定你的系统和更广阔的应用类型有什么共性,确定来自这些应用体系结构中的知识有多少可以复用。

        对于嵌入式系统以及针对个人电脑和移动设备设计的应用,不需要为系统设计一个分布式体系结构。然而,大多数大型系统是分布式系统,其中系统软件分布在许多不同的计算机上。

        一个软件系统的体系结构可以基于特定的体系结构模式或风格。体系结构模式捕捉了一个在不同的软件系统中使用的体系结构的本质特性。在进行体系结构设计时,应当了解通用的模式、这些模式的适用场合、它们的优势和弱点。

        由于非功能性系统特性和软件体系结构的密切关系,体系结构风格和结构的选择应当根据系统的非功能性需求来确定。

       1.性能。如果性能是一个关键性需求,那么体系结构设计应当将关键性操作局部化到少量的构件中,尽量让这些构件部署在同一台计算机上而不要分布在网络上。

       2.信息安全。如果信息安全是一个关键性需求,那么应该使用一种层次化的体系结构组织,把最关键的资产放在最内层进行保护,并对这些层应用高级的信息安全确认。

       3.安全性。如果安全性是一个关键性需求,那么体系结构设计应该让安全性相关的操作集中在单个构件或少量构件中。

       4.可用性。如果可用性是一个关键性需求,那么体系结构设计应该包含冗余的构件以便在不停止系统的情况下可以更换或更新构件。

       5.可维护性。如果可维护性是一个关键性需求,那么系统体系结构设计应当使用容易改变的细粒度、自包含的构件。

       显然,上面这些体系结构之间存在潜在的冲突,在具体的系统体系结构设计时就必须要进行权衡折中:有时可以通过在系统的不同部分使用不同的体系结构模式或风格来实现权衡。

        评价一个体系结构很难,因为真正的体系结构评判标准是,系统在使用时能够在多大程度上满足它的功能性和非功能性需求。

    §6.2体系结构视图

       此外,体系结构模型也可以用于设计的文档化,这样,体系结构可以作为更加详细的系统设计以及实现的基础。在单个图中表示出与一个系统的体系结构相关的所有信息是不可能的,因为一个图形化模型只能显示一个系统视图或视角。通常来说,需要从多个不同的视图来呈现软件体系结构。

        1.逻辑视图。这个视图将系统中的关键抽象显示为对象或对象类。

        2.进程视图。这个视图显示系统在运行时如何通过相互交互的进程来构成。

        3.开发视图。这个视图显示软件如何面向开发任务进行分解;也就是说,该视图显示了软件如何分解为由单个开发者或开发团队实现的构件。

        4.物理视图。这个视图显示系统硬件以及软件构件如何分布在系统中的处理器上。

        在实践中,一个系统体系结构的概念视图几乎总是在设计过程中开发。这些概念视图用于向利益相关者解释系统体系结构以及告知体系结构设计决策。在设计过程中,其他一些视图也可以在讨论系统的不同方面的时候进行开发,但是一般都不需要从所有的视角出发开发一个完整的描述。

        当使用UML描述一个软件系统的体系结构时,通常都是以一种非正式的方式进行应用的。而另有一些人提出,应使用更加专业化的体系结构描述语言(Architectural Description Language, ADL)来描述系统体系结构。体系结构描述语言的基本元素是构件和连接器,并且包含面向结构良好的体系结构的规则和指南。然而,由于体系结构描述语言是专家语言,领域和应用专家感觉很难理解和使用体系结构描述语言。

        与之对比的是敏捷方法的使用者,他们认为详细的设计文档通常都是没有用的,即开发这种文档是浪费时间。

    §6.3体系结构模式

        将模式作为一种表示、分享、复用软件系统相关知识的思想已经在软件工程中的一系列领域中得到了采用。

        体系结构模式是在20世纪90年代提出的,最初被称为“体系结构风格”。可以将体系结构模式理解为对好的实践的一种风格化、抽象化的描述,这些实践已经在不同的系统和环境中进行了尝试和测试。因此,一个体系结构模式应当描述一种已经在此前的系统中得到成功应用的系统的组织。它应当包含何时适合以及何时不适合使用该模式,还应包含关于该模式的优缺点的详细描述等信息。

    【例】模型—视图—控制器(MVC)模式

    名称 MVC(模型—视图—控制器)
    描述 将呈现和交互从系统数据中分离出来。系统被组织为3个相互交互的逻辑构件。模型(Model)构件管理系统数据以及相关的对这些数据的操作。视图(View)构件定义并管理数据呈现给用户的方式。控制器(Controller)构件管理用户界面(例如按键、鼠标点击等)并将这些交互传递给视图和模型。
    例子 显示了一个使用MVC模式进行组织的基于Web的应用系统的体系结构
    何时使用 当存在多种查看数据以及数据交互的方式时使用。也可在未来关于数据的交互和呈现的需求未知时使用
    优点 允许数据独立于它的呈现方式进行变更,反之亦然。支持以不同的方式呈现同样的数据,在某一呈现方式中进行的修改可以在所有呈现方式中显示
    缺点

    当数据模型和交互比较简单时,可能包含额外的代码以及代码复杂性

    这是该体系结构模式的“型”

        上表和上图所示是模型—视图—控制器的体系结构模式。该模式是许多基于Web的系统中交互管理的基础,并且得到了大多数语言框架的支持。这种风格化的描述包括一个模式名称、一段简要描述、一个图形化模型,以及一个使用了这种模式的系统的例子。(见下图)其中还应当包含关于该模式应该在何种情况下使用以及模式的优缺点的信息。

    这是该体系结构模式的“值”

        6.3.1分层体系结构

        分离和独立性的思想是体系结构设计的基础,因为这可以使变更被局部化。分层体系结构模式是另一种实现分离和独立性的方式。系统功能被组织为多个分离的层次,每个层次只依赖于紧邻的下一层所提供的设施和服务。

        这一分层的方法支持系统的增量开发。一个层次开发好之后,该层次所提供的一些服务可以提供给用户。该体系结构也是可变化和可前移的。如果接口不变,那么一个功能进行了扩展的新层可以在不影响系统的其他部分的情况下取代一个已有的层。而且,当一个层次的接口发生变化或者增加了新的设施时,只有相邻的层次受到影响。由于分层的系统将机器的依赖局部化了,这使提供一个应用系统的多平台实现变得更容易了。只需将与机器有依赖关系的层重新实现,便可以适应不同的操作系统或数据库的设施。

    分层体系结构
    名称 多层体系结构
    描述 将系统组织为多个层次,每个层次与一些相关的功能相联系。每个层次向其上的一层提供服务,因此那些最低层次表示很可能在整个系统中使用的核心服务
    例子 一个数字化学习系统的分层模型支持学校中所有科目的学习
    何时使用 当在已有系统之上构建新的设施时使用;当开发涉及多个团队,每个团队负责一个层次上的功能时使用;当存在多个层次上的信息安全需求时使用
    优点 只要接口保持不变,允许对整个层进行替换。可以在每个层次上提供冗余设施以增加系统的可依赖性
    缺点 在实践中,将各层之间干净地分离经常很难做到,较高层次上的层可能不得不与较低层次上的层直接交互,而不是通过紧邻着的下一层。性能可能是一个问题,因为当一个服务请求在各个层次上进行处理时需要经过多层的解析

        6.3.2知识库体系结构

        知识库模式,则描述了一组相互交互的构件如何共享数据。大多数使用大量数据的系统都是围绕一个共享数据库或知识库组成的。因此,这个模型适合于数据由一个构件生成同时由另一个构件使用的应用。

    知识库模式
    名称 知识库
    描述 一个系统中的所有数据在所有系统构件都能访问的中心知识库中进行管理。构件相互之间并不直接交互,仅通过知识库进行交互
    例子 下图是一个集成开发环境(IDE)的例子,其中构件使用系统设计信息的知识库。每个软件工具生成的信息都会提供给其他工具使用
    何时使用 当系统生成大量需要长时间保存的信息时应当使用这个模式。还可以在数据驱动的系统中使用,这类系统中的知识库中增加新数据时会触发一个动作或工具
    优点 构件可以保持独立,它们不需要知道其他构件的存在;一个构件进行的修改可以被传播到所有构件;所有数据都可以一致地进行管理(例如同时进行备份),因为这些数据都位于一个地方
    缺点 知识库可能存在单点失效问题,因此知识库中的问题会影响整个系统;通过知识库组织所有的通信可能效率不高;将知识库分布到多台计算机上可能比较困难
    面向集成开发环境(IDE)的知识库体系结构

        围绕一个知识库组织工具是一个共享大量数据的有效方法。不需要显式地从一个构件向另一个构件传输数据。然而,构件必须围绕一个达成共识的知识库数据模型运转。这其中不可避免地要对每个工具的特定需要进行权衡,而且如果一个新构件与数据模型不相符,那么就可能很难甚至无法集成了。在实践中,可能很难将知识库分布到多台不同的机器上。虽然有可能实现一个逻辑上的集中知识库的分布式部署,这其中会涉及维护数据的多份拷贝。保证这些拷贝的一致性以及及时更新给系统增加了更多的额外负担。

        6.3.3客户-服务器体系结构

        知识库模式关注系统的静态结构,没有显示系统的运行时组织。【例】客户-服务器模式,描述了一种常用的分布式系统运行时的组织方式。一个遵循客户-服务器模式的系统被组织为一组服务和相关联的服务器,以及访问并使用服务的客户端。该模型的主要构件包括以下这些:

        1.一组向其他构件提供服务的服务器。服务器的例子包括:提供打印服务的打印服务器,提供文件管理服务的文件服务器,提供编程语言编译服务的编译服务器。服务器是软件构件,多个服务器可能运行在同一台计算机上。

        2.一组调用服务器提供的服务的客户端。通常会有一个客户端程序的多个实例并行运行在多台计算机上。

        3.一个允许客户端访问这些服务的网络。客户-服务器系统通常实现为分布式系统,使用互联网协议连接。

    客户-服务器模式
    名称 客户-服务器
    描述 在客户-服务器体系结构中,系统被呈现为一组服务,其中每个服务都由一个独立的服务器提供。客户端是这些服务的用户,通过访问服务器来利用这些服务
    例子 下图是一个组织成客户-服务器系统的电影和视频/DVD库的例子
    何时使用 当一个共享数据库中的数据必须从一系列不同的位置进行访问时使用。因为服务器可以复制,因此也可以在一个系统的负载多变的情况下使用
    优点 这种模型的主要优点是服务器可以分布在网络上。通用的功能(例如一个打印服务)可以向所有客户端开放使用,不需要由所有服务实现
    缺点 每个服务都存在单点失效问题,因此容易受到拒绝服务攻击或服务器失效的影响;性能可能不可预测,因为这取决于网络以及系统;如果服务器属于不同的组织,那么还可能会出现管理问题

        客户-服务器体系结构通常被认为是分布式系统体系结构,但是运行在不同的服务器上的独立服务的逻辑模型可以被实现在单台计算机上。这里的一个重要优势仍然是分离和独立性。服务和服务器可以在不影响系统的其他部分的情况下被修改。

        客户端可能必须知道可用的服务器以及它们所提供的服务的名称。然而,服务器不需要知道客户端的身份或者有多少客户端正在访问它们的服务。客户端通过使用请求-应答协议的远程过程调用访问一个服务器提供的服务,其中客户端向一个服务器发出请求,并且一直等待直到收到来自服务器的应答。

        下图是一个基于客户-服务器模型的系统的例子,这是一个提供电影和照片库的多用户、基于Web的系统。

    一个电影库的客户—服务器体系结构

        客户-服务器模型最重要的优势在于它是一个分布式体系结构。带有很多分布式处理器的网络化系统可以获得有效的使用。很容易增加一个新的服务器并将其与系统的剩余部分相集成,或者在不影响系统其他部分的情况下透明地升级服务器。

        6.3.4管道和过滤器体系结构

        这是一个通用体系结构的模型,其中功能性的变换处理输入并产生输出。数据从一个构件流动到另一个构件,在流经这个序列时进行变换。每个处理步骤被实现为一个变换。输入数据流经这些变换直到被转换为输出。这些变换可以串行或并行执行。每个变换可以一项项地处理数据,也可以在单个批次中一次性处理。

    管道和过滤器模式
    名称 管道和过滤器
    描述 系统中的数据处理通过组织,每个处理构件(过滤器)可以分离开来并执行一种数据转换。数据从一个构件流动(就像在管道中一样)到另一个构件进行处理
    例子 下图是一个用于处理发货单的管道和过滤器系统的例子
    何时使用 在数据处理应用(无论是批处理还是基于事务)中得到了广泛应用,这类应用中输入在多个分离的阶段中进行处理,并最终生成相关的输出
    优点 容易理解并且支持变换的复用;这种工作流风格与许多业务过程的结构相匹配;通过增加变换来进行演化是非常直观的;可以被实现为一个顺序系统或一个并发系统
    缺点 针对数据转换的格式必须在相互通信的多个变换之间达成一致;每个变换必须解析它的输入,并将输出转换成所约定的形式,增加了系统的负担,同时可能意味着无法复用使用不兼容的数据结构的体系结构构件
    一个管道和过滤器体系结构的例子

        【例】一个管道和过滤器体系结构的例子

        管道和过滤器最适合于用户交互很少的批处理系统和嵌入式系统。交互式系统很难使用管道和过滤器模型实现,因为管道和过滤器模型需要处理数据流。虽然简单的文本输入和输出可以用这种方式建模,但是对于图形化的用户界面、更复杂的输入/输出格式以及基于事件的控制策略,很难将这些实现为一种符合管道和过滤器模型的顺序流。

    §6.4应用体系结构

        应用系统的目的是满足一个企业或者一个组织的需要。所有的企业都有很多共性:它们都需要雇人、开发货单、保存账户等。同属一个行业的企业使用通用的行业特定的应用。因此,与通用的企业功能一样,所有的电话公司都需要系统来连接呼叫和计费、管理他们的网络、向客户发出账单。因此,这些企业使用的应用系统同样有很多共性。

        这些共性促使人们去开发描述特定类型软件系统的结构合组织的软件体系结构。应用体系结构封装了一类系统的主要特性。应用体系结构可以在开发系统时重新实现,应用体系结构复用是隐式的。这一点在广泛使用的企业资源规划(Enterprise Resource Planning, ERP)系统以及可配置的成品应用系统中可以看到。这些系统有一个标准的体系结构以及相关的构件。这些构件可以通过配置和适应性调整来创建一个特定的企业应用。

        一个软件设计者可以通过以下这些不同的方式使用应用体系结构模型:

        1.作为体系结构设计过程的起点。如果你不熟悉你正在开发的应用类型,你可以将你的初始设计建立在一个通用的应用体系结构基础上。

        2.作为一个设计检查表。如果你已经为一个应用系统开发了一个体系结构设计,那么你可以将它与通用的应用体系结构相比较,检查你的设计是否与通用体系结构相一致。

        3.作为组织开发团队工作的一种方式。应用体系结构识别出了系统体系结构中稳定的结构特征,而且这些结构单元很多时候可以并行开发。

        4.作为评价构件复用的一种方式。如果你有一些可复用的构件,可以将它们与通用结构相比较,以确定应用体系结构中是否有与之相当的构件。

        5.作为谈论应用时的一种词汇表。如果你正在讨论一个特定的应用或者试图比较不同的应用,那么你可以使用通用体系结构中所识别的概念来讨论这些应用。

        存在许多类型的应用系统,有时候它们可能看上去很不一样。然而,表面上不一样的应用可能有很多共性,因此可以共享一个抽象应用体系结构。

    【例】

        1.事务处理应用。事务处理应用是以数据库为中心的应用,处理用户的信息请求并且更新数据库中的信息。

        2.语言处理系统。语言处理系统中用户的意图用形式化语言来表达。

        6.4.1事务处理系统

        事务处理系统被设计用于处理用户获取数据库中信息的请求或者更新数据库的请求。从技术上看,一个数据库事务包含一个操作序列并且该序列作为整体处理。一个事物中的所有操作必须在数据库修改被持久化之前完成。这保证了一个事务中失败的操作不会导致数据库中的不一致。

        从用户的角度看,一个事务是任何满足一个目标的内聚的操作序列。如果用户事务不需要对数据库进行修改,那么不一定要将其作为一个技术上的数据库事务。

        事务处理系统通常是交互式系统,其中发出的异步的服务请求。下图描述了事务处理应用的概念体系结构。首先,用户通过一个输入/输出处理构件向系统发出请求。该请求由一些应用特定的逻辑进行处理。一个事务被创建并传递给事务管理器(通常嵌入在数据库管理系统中)。事务管理器在保证事务被正确完成后,再通知应用处理已完成。

    事务处理应用的结构

        可将事务处理系统组织为含有负责输入、处理、输出的系统构件的“管道和过滤器”体系结构。

        6.4.2信息系统

        所有包含与一个共享数据库交互的系统都可以认为是基于事务的信息系统。一个信息系统允许对一个很大的信息库的受控访问。信息系统几乎都是基于Web的系统,其中用户界面在一个Web浏览器中实现。

        下图展示了一个非常通用的信息系统模型。系统使用层次化的方法进行建模,其中最顶层支持用户界面,最底层是系统数据库。用户通信层处理来自用户界面的所有输入和输出,信息检索包括特定应用的数据库访问和更新逻辑。这个模型中的各个层可以直接映射到一个分布式基于互联网的系统中的服务器上。

    分层的信息系统体系结构

        可以通过识别支持用户通信以及信息检索和访问的构件,向这个模型的每一层都增加了一些细节。信息和资源管理系统有时候也是事务处理系统。这些系统中的服务器通常反映了上图所示的4层通用模型。这些系统经常实现为带有多层客户端/服务器体系结构的分布式系统。

        1.Web服务器负责所有的用户通信,并带有使用Web浏览器实现的用户界面。

        2.应用服务器负责实现特定应用逻辑以及信息存储和检索请求。

        3.数据库服务器将信息移动到数据库,从数据库中获取数据,同时处理事务管理

        使用多个服务器可以实现高吞吐量,使每分钟处理完成千上万的事务成为可能。随着请求量的增长,每个层次都可以增加服务器以应对所需要的额外处理能力。

        6.4.3语言处理系统

        语言处理系统将一种语言翻译为该语言的另一种表示方式,对于编程语言还可以执行所产生的代码。编译器将一种编程语言翻译为机器代码。其他语言处理系统可以将XML数据描述为数据库查询命令或者另一种XML表示形式。自然语言处理系统可以将一种自然语言翻译为另一种语言。

        一个面向编程语言的语言处理系统体系结构如下图所示。源语言指令定义了要执行的程序,一个翻译器将这些转换为面向抽象机器的指令。这些指令接着被另一个构件解析,该构件取出执行指令并且使用来自环境的数据执行这些指令。该过程的输出是解析输入数据中的指令的结果。

        对于许多编译器,解析器是处理机器指令的系统硬件,而抽象机器是真实的处理器。然而,对于动态类型语言,解析器是一个软件构件。

        作为更通用的编程环境的一部分的编程语言编译器具有一个通用体系结构,其中包括以下这些构件:

        1.一个词法分析器,读入输入语言标记符号,并将其砖混为一种内部形式。

        2.一个符号表,包含与所翻译的文本中使用的实体(变量、类名、对象名等)名称相关的信息。

        3.一个语法分析器,检查所翻译的语言的语法。它使用该语言所定义的语法,并且构造一个语法树。

        4.语法树,这是所编译的程序的一种内部表示结构。

        5.语义分析器,使用来自语法树的信息以及符号表来检查输入语言文本的语义正确性。

        6.代码生成器,遍历语法树并且生成抽象的机器代码。

        还可以包含其他对语法树进行分析和转换以提高效率并从所生成的机器代码中消除冗余的构件。在其他类型的语言处理系统中,还有一些附加的构件,例如字典。系统的输出是对输入文本的翻译。

        【例】下图描述了一个语言处理系统如何作为一个集成的编程支持工具集的一部分。

        其他体系结构模式也可以用于语言处理系统。编译器的实现可以将知识库模型和管道过滤器模型结合起来使用。在一个编译器体系结构中,符号表是一个共享数据的知识库。词法、语法和语义分析阶段以顺序化的方式进行组织,并且通过共享的符号表进行通信。

        这一语言编译的管道和过滤模型在批处理环境中很有效,其中程序的编译和执行都不需要与用户交互。然而,当一个编辑器与其他语言处理工具相集成时,该模型就没那么有效了。在这种情况下,更好的办法是围绕一个知识库来组织系统。

    展开全文
  • 软件体系结构设计|描述与架构风格

    千次阅读 2017-05-15 16:16:52
    软件体系结构设计软件体系结构设计 什么是体系结构 架构描述 AD 架构风格计算机硬件系统中包含的两个重要因素: 基本硬件模块:控制器、运算器、内存储器、外存储器、输入设备…… 硬件模块之间的连接关系:总线...

    软件体系结构设计

    计算机硬件系统中包含的两个重要因素:

    • 基本硬件模块:控制器、运算器、内存储器、外存储器、输入设备……
    • 硬件模块之间的连接关系:总线(控制总线、地址总线、数据总线)

    计算机系统体系结构的风格:

    • SISD :单指令流单数据流 串行处理器
    • SIMD :单指令流多数据流 并行处理器
    • MIMD :多指令流多数据流 多处理器

    什么是体系结构?

    软件构件和构件之间的关系。

    体系结构的例子

    网络爬虫系统

    原则

    • 种子:初始的连接
    • 爬取:爬取连接中的数据
    • 解析:解析初始连接中的其他连接
    • 爬取:……
      ……

    架构描述 (AD)

    架构文档的产品的集合 称为 架构描述

    四种常见视图 (都属于架构描述)

    • 逻辑视图:将系统分解为一系列的抽象形式,多来自于问题域,如类图、对象图或功能层次结构图。
    • 过程视图:关注系统动态运行时,主要是进程以及相关的并发、同步、通信等问题。
    • 物理视图:描述软件到硬件的映射,反映了分布式特征。
    • 开发视图:开发环境中,围绕静态组织结构。使用构件图、包图。

    架构风格:

    描述领域中众多系统所共有的结构和特性,并指导如何将各个模块和子系统有效的组织成一个完整的系统。

    分类:

    • 数据中心架构

    这里写图片描述

    将数据进行中心存放,应用和应用之间不直接进行联系,所有的信息交换和操作,都建立在中心数据之上。
    
    • 数据流架构 (管道过滤系统)

    这里写图片描述

    数据在流动时,需要filter进行加工和处理,而这个加工和处理是自动的。试用于批处理系统,不适用于交互类系统。
    
    • 调用返回架构

    这里写图片描述

    • 面向对象的架构

      特点:
      每个对象都进行了特定的封装,对外提供预留的接口,并隐藏内部数据的表示。
      联系方法:
      基于消息机制(本质是方法调用)建立对象间的联系。

    • 层次架构

    这里写图片描述

    特征:
    横向联系,上下层调用。
    不可以跨层调用。

    好处:
    让复杂的问题变得简单了。

    • 客户服务器架构

      一个应用被分为两个逻辑上分离的部分,每个部分充当不同额角色、完成不同的功能。

      • 客户端:业务逻辑、与服务器通信的接口。
      • 服务器:与客户机通信的接口、业务逻辑、数据管理
    • MVC 架构

      将应用程序中的应用逻辑、用户界面、控制逻辑等分别放在独立的构件中,从而使得任何一种构件的改变都不会对其他构件造成很大的影响。

    • 消息总线架构

      适用于消息订阅发布系统(广播系统)。
      利用消息总线来实现调用和交互。


    本博客内容到此结束,欢迎指正!

    展开全文
  • 软件体系结构设计

    2014-11-16 16:40:25
    软件体系结构

      软件体系结构 将系统的总体结构(包含构建及其连接关系)与各个构件的内部细节相分离。对于构件及其连接的关系的构建有时被称为全局性编程,而单个构件的详细设计被称为局部性编程。

      软件体系结构可以再不同的细节层次上进行描述。在较高的细节层次上,体系结构可以描述软件系统是如何分解为子系统的。在较低的细节层次上,体系结构可以描述子系统是如何分解为模块或者构件的。这些不同层次上的体系结构强调的都是子系统/构件的外部视图,即子系统/构件所提供和需要的接口以及其他子系统/构件的连接关系。

      设计软件体系结构多喝时候应该考虑系统的软件质量属性。这些属性与体系结构如何满足重要的非公能性相关需求,例如性能,安全性和可维护性等等。

      软件体系结构有时被称为高层设计。软件体系结构可以从不同的视图进行描述,重要的是保证体系结构同时满足功能性(即软件必须做什么)和非公能性(即软件应当做的多好)软件需求。软件体系结构同时也是软件的详细设计和实现的出发点和重要依据。

      软件设计表示法 是一种是用图形或者文本方式或者同时使用文本和图形来描述软件设计的方法。

      软件设计思想 是一种可以用于设计整体性规划和方向性指导。

      软件结构组织准则 是用于帮助设计者将软件系统组织为构件的启发式规则或指导方针。

      软件设计方法 是一种描述用于在给定的的应用系统软件需求基础上创建一个设计方案的步骤序列的系统化方案。

     

    展开全文
  • 软件工程设计概念与体系结构设计

    千次阅读 2020-04-15 11:46:39
    软件工程第四次作业 11.1 当你编写程序时...在软件设计的过程中,设计工程是设计软件的概念之一。在开始软件设计时,需求应该被分析和建模。这个模型能够保证质量和在编码生成时能够进行改进。 在一个软件工程的内...
  • 软件工程-系统结构设计

    千次阅读 2019-11-04 23:00:52
    分为变换分析设计和事务分析设计。...实际问题也许不完全属于变换型或事务型的,很可能是两者的结合,因此我们要学会变换分析技术和事务分析技术联合使用,从而导出符合系统逻辑模型的系统初始结构图。 ...
  • 软件工程---6.体系结构设计

    千次阅读 2019-12-11 09:16:50
    大体系结构关注包括其他系统、程序和程序构件的复杂企业系统体系结构。 非功能性需求影响最大 对体系结构有显著影响的需求”的研究中确认了这一点, 他们发现非功能性需求对于系统体系结构的影响最大 体系结构视图....
  • 关于软件体系结构设计模式的总结

    千次阅读 2014-05-28 22:27:56
    因为软件体系结构设计模式太多了,如果用的不多,shi
  • 软件体系结构设计心得体会

    千次阅读 2016-06-04 23:53:00
    当我认为有些问题可以通过编程解决的时候,那就不能只放眼于具体的代码实现阶段,而是需要用一个类似于软件构架师的思维和角度去仔细思考和斟酌如何才能设计出一个体系结构相对合理,存储方式比较简洁的产品项目。...
  • 一个典型的采集服务器体系结构设计

    万次阅读 热门讨论 2006-09-18 10:14:00
    一个典型的采集服务器体系结构设计一个基于大量可复用模块的系统架构作者:成晓旭http://blog.csdn.net/cxxsoft(声明:版权保留,欢迎转载、请保证文章完整性)1、 整个系统简介假设系统是一个常见的监控、数据采集...
  • 比如,我们要做一个web学生作业在线管理系统,它的系统结构(软件体系结构、软件架构)设计是什么?我们老师要求做这一部分的PPT讲解,我不知道这一块怎么写。求助。不是功能图吧?功能图我已经分析并做好了
  • 一个开源的IoC采集服务器体系结构设计

    万次阅读 多人点赞 2007-09-06 22:33:00
    一个开源的IoC采集服务器体系结构设计基于IoC思想设计的系统架构作者:成晓旭http://blog.csdn.net/CXXSoft/(声明:版权保留,欢迎转载、请保证文章完整性)1. 引言Java领域的开发人员,可以采用spring开源框架,...
  • 最近学习软件体系结构课,结合自己的项目实践,对于软件的体系结构设计有一点想法。 在本次课程中,好像更倾向于自顶向下的设计方法。最近我在看《重构》这本书,里面则青睐从细节向结构的设计方法。 对于自顶...
  • @Override public int readInt() { checkReadableBytes0(4); int v = _getInt(readerIndex); readerIndex += 4; return v; } protected abstract int _getInt(int index);
  • 在VL2所提出的体系结构中,应用程序使用服务地址通信而底层网络使用位置信息地址进行转发,这就使得虚拟机能够在网络中任意迁移而不影响服务质量。加州大学的Mysofe等人提出了PortLandL,PortLand使用的同样是...
  • /** * {@inheritDoc} * <p>Expects a handler to have either a type-level @{@link Controller} * annotation or a type-level @{@link RequestMapping} annotation. */ @Override ...
  • 计算机体系结构.体系结构简介 什么是计算机体系结构 对于“Computer Architecture”,有些地方译为“计算机系统结构”,有些地方译为...计算机体系结构包含了整个计算机设计与实现的方方面面,是对整个计算机系...
  • 系统总体结构设计

    千次阅读 2020-02-16 04:25:08
    系统总体结构设计     系统设计工作应该自顶向下地进行。首先设计总体结构,然后再逐层深入,直至进行每一个模块的设计。总体设计主要是指在系统分析的基础上,对整个系统的划分(子系统)、机器...
  • 体系结构设计基础

    千次阅读 2015-04-02 13:07:39
    2) 结构一致性(概念完整性):体系结构的风格,模块化。 3) 坚固性(高质量):易开发、易修改、易复用、易调试、易维护。   2.已知的软件设计方法与技术(至少5中),并说明它们促进了哪些审美标准的达成?  1...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,488,373
精华内容 595,349
关键字:

系统结构设计