系统建模与体系结构设计

系统建模

系统建模就是建立系统抽象模型的过程，其中每一个模型表示系统一个不同的视角或观点。

模型的用处：1、需求工程过程中：帮助得到详细的系统需求。2、设计过程中：为了向实现系统的工程师描述系统。3、实现系统后：为了描述系统的结构和运行。

系统模型是一个系统的完备表示（N）模型是系统的另一种表示（N）模型是所研究系统的一种抽象（Y）模型只包含了系统的部分特征（Y）

不同视角的模型：1、外部视角：对系统上下文或系统环境建模2、交互视角：对系统与环境之间或系统构件之间的交互进行建模3、结构化视角：对系统的体系结构和系统处理的数据的结构建模.4、行为视角：对系统的动态行为和对事件的响应方式建模。

图形化模型的使用场景：1讨论时：推动以及焦距系统开发工程师间的讨论（模型可以不完整）。2有系统时：用于文档化现有系统（模型不需要完整但要正确）。3生成系统实现时：用于生成系统实现的详细系统描述。（模型必须正确且完整）

5种UML图：

5、状态图。描述系统如何对内部和外部的事件作出响应。1、活动图。描述一个过程或数据处理中所包含的活动

3、顺序图。描述参与者与系统之间以及系统构件之间的交互。4、类图。描述系统的对象类以及这些类之间的联系

2、用况图。描述一个系统与其环境之间的交互，描述软件功能

模型视角一：上下文模型：（活动图）概念:系统、环境。在系统规格说明的早期阶段, 应当确定系统的边界，也就是说确定哪些属于、哪些不属于所开发的系统。（1、边界清除的情况：新系统取代旧系统时：新系统的环境通常和旧系统的环境一样2、提前确定边界：例子：Mentcare在管理参加心理健康诊断和安排治疗的病人的信息时，必须提前确定好收集病人信息的功能是新开发还是由其他系统提供3、部署时确定：例子：iLearn需要很多系统功能, 在部署时再确定边界。

4、非技术原因确定）

模型视角二：交互模型（用况图、顺序图）：所有系统都包含某种类型的交互。

交互的分类：

用户交互：作用是帮助识别用户需求。

系统间的交互：可以突出可能的出现的通信问题。

不同构件间交互：帮助理解系统结构是否实现所要求的系统性能和可依赖性。

交互建模的方法：1、用况建模。用于建模系统和外部主体（人类用户或其它系统）之间的交互。用况模型在系统设计的早期而不是需求工程中比较有用。用例：椭圆；参与者：线性小人；一般没有箭头。复合用况图：显示多个不同的用况。用况太多时，开发多个用况图，每个只显示相关的用况。

判断题：参与者（小人）一般只表示人，不表示其他外部系统和硬件。（N）

2、顺序图用于建模系统构件之间的交互，但是也可以包含外部主体。

顺序图：显示在一个特定的用况或用况实例执行过程中发生的交互序列：建模参与者和系统中的对象之间的交互；建模这些对象自身相互间的交互。

模型视角三：结构模型（类图）：按照工程系统的构件以及它们之间的关系显示系统的组织。（静态模型：描述系统设计组织，本章关注类图||动态模型：描述系统执行时一组相互交互的线程）

类图：显示系统中的类以及类之间的关联。

对象类：可以理解为一类系统对象的泛化定义

类图中的几种关系：

1、泛化(General ization):用于管理复杂性的一种日常技术。在Java中，用继承机制来实现。

泛化的好处：不需要在系统的所有类里寻找可能受变更影响的地方, 只在最高层泛化层次上进行变更。

泛化表示为一个向上指向更泛化的类的箭头.较低的类从父类哪里集成属性和操作，也可以增加特定的属性和操作。举例：增加了细节的泛化层次。全科医生不在医院工作, 所以没有员工编号，但是有个人诊所和地址

2实现关系(Impl ementat i on/Rea l i zat i on)：B类实现了A接口，就说A接口和B类之间有实现关系，实现关系是依赖关系的特例。用于类和接口之间。

