《软件体系结构》课件 07-软件体系结构描述方法

软件体系结构描述方法软件体系结构课程组目录软件体系结构描述1软件体系结构建模22软件体系结构描述-概念3软件体系结构不仅是系统的蓝图，也是开发改系统项目的蓝图。它定义了工作分配。它是质量属性的主要载体。它是早期分析的最佳工具。它是部署后维护和挖掘的关键。描述软件系统结构是创建体系结构的最重要步骤。无论目前还是20年后，软件体系结构文档都能代表软件体系结构的设计思路。

软件体系结构由一定形式的结构化元素组成，即是构件的集合。包括处理构件、数据构件和连接构件。处理构件负责加工数据，数据构件代表被加工的信息，连接构件则负责组合连接不同的构件。概念软件体系结构描述-作用4作用描述软件体系结构是理解体系结构设计思想、交流如何使用体系结构指导系统构建的基础。如果不能理解，如何使用体系结构？如果不能沟通，如何理解？软件体系结构设计理解与交流软件体系结构描述文档软件体系结构描述-时机5浏览网站与客户互动体系结构评估什么时候需要描述当我们浏览自己公司的网站、与客户互动、或进行软件体系结构评估，都需要获得一份关于软件体系结构的描述文档，作为交流的凭借。软件体系结构描述-方式6在工业界，采用的描述方式或问题一般是“使用UML。”“画框和线。”“除了我的Rose类图中，我还需要什么？”“自然语言不是很好。”“怎么记录变化的信息？”传统描述方式工业界采用的传统描述方式存在一定的局限性，而专业的软件体系结构描述文档则可解决这一问题。软件体系结构描述-原则(1/11)71.从读者的角度写。2.避免不必要的重复。3.避免歧义。4.使用标准组织结构。5.记录理由。6.保持文档时效性但不是频繁更新

（有限的稳定性）。7.审查文档是否符合需求建立描述文档的基本原则8读者在阅读文档时希望知道什么？使信息易于查找！您的读者将感谢您的努力，并且更有可能阅读您的文档。为方便作者而写的文件标志：意识流：是作者脑海中发生事情的顺序执行流：是计算机中事物发生的顺序软件体系结构描述-原则(2/11)1.从读者的角度撰写每种信息都应准确记录在一个地方。（必要时使用参考）。这使文档更易于使用和更改。重复经常会造成混淆，因为重复信息的方式略有不同，不知道哪个是正确的？9软件体系结构描述-原则(3/11)2.避免不必要的重复10文档用于交流信息和想法，如果造成误会则说明文档失效精确定义的符号/语言有助于避免歧义。建立字典有助于避免歧义。如果文档使用了图形语言需要建立一个图例图例需要正式定义或给出每个符号的含义。软件体系结构描述-原则(4/11)3.避免歧义(1/2)11软件体系结构描述-原则(5/11)3.避免歧义(2/2)线框图是建筑符号的一种非常常见的形式。但是它们是什么意思？没有明确的解释，就不能被称为是一种体系结构描述。如果我们使用这种方式描述体系结构，则始终要精确定义方框和线条的含义。如果我们看到一个没有定义的框图，也需要询问所有者这是什么意思，或许能获得比较有趣的结果。12软件体系结构描述-原则(6/11)4.使用标准组织结构组织结构建立标准组织结构，确保文档遵循它，并确保读者知道它是什么管理一个成功的文档将被引用数百或数千次使信息易于查找作用帮助读者浏览和查找信息帮助作者衡量尚待完成工作体现完整性规则，并帮助检查验证不要留下不完整的部分空白标记它们“待定”13为什么要像以前那样做出某些设计决策？下周，明年或未来十年，将如何记住当时的决策？下一位设计师怎么知道？记录基本原理，从长远来看可以节省大量时间。记录驳回的替选方案。软件体系结构描述-原则(7/11)5.记录理由14保持文档的时效性:不完整的、过时的、不反映事实的文档以及不遵守其自身组织结构要求的文档不应当被使用要使用最新的文档。在当前文档中，通过内容可以最有效地回答问题。如果文档无法回答问题，请修复文档软件体系结构描述-原则(8/11)6.保持文档时效性(1/2)15不要太及时更新文档在设计过程中，决策被频繁考虑和重新考虑。每五分钟修订一次文档将导致不必要的费用。更新文档时选择开发计划中的要点遵循对项目有意义的发布策略。软件体系结构描述-原则(9/11)6.保持文档时效性(2/2)161.谁将使用本文档？其用途是什么？2.我们应记录有关架构的哪些信息？3.我们将使用什么语言和符号来记录该信息？4.我们如何使用所选的语言/符号记录和组织

所选的信息，以最好地满足我们确定的目标？7.审查文档是否符合需求(1/2)软件体系结构描述-原则(10/11)177.审查文档是否符合需求(2/2)谁是架构文档的读者？他们使用文档的目的是什么？沟通与理解对系统新手的引导分析软件体系结构描述-原则(11/11)目录软件体系结构描述1软件体系结构建模21819“视图”的概念为我们提供了描述体系结构的原则：记录相关的意见然后添加适用于多个视图的信息从而将观点联系在一起架构元素–软件或硬件中存在的一组实际元素视图–由系统相关者编写和读取的一组连贯的

