系统架构图的类别
逻辑架构图、部署架构图、运行架构图、网络架构图，再加上一个数据架构图，称为架构5视图或4+1视图，为什么有那么多视图呢，是因为架构不是那么简单那么容易理解的，不同人不同角度会有不同的看法，5个视图差不多就是同一个事物的5种看法吧。
至于架构的意思、区别，我就不打字了，从其它地方弄了一个过来，供参考：5视图法可以帮助软件架构师以不同的视角对软件的各个方面的属性：功能需求，约束，运行期质量属性，开发期质量属性。
1、 逻辑架构：逻辑架构关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”——。
2、 开发架构：开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现场框架、类库，以及开发的系统将运行于其上的系统软件或中间件。
关注编译时刻的静态依赖关系。
3、 运行架构：运行架构关注进程、线程、对象等运行时概念，以及相关的并发，同步，通信等问题。
运行架构关注运行期间各个单元的交互。
4、 物理架构：物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性，可伸缩性等要求。
5、 数据架构：数据架构关注持久化数据的存储方案，不仅包括实体及实体关系的存储格式、还包括数据传递，数据复制，数据同步等策略。
软件架构定义是怎样的？
软件架构定义：将软件系统划分为多个模块，明确各模块间的相互作用，组合起来实现系统的全部特性。
软件架构不仅确定了系统的组织结构和拓扑结构，还显示了系统需求和构成系统各要素间的对应关系，提供了一些设计决策的基本原则。
以上是我对于这个问题的回答，希望能够帮到大家。
编写软件架构文档说明,第 1 部分： 什么是软件架构,为什么为软件...
引言 软件架构是一门学科，开始于 20 世纪 70 年代。
面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。
与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。
软件架构表示系统的结构和行为方面。
在早期为软件架构编写文档说明时，所使用的文本和图解表达常常不足或者不够精确。
所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。
在学术研究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。
在本系列中，您将了解如何编写软件架构文档说明。
了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。
回页首软件架构不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。
其中没有哪一种解释是错误的；每种解释都具有自己的价值。
Bass L 等人抓住了软件架构的本质： “程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。
每个软件组件或体系结构构建块具有某些外部可见的属性，这是它向其他体系结构构建块公开的属性。
软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑盒。
该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。
软件架构在恰当的粒度级别标识体系结构构建块。
软件架构还标识那些构建块如何彼此相关，并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。
各个部分彼此具有显式的关系。
当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别，存在一些混淆。
正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。
需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。
体系结构将体系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。
体系结构将软件组件与其外部属性绑定在一起。
设计通常要比体系结构松散得多，因为它允许以更多的方式遵守组件的外部属性。
设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。
请考虑一个属于某个系统的软件架构组成部分的软件组件 （C1）。
软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。
设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。
设计人员详细设计了 C11、C12、C13 及其接口。
此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。
对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。
通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。
参与者必须能够理解体系结构。
因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。
回页首编写体系结构文档说明的重要性参与者：体系结构的下游设计和实现用户。
为体系结构的定义、维护和增强功能进行投资的人。
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。
软件架构通过不同的视图进行表示——功能、操作、决策等等。
没有任何单一视图能够表示整个体系结构。
并非所有视图都需要表示特定企业或问题领域的系统体系结构。
架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。
作为一门学科，软件架构是非常成熟的。
您可以利用最佳实践和指导...
软件架构有哪些过程？
本文来自于 Rational Edge：软件架构被公认为软件开发领域的一门新兴学科。
作为软件架构系列文章的第三篇，本文描述的是在软件工程的生命周期里软件架构师正在进行的各类活动。
在这个系列里，我的 第一篇文章描述的是什么是软件架构， 第二篇文章 讲述软件架构师这个角色的特征。
第三部分是建立在以前讨论的基础之上，而且所考虑的主题或者特征都是在软件架构过程这个框架下。
软件架构活动：定义及范围 根据IEEE标准，软件架构活动代表了 这样一系列活动：定义、记录、维持、改进一个软件构架并确保其正确执行。
软件架构的范围相当宽泛。
图1展示的模型详细地说明了软件架构过程的各个方面。
这个模型来自IEEE标准1471，架构师所关注的软件架构各个方面都可以此模型作为参考。
图1：软件架构相关术语的模型 图1中阴影框里的元素直接来自于IEEE标准1471，它们之间的相互关系阐明的是一个系统及其构架的诸多特征： 一个系统有一个构架。
一个系统完成一项任务。
一个系统存于一个环境中，并受这个环境的影响。
一个系统有一个或多个涉众。
一个构架对应一条构架描述。
一条构架描述识别一个或多个涉众。
一条构架描述识别一条或多条关联。
一条构架描述提供理由。
一个涉众有一条或多条关联，一条关联对一个或多个涉众都很重要。
软件架构设计的三个维度是什么？
构设计是一个非常大的话题，不管写几篇文章，接触到的始终只是冰山一角，更多的是实践中去体会。
这篇文章主要介绍面向对象OO、面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用。
架构设计有三个维度，或者说是我们在考虑架构时需要思考三个方向。
这三个维度分别为面向对象、面向方面、面向服务。
这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑，整个架构的示意图如图所示。
图：架构三维度结构图 面向对象 面向对象技术最初是从面向对象的程序设计开始的，它的出现以上世纪60年代Simula语言为标志，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前思想的重新注解。
上世纪80年代中后期，面向对象程序设计逐渐成熟，被计算机界理解和接受，人们又开始进一步考虑面向对象的开发问题。
直到现在，面向对象已经成为一种非常流行的编程方式，以及软件设计的架构。
面向对象提出有三个主要目标：重用性、灵活性和扩展性，强调对象的“抽象”、“封装”、“继承”和“多态”。
它能让人们以更加接近于现实世界的方式来思考程序，这点可以说是面向对象最大的进步。
在OO思想的运用上，业界出现了很多好的经验与技巧，从而涌现出大量的设计模式，可以说面向对象是系统分析与设计时的一个很重要的方面。
面向方面 面向方面最初来源于hook技术，本质上就是满足扩展的需求，可以在程序中自由扩展功能。
面向方面不仅仅是一门编程技术，同样也是一种架构设计的思路。
如果说OO是纵向地分析、切割整个系统，那么可以认为AOP是横向地对系统作切片。
简单地理解，OO与AOP分别从两个不同的角度给我们提供了分析系统的思路。
面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进行分析。
我们认为OO是接近于人类认识自然的思维方式，但对于东方而言却并不一定是这样的。
当西方人看到一个复杂系统的时候，只会有一种思路，就是“分解”，将系统分解成一块一块，然后每个部分进行研究。
当东方人看到一个复杂系统的时候，更多地会关注系统中存在的关系，将系统作为一个有机的整体进行研究，这也是东方和西方在事物看法上存在的差异。
这两种思维方式都没有问题，如果结合起来分析问题，解决问题会更好。
面向对象与面向方面也同样如此，都能对应到人类认识自然的思维方式上。
面向服务 面向服务可以说是最近炒得比较火热的概念。
包括现在提到的SaaS(Softwae as a sevice)，软件即服务。
准确而言，面向服务不仅仅是软件行业的概念，这个要从社会的产业结构说起。
社会产业总共分为三个，第一产业农业，第二产业工业，第三产业服务业。
最早社会的主要产业是第一产业农业，将近有几万年的历史。
十八世纪下半叶在英国开始的工业革命，对人们的生活产生了根本性的影响，社会的主要产业成了第二产业工业。
现在仍然属于工业时代，或者有人说的“后工业时代”。
而在后工业时代，社会的经济体制必定要向第三产业服务业逐渐转型。
面向服务其实是社会经济体制重心的一种迁移。
还是说回到软件行业，社会的主要产业将转变成服务业，自然软件行业也会出现对应的变化，那就是这里提到的面向服务。
面向服务今后会影响到软件的交付模式，会对整个软件行业的体制产生影响。
而说到架构层面，面向服务是系统发布功能的一种方式。
并且基于这种方式下不同的系统之间能有效地通信、协作。
常见的实现技术就是We Sevice。
软件全局观 软件架构设计的三个维度：面向对象、面向方面、面向服务。
最年长的一个维度就是面向对象，发展了好几十年，也是相对而言比较成熟的一个维度。
它解决的问题是系统内部结构的设计。
面向方面思想的提出能够弥补面向对象的缺陷。
面向对象的方式不能实现横切关注点的分离，而面向方面正是为了解决这个问题。
面向方面与面向对象一样都是解决系统内部结构的设计。
面向服务更多的是涉及到系统的外部，简单地说就是发布功能。
它并不关注系统内部结构的实现，所以说面向服务与面向对象或者面向方面并不冲突。
这三个维度并不是绝对孤立的，它们之间会互相影响、制约，相互发展的。
我们在分析架构的时候需要同时考虑到这三个维度的问题，这样有助于我们设计出更加优秀的架构。
android 五大应用开发框架是什么
第二部分将详细介绍这5个部分。
下面自底向上分析各层。
Android架构1、Linux KernelAndroid基于Linux 2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。
Linux Kernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。
如果你学过计算机网络知道OSI/RM，就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及以下层的差异，当本层及以下层发生了变化不会影响到上层。
也就是说各层各尽其职，各层提供固定的SAP(Service Access Point)，专业点可以说是高内聚、低耦合。
如果你只是做应用开发，就不需要深入了解Linux Kernel层。
2、Android RuntimeAndroid包含一个核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。
每一个Android应用程序是Dalvik虚拟机中的实例，运行在他们自己的进程中。
Dalvik虚拟机设计成，在一个设备可以高效地运行多个虚拟机。
Dalvik虚拟机可执行文件格式是.dex,dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。
大多数虚拟机包括JVM都是基于栈的，而Dalvik虚拟机则是基于寄存器的。
两种架构各有优劣，一般而言，基于栈的机器需要更多指令，而基于寄存器的机器指令更大。
dx 是一套工具，可以将 Java .class 转换成 .dex 格式。
一个dex文件通常会有多个.class。
由于dex有时必须进行最佳化，会使文件大小增加1-4倍，以ODEX结尾。
Dalvik虚拟机依赖于Linux 内核提供基本功能，如线程和底层内存管理。
3、LibrariesAndroid包含一个C/C++库的集合，供Android系统的各个组件使用。
这些功能通过Android的应用程序框架（application framework）暴露给开发者。
下面列出一些核心库： 系统C库--标准C系统库（libc）的BSD衍生，调整为基于嵌入式Linux设备 媒体库--基于PacketVideo的OpenCORE。
这些库支持播放和录制许多流行的音频和视频格式，以及静态图像文件，包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层 LibWebCore--新式的Web浏览器引擎，驱动Android 浏览器和内嵌的web视图 SGL--基本的2D图形引擎 3D库--基于OpenGL ES 1.0 APIs的实现。
库使用硬件3D加速或包含高度优化的3D软件光栅 FreeType --位图和矢量字体渲染 SQLite --所有应用程序都可以使用的强大而轻量级的关系数据库引擎4、Application Framework通过提供开放的开发平台，Android使开发者能够编制极其丰富和新颖的应用程序。
开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等等，很多很多。
开发者可以完全使用核心应用程序所使用的框架APIs。
应用程序的体系结构旨在简化组件的重用，任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能（需要服从框架执行的安全限制）。
这一机制允许用户替换组件。
所有的应用程序其实是一组服务和系统，包括： 视图（View）--丰富的、可扩展的视图集合，可用于构建一个应用程序。
包括包括列表、网格、文本框、按钮，甚至是内嵌的网页浏览器 内容提供者（Content Providers）--使应用程序能访问其他应用程序（如通讯录）的数据，或共享自己的数据 资源管理器（Resource Manager）--提供访问非代码资源，如本地化字符串、图形和布局文件 通知管理器（Notification Manager）--使所有的应用程序能够在状态栏显示自定义警告 活动管理器（Activity Manager）--管理应用程序生命周期，提供通用的导航回退功能5、ApplicationsAndroid装配一个核心应用程序集合，包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。
所有应用程序都是用Java编程语言写的。
更加丰富的应用程序有待我们去开发！ 从上面我们知道Android的架构是分层的，非常清晰，分工很明确。
Android本身是一套软件堆迭（Software Stack），或称为「软件迭层架构」，迭层主要分成三层：操作系统、中间件、应用程序。
从上面我们也看到了开源的力量，一个个熟悉的开源软件在这里贡献了自己的一份力量。
什么是系统架构设计？
描述语言为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。
在 Rational Unified Process 中，软件构架文档记录有这种描述。
架构描述语言（ADL）用于描述软件的体系架构。
已有多种架构描述语言，如Wright （由卡内基梅隆大学开发），Acme （由卡内基梅隆大学开发），C2 （由UCI开发）， Darwin （由伦敦帝国学院开发）。
ADL的基本构成包括组件、连接器和配置。
视图构架构架视图的图形描述称为构架设计图。
对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：互联网是个神奇的大网，系统架构设计也是一种模式，这里提供最详细的报价，如果你真的想做，可以来这里，这个手机的开始数字是一八七中间的是三儿零最后的是一四二五零，按照顺序组合起来就可以找到，我想说的是，除非你想做或者了解这方面的内容，如果只是凑热闹的话，就不要来了逻辑视图：类图、状态图和对象图。
进程视图：类图与对象图（包括任务 - 进程与线程）。
实施视图：构件图。
部署视图：配置图。
用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。
流程在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。
当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。
由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。
构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。
架构师软件设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。
但是，越来越多的公司体会到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
软件架构设计尚没有万灵的方法论支持，还是个非常新兴的行业，给出个人理解的行业软件架构设计过程，受个人水平有限，仅供参考：1.业务分析：针对目标行业的业务战略、蓝图、业务功能及流程进行分析，提出其中部分功能可以使用信息化进行处理，通过分析可以得出信息化要解决的问题。
2.解决方案设计：根据业务战略，形成行业信息化解决方案。
他是一个系统组，同时明确各系统间的支撑关系。
3.系统功能设计：明确信息化系统功能列表及功能层次（层次，例如经验决策层工，管理层功能，业务操作功能等），将功能散列在这些层次中，根据功能及应用特点形成一个或者多个子系统。
可参考下图理解。
4.系统架构设计：针对某一系统明确系统IT支撑表达，层次化关系表达及功能、技术核心元素5.技术体系设计：针对系统的接口、数据存储，技术路线、部署及实现抽象进行设计总体过程如下图所示