3依赖关系(Dependency)：对于两个相对独立的对象，当一个对象负责构造另对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。与关联关系不同的是，依赖关系是以参数变量的形式传入到依赖类中的，依赖是单向的，要避免双向依赖。一般来说，不应该存在双向依赖。依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候(可以说是“uses” 了那个类)，就可以把这种关系看成是依赖。

如果在一个A类中用到了另一个B类，那么就说A类依赖B类。包括几种情况：(1) A类中有B类型的成员变量;(2) B类是A类方法的返回类型;(3) B类是A类方法的参数类型;(4) A类的方法中用到了B类。

public classProgrammer {

public void work(Computer computer){

}

}

4关联关系（Association）：对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。关联关系实际上就是类与类之间的联系，是依赖关系的特例。关联具有导航性：即双向关系或单向关系；关系具有多重性：如” 1 “（表示有且仅有一^ ），” 0…“（表示0个或者多个），“ 0,1”（表示0个或者1个），” n・・・m“（表示n到m个都可以）,” m…*"（表示至少m个）。举例：对象持久化时，如外键这种强依赖关系就是关联关系。双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。如：人和手机双向1对1关系。

// 企鹅类

public classPenguin {

// 天气类

private Climate climate;

}

5聚合关系/聚集关系（Aggregat i on）：一个对象（整体）经常由不同的部分组成（部分）；整体和部分是可以分开的，它是关联关系的特例。在链接关系中表示整体的那一段加上一个菱形。

6组合关系(Compos i te)：和聚合关系类似，组合关系关系也是用来描述整体和部分的关系，但是，它规定了部分和整体是不能分开的，即：整体与部分是同生共死的关系。组合关系使用实心麦形表示。可以将组合关系比喻成人和大脑、心脏的关系，在人出生的时候，必须有健康的大脑和心脏，人和大脑、心脏是患难与共的，人没了，大脑也没了。

public class Bird{

private Wing wing;

public Bird() {

this.wing = new Wing();

}

}

模型视角四：行为模型：行为模型是描述系统运行时的动态行为的模型。描述了当系统响对来自环境的激励进行响应是发生什么或者该发生什么。激励可以是数据（数据驱动的建模）或者事件（事件驱动的建模）。

一、数据驱动的建模（活动图、顺序图）：描述处理输入数据和生成相关的输出过程中所涉及的动作序列。可以用在需求分析过程中，描述系统端到端的处理。

1、数据流图(DFD):用于描述数据流如何从一系列处理步骤中流过。数据流图(DFD)可以用UML中的活动图来表示。

数据流模型的好处：1、追踪、描述数据是如何在系统中流动的2、有助于分析人员和设计者理解此过程3、数据流图简单直观，有利于利益相关者理解

2、顺序图：另一种描述系统中处理序列的方法是UML中的顺序图。顺序图可以用于交互建模，如果消息都是从左到右，顺序图可以描述数据处理。

二、事件驱动的建模(Event-driven modeling)（状态图）：描述一个系统如何对内外部事件作出响应。具有有限的状态以及事件可以导致状态间的转换。UML采用状态图(state diagram)支持基于事件的建模。

基于状态的建模的问题:可能状态的数据会快速的增长。解决方式：使用“父状态”的概念，封装一些独立的状态，在需要的时候可以展开。

基于状态的建模提供了关于事件处理的概览，但是更详细的细节如何获取？解决方式：使用一个表格列出状态以及激励状态转换的事件（包括它们的描述）。

模型驱动的工程(Model-driven engineering, MDE)：是一种软件开发方法，开发过程的主要产物不是程序而是模型。在硬件/软件平台上运行的程序是模型自动生成的。

AMDE和MDA的联系和区别：1、MDE是从模型驱动的体系结构(model-driven architecture, MDA)基础上发展起来的。2、MDA关注软件开发的设计和实现阶段；MDE关注软件工程过程的所有方面。

现实情况：MDE推广得并不顺利。很少有公司在整个软件开发生命周期中采用该方法。所以本章只关注MDA。

模型驱动的体系结构(Model-driven architecture, MDA)：是一种关注模型的软件设计和实现方法。MDA方法建议应当产生以下三种类型的抽象系统模型：计算无关模型、平台无关模型、平台相关模型。

