 |
| 编程软件 |
软件并不只是包括可以在计算机上运行的程序，与这些程序相关的文件一般也被认为是软件的一部分。
软件被应用于世界的各个领域，对人们的生活和工作都产生了深远的影响。
系统软件编辑本段回目录
系统软件为计算机使用提供最基本的功能，可分为操作系统和支撑软件，其中操作系统是最基本的软件；
系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作。系统软件使得计算机使用者和其他软件将计算机当作一个整体而不需要顾及到底层每个硬件是如何工作的。
1.操作系统是一管理电脑硬件与软件资源的程序，同时也是计算机系统的内核与基石。操作系统身负诸如管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务。操作系统也提供一个让使用者与系统交互的操作接口。操作系统分为BeOS 、BSD 、DOS 、Linux 、Mac OS、OS/2 、QNX 、Unix、Windows等。
2.支撑软件是支撑各种软件的开发与维护的软件,又称为软件开发环境。它主要包括环境数据库、各种接口软件和工具组。著名的软件开发环境有IBM公司的Web Sphere,微软公司的Studio.NET等。包括一系列基本的工具（比如编译器，数据库管理，存储器格式化，文件系统管理，用户身份验证，驱动管理，网络连接等方面的工具）。
应用软件编辑本段回目录
 |
| 杀毒软件 |
应用软件是为了某种特定的用途而被开发的软件。它可以是一个特定的程序，比如一个图像浏览器。也可以是一组功能联系紧密，可以互相协作的程序的集合，比如微软的Office软件。也可以是一个由众多独立程序组成的庞大的软件系统，比如数据库管理系统。
较常见应用软件的有：
行业管理软件 ：如电脑行业管理软件开龙IT200 商软ERP等
文字处理软件 ：如Office、WPS等
信息管理软件 ：如Assces数据库
辅助设计软件 ：如AutoCAD、Photoshop
媒体播放软件：如暴风影音、豪杰超级解霸、Windows Media Player、RealPlayer等
系统优化软件：如windows优化大师、超级兔子魔法设置
实时控制软件 ：
教育与娱乐软件 ：
图形图像软件 ：coreldraw ,painter,GIMP(linux下),3DS MAX,MAYA,softimage|xsi,lightwave,cineme 4d,Houdini
数学软件：Mathematica，Maple，Matlab，MathCad
统计软件：SAS，SPSS
后期合成软件 ：after effects,combustion,digital fusion,shake,flame
杀毒软件 ：如瑞星、金山毒霸、卡巴斯基、江民等
软件开发编辑本段回目录
软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉，需求分析，设计，实现和测试的系统工程。软件一般是用某种程序设计语言来实现的。通常采用软件开发工具可以进行开发。软件：具有一定功能的各种电脑程序，称为软件。
操作系统软件
操作系统是一管理电脑硬件与软件资源的程序，同时也是计算机系统的内核与基石。操作系统身负诸如管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务。操作系统也提供一个让使用者与系统交互的操作接口。
BeOS
BSD
DOS
Linux
Mac OS
OS/2
QNX
Unix
Windows
软件开发内容编辑本段回目录
软件开发的内容是：需求、设计、编程和测试！
需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据......为了清楚地知道这些需求，你经常要和客户、项目经理等交流。
设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照这个来做，否则可能会一团糟。
编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。
测试：目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这样可以及时知道你是否真地完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。
软件客户和开发人员编辑本段回目录
 |
