架构蓝图--软件架构-4+1-视图模型
软件架构 4+1 视图模型
RUP 4+1架构软件需求分析的复杂性图 1 软件需求分类的复杂性RUP 4+1架构RUP4+1架构方法采用用例驱动，在软件生命周期的各个阶段对软件进行建模，从不同视角对系统进行解读，从而形成统一软件过程架构描述.用例视图（Use Cases View），最初称为场景视图，关注最终用户需求，为整个技术架构的上线文环境.通常用UML用例图和活动图描述。
逻辑视图（Logical view），主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，不涉及具体的编译即输出和部署，通常在UML中用类图，交互图，时序图来表述，类似与我们采用OOA的对象模型。
开发视图(Development View)，描述软件在开发环境下的静态组织，从程序实现人员的角度透视系统，也叫做实现视图(implementation view)。
开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图，包图来表述。
开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
处理视图（Process view）处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题。
处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题，在UML中通常用活动图表述。
物理视图（Physical view ）物理视图通常也叫做部署视图(deployment view)，是从系统工程师解读系统，关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。
物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
软件体系结构4 1模型实例
第七部分设备管理1.功能描述：设备管理功能主要包括设备信息的编辑（增加、删除、修改）。
1.1.设备信息包括设备的位置信息、名称、状态。
1.2.设备信息的编辑：支持对设备信息的编辑（增加、删除、修改）。
2.内容概述：运用4+1视图模型，从5种视图角度，进行分析设计。
2.1场景视图（Use case）使用user case图设计系统的各个场景。
2.2逻辑（功能）视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
2.3开发（模块）视图（Development View），描述了在开发环境中软件的静态组织结构。
2.4物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
2.5过程视图（Process View），捕捉设计的并发和同步特征。
4+1视图综述：3.设计详情：3.1场景视图(Scenarios)：参与者与用例构成场景视图，对设备的设置从修改，删除，增加三方面驱动。
如图1：图1在设计场景视图时，对包含（include）和扩展(extend)的应用需要仔细琢磨，刚开始并不知道每种的应用范围，看了网上的例子，和以前软件工程的书，大概了解包含的概念是一些必然发生的用例，然而扩展是在特殊情况的时候才可能发生的非正常情况。
我觉得一个小小的箭头也许在现在的项目作业中并不重要，但是在今后的学习工作中它会从某种程度上决定项目的成败，并体现出个人对工作和生活的认真态度，所以，大学课程的好处就是允许我们在实践和失败中汲取教训，总结经验。
在这部分，有同学提出了质疑，认为需要具体细分一下，如图2：图2在这里，也是得到其他同学的启发，场景视图必须要具体细分，它注重功能的概念，细分的过程可以放在逻辑视图中，通过函数来具体实现。
在这部分，我还需要更深入的了解，在实际应用过程中不断摸索。
3.2逻辑视图（Logic View）：逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。
软考高级-系统架构设计师真题知识点总结
1.常见缩写基于架构的软件设计（Architecture-Based Software Design, ABSD)特定领域软件架构（Domain Specific Software Architecture，DSSA）软件架构评估方法：1）架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）2）软件架构分析方法（Software Architecture Analysis Method， SAAM）快速应用开发（Rapid Application Development，RAD)软件开发环境（Software Development Environment，SDE)架构描述语言（Architecture Description Language, ADL)“4+1”视图模型（逻辑开发（姬发）进屋里的场景）-类实现进程部署的例子设计模式：1）创建型：单元相公造；2）结构型：理赔乔装观元组软件架构风格：流返购机舱用例关系包括：包含include、扩展extend、泛化UML图、类图关系：范组局联谊（泛化、组合、聚合、关联、依赖）系统可靠性：冗余技术、软件容错技术（恢复块设计、N版本程序设计）、双机容错技术、集群技术软件可靠性：软件容错设计（恢复块设计、N版本程序设计）、检错设计和降低复杂度设计2.*基于架构的软件设计（ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。
它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。
用例描述的是功能需求，质量属性场景描述的是质量需求。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始。
ABSD方法有三个基础：第一个是功能分解，在功能分解中使用已有的基于模块的内聚和耦合技术。
第二个是通过选择架构风格来实现质量和商业需求。
第三个是软件模板的使用。
ABSD方法是一个自顶向下，递归细化的过程，软件系统的架构通过该方法得到细化，直到能产生软件构件的类。
软件体系结构
1、MVC（模型-视图-控制）：针对用户界面 模型：核心数据封装、逻辑和功能的计算，它独立于具体的界面表达和输入/输出操作。 视图：把模型数据等信息以特定形式展示给用户。 控制：处理用户与软件的交互操作。它接受用户的输入，将输入反馈给模型，进而实现对模 型的计算控制，是使模型和视图协调工作的部件。
2、软件重用的定义 软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相近软件元素的过程。 可重用软件元素越大，重用粒度越大。
7、基于事件的隐式调用的定义 基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事 件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调 用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一个模块中过程的调用。
8、基于事件的隐式调用的优缺点 优点： （1）为软件重用提供了强大的支持。 （2）为系统带来了方便。
end Attendห้องสมุดไป่ตู้e;
16、C2 对体系结构的描述 architecture MeetingScheduler is
conceptual_components Attendee;ImportantAttendee;MeetingInitiator;
connector connector MainConn is message_filter no_filtering; connector AttConn is message_filter no filtering; connector ImportantAttConn is message_filter no filtering;
体系结构蓝图—软件体系结构的+视图(中文版)
体系结构蓝图—软件体系结构的+视图(中文版)————————————————————————————————作者：————————————————————————————————日期：本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry 和Wolfe 使用一个精确的公式来表达，该公式由Boehm 做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
体系结构蓝图—软件体系结构的41视图（中文版）
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的 Abowd& Allen、SEI 的Clemen ts。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry和 Wolfe使用一个精确的公式来表达，该公式由 Boehm做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
软件架构设计之“4+1”视图模型
软件架构设计之“4+1”视图模型1、软件架构设计 软件架构是具有⼀定形式的结构话元素，即构件的集合，包括处理构件、数据构件和连接构件。
处理构件负责对数据进⾏加⼯，数据构建是被加⼯的信息，连接构件把架构不同部分负责连接起来。
软件架构是软件设计过程中⼀个层次，这⼀层次超越计算过程中的算法设计和数据结构设计。
2、软件架构建模 设计软件架构的⾸要问题是如何表⽰软件架构，即对软件架构建模。
根据建模的侧重点不同，可以讲软件建构的模型分为5种，分别是结构模型、框架模型、动态模型、过程模型和功能模型。
2.1结构模型这是⼀个最直观、最普遍的建模⽅法。
这种⽅法以架构的构件、连接件和其他概念呢来刻画架构，并⼒图通过结构来反映系统的重要寓意内容，包括系统的配置、约束、隐含的假设条件、风格和性质等。
研究结构模型的核⼼是架构描述语⾔。
2.2框架模型框架模型和结构模型类似，但他不太侧重描述结构的细节⽽更侧重与整体的结构。
框架模型主要以⼀些特殊的问题为某表建⽴⾄针对和适应该问题的结构。
2.3动态模型动态模型是对结构或框架模型的补充，研究系统“⼤颗粒”的⾏为性质例如，描述系统的重新配置活演化。
动态可以指系统的总体结构和配置、建⽴活拆除通信通道或计算的过程。
这类系统是激励型的。
2.4过程模型过程模型研究构造系统的步骤和过程，因⽽结构是遵循某些过程脚本的结果。
2.5功能模型该模型认为架构是⼀组功能构件按层次组成，下层向上提供服务。
它可以看作是⼀种特殊的框架模型。
在这5中模型中，最常⽤的是结构模型和动态模型。
这5中模型各有所长，将5中模型有机地统⼀在⼀起，形成⼀个完整的模型来刻画软件架构更合适。
例如，Kruchten在1995年提出了“4+1”视图模型。
3、“4+1”视图模型 “4+1”视图模型从5个不同的视⾓包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。
每个视图只关⼼系统的⼀个侧⾯，5个视图结合在⼀起才能反映系统软件架构的全部内容。
软件体系结构 4+1模型案例
案例教学1：4+1视图方法进行软件体系结构设计要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。
1、呼唤体系结构设计的多重视图方法灵感一闪，就想出了把大象放进冰箱的办法，这自然好。
但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。
需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。
以工程领域的例子开道吧。
比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
图1 软件需求分类的复杂性2、超市系统案例：理解需求种类的复杂性例子是最好的老师。
为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。
在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
表1 超市系统案例：理解需求种类的复杂性简单而言，功能需求就是"软件有什么用，软件需要做什么"。
4+1架构体系的内容_解释说明以及概述
4+1架构体系的内容解释说明以及概述1. 引言1.1 概述在软件开发领域，架构体系（Architecture）扮演着关键的角色，它定义了软件系统的整体结构和组织，并对系统的功能、性能和可扩展性等方面产生深远影响。
而4+1架构体系是一种被广泛采用和认可的架构设计方法。
本文将详细解释和说明4+1架构体系的内容，并对其概述进行阐述。
1.2 文章结构本文共分为五个部分。
首先，在引言部分我们给出了文章的概述，明确了文章对于4+1架构体系的解释说明以及概述要探讨的内容。
接下来，第二部分将详细介绍什么是4+1架构体系，并重点讨论其核心要素——架构视图和场景描述。
此后，我们将在第三部分和第四部分中探讨该架构体系下涉及到的具体要点，从而更加全面地了解这一设计框架。
最后，在第五部分中，我们将总结回顾本文所探讨的主要观点和进展，并给出未来发展的展望和建议。
1.3 目的通过本文对于4+1架构体系内容的解释说明以及概述，旨在帮助读者深入理解这一软件架构设计方法，并为软件开发人员在实践中应用4+1架构体系提供指导和参考。
同时，本文也着重强调了该架构体系的重要性和实用价值，以及对未来软件系统开发领域的发展前景作出探讨。
以上是对于“1. 引言”部分内容的详细清晰撰写，如有需要，请继续咨询其他部分的内容。
2. 4+1架构体系的内容解释说明概述2.1 什么是4+1架构体系？4+1架构体系是一种在软件工程领域中常用的软件体系结构描述方法。
该方法由美国计算机科学家Philippe Kruchten于1995年提出，并被广泛应用于软件系统设计和开发中。
这一软件体系结构描述方法将系统的架构划分为四个视图（Views）以及一个场景描述（Scenarios）。
它强调了以多视图和用例为基础的方式来描述和显示系统的各个方面，从而帮助团队成员更好地理解和沟通软件系统体系结构。
2.2 架构视图（Views）在4+1架构体系中，架构视图指的是通过不同角度来描述系统的多个视角。
基于SA的UML4+1模型分析
基于SA基本特性与核心属性的UML4+1模型分析报告摘要：由于软件体系结构的描述方法多种多样．各种工具不仅涉及不同领域，而且描进方法不尽相同。
给系统选择一种合适工具描述体系站构带来了难度。
统一建模语言UML是一种被广泛采纳的可视化建模语言。
它将系统结构的共同特征用相关语义、符号、图形加以描述。
Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、部署视图、开发视图、用例视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个试图结合在一起反映系统的软件体系结构的全部内容。
关键字：软件架构，UML，4+1模型，建模1、引言软件体系结构建模是工业化生产软件开发的基本工作。
复杂的系统难以被人们完全理解，通过建立良好的模型，帮助我们掌握复杂的体系结构也为开发成功的软件系统打下基础。
随着复杂系统的日益增加，好的建模技术也日益其重要性。
在UML统一建模语言出现以前．没有一种占统治地位的建模语言。
各种语言各有特色，用户必须选择几种类似的建模语言，以完成复杂的体系结构描述。
大部分建模语言都有一些主要的、共同的概念，而在描述和表达方面却又有所不同．缺乏一种强大的具有扩展能力的建模语言，给使用者带来许多麻烦，不利于软件的推广和重用。
”4+1’模型采用UML作为各视图的表达和解释环境，统一各部分的建模描述语言，有利于合作开发以及各层次、各环节开发人员之间的沟通，建立切合实际的模型，平衡软件质量与开发周期间的矛盾，加速软件开发和推广。
2、UML 4+1模型概述UML的“4+1视图”是指从某个角度观察系统构成的4+1个视图，每个视图都是系统描述的一个投影，说明了系统某个侧面的特征。
其包含如下的几个视图：（1）用例视图（场景视图）（2）逻辑视图（3）开发视图（4）进程视图（5）部署视图（物理视图）对体系结构进行的描述是围绕着以上4个视图展开的。
然后，通过选择出的一些用例对体系结构加以说明。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
架构蓝图--软件架构 "4+1" 视图模型本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw1、CMU 的 Abowd & Allen、SEI 的 Clements。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改：软件架构＝ {元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
我们用由多个视图或视角组成的模型来描述它。
为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图 1）：•逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
•过程视图（Process View），捕捉设计的并发和同步特征。
•物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
•开发视图（Development View），描述了在开发环境中软件的静态组织结构。
架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例（use cases）或场景(scenarios)来说明，从而形成了第五个视图。
正如将看到的，实际上软件架构部分从这些场景演进而来，将在下文中讨论。
图 1 － "4＋1"视图模型我们在每个视图上均独立地应用 Perry & Wolf 的公式，即定义一个所使用的元素集合（组件、容器、连接符），捕获工作形式和模式，并且捕获关系及约束，将架构与某些需求连接起来。
每种视图使用自身所特有的表示法－蓝图（blueprint）来描述，并且架构师可以对每种视图选用特定的架构风格（architectural style），从而允许系统中多种风格并存。
我们将轮流的观察这五种视图，展现各个视图的目标：即视图的所关注的问题，相应的架构蓝图的标记方式，描述和管理蓝图的工具。
并以非常简单的形式从 PABX 的设计中，从我们在Alcatel 商业系统（Alcatel Business System）上所做的工作中，以及从航空运输控制系统（Air Traffic Control system）中引出一些例子―旨在描述一下视图的特定及其标记的方式，而不是定义这些系统的架构。
"4+1"视图模型具有相当的"普遍性"，因此可以使用其他的标注方法和工具，也可以采用其他的设计方法，特别是对于逻辑和过程的分解。
但文中指出的这些方法都已经成功的在实践中运用过。
逻辑结构面向对象的分解逻辑架构主要支持功能性需求――即在为用户提供服务方面系统所应该提供的功能。
系统分解为一系列的关键抽象，（大多数）来自于问题域，表现为对象或对象类的形式。
它们采用抽象、封装和继承的原理。
分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。
我们使用Rational/Booch 方法来表示逻辑架构，借助于类图和类模板的手段4。
类图用来显示一个类的集合和它们的逻辑关系：关联、使用、组合、继承等等。
相似的类可以划分成类集合。
类模板关注于单个类，它们强调主要的类操作，并且识别关键的对象特征。
如果需要定义对象的内部行为，则使用状态转换图或状态图来完成。
公共机制或服务可以在类功能（class utilities）中定义。
对于数据驱动程度高的应用程序，可以使用其他形式的逻辑视图，例如 E-R 图，来代替面向对象的方法（OO approach）。
逻辑视图的表示法逻辑视图的标记方法来自 Booch 标记法4。
当仅考虑具有架构意义的条目时，这种表示法相当简单。
特别是在这种设计级别上，大量的修饰作用不大。
我们使用 Rational Rose? 来支持逻辑架构的设计。
图 2 －逻辑蓝图的表示法逻辑视图的风格逻辑视图的风格采用面向对象的风格，其主要的设计准则是试图在整个系统中保持单一的、一致的对象模型，避免就每个场合或过程产生草率的类和机制的技术说明。
逻辑结构蓝图的样例图 3 显示了 Télic PABX 架构中主要的类。
图 3 － a. Télic PABX 的逻辑蓝图 b.空中交通系统的蓝图PABX 建立终端间的通信连接。
终端可以是电话设备、中继线（例如，连接到中央办公室）、连接线（PABX 专线到 PABX 线)、电话专线、数据线、ISDN 等等。
不同的线路由不同的接口卡提供支持。
线路 controller 对象的职责是在接口卡上对所有的信号进行解码和注入，在特定于接口卡的信号与一致性的小型事件集合之间进行相互转换：开始、停止、数字化等。
controller 对象同时承载所有的实时约束。
该类派生出许多子类以满足不同的接口类型。
terminal 对象的责任是维持终端的状态，代表线路协调各项服务。
例如，它使用 numbering plan 服务来解释拨号。
conversation 代表了会话中的一系列终端。
conversation 使用了Translation Service(目录、逻辑物理映射、路由),以及建立终端之间语音路径的Connection Service 。
对于一个包含了大量的具有架构重要意义的类的、更大的系统来说，图 3 b 描述了空中交通管理系统的顶层类图，包含 8 个类的种类（例如，类的分组）。
进程架构过程分解进程架构考虑一些非功能性的需求，如性能和可用性。
它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起－即在哪个控制线程上，对象的操作被实际执行。
进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。
在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作"processes"）的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过 LAN 或者 WAN 连接起来。
多个逻辑网络可能同时并存，共享相同的物理资源。
例如，独立的逻辑网络可能用于支持离线系统与在线系统的分离，或者支持软件的模拟版本和测试版本的共存。
进程是构成可执行单元任务的分组。
进程代表了可以进行策略控制过程架构的层次（即：开始、恢复、重新配置及关闭）。
另外，进程可以就处理负载的分布式增强或可用性的提高而不断地被重复。
软件被划分为一系列单独的任务。
任务是独立的控制线程，可以在处理节点上单独地被调度。
接着，我们可以区别主要任务、次要任务。
主要任务是可以唯一处理的架构元素；次要任务是由于实施原因而引入的局部附加任务（周期性活动、缓冲、暂停等等）。
它们可以作为 Ada Task 或轻量线程来实施。
主要任务的通讯途径是良好定义的交互任务通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等。
次要任务则以会见或共享内存来通信。
在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。
消息流、过程负载可以基于过程蓝图来进行评估，同样可以使用哑负载来实现"中空"的进程架构，并测量在目标系统上的性能。
正如 Filarey et al. 在他的 Eurocontrol 实验中描述的那样。
进程视图的表示法我们所使用的进程视图的表示方法是从Booch最初为 Ada 任务推荐的表示方法扩展而来。
同样，用来所使用的表示法关注在架构上具有重要意义的元素。
(图 4)图 4 －过程蓝图表示法我们曾使用来自 TRW 的 Universal Network Architechure Services（UNAS0）产品来构建并实施过程和任务集合（包扩它们的冗余），使它们融入过程的网络中。
UNAS 包含 Software Architect Lifecycle Environment(SALE)工具，它支持上述表示方法。
SALE 允许以图形的形式来描述进程架构，包括对可能的交互任务通信路径的规格说明，正是从这些路径中自动生成对应的 Ada 或 C++ 源代码。
使用该方法来指定和实施进程架构的优点是易于进行修改而不会对应用软件造成太多的影响。
进程视图的风格许多风格可以适用于进程视图。
例如采用 Garlan 和 Shaw 的分类法1,我们可以得到管道和过滤器（Pipes and filters）,或客户端/服务器，以及各种多个客户端/单个服务器和多个客户端/多个服务器的变体。
对于更加复杂的系统,可以采用类似于 K.Birman 所描述的ISIS系统中进程组方法以及其它的标注方法和工具。
进程蓝图的例子图 5 － Télic PABX 的过程蓝图（部分）所有的终端由单个的 Termal process 处理，其中 Termal process 由输入队列中的消息进行驱动。
Controller 对象在组成控制过程三个任务之中的一项任务上执行：Low cycle rate task 扫描所有的非活动终端(200 ms)，将 High cycle rate task(10 ms)扫描清单中的终端激活，其中 High cycle rate task 检测任何重要的状态变化，将它们传递给 Main controller task，由它来对状态的变更进行解释,并通过向对应的终端发送消息来通信。