模型驱动的工程有什么好处？1、运行工程师在较高的抽象层次上考虑系统，不用考虑实现细节；2、减少了错误的可能性，加快了设计和实现过程；3、同时还可以创建可复用、平台无关的应用模型。

通过开发模型转换器，所有平台无关的模型就可以快速在新平台上落地了。MDA建立在模型间的转换可以通过软件工具进行定义和自动化执行的思想基础上的。因此在原则上，可执行软件可以从一个高层系统模型生成。平台无关模型向平台相关模型转换是一个比较简单的技术问题，有一些商业化工具和开源工具可以使用。原则上只需要维护一个PIM，针对不同平台生成PSMo

MDA思想这么先进, 为什么没有成为主流软件开发方法？1每个公司的执行环境不一样，因此没有现成的成品支持工具。2是一个便于讨论软件设计的好方法，对讨论有用的抽象对实现而言却并非总是正确的抽象。3对大型复杂系统，实现不是主要问题——需求工程、信息安全和可依赖性、遗留系统的集成和测试才是更重要的问题。4追求平台无关性只对大型、长生命周期系统有意义，其中平台会在系统生命周期过程中逐渐变得过时。5敏捷方法成功第将开发人员的注意力吸引走了。

敏捷方法和模型驱动的体系结构方法之间的关系?事先进行全面的建模的思想和敏捷宣言中的基本思想是冲突的。MDA的一些方面可以用于敏捷过程，但是自动的代码生成是不现实的。

体系结构设计（属于软件开发中设计与实现中的一环）

体系结构设计： 关注理解一个软件系统应当如何组织，以及设计该系统的整体结构。

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

为什么敏捷开发不采用增量的方式设计体系结构？1一个敏捷开发过程的早期阶段应该关注设计一个整体的系统体 系结构。2体系结构的增量开发通常都不会成功。3根据变化重构构件通常相对容易。4然而，重构体系结构却很昂贵，因为可能需要修改大部分系统构件以使它们能够适应体系结构的变化。

为什么需求阶段需要体系结构？在实践中，需求工程过程和体系结构设计过程之间存在显著的重叠。理想情 况下，系统规格说明不应当包含任何设计信息。然而，这个设想是不现实的； 因此，作为需求工程过程的一部分， 要提出一个抽象的系统体系结构，其中 将一组组的系统功能或特征与大规模的构件或子系统关联起来。然后使用这 一分解结构与客户讨论需求以及更加详细的系统特征。

体系结构对一个系统的影响：功能、健壮性、分布性、可维护性。单个构件实现了功能性的系统需求；体系结构对非功能性需求主导性影响

明确地设计并描述软件体系结构的好处：1、利益相关者交流。体系结构是一种可以作为许多不同利益相关者讨论的焦点的系统的高层表示。2、系统分析。在系统开发早期阶段明确系统的体系结构要求进行一些分析。3、大范围复用。具有相似需求的系统经常具有相同的系统体系结构，因此可以支持大范围的软件复用。

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

优点：1、框图呈现了一种系统结构的高层样貌。2、直观，领域专家和软件工程师都可以理解并参与 关于系统的讨论。3、对于很多项目，框图是唯一的体系结构描述。

缺点：1、没有显示系统构件之间的关系类型；2、没有显示构件的外部可见属性。

体系结构模型的两种使用方式：1、作为一种鼓励对系统设计进行讨论的方式(可以使与需求或设计相关的讨论更加聚焦)。2、作为一种文档化已经设计好的体系结构的方式(用于设计的文档化)。

6.1体系结构设计决策

如何设计体系结构？体系结构设计是一个创造性的过程，在这个过程中你会设计一个满足 系统功能性和非功能性需求的系统组织结构。具体的体系结构设计过程取决于所开发的系统的类型、系统架构师的 背景和经验，以及系统的特定需求，因此也并不存在公式化、形式化 的体系结构设计过程。最好将体系结构社会作为一系列决策而不是一个活动序列来考虑

