系统架构设计(一)
软件架构概念
软件架构的定义
软件架构(Sofware Architecture，SA）：一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性（构件的功能、接口...)以及它们之间的相互关系。(从需求分析到软件设计之间的过渡过程)
架构并非可运行软件。确切地说，它是一种表达，使软件工程师能够:
- 分析设计在满足所规定的需求方面的有效性;
- 在设计变更相对容易的阶段，考虑体系结构可能的选择方案;
- 降低与软件构造相关联的风险
软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个迭代的过程。
架构设计主要关注软件构件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。
软件架构是项目干系人进行交流的手段(与项目有关的人),明确了对系统实现的约束条件，决定了开发和维护组织的组织结构,制约着系统的质量属性。研究软件架构的根本目的是解决好软件的复用、质量和维护问题。
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
软件架构设计与生命周期
需求分析阶段
需求分析和SA设计面临的是不同的对象:一个是问题空间:另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题:如何根据需求模型构建SA模型。如何保证模型转换的可追踪性（需求可以反映在架构中）。
设计阶段
设计阶段是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括:SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3个层次:SA的基本概念(构件和连接子)、体系结构描述语言ADL、SA模型的多视图表示。
SA模型的多视图表示从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的SA模型。多视图体现了关注点分离SOC的思想。
典型的多视图的方案包括4+1模型(逻辑视图、进程视图、开发视图、物理视图，加上统一的场景)。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。
逻辑视图:也称设计视图，主要描述系统的功能需求，
进程视图:也称过程视图，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。
开发视图:也称实现视图，侧重于软件模块的组织和管理。
物理视图:主要描述如何把软件映射到硬件上，通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
统一的场景:可以看作是那些重要系统活动的抽象，它使4个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件以及它们之间的作用关系。逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。
实现阶段
最初SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现SA设计向实现的转换，实现阶段的体系结构研究表现在以下几个方面。
- (1)研究基于SA的开发过程支持，如项目组织结构、配置管理等。
- (2)寻求从SA向实现过渡的途径，如将程序设计语言元素引入SA阶段、模型映射、构件组装复用中间件平台等。
- (3)研究基于SA的测试技术。
构件组装阶段
在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。研究内容包括如下两个方面。
- 如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。
- 在组装过程中，如何检测并消除体系结构失配问题。
在构件组装阶段的失配问题主要包括:由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。
部署阶段
SA对软件部署作用如下:
(1)提供高层的体系结构视图来描述部署阶段的软硬件模型。
(2)基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案
后开发阶段
后开发阶段是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。
(1)动态软件体系结构。现实中的软件具有动态性，体系结构会在运行时发生改变。运行时变化包括两类:软件内部执行所导致的体系结构改变;软件系统外部的请求对软件进行的重配置。动态软件体系结构包括两个部分的研究:体系结构设计阶段的支持、运行时刻基础设施的支持。
(2)体系结构恢复与重建。对于现有系统在开发时候没有考虑SA的情况，从这些系统中恢复或重构体系结构。从已有的系统中获取体系结构的重建方法分为4类:手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术(如数据挖掘等)。
构件
- 构件是面向软件体系架构的可复用软件模块。构件(Component)是可复用的软件组成成份，可被用来构造其他软件。它可以是被封装的对象类、功能模块、软件框架(Framework)、中间件等。
- 构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务
- 构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能够被单独部署
- 构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
- 模块:是不带单独资源的原子构件，是一组类和可能的非面向对象的结构体，比如过程或者函数
构件的特性
(1)独立部署单元，具有原子性，是不可拆分的
(2)作为第三方的组装单元
(3)没有外部的可见状态
一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。
对象的特性
(1)一个实例单元，具有唯一的标志。
(2)可能具有状态，此状态外部可见。
(3)封装了自己的状态和行为。
构件接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。
面向构件的编程(COP)
关注于如何支持建立面向构件的解决方案。面向构件的编程需要下列基本的支持
多态性(可替代性);
模块封装性(高层次信息的隐藏):
后期的绑定和装载(部署独立性):
安全性(类型和模块安全性)。
构件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行了封装，同时对各种业务逻辑规则进行了实现，用于处理用户的内部操作细节。目前，国际上常用的构件标准主要有三大流派:
- EJB(Enterprise Java Bean)规范由Sun公司制定，有三种类型的EJB，分别是会话Bean(Session Bean)、实体Bean(Entity Bean)和消息驱动Bean(Message-driven Bean)。EJB实现应用中关键的业务逻辑，创建基于构件的企业级应用程序。
- COM、DCOM、COM+:组件对象模型，COM是微软公司的。DCOM是COM的进一步扩展，具有位置独立性和语言无关性。COM+并不是COM的新版本，是COM的新发展或是更高层次的应用。
- COBRA标准，是由OMG制定的一种面向对象分布式应用程序体系规范。主要分为三个层次:对象请求代理、公共对象服务和公共设施。最底层是对象请求代理ORB，规定了分布对象的定义(接口)和语言映射，实现对象间的通讯和互操作，是分布对象系统中的“软总线”;在ORB之上定义了很多公共对象服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务:最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。
基于架构的软件开发方法
概述
- 基于架构的软件设计(Architecture-Based Software Design，ABSD)方法是由架构驱动，即由构成架构的商业、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。
- 使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。
- ABSD方法有三个基础。第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术（高内聚低耦合）;第二个基础是通过选择架构风格来实现质量和商业需求:第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
- ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。
概念和术语
设计元素
ABSD方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
ABSD方法中使用的设计元素．在最项层，系统被分解为若干概念子系统和一个或若干个软件模板。在第2层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。
视角与视图
考虑体系结构时，要从不同的视角(Perspective)来观察对架构的描述，这需要软件设计师考虑体系结构的不同属性。例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性，因此，选择的特定视角或视图(如逻辑视图、进程视图、实现视图和配置视图)可以全方位的考虑体系结构设计。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能、性能等。
用例和质量场景
用例已经成为推测系统在一个具体设置中的行为的重要技术，用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求。
在使用用例捕获功能需求的同时，人们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。
基于架构的开发模型
传统的软件开发过程是问题定义，需求分析，软件设计，实现，测试。ABSD把整个软件过程分成六个部分，架构需求，架构设计，架构文档化，架构复审，架构实现和架构演化六个步骤。
(1)架构需求:重在掌握标识构件的三步，如下图。架构需求一般来自3个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标
(2)架构设计:将需求阶段的标识构件映射成构件，进行分析，如下图。
(3)架构文档化:主要产出两种文档，即架构规格说明和测试架构需求的质量设计说明书。文档的完整性和质量是软件架构成功的关键因素，是所有人员通信的手段，关系开发的成败。
- 文档要从使用者的角度进行编写
- 文档分发给所有与系统有关的开发人员
- 必须保证开发者手上的文档是最新的
(4)架构复审:由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构能否满足需求、质量需求是否在设计中得到体现、构件的划分是否合理等。若复审不过则返回架构设计阶段重新进行架构设计、文档化和复审。架构复审的目的是标识潜在的风险，即早发现架构设计中的缺陷和错误．
(5)架构实现:用实体来显示出架构。实现构件，构件组装成系统，如下图。
(6)架构演化:对架构进行改变，按需求增删构件，使架构可复用，如下图。