| 办公软件 |
客户：
定义每个用户需求的商业优先级；
制订总体计划，包括用多少投资、经过多长时间、达到什么目的；
在项目开发过程中的每个工作周，都能让投资获得最大的收益；
通过重复运行你所指定的功能测试，准确地掌握项目进展情况；
能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划；
能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，正在进行或未完成的的工作则应该是不难接手的。
开发人员：
知道要做什么，以及要优先做什么；
工作有效率；
有问题或困难时，能得到客户、同事、上级的回答或帮助；
对工作做评估，并根据周围情况的变化及时重新评估；
积极承担工作，而不是消极接受分配；
一周40小时工作制，不加班。
软件开发包括6个阶段编辑本段回目录
计划
对所要解决的问题进行总体定义，包括了解用户的要求及现实环境，从技术、经济和社会因素等3个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源（如计算机硬件、系统软件、人力等）成本，可取得的效益和开发进度作出估计。制订完成开发任务的实施计划。
分析
软件需求分析就是回答做什么的问题。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。
设计
软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元。模块，然后进行模块设计。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，常用方法还是结构化程序设计方法。
编码
软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的"源程序清单"。充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。
当前软件开发中除在专用场合，已经很少使用二十世纪80年代的高级语言了，取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体，大大提高了开发的速度。
测试
软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例（测试数据和预期的输出结果组成了测试用例）。如何才能设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。黑盒法。
维护
维护是旨在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。
一个中等规模的软件，如果研制阶段需要一年至二年的时间，在它投入使用以后，其运行或工作时间可能持续五年至十年。那么它的维护阶段也是运行的这五年至十年期间。在这段时间，人们几乎需要着手解决研制阶段所遇到的各种问题，同时还要解决某些维护工作本身特有的问题。做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以使它扩展功能，提高性能，为用户带来明显的经济效益。然而遗憾的是，对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多。
在实际开发过程中，软件开发并不是从第一步进行到最后一步，而是在任何阶段，在进入下一阶段前一般都有一步或几步的回溯。在测试过程中的问题可能要求修改设计，用户可能会提出一些需要来修改需求说明书等。
计算机软件 编辑本段回目录
开放分类： 计算机 软件
计算机软件(Computer Software)是指计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述；文档是为了便于了解程序所需的阐明性资料。程序必须装入机器内部才能工作，文档一般是给人看的，不一定装入机器。
软件是用户与硬件之间的接口界面。用户主要是通过软件与计算机进行交流。软件是计算机系统设计的重要依据。为了方便用户，为了使计算机系统具有较高的总体效用，在设计计算机系统时，必须通盘考虑软件与硬件的结合，以及用户的要求和软件的要求。
软件的正确含义应该是:
(1)运行时，能够提供所要求功能和性能的指令或计算机程序集合。
(2)程序能够满意地处理信息的数据结构。
(3)描述程序功能需求以及程序如何操作和使用所要求的文档。
软件特点: 编辑本段回目录
(1)表现形式不同
设计软件
硬件有形，有色，有味，看得见，摸得着，闻得到。而软件无形，无色，无味，看不见，摸不着，闻不到。软件大多存在人们的脑袋里或纸面上，它的正确与否，是好是坏，一直要到程序在机器上运行才能知道。这就给设计、生产和管理带来许多困难。
(2)生产方式不同
软件是开发，是人的智力的高度发挥，不是传统意义上的硬件制造。尽管软件开发与硬件制造之间有许多共同点，但这两种活动是根本不同的。
(3)要求不同
硬件产品允许有误差，而软件产品却不允许有误差。
(4)维护不同
硬件是要用旧用坏的，在理论上，软件是不会用旧用坏的，但在实际上，软件也会变旧变坏。因为在软件的整个生存期中，一直处于改变(维护)状态。
软件语言 编辑本段回目录
开放分类： 计算机 软件 计算机语言
软件语言（Software Language）是用于书写计算机软件的语言。它主要包括需求定义语言、功能性语言、设计性语言、程序设计语言以及文档语言等。
需求定义语言用以书写软件需求定义，软件需求定义是软件功能需求和非功能需求的定义性描述。软件功能需求刻画“做什么”，软件非功能需求刻画诸如功能性限制、设计限制、环境描述、数据预通信规程以及项目管理等。需求定义语言经历了从非形式的自然语言到半形式化语言以及形式化语言的发展，迄今半形式化的需求定义语言已经有很大的发展，已逐步用于软件工程的实践。
功能性语言用以书写软件功能规约，软件功能规约是软件功能的严格而完整的陈述。软件功能规约通常只刻画软件系统“做什么”的外部功能，而不涉及系统“如何做”的内部算法，因此，功能性语言通常又称为功能规约语言。从形式化的程度看，有非形式化功能性语言和形式化功能性语言之分。功能性语言涉及对象，规约方法以及规约性质等。规约对象主要包括过程抽象和数据抽象两类：过程抽象是指从输入值到输出值集的映射，其定义域和值域均由数据抽象刻画。数据抽象则提供了数据值及其上的运算符集。规约方法涉及如何对过程抽象预数据抽象进行规约。
设计性语言用以书写软件设计规约。软件设计规约是软件设计的严格而完整的陈述。一方面，它是软件功能规约的算法性细化，刻画了软件“如何做”的内部算法；另一方面，它又是软件实现的依据从。从细化程度来看，有总体设计规约与详细设计规约之分。前者刻画设计的总计框架；后者刻画详尽细节。
实现性语言，即一般的程序设计语言，用于计算机程序、处理对象和规则的描述。程序设计语言有高级语言和低级语言之分。
文档语言用以书写软件文档。以上的软件需求定义，软件功能规约，软件设计规约等都是软件文档。此外还可能有一些其他阐明性的资料，这些也是软件文档。
各种软件语言
PDL：一种典型的设计性语言，常用于详细的设计。
Z：一种功能性语言，是以一阶谓词演算为基础的一种规约语言。
程序设计语言用于书写计算机语言，包含语法、语意和语用三个方面。
Prolog：非过程式语言，一种说明性语言，一种人工智能程序设计语言。
RPG：非过程式语言。
C ：面向对象语言。
Java：面向对象语言。
Smalltalk：面向对象语言。
软件架构 编辑本段回目录
软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”
但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
是一般而言，软件系统的架构（ArchitECture）有两个要素：
·它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
历史早在1960年代，诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在 Rational Software Corporation 和MiCROSoft内部的相关活动，软件架构这个概念开始越来越流行起来。
卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwaRDS our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（FORMs follows function）。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是模式理论和XP理论。
架构的目标 编辑本段回目录
正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：
·可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
·可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。
·可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展
·可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费
·客户体验（Customer Experience）。软件系统必须易于使用。
·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
架构的种类编辑本段回目录
根据我们关注的角度不同，可以将架构分成三种：
·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图
可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。
其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。
根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。
构架描述
为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。
构架视图编辑本段回目录
我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。
构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。
典型的构架视图集
构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4 1 视图模型”[KRU95]。它包括：
用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。实施视图：包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4 1 视图模型中的一些视图。
 |