系统架构师要考虑的基本问题：1、是否存在一个通用的应用体系结构可以作为所设计的系统的模板。2、系统将如何分布到各个硬件核或处理器上？3、可以使用什么体系结构模式或风格？4、用来组织系统的基本方法是什么？5、用什么样的策略来控制系统中的构件的运行？6、系统中的结构构件将如何分解为子构件7、什么样的体系结构组织是实现系统的非功能性需求的最佳选择？8、系统的体系结构应当如何文档化？

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

分布式体系结构的选择：对于嵌入式系统以及针对个人电脑和移动设备设计的应用，不需要为系统设计一个分布式体系结构。然而，大多数大型系统是分布式系统，其中系统软件分布 在许多不同的计算机上。分布式体系结构的选择是一个影响系统性能和可靠性的关键决策。

体系结构模式：体系结构模式捕捉了一个在不同的软件系统中使用的体系结构的本质特性。

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

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

性能（使用大构件 ，减少构件间的通信量）、信息安全（应该使用一种层次化的体系结构组织）、安全性（应该让安全性相关的操作集中在单个构件或少量构件中）、可用性（应该包含冗余的构件）、可维护性（应当使用容易改变的细粒度、自包含的构件）

6.2 体系结构视图

体系结构视图：单个图中表示出与一个系统的体系结构相关的所有信息是不可能的，因为一个图形 化模型只能显示一个系统视图或视角。通常来说，需要从多个不同的视图来呈现软件体系结构：

逻辑视图（这个视图将系统中的关键抽象显示为对象或对象类。UML中由类图表示）、进程视图（这个视图显示系统在运行时如何通过相互交互的进程来构成。）、开发视图（这个视图显示软件如何面向开发任务进行分解）、物理视图（这个视图显示系统硬件以及软件构件如何分布在系统中的处理器上。）、概念视图（这个视图是一种系统的抽象视图。）

概念视图的用途：1、将高层需求分解为更详细的规格说明的基础，帮助工程师确定可以复用的构件；以及表示一个产品线而不是单个系统。2、用于向利益相关者解释体系结构以及告知体系结构设计决策。

在设计过程中，其他一些视图也可以在讨论系统的不同方 面的时候进行开发，但是一般都不需要从所有的视角出发开发一个完整的描述。

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

非正式的模型和表示法 (例如UML) 依旧是最常使用的系统体系结构描述方式。

不要开发全部的视图：敏捷方法的使用者，他们认为详细的设计文档通常都是没有用的，即开 发这种文档是浪费时间。这一观点基本是正确的。除非是关键系统，否则从所有体系结构视图出发开发一个详细的体系结构描述是不值得的。应该只开发对于交流有用的视图，不要担心体系结构文档是否完整。

6.3 体系结构模式

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

模型—视图—控制器(MVC)模式：

描述：将呈现和交互从系统数据中分离出来。系统被组织为3个相互交互的逻辑构件。 模型 (Model)构件管理系统数据以及相关的对这些数据的操作。视图 (View)构件定义并管理数据呈现给用户的方式。控制器(Controller)构件管理用户界面(例如按键、鼠标点击等)并将这些交互传递给视图和模型。

例子：显示了一个使用MVC模式进行组织的基于Web的应用系统的体系结构

何时使用：当存在多种查看数据以及数据交互的方式时使用。也可在未来关于数据的交互和呈现的需求未知时使用

优点：允许数据独立于它的呈现方式进行变更，反之亦然。支持以不同的方式呈现同样的数据，在某一呈现方式中进行的修改可以在所有呈现方式中显示

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

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

特点：1、支持增量开发2、支持增量开发（接口不变、接口改变）3、可迁移性(跨平台)

描述：将系统组织为多个层次，每个层次与一些相关的功能相联系。每个层次向其上的一层提供服务，因此那些最低层次表示很可能在整个系统中使用的核心服务

例子：一个数字化学习系统的分层模型支持学校中所有科目的学习

何时使用：当在已有系统之上构建新的设施时使用；当开发涉及多个团队，每个团队负责一个层次上的功能时使用；当存在多个层次上的信息安全需求时使用

优点：只要接口保持不变，允许对整个层进行替换。可以在每个层次上提供冗余设施以增加系统的可依赖性

缺点：在实践中，将各层之间干净地分离经常很难做到，较高层次上的层可能不得不与较低层次上的层直接交互，而不是通过紧邻着的下一层。性能可能是一个问题，因为当一个服务请求在各个层次上进行处理时需要经过多层的解析