架构元素的表示视图的概念(1/3)软件体系结构建模-视图(1/10)20视图的概念(2/3)软件体系结构建模-视图(2/10)视图是一组架构元素及其关联关系的表示。但并非涵盖所有架构元素。视图绑定了体系结构描述时感兴趣的元素类型和关系类型，并显示了它们。21视图是一种复杂的管理方法。每个视图都可以回答有关体系结构的不同问题主要执行单元和数据存储是什么？其他软件如何使用该软件？数据是如何在系统中流动的？如何将软件部署到硬件上？视图的概念(3/3)软件体系结构建模-视图(3/10)22视图的类型(1/3)软件体系结构建模-视图(4/10)分解视图–显示与“关联的子模块”关系相关联的模块使用视图–显示与“使用”关系相关联的模块

（即，一个模块使用另一模块提供的服务）分层视图–显示被划分为相关和连贯功能的模块组。

每个组代表整体结构中的一个层。类/泛化视图–显示称为类的模块，这些模块通过关系的

“继承”或“实例”关联23视图的类型(2/3)软件体系结构建模-视图(5/10)进程视图–显示通过通信、同步和排除操作连接的进程或线程并发视图–显示组件和连接器，其中连接器代表“逻辑线程”共享数据（存储库）视图–显示创建、存储和访问持久数据的组件和连接器客户端-服务器视图–显示协作的客户端和服务器以及它们之间的连接器（即它们共享的协议和消息）24视图的类型(3/3)软件体系结构建模-视图(6/10)部署视图–显示软件元素及其对硬件和通信元素的分配实施视图–显示开发、集成和配置控制环境中的软件元素及其到文件结构的映射工作分配视图–显示模块及其如何分配给负责实施和集成它们的开发团队25软件应用程序体系结构的规范称为体系结构描述。在IEEE1471的术语中，系统具有体系结构，通过体系结构说明书来描述。架构描述选择一个或多个视点。每个视点包含了一个或多个相关的视图视图由一个或多个模型组成，并集中一个视点。架构描述由一个或多个视图组成。基于视图的体系结构建模规范(1/3)软件体系结构建模-视图(7/10)26逻辑视图：支持行为要求。关键抽象，是对象或对象类。过程视图：解决并发和分发。将线程映射到对象。开发视图：组织软件模块，库，子系统，开发单元。物理视图：将其他元素映射到处理和通信节点。用例视图：将其他视图映射到重要的用例（这些用例被称作场景）上对体系结构加以说明，它们构成了第5个视图。Rational公司的Kruchten在1995年提出了用于体系结构描述的“4+1”模型。该模型建立在由Perry&Wolf和BerryBoehm提出的体系结构定义的基础上。基于视图的体系结构建模规范(2/3)软件体系结构建模-视图(8/10)27Siemens四视图（Hofmeister，Nord，Soni，2000年）：概念视图模块互连视图执行视图代码视图Herzum&Sims(BusinessComponentFactory,1999年):技术架构应用架构项目管理架构功能架构降低软件成本的方法（Parnas等人，1980年代）模块分解视图：将模块显示为封装单位；用于隔离变化以及实现其可修改性流程视图：显示流程及其在运行时如何进行同步和通信；用于实现性能使用视图：显示程序以及它们之间相互依赖关系；用于实现增量开发和快速部署子集的能力基于视图的体系结构建模规范(3/3)软件体系结构建模-视图(9/10) 许多作者和方法都规定了一组标准的视图，但是每个视图都有一定的成本以及相应的长处。因此，我们需要一种选择视图的方法。1.建立表格行:

列举利益相关的系统架构列:列举可应用于所记录架构的一组样式。若利益相关的系统架构x需要视图y，则选中（x，y）框。2.适当组合视图以减少数量。3.根据需求对视图进行优先排序（某些利益相关者可能有额外的权重）。如何选择视图软件体系结构建模-视图(10/10)