| vista系统 |
构架重点
虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：
模型的结构，即组织模式，例如分层。基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。
构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要：
系统演进，即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量，例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。
构架模式
构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。
构架模式示例
[BUS96] 根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。
类别 模式结构 层管道和过滤器黑板分布式系统 代理交互系统 模型-视图-控制器表示-抽象-控制自适应系统 反射微核
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]
但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
为阐明其含义，下面将详述其中的两个；完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示：
模式名环境问题影响，描述应考虑的不同问题方面解决方案基本原理结果环境示例模式名层
环境需要进行结构分解的大系统。
问题必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。
影响
系统的某些部分应当是可替换的构件中的变化不应波动相似的责任应归为一组构件大小 -- 复杂构件可能要进行分解解决办法将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。
示例：
1. 通用层
严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用，它包括更明显的机制。
2. 业务系统层
上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。
有关该模式的深入讨论，请参见指南：分层。
模式名黑板
环境没有解决问题的确定方法（算法）或方法不可行的领域。例如 AI 系统、语音识别和监视系统。
问题多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。
影响
知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略
不同顾问的输入（结果或部分解决方案）可能有不同的表示方式
各顾问并不直接知道对方的存在，但可以评估对方发布的工作
解决办法多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。
示例：
以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。
构架风格软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（Rational Unified Process 中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。
构架设计图构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：
逻辑视图：类图、状态机和对象图。进程视图：类图与对象图（包括任务 - 进程与线程）。实施视图：构件图。部署视图：配置图。用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。构架设计流程在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。
架构师
软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。
这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。
但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