知识库体系结构：面向IDE的知识库体系结构。

知识库模式，则描述了一组相互交互的构件如何共享数据。大多数使用大量数据的系统都是围绕一个共享数据库或知识库组 成的。因此，这个模型适合于数据由一个构件生成同时由另一个构件使用的应用。这类系统的例子：指挥控制系统、管理信息系统、计算机辅助设 计系统、交互式软件开发环境等。

知识库：

描述：一个系统中的所有数据在所有系统构件都能访问的中心知识库中进行管理 构件相互之间并不直接交互，仅通过知识库进行交互

例子：下图是一个集成开发环境(IDE)的例子，其中构件使用系统设计信息的 知识库。每个软件工具生成的信息都会提供给其他工具使用

何时使用：当系统生成大量需要长时间保存的信息时应当使用这个模式。还可以在数据驱动的系统中使用，这类系统中的知识库中增加新数据时会触发一个动作或工具

优点：(1)构件可以保持独立，它们不需要知道其他构件的存在；(2)一个构件进行的修改可以被传播到所有构件；(3)所有数据都可以一致地进行管理(例如同时进行备份)，因为这些数据都位于一个地方

缺点：知识库可能存在单点失效问题，因此知识库中的问题会影响整个系统；通 过知识库组织所有的通信可能效率不高；将知识库分布到多台计算机上可 能比较困难

围绕一个知识库组织工具是一个共享大量数据的有效方法。

如果一个新构件与数据模型不相符，那么 就可能很难甚至无法集成了。

在实践中，可能很难将知识库分布到多台不同的机器上。即使逻辑上实现了分布式存储，在保证这些拷贝的一致性以及及时更新给系统时，也增加了更多的额外负担。

客户—服务器体系结构：知识库模式关注系统的静态结构，没有显示系统的运行时组织。一个遵循客户-服务器模式的系统被组织为一组服务和相关联的服务器，以及访问并使用服务的客户端。

客户—服务器体系结构：主要构件包括：客户端、服务器、网络

描述：在客户-服务器体系结构中，系统被呈现为一组服务，其中每个服务都由一个独立的服务器提供。客户端是这些服务的用户，通过访问服务器来利用这些服务

例子：下图是一个组织成客户-服务器系统的电影和视频/DVD库的例子

何时使用：(1)从多个不同的位置进行访问一个共享数据库中的数据时使用。(2) 因为服务器可以复制， 因此一个系统的负载时好时坏时使用(备份服务器正常运行保证可靠性)

优点：这种模型的主要优点是服务器可以分布在网络上。通用的功能(例如一个 打印服务)可以向所有客户端开放使用，不需要由所有服务实现

缺点：每个服务都存在单点失效问题，因此容易受到拒绝服务攻击或服务器失效 的影响；性能可能不可预测，因为这取决于网络以及系统；如果服务器属 于不同的组织，那么还可能会出现管理问题

客户端可能必须知道可用的服务器以及它们所提供的服务的名称。服务器不需要知道客户端的身份或者有多少客户端正在访问它们的服务。客户端通过使用请求-应答协议的远程过程调用访问一个服务器提供的服务，其中客户端向一个服务器发出请求，并且一直等待直到收到来自服务器的应答。客户-服务器模型最重要的优势在于它是一个分布式体系结构。很容易增加一个新的服务器并将其与系统的剩余部分相集成。

管道和过滤器体系结构

管道和过滤器是一个系统运行时组织结构的模型。其中 (功能性的) 变换处理输入并产生输出。数据从一个构件流动到另一个构件，在流经这个序列时进行变换。每个处理步骤被实现为一个变换。这些变换可以串行或并行执行。

描述：系统中的数据处理通过组织，每个处理构件(过滤器)可以分离开来并执行一种数据转换。数据从一个构件流动(就像在管道中一样)到另一个构件进行处理

例子：下图是一个用于处理发货单的管道和过滤器系统的例子

何时使用：在数据处理应用(无论是批处理还是基于事务)中得到了广泛应用，这类应用中输入在多个分离的阶段中进行处理，并最终生成相关的输出