UML和其他体系结构描述方法相比有什么优势语言和符号UML架构描述语言boxandline并非旨在记录体系结构信息。事实上标准语言UML2.0更好，它具有“组件”和“连接器”之类的体系结构。始终使用图例优势：灵活性。缺点：模糊，没有工具支持1990年代许多研究的主题；在实践中使用不多：Rapide，Wright，UniCon，ACME等…架构描述语言（ADL）最近成为IEEE标准。软件体系结构建模-UML(1/18)UML与其他方法比较30“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，只有5个视图结合在一起才能反映系统的软件体系结构的全部内容。用例视图(场景)从外部世界的角度描述正在建模的系统的功能。需要使用此视图来描述系统应该执行的操作。所有其他视图都依靠用例视图（场景）来指导它们，这就是将模型称为4+1的原因。该视图通常包含用例图，描述和概述图。软件体系结构建模-UML(2/18)4+1视图(1/3)31逻辑视图描述系统各部分的抽象描述。用于建模系统的组成部分以及各组成部分之间的交互方式。通常包括类图，对象图，状态图和协作图。过程视图描述系统中的进程。当可视化系统中一定会发生的事情时，此视图特别有用。该视图通常包含活动图。软件体系结构建模-UML(3/18)4+1视图(2/3)32物理视图描述如何将前三个视图中所述的系统设计实现为一组现实世界的实体。该视图中的图表展示了抽象部分如何映射到最终部署的系统中。该视图通常包含部署图。开发视图描述系统的各部分如何被组织为模块和组件。管理系统体系结构中的层非常有用。该视图通常包含包图和组件图。软件体系结构建模-UML(4/18)4+1视图(3/3)软件体系结构建模-UML(5/18)用例是帮助理解系统功能需求的宝贵工具，是系统提供的功能的描述。用于显示若干角色以及这些角色与系统提供的用例之间的连接关系。重要的是记住用例代表了系统的外部视图因此，不要期望用例与系统内部的类之间存在任何关联。软件体系结构建模-UML(6/18)用例图（UseCase）类图表示系统中的类和类与类之间的关系，它是对系统静态结构的描述。

类图的麻烦在于它们特别多样化，这里有一些使用技巧：不要使用所有可用的符号。从简单的东西开始：类，关联，属性，泛化和约束。仅在需要时才引入其他符号。概念类图在探索业务语言时非常有用。不要为所有事物绘制模型；最好使用一些最新的图表，而不要使用许多被遗忘的，过时的模型。软件体系结构建模-UML(7/18)类图（ClassDiagram）36对象图是某个时间点系统中对象的快照，因为它显示的是实例而不是类，所以通常称为实例图。对象图对于显示连接在一起的对象的示例很有用。在许多情况下，可以使用类图精确地定义结构，但是该结构仍然难以理解。在这些情况下，几个对象图示例可能会起到很大作用。软件体系结构建模-UML(8/18)对象图（ObjectDiagram）状态图（StateDiagram）状态图是描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常，状态图是对类图的补充。37擅长描述对象在多个用例中的行为，不太擅长描述涉及许多对象协作的行为。在使用状态图时，不要尝试为系统中的每个对象绘制状态图。仅对明显有特殊行为的对象使用状态图有助于了解发生了什么目前UI和控制对象是采用状态图描述最多的对象，因为他们有多种行为类型。软件体系结构建模-UML(9/18)协作（通信）图（CommunicationDiagram）协作图是一种交互图，强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象及对象之间的联系以及对象间发送和接收的消息。38描述对象间的协作关系，协作图（通信图）跟序列图相似，显示对象间的动态合作关系。主要问题是何时使用协作图（通信图），而不是更常见的序列图。这在很大程度上取决于个人偏好：有些人喜欢一个而不是另一个。当想强调呼叫序列时，选择序列图更好；当想强调链接时，选择协作图(通信图)更好。许多人发现，协作图(通信图)更容易在白板上更改，因此是探索替代方法的好方法。软件体系结构建模-UML(10/18)序列图（SequenceDiagram）在软件工程中，序列图是对象交互的一种表现方式。主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。39用来反映若干个对象间的动态协作关系，即随着时间的推移，对象之间是如何交互的。用来查看单个用例中多个对象的行为。更多的是描述对象之间的协作，而不擅长对其行为的精确定义。在查看多个用例中单个对象的行为时，一般使用状态图。在查看多个用例或多个线程中的行为时，一般考虑使用活动图。软件体系结构建模-UML(11/18)活动图（ActivityDiagram）描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。40巨大优势在于支持和鼓励并行行为。这使得其成为工作流程和流程建模的绝佳工具，而UML2.0中的推动实际上大部分来自参与工作流的人。原则上，可以利用分叉和联接的优势来描述并发程序的并行算法。软件体系结构建模-UML(12/18)包图（PackageDiagram）包是在UML中用类似于文件夹的符号表示的模型元素的组合，允许从UML中获取任何结构，并将其元素分组到更高级别的单元中。41包可被用于UML的任何部分。系统中的每个元素都只能为一个包所有，一个包可嵌套在另一个包中使用包图可以将相关元素归入一个系统一个包中可包含附属包、图表或单个元素软件体系结构建模-UML(13/18)组件图（ComponentDiagram）组件图描述代码构件的物理结构及各构件之间的依赖关系。将系统划分为组件并希望通过接口或组件细分为较低级别的结构来显示其相互关系。42主要目的是显示系统组件间的结构关系。在以组件为基础的开发（CBD）中，组件图为架构师提供一个开始为解决方案建模的自然形式。并允许一个架构师验证系统的必需功能是由组件实现的。对于不同的小组是有用的交流工具。软件体系结构建模-UML(14/18)部署图（DeploymentDiagram）部署图定义系统中软硬件的物理体系结构。描述了一个运行时的硬件结点，以及在这些结点上运行的软