软件详细设计

这是一篇关于软件详细设计的思维导图，主要包括系统建模和体系结构设计两部分内容。

软件详细设计

• 第五章 系统建模
  • 系统建模就是建立系统抽象模型的过程，其中每一个模型表示系统的一个不同的视角或观点。
  • 在需术工程过程中使用模型，是为了帮助得到详细的系统需求；在设计过程中使用模型，是为了向实现系统的工程师描述系统；在实现系统之后还要使用模型，是为了描述系统的结构和运行。
  • 理解系统模型并不是系统的一个完备表示，很重要。 系统模型有意去掉一些细节以使模型更容易理解。 模型是所研究系统的一种抽象，而不是系统的另一种表示。 系统的一个表示应当包含关于所表示的实体的所有信息。 一个抽象则有意简化一个系统设计并选取最显著的特性。
  • 可以同时针对现有系统和待开发系统开发系统模型。 现有系统模型在需求工程过程使用。帮助阐明现系统做什么，且可用于让利益相关者间讨论聚焦于现系统优势和弱点。 新系统模型在需求工程过程中使用。帮助解释对其他系统利益相关者所提 出的需求。 工程师使用这些模型来讨论设计方案并描述系统以用于实现
  • 可以开发不同的模型来从不同的视角表示系统。 外部视角，对系统的上下文或环境进行建模； 交互视角，对系统及其环境或者系统构件之间交互进行建模； 结构化视角，对系统组织或系统所处理数据的结构进行建模； 行为视角，对系统的动态行为及系统如何响应事件进行建模。
  • 开发系统模型时，开发者可灵活决定图形化表示法使用方式。
  • 开发者并不总是需要严格坚持一些细节。一个模型的细节和严格性取决于开发者打算如何使用它。
  • 作为推动关于现有或新系统的讨论以及使讨论聚焦的方式。 模型目的是推动以及聚焦参与系统开发的软件工程师之间讨论。模型可不完整(要覆盖讨论要点)，且可能会以一种非正式的方式使用建模表示法。敏捷建模常见模型使用方式。
  • 作为一种文档化现有系统的方式。 当模型被用于文档化时，它们不需要完整，因为你可能只需要使用模型去描述系统的一些部分。必须是正确的—它们应当正确地使用相应建模表示法，且对系统准确描述。
  • 作为一种可以用于生成系统实现的详细系统描述。 当模型作为基于模型开发过程的一部分被使用时，系统模型必须是完整正确。可以作为生成系统源代码基础，因此不要混淆相似但含义各不相同符号(如，线形箭头和块状箭头)。
  • 在系统规格说明的早期阶段，你应当确定系统的边界，也就是说确定哪些属于、哪些不属于所开发的系统。
  • 与系统利益相关者一起决定哪些功能应当包含在系统中，以及哪些处理和操作应当在系统的运行环境中执行。
  • 开发者决定哪些业务自动化，哪些手工或由其他系统支持。
  • 应考虑新系统功能与原系统可能存在的重叠部分，并决定新功能应当在哪里实现。
  • 这些决定应早做，以控制理解需求和设计所需成本和时间。
  • 有时，系统及其环境的边界相对清楚。如，自动化系统准备取代已有手工或计算机化系统时，新旧系统的环境通常一样。
  • 而在其他情况下则存在更多的灵活性，需要在需求工程过程中确定系统及其环境的边界由哪些因素构成。
  • 系统将管理参加心理健康诊断以及安排治疗的病人的信息。
  • 必须确定系统是否应当只关注收集诊疗的信息，还是系统也应该收集病人信息。依赖其他系统获取病人信息好处是避免数据重复。缺点是使用其他系统可能信息访问慢，另外如果这些系统不可用那么Mentcare系统也会无法使用。
  • 有些情况，系统用户基础非常分散，有很多不同需求：可能会不定义系统边界，而开发一个可以通过调整适应不同用户需要的可配置系统。iLearn系统的开发中就釆用了这种方法。用户范围很广，从很小的还无法阅读的小孩子到年轻人、他们的老师以及学校管理人员。用户群体需要不同的系统边界，设计可以允许系统在部署时再确定边界的可配置系统。
  • 上下文模型
    • 边界确定，定义系统上下文以及系统对于其环境的依赖。
    • 上下文模型没有显示环境中的系统之间关系的类型 外部系统可能提供或消费系统数据、共享数据，可能直接网络连接或没有连接，可能位于同一位置或位于不同建筑中。 所有这些关系都可能会影响所定义的系统的需求和设计，必须加以考虑。可以和其他模型 ，如业务过程模型一起使用。
    • UML活动图可以显示系统使用所处的业务过程。 描述 Mentcare系统心理健康问题治疗过程—强制留置。
    • 活动图强调从活动到活动的控制流，是内部处理驱动的流程。 UML用于对系统动态行为建模一种常用工具，描述活动的顺序，展现从一个活动到另一个活动的控制流。
    • 活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模
    • 系统都包含某种交互:可以是用户交互(输入和输出)；也可是开发软件和其他系统间交互；或者软件内部构件间交互。 用户交互建模很重要，因为它可以帮助识别用户需求。 建模系统间的交互可以突出可能出现的通信问题。 建模构件交互可以帮助我们理解所提出的系统结构是否能实现所要求的系统性能和可依赖性。 用例建模，建模系统与外部主体(人用户或其他系统)间交互； 顺序图，建模系统构件之间交互，也可以包含外部主体。 用例模型和顺序图表示不同抽象层次交互，可以一起使用。 例如，一个高层用例中所包含的交互的细节可以在一个顺序图中描述。
  • 用例建模
    • 参与者 医疗接待员、病人记录系统（PRS）
    • 描述 医疗接待员可以从Mentcare系统向健康管理机构维护的通用的病人记录数据库传输数据 所 传输的信息可以是更新的个人信息（地址、电话号码等）或者病人的诊断和治疗情况总结
    • 数据 病人个人信息、治疗总结
    • 触发激励 医疗接待员发出的用户命令
    • 响应 PRS已经更新的确认信息
    • 注解 医疗接待员必须具有访问病人信息以及PRS的适当的信息安全许可
  • 顺序图
    • UML顺序图用于建模参与者与系统中的对象之间的交互以及这些对象自身相互间的交互。重点是顺序图的一些基本特性。 顺序图显示在一个特定的用例或用例实例执行过程中发生的交互序列。下图是描述顺序图的基本表示法的例子。
    • 顺序图顶部列出参与交互的对象和参与者，下面有垂直方向虚线。矩形表示对象生命线。 箭头表示对象间交互。标签表示调 用、调用参数及返回值。 按照从上到下顺序阅读交互。 可选项的表示法。其中带有alt名称的方框、方括号中的条件、用虚线分隔的可选的交互选项。
  • 交互模型
    • 医疗接待员触发Patientlnfo(病人信息)对象类的一个实例P中的Viewlnfo(査看信息) 方法，提供病人的标识符P1D来确定所需要信息。P是个用户界面对象，显示病人信息的表单。 实例P调用数据库返回所需信息，提供接待员的标识符UID用于信息安全检 査。 数据库通过权限系统检查接待员是否具有执行此动作权限。 如果权限检査通过，那么病人信息被返回并呈现在用户屏幕上的一个表单上。 如果权 限检査不通过，那么返回一个错误消息。 左上角那个带有alt标签的方框是一个选择框.表示所包含的交互中某一个会被执行。选择每个选项的条件显示在方括号中。
  • 结构模型
    • 软件的结构模型按照构成系统的构件以及它们之间的关系显示系统的组织。 结构模型可以是描述系统设计组织的静态模型，也可以是描述系统执行时的组织的动态模型。 系统的动态组织是一组相互交互的线程。 可以在讨论和设计系统体系结构时创建系统的结构模型。 可以是总体的系统体系结构模型或者更加详细的系统中的对象及其关系的模型。 类图对软件系统中的对象类的静态结构进行建模。 UML构件图、包图、部署图都可以用于描述体系结构模型。
  • 类图
    • 当开发一个面向对象系统模型来显示系统中的类以及类之间的关联时，可以使用类图。
  • 泛化
    • 日常生活中并不是从经历的所有事情的详细特性中进行学习的，而是学习通用的类(动物、汽车等)及这些类特性。 在此基础上通过对事物进行分类来复用这些知识，并关注它们与它们所属的类之间的差异。 在建模系统时，检査系统中是否存在泛化和创建类的空间。 通用的信息只需要在一个地方保存即可。最高泛化层上变更。 在Java等面向对象语言中，类继承的机制来实现。
  • 聚集
    • 现实世界中的对象经常由不同的部分组成。例如，一个课程的学习包可能包括一本书、 PowerPoint.课堂测验、推荐阅读。 UML的聚集，意思是一个对象(整体)由其他对象(部分)组成。
  • 行为模型
    • 行为模型是关于系统在运行时的动态行为的模型，描述当系统对来自环境的激励进行响应时发生什么或者应该发生什么。 激励可以是数据或事件 统必须处理的数据产生了。数据的产生触发相应的处理过程 一个事件发生了，触发了系统处理。事件可以有相关联的数据，虽然并非总是如此。实时系统多事件驱动 数据流图是展现功能性视角的系统模型，每个转换表示单个功能或过程，用于描述数据流如何从一系列处理步骤中流过。 UML中的活动图可以用于表达数据流图。
  • 数据驱动的建模
    • 数据驱动的模型描述处理输入数据以及生成相关的输出过程中所涉及的动作序列。描述了系统中端到端的处理。 需求分析过程中使用 UML活动图描述 另一种描述系统中的 处理序列的方法是使 用UML顺序图
  • 事件驱动的建模
    • 事件驱动的建模描述一个系统如何对外部和内部事件做出响应。这种模型建立在系统具有有限数量的状态以及事件（激励）可以导致状态间的转换的假设基础上。 UML通过状态图支持基于事件的建模， 状态图描述了系统状态以及导致状态间转换的事件。 状态图不会描述系统中的数据流，但是可以包含关于每个状态中所执行的计算的额外信息