适用的场景：管道和过滤器最适合于用户交互很少的批处理系统和嵌入式系统。

不适用的场景：交互式系统很难使用管道和过滤器模型实现，因为管道和过滤器模型需要处理数据流。对于图形化的用户界面、更复杂的输入/输出格式以及基于事件的控制策略，很难将这些实现为一种符合管道和过滤器模型的顺序流。

优点：容易理解并且支持变换的复用；这种工作流风格与许多业务过程的结构相匹配；通过增加变换来进行演化是非常直观的；可以被实现为一个顺序系统或一个并发系统

缺点：针对数据转换的格式必须在相互通信的多个变换之间达成一致；每个变换必须解析它的输入，并将输出转换成所约定的形式，增加了系统的负担，同时可能意味着无法复用使用不兼容的数据结构的体系结构构件

6.4 应用体系结构

应用系统：应用系统的目的是满足一个企业或者一个组织的需要。所有的企业都有很多共性：它们都需要雇人、开发货单、保存账户等。因此，这些企业使用的应用系统同样有很多共性。

应用体系结构：这些共性促使人们去开发描述特定类型软件系统的结构合组织的软件体系结构。应用体系结构封装了一类系统的主要特性。它们的共性的体系结构在开发同一类型新系统时可以复用。

应用体系结构例子：对很多企业系统，当通过配置通用的应用系统来创建一个新的应用时，应用体系结构复用是隐式的。这一点在广泛使用的企业资源规划系统 ( Enterprise Resource Planning,ERP) 以及可配置的成品应用系统 (财务系统、仓库管理系统)中可以看到。这些系统有一个标准的体系结构以及相关的构件。这些构件可以通过配置和适应性调整来创建一个特定的企业应用。

事务处理应用

事务处理应用是以数据库为中心的应用，处理用户的信息请求并且更新数据库中的信息。例如：电子商务系统。

语言处理系统

语言处理系统中用户的意图用形式化语言 (如编程语言) 来表达。如编译器。

应用体系结构作用(应用体系结构使用方式)：1、作为一个设计检查表2、作为组织开发团队

工作的一种方式3、作为评价构件复用的一种方式4、作为谈论应用是的一种词汇表5、作为体系结构设计过程的起点

事务处理系统：事务处理系统被设计用于处理[用户获取数据库中信息的]请求或者 [更新数据库的]请求。

从技术上看，一个数据库事务包含一个操作序列并且该序列作为整体处理。一个事物中的所有操作必须在数据库修改被持久化之前完成。这保证了一个事务中失败的操作不会导致数据库中的不一致。(原子性)

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

事务处理系统通常是交互式系统，其中发出的异步的服务请求。下图描述了事务处理应用的概念体系结构。

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

事务处理系统包括：交互式银行系统、电子商务系统、信息系统、预订系统等。

信息系统：所有包含与一个共享数据库交互的系统都可以认为是基于事务的信息系统。

和6.4.2节“事务处理系统” 的关系是包含被包含的关系。因为事务处理系统包括交互式银行系统、电子商务系统、信息系统、预订系统等。

信息系统几乎都是基于Web的系统，其中用户界面在一个Web浏览器中实现。

语言处理系统：语言处理系统将一种语言翻译为该语言的另一种表示方式，对于编程语言还可以执行所产生的代码。三种形式如下：

1、编译器 将 一 种编 程 语 言 翻 译 为机器代码。

2、其他语言处理系统可以将XML数据描述为数据库查询命令或者另一种XML表示形式。

3、自然语言处理系统可以将一种自然语言翻译为另一种语言。

面向编程语言的语言处理系统体系结构：源语言指令定义了要执行的程序，一个翻译器将这些转换为面向抽象机器的指令。对于许多编译器，解析器是处理机器指令的系统硬件， 而抽象机器是真实的处理器。然而，对于动态类型语言(如Ruby，Python等)，解析器是一个软件构件。

作为更通用的编程语言编译器具有一个通用体系结构，其中包括以下这些构件：词法分析器、符号表、语法分析器、语法树、语义分析器、代码生成器。

语言处理系统的知识库体系结构：

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