• 体系结构设计
  • 体系结构设计关注理解一个软件系统应当如何组织，以及设计该系统的整体结构。 体系结构设计是设计和需求工程之间关键性衔接环节，因为它会确定组成一个系统的主要结构构件以及它们之间关系。 体系结构设计过程输出是一体系结构模型，该模型描述系统如何被组织为一组相互通信的构件。
  • 作为需求工程过程的一部分，要提出一个抽象的系统体系结构，其中将一组组的系统功能或特征与大规模的构件或子系统关联起来 接下来，要使用这一分解结构来与利益相关者讨论需求以及更加详细的系统特征。 可在两个抽象层次上设计软件体系结构 小体系结构关注单个程序的体系结构。关注单个的程序是如何被分解为构件的。 大体系结构关注包括其他系统、程序和程序构件的复杂企业系统体系结构，这些企业系统可以分布在不同的计算机上，这些计算机可以由不同的公司拥有和管理
  • 软件体系结构很重要，它会影响系统的性能、健壮性、分布性和可维护性。单个构件实现了功能性系统需求，非功能性系统特性的主导影响因素是系统的体系结构。非功能性需求对于系统体系结构的影响最大。设计软件体系结构3好处。 利益相关者交流。体系结构是一种可以作为许多不同利益相关者讨论的焦点的系统的高层表示 系统分析。在系统开发的早期阶段明确系统的体系结构要求进行一些分析体系结构设计决策对于系统是否能够满足性能、可靠性、可维护性等关键需求具有深远的影响 大范围复用。体系结构模型是关于系统如何组织以及构件如何互操作的一个紧凑、可管理的描述。具有相似需求的系统经常具有相同的系统体系结构，因此可支持大范围软件复用
  • 体系结构设计是一个创造性的过程，在这个过程中你会设计一个满足系统功能性和非功 能性需求的系统组织结构。 并不存在公式化的体系结构设计过程。 具体的体系结构设计过程 取决于所开发的系统的类型、系统架构师的背景和经验，以及系统的特定需求。 最好是将体系结构设计作为一系列决策而不是活动序列。
  • 在体系结构设计中，系统架构师必须做出一系列深刻影响系统及其开发过程的结构决策，基于他们的知识和经验，必须考虑图中所显示基本问题
  • 每个软件系统都是独特的，但同一个应用领域中的系统经常具有相似的、反映领域的基本概念的体系结构。 当设计系统体系结构时，必须确定系统和更广阔的应用类型有什么共性，确定来自这些体系结构中知识有多少可以复用。 嵌入式系统及针对PC和移动设备设计应用，不需要设计分布式体系结构。大型系统是分布式系统。分布式体系结构的选择是一个影响系统性能和可靠性的关键决策。 软件体系结构可以基于特定的体系结构模式或风格。是一种系统组织方式的描述，例如，C/S组织或者层次化体系结构。 体系结构模式捕捉了一个在不同的软件系统中使用 的体系结构的本质特性。在进行系统体系结构决策时应当了解通用的模式、这些模式的适用 场合、它们的优势和弱点。6.3节介绍了几个经常使用的模式。
  • 体系结构风格和结构选择应当根据系统非功能性需求来决定。 性能。如是关键性需求，应将关键性操作局部化到少量的构件，尽量使用一些相对较大颗粒的构件部署在同一台计算机上而不要分布在网络上-。减少了构件间通信量。还可考虑运行时系统中允许系统多副本部署在不同处理器上执行。 信息安全。如是关键性需求，使用层次化体系结构，把最关键资产放在最内层保护，对这些层应用高级的信息安全确认。 安全性。如是关键性需求，应将安全性相关操作集中在单个或少量构件。减少安全性确认成本和问题，并提供相关保护系统，保护系统可以在失效发生时安全地关闭系统。 可用性。如是关键性需求，那么体系结构设计应该包含冗余的构件以便在不停止系统的情况下可以更换或更新构件。 可维护性。如是关键性需求，那么系统体系结构设计应当使用容易改变的细粒度、自包含的构件。应当将数据的生产者与数据的消费者相分离，同时应当避免共享的数据结构。
  • 体系结构模型可以与软件需求或设计相关 体系结构模型也可以用于设计的文档化，体系结构可以作为更加详细的系统设计以及实现的基础。 在设计和描述一个体系结构时，哪些视图或视角是有用的？ 应当使用哪些表示法来描述体系结构模型？ 单个图表示出一个体系结构相关的所有信息是不可能 一个图形化模型只能显示一个系统视图或视角。 可以显示系统如何分解为模块、运行时进程如何交互，或者系统构件在一个网络上的不同分布方式。 通常都需要从多个不同的视图来呈现软件体系结构。
  • 著名的4+1”软件体系结构视图模型提出应当有4个基本的体系结构视图，这些视图可通过共同的用例或场景连接在一起。 逻辑视图，将系统中的关键抽象显示为对象或对象类应该可以将系统需求与这逻辑视图中的实体联系起来。 进程视图，系统运行时如何通过相互交互的进程来构成。对于做出关于非功能性特性（性能、可用性）的判断很有用。
  • 开发视图。显示软件如何面向开发任务进行分解；即，显示了软件如何分解构件。软件开发管理者和程序员都很有用。 物理视图。显示系统硬件及软件构件如何分布在系统中的处理器上。对于规划系统部署方案的系统工程师很有用。
  • 模式一种表示、分享、复用软件系统相关知识的思想已在软件工程中一系列领域中得到采用。90年代提出体系结构模式 体系结构模式理解为对好的实践一种风格化、抽象化描述。 一个体系结构模式应当描述一种已经在此前的系统中得到成功应用的系统的组织。它应当包含何时适合以及何时不适合使用该模式，还应包含关于该模式优缺点详细描述等信息。
    • 名 称 MVC （模型-视图-控制器）
    • 描述 将呈现和交互从系统数据中分离岀来，系统被组织为3个相互交互的逻辑构件.模 型（Model）构件管理系统数据以及相关的对这些数据的操作，视图（View）构件定义并管理数据呈现给用户的方式，控制器（Controller）构件管理用户界面（例如按键、 鼠标点击等）并将这些交互传递给视图和模型。
    • 例子 下页图显示了一个使用MVC模式进行组织的基于Web的应用系统的体系结构
    • 何时使用 当存在多种査看数据以及与数据交互的方式时使用，也可以在未来关于数据的交互 和呈现的需求未知时使用
    • 优点 允许数据独立于它的呈现方式进行变更，反之亦然。支持以不同的方式呈现同样的 数据。在某一个呈现方式中进行的修改可以在所有呈现方式中显示
    • 缺点 当数据模型和交互比较简单时，可能包含额外的代码以及代码复杂性
  • 分离和独立性的思想是体系结构设计的基础，可以使变更被局部化。MVC模式将系统元素分离，允许它们独立变更。 如，增加一新视图或者改变一现有视图可以在不改变所依赖的模型中的数据的情况下实现。 分层体系结构模式是另一种实现分离和独立性方式，系统功能被组织为多个分离的层次，每个层次只依赖于紧邻的下一层所提供的设施和服务。支持系统增量开发。一个层次开发好之后，该层次所提供的一些服务可以提供给用户。 该体系结构也是可变化和可前移。如接口不变，一个功能进行扩展的新层可在不影响系统其他部分情况下取代已有层。 当一个层次接口变化或者增加新设施，只有相邻层次受影响。 分层系统将机器的依赖局部化了，这使提供一个应用系统的多平台实现变得更容易了。只需将与机器有依赖关系的层重新实现，便可以适应不同的操作系统或数据库的设施。
    • 名 称 分层体系结构
    • 描述 将系统组织为多个层次，每个层次与一些相关的功能相联系：每个层次向其上的一层提供服务，因此那些最底层次表示很有可能在整个系统中使用的核心服务
    • 例子 一个数字化学习系统的分层模型支持学校中所有科目的学习
    • 何时使用 在已有系统之上构建新的设施时使用；开发涉及多个团队，每个团队负责一个层次上的功能时使用；存在多个层次上的信息安全需求时使用
    • 优点 只要接口保持不变，允许对整个层进行替换，可以在每个层次上提供冗余设施（如，身份认证）以增加系统的可依赖性
    • 缺点 在实践中，将各层之间干净地分离经常很难做到，较高层次上的层可能不得不与较低层次上的层直接交互，而不是通过紧邻着的下一层。性能可能是一个问题，因为当一个服务请求在各个层次上进行处理时需要经过多层的解析
  • 作为体系结构模式的例子，分层体系结构和MVC模式所呈现的视图都是一个系统的概念化组织。 下一个体系结构模式的例子，知识库模式，则描述了一组相互交互的构件如何共享数据
  • 大多数使用大量数据系统都是围绕一个共享数据库或知识库组织。 这个模型适合于数据由一个构件生成同时由另一个构件使用应用。 这类系统例子包括指挥控制系统、管理信息系统、计算机辅助设计系统、交互式软件开发环境。
    • 名称 知识库
    • 描述 一个系统中的所有数据在所有系统构件都能访问的中心知识库中进行管理。构件相互之间并不直接交互，仅通过知识库进行交互
    • 例子 一个集成开发环境（IDE）例子，其中构件使用系统设计信息的知识库。每个软件工具生成的信息都会提供给其他工具使用
    • 何时使用 当系统生成大量需要长时间保存的信息时应当使用这个模式。还可以在数据驱动的系统中使用，这类系统中的知识库中增加新数据时会触发一个动作或工具
    • 优点 构件可以保持独立，它们不需要知道其他构件的存在；一个构件进行的修改可以被传播到所有构件；所有数据都可以一致地进行管理（例如同时进行备份），因为这些数据都位于一个地方
    • 缺点 知识库可能存在单点失效问题，因此知识库中的问题会影响整个系统；通过知识库组织所有的通信可能效率不高；将知识库分布到多台计算机上可能比较困难
  • 下图面向集成开发环境（IDE），其中包含不同支持模型驱动开发工具。知识库可以是一个追踪对软件的修改并且允许回滚到早期版本的版本控制环境。 围绕知识库组织工具是共享大量数据有效方法。不需显式地在构件间传输数据。构件须围绕达成共识的知识库数据模型运转。 要对每个工具的特定需要进行权衡，且如一个新构件与数据模型不相符，那么就可能很难甚至无法集成
  • 在实践中，可能很难将知识库分布到多台不同的机器上。虽然 有可能实现一个逻辑上的集中知识库的分布式部署，这其中会涉及维护数据的多份拷贝。保证这些拷贝的一致性以及及时更新给系统增加了更多的额外负担。 知识库是被动的，使用知识库的构件负责进行控制。另一种从人工智能（AI）系统中派生出来的方法是，使用一个“黑板”模型在特定的数据可用时触发构件运行。当知识库中的数据是非结构化数据时，这种方法是合适的。关于应当激活哪个工具的决策只能在对数据进行分析之后做出。
  • 知识库模式关注系统静态结构，没有显示系统的运行时组织。 客户-服务器模式描述了一种常用的分布式系统运行时组织方式。一个遵循客户-服务器模式的系统被组织为一组服务和相关联服务器，以及访问并使用服务客户端。主要构件包括： 一组向其他构件提供服务的服务器。服务器的例子包括：提供打印服务的打印服务 器，提供文件管理服务的文件服务器，提供编程语言编译服务的编译服务器服务器是软件构件，多个服务器可能运行在同一台计算机上。 一组调用服务器提供的服务的客户端，通常会有一个客户端程序的多个实例并行运行 在多台计算机上。 一个允许客户端访问这些服务的网络 客户-服务器系统通常实现为分布式系统， 使用互联网协议连接。
    • 名 称 客户-服务器
    • 描述 系统被呈现为一组服务，其中每个服务都由一个独立的服务器提供。客户端是这些服务的用户。通过访问服务器来利用这些服务。
    • 例子 一个组织成客户-服务器系统的电影和视頻/DVD库的例子
    • 何时使用 当一个共享数据库中的数据必须从一系列不同的位置进行访问时使用，因为服务器可以复制。因此也可以在一个系统的负载多变情况下使用
    • 优点 主要优点是服务器可以分布在网络上。通用的功能（例如一个打印服务） 可以向所有客户端开放使用，不需要由所有服务实现。
    • 缺点 每个服务都存在单点失效问题，因此容易受到拒绝服务攻击或服务器失效的影响；性能可能不可预测，因为这取决于网络以及系统；如果服务器属于不同的组织，那么还可能会出现管理问题。
  • B-S体系结构被认为是分布式系统体系结构。重要优势仍然是分离和独立性。服务和服务器可以在不影响系统的其他部分的情况下被修改。 客户端可能必须知道可用的服务器以及它们所提供的服务的名称。 服务器不需要 知道客户端的身份或者有多少客户端正在访问它们的服务。客户端使用请求-应答协议（http）远程过程调用访问一个服务器的服务
    • 名 称 管道和过滤器
    • 描述 系统中的数据处理通过组织，每个处理构件（过滤器）可以分离开来并执行一种数据 转换。数据从一个构件流动到另一个构件进行处理
    • 例子 一个用于处理发货单的管道和过滤器系统的例子
    • 何时使用 在数据处理应用（无论批处理还是事务）中得到了广泛应用，这类应用中输入 在多个分离的阶段中进行处理，并最终生成相关的输出
    • 优点 容易理解并且支持变换的复用；这种工作流风格与许多业务过程的结构相匹配；通 过增加变换来进行演化是非常直观的；可以被实现为一个顺序系统或一个并发系统
    • 缺点 针对数据转换的格式必须在相互通信的多个变换之间达成一致；每个变换必须解析 它输入，并将输出转换成所约定形式，增加了系统负担，无法 复用使用不兼容的数据结构的体系结构构件
  • 管道和过滤器来自于Unix操作系统。 计算机最初被用于自动化地数据处理，已经使用该模式变体。 当变换是顺序化的而所处理的是批量数据时，这个管道和过滤器体系结构模型就成为批量顺序模型。 一 种通用的数据处理系统（如账单系统）的体系结构。 例子。一个组织向客户发出发货单。每个星期他们都会将已经收到的付款与这些发货单进行对账对于已经付款的发货单，他们会发出一个收据。对于那些在所允许的支付时间内还没有付款的发货单，他们会发出一个付款提醒。 最适合于用户交互很少的批处理系统和嵌入式系统。
  • 交互式系统很难使用管道和过滤器模型，因为管道和过滤器模型需要处理数据流
  • 应用系统目的是满足企业的需要。企业很多共性：都要雇人、开发货单、保存账户等；同行业企业使用通用行业特定应用 通用企业功能一样，所有电话公司需要系统连接呼叫和计费、管理网络、向客户发岀账单。它们的应用系统有很多共性。 共性促使开发描述特定类型软件系统结构和组织软件体系结构。 应用体系结构封装了一类系统的主要特性。 例如实时系统可能包含不同的通用体系结构模型，如数据收集系统或监控系统。实例细节存在差异，共性体系结构复用。 应用体系结构可以在开发新系统时重新实现。 许多企业系统，当通过配置通用的应用系统来创建一个新应用时，应用体系结构复用是隐式的。 ERP及可配置的成品应用系统(如财务和仓库管理)中可以看到 这些系统有标准的体系结构及相关的构件。这些构件可以通过配置和适应性调整来创建一个特定的企业应用。 如，一个供应链管理系统可通过适应性调整来支持不同类型的供应商、商品、合同关系。
  • 信息和资源管理系统有时候也是事务处理系统。 电子商务系统基于互联网资 源管理系统，接受商品或服务的电子订单，然后安排这些商品或服务向客户交付。系统应用特定层包括附加功能以支持购物车，用户可以通过多个分开的事务放入一些购物项，然后在一个事务中一起支付所有购物项。 系统中的服务器组织通常反映了4层通用模型。这些系统经常实现为带有多层客户端/服务器体系结构的分布式系统。 Web服务器负责所有的用户通信，并带有使用Web浏览器实现的用户界面。 应用服务器负责实现特定应用逻辑以及信息存储和检索请求。 数据库服务器将信息移动到数据库，从数据库中获取数据，同时处理事务管理。 使用多个服务器可以实现高吞吐量，使每分钟处理成千上万的事务成为可能。随着请求量的増长，每个层次都可以增加服务器以应对所需要的额外处理能力。
  • 面向编程语言的语言处理系统体系结构如图所示。 源语言指令定义了要执行的程序，一个翻译器将这些转换为面向抽象机器指令。另一个构件解析，该构件取出执行指令并且使用来自环境的数据执行这些指令。