中国科学:信息科学2014年第44卷第5期:564–587
https://www.doczj.com/doc/4910895099.html, https://www.doczj.com/doc/4910895099.html,
ABC:一种全生命周期软件体系结构建模方法
梅宏xy?,黄罡xy,张路xy,张伟xy
x高可信软件技术教育部重点实验室(北京大学),北京100871
y北京大学信息科学技术学院软件研究所,北京100871
*通信作者.E-mail:meih@https://www.doczj.com/doc/4910895099.html,
收稿日期:2013–12–19;接受日期:2014–03–04
摘要随着计算机硬件能力的快速增长和软件应用规模的不断扩大,软件的复杂性也在持续增长,并始终制约着软件开发效率和质量的有效提升.软件的结构复杂性,尤其是高层结构的复杂性,是软件复杂性的一种重要表现.如何实现对软件高层结构复杂性的有效控制,是当前开放、动态、难控的网络环境下大规模软件系统开发与演化所面临的主要问题.针对这个问题,我们将设计阶段高层结构复杂性的控制模型―软件体系结构模型―扩展到整个软件生命周期,提出了一种以体系结构为中心的软件开发方法―ABC.该方法将软件生命周期各阶段的核心制品与活动,统一到软件体系结构模型及对其连续迭代的细化、映射和转换,实现对软件高层结构复杂性的一致、灵活、系统化的建模和管理.本文旨在系统性地总结ABC方法在软件体系结构建模方面的成果,并重点介绍近几年在协同式特征建模、运行时体系结构生成、体系结构逆向恢复与建模等方面取得的新进展.
关键词软件复杂性软件体系结构特征模型运行时模型程序分析网构软件
1引言
软件的开发效率和质量难以满足社会经济发展对软件的实际需求是导致软件危机的直接原因,其深层原因是软件技术的发展无法有效应对软件规模和复杂性的快速增长.
软件的规模通常使用代码行来度量.在目前阶段,大规模软件的代码行在千万到亿的数量级上,并呈现持续增长的趋势.例如,Windows操作系统的规模从初期(1995年)的1500万行逐渐增长至2007年的6000万行(图1);2011年宝马7系轿车中软件的规模达到2亿多行;空客A380飞机中软件的规模甚至超过10亿行.导致软件规模持续增长的主要原因在于软件应用范围的不断扩大和应用程度的不断加深:软件必须具备更多、更强、更复杂的能力,以应对更加复杂的应用环境.
软件复杂性的成因可以从以下几个方面进行理解.第一,软件的复杂性在一定程度上源于现实世界固有的复杂性:大多数软件是对现实世界的反映和模拟,而现实世界的很多事物经过了长期的发展变化,形成了错综复杂的关系,因而导致反映和模拟这些事物的软件也需要承载这些已经存在的复杂关系.第二,软件语言和自然语言之间的差异性也是导致软件复杂性的一个重要原因:由于软件语言和自然语言之间在语法、语义和语用上存在很大的差异,使用软件语言对现实世界的问题域进行描述会进一步增加软件制品的复杂性.第三,作为一种知识制品,软件在结构上呈现出分形的特点,即:从任何一个抽象层次看,软件的各个组成部分都呈现出相似但又不完全相同的特点.因此,对于动辄具有
中国科学:信息科学第44卷第5期
L i n e s o f c o d e (10 m i l l i o n l i n e s ) 0
1
234567
Win 95 Win 98 Win XP Vista
图1
Windows 操作系统规模的不断增长Figure 1The scale increasing of Windows operation systems
(a)(b)
图2(网络版彩图)软件复杂性示例:某企业信息系统软件模块关系(a)和微软Web 服务器显示一张图片的函
数调用序列(b)
Figure 2(Color online)Examples of software complexity:the software module relation map of an enterprise’s information system (a)and an invoking sequence to display a picture in Microsoft web server software (b)
数百万、上千万行代码的软件而言,其复杂性会随着软件规模的增大呈现非线性的增长,且不同规模的软件所蕴含的复杂性及其控制各不相同.第四,软件的持续演化也会导致软件复杂性的不断增长:用户需求和运行环境的变化往往需要对软件进行适应性调整,而不论是对可预期的变化进行主动调整,还是对非预期的变化进行被动适应,都会进一步导致软件复杂性的增长.软件复杂性的示例如图2所示.
当软件的规模和复杂性超出开发者和技术所能掌控的范围,就会使得软件在开发效率、成本及质量上无法满足实际需求,进而导致软件危机的产生.软件工程,作为应对软件危机问题而产生的一个研究和实践领域,其核心目标即是实现对软件复杂性的有效建模与控制.考察软件工程中建模和控制软件复杂性的各种原则、方法和技术,其基本思想可以归纳为分治(separation of concerns,或称为“分而治之”).分治的内涵包括3个方面(如图3所示).第一,分治表现为“分解”,即:将一个大规模或较大规模的软件分解为多个组成部分,然后分别对每个组成部分的复杂性进行建模和控制,进而实现对整个软件系统复杂性的控制.第二,分治表现为“分层”(或称为“抽象”),即:将高层结构与实现细节565
梅宏等:ABC:一种全生命周期软件体系结构建模方法Decomposition
Phase-Control SOC in time
SOC in scale SOC in level SOC (Separation of concerns)
Abstraction 图3
分治的3个方面Figure 3The three aspects of separation of concerns
相分离,使得开发人员在进行开发活动时可以集中关注于特定的抽象层次.其三,分治表现为“分步”,即:将整个软件生命周期划分为需求、分析、设计、实现、测试、部署、维护、演化等一系列阶段或步骤,并分由不同类型的开发人员进行具体实施.
软件复杂性具有多种不同的表现形式[1].如,结构复杂性、算法复杂性、计算复杂性、数据复杂性、功能复杂性等.其中,结构复杂性是影响软件开发效率和质量的主要因素[2].
考察软件技术的发展历史,可以发现,如何有效控制结构复杂性一直是程序模型及编程语言领域的研究主线.最早的软件使用机器语言或汇编语言编写,构成软件的基本单元是指令,控制机制主要是顺序和转移.高级语言的出现使得开发人员可以在更高抽象层次上进行程序设计,但转移语句(goto)的滥用也会导致软件结构的混乱.结构化编程的出现使得任意计算流程均可使用顺序、分支和循环这三种基本控制结构的组合来描述,从而消除了转移语句滥用带来的问题.函数、过程等程序元素的出现为信息的封装提供了一种更大粒度的抽象机制,进而可以构造出更大规模的软件.面向对象的编程则进一步提供了一种以对象为基本计算单元,以消息传递为基本交互手段的软件模型:该模型以拟人化的观点来看待客观世界,既符合人的思维模式,又符合客观世界的构成规律.从复杂性控制的角度看,程序模型及编程语言技术的发展呈现出抽象层次不断提高、更加符合人类思维模式这两种趋势,从而使得开发人员能够更方便地构造更大规模和更复杂的软件.
然而,随着软件规模和复杂性的持续增长,人们逐渐发现,仅在编程层次对软件的结构复杂性进行控制还远远无法满足大规模复杂软件开发的实际需求:与编程层次的结构复杂性相比,软件高层结构的复杂性对大规模复杂软件的开发效率和质量具有更为重要的影响.上世纪90年代初,软件工程界借鉴建筑学中体系结构的思想,提出了软件体系结构(Software Architecture,SA)的概念,并发展了相应的软件开发方法.在概念上,软件体系结构被定义为一组软件构件、构件之间的连接子、以及作用于构件和连接子之上的约束和配置;相应的开发方法将软件体系结构作为软件设计阶段的核心制品,致力于利用软件体系结构来建模设计阶段软件高层结构的复杂性,并通过相应的分析与设计方法对这种复杂性进行控制[3].
软件工程的已有实践表明,没有一种单一的技术可以完美地应对各种形式的软件复杂性[4].虽然软件体系结构在控制软件复杂性方面展现出特有的优势,但仅在设计阶段建模和控制软件高层结构的复杂性,其有效性和实用性仍存在较大的局限:软件生命周期的其它阶段也存在类似的高层结构复杂性,这些结构复杂性也会对软件的开发效率和质量产生直接的影响.特别地,在需求阶段,由于环境的开放和不确定性,其结构复杂性不亚于设计阶段;在运行阶段,由于动态性和并发性的出现,也使得其结构复杂性远大于设计阶段.
基于以上分析,我们提出了以体系结构为中心的软件开发方法ABC(Architecture Based Compo-566
中国科学:信息科学第44卷第5期Reqs. model Design model Impl.model Deploy. model Runtime
model Requirements
analysis
D e s i g n
C o m p o n e n t c o m p o s i t i o n
D e p l o y m e n t
M a i n
t e n a n c e &e v o l u t i o n SA
图4
ABC 方法研究思路Figure 4The basic ideas of ABC method
nent Composition)来控制软件生命周期各个阶段的高层结构复杂性,并通过基于构件的软件复用来提高软件的开发效率和质量.如图4所示,ABC 方法的核心是全生命周期软件体系结构建模,即:将软件生命周期各阶段的核心制品与活动,统一为软件体系结构模型及对其连续迭代的细化、映射和转换,从而实现对软件高层结构复杂性一致、灵活、系统化的管理和控制.
本文的组织结构如下:第2节概要介绍ABC 方法并总结其在全生命周期软件体系结构建模方面的主要成果;随后几节分别介绍近几年以互联网软件为研究对象,在协同式特征建模、运行时体系结构生成和体系结构逆向建模3个方面的最新进展;最后总结全文并展望未来工作.
2ABC 方法概览
ABC 方法于1999年萌芽[5],2003年形成雏形[6],2006年基本成型[7],此后又经过不断地改进和完善.ABC 方法的核心思想是将软件体系结构引入软件开发的各个阶段,作为系统开发的蓝图,并利用工具支持的自动转换机制缩小从高层设计到实现的距离,然后在构件运行平台(即软件中间件)的支持下实现自动的系统组装生成.
ABC 方法过程模型如图5所示,其中:
(1)需求分析阶段的软件体系结构及其建模:ABC 在需求分析阶段引入了软件体系结构的概念,以结构化的方式来组织问题空间和用户需求.在此阶段,软件需求以特征(Feature)的形式表示,需求之间的关系则由特征之间的关系来刻画,即:以特征作为建模需求的一阶实体,通过显式描述特征之间的静态和动态依赖关系实现对需求的有效分解和组织,形成被称为特征模型的分析模型.为了有效地刻画需求之间的关系,特征模型刻画了特征之间的4种重要关系:精化、约束、影响和交互,分别描述特征之间的静态和动态依赖关系.为了支持需求层次的复用,ABC 在特征模型中引入了变化性的表示机制,以描述一类相似或相近的软件系统的共性和变化性需求:通过对特征模型的定制,产生适应于特定软件应用的需求模型,并利用特征之间的约束关系来保证软件应用需求模型的完整性和一致性.在此基础上,ABC 的特征建模方法通过对软件责任(Responsibility)的识别以及对特征之间交互567
梅宏等:ABC:一种全生命周期软件体系结构建模方法
Architecture-
oriented requirement analysis Architecture
design
Architecture-
based
composition
Architecture-
based
deployment
Architecture-
based
maintenance
& evolution
Object-oriented
design
Object-oriented
implementation
Component
qualification
& adaptation 图5全生命周期软件体系结构建模过程
Figure5The process of whole lifecycle software architecture modeling
关系的分析,可以半自动地导出软件系统的高层体系结构,作为后续设计、组装、部署、以及维护与演化的基础.
(2)设计阶段的软件体系结构及其建模:ABC在设计阶段主要进行软件体系结构建模.在此阶段, ABC通过分析软件系统的需求规约,制定相应的全局设计决策,创建必需的构件和连接子,建立静态和动态的软件体系结构模型(包括类型图、实例图和过程图等),并进一步精化特征模型与软件体系结构的追踪关系.为了更好地通过复用提高目标软件系统的开发效率和质量,ABC还提供了辅助设计者从资产池中选取可复用的构件和连接子的能力.从兼容性角度考虑,ABC并不排斥其它的软件开发范型,如面向对象分析与设计产生的高层设计或概要设计也可视为一种软件体系结构:只要将这种面向对象的软件体系结构中的基本组成元素从对象封装为构件(如,按照对象来源、功能类别、用况、通信频繁程度、并发和分布情况、一般—特殊结构、整体—部分结构、关联、包的关系密集程度等准则,可以将一组对象封装为一个构件),就可以将这种构件化的软件体系结构直接作为本阶段的设计结果.
(3)实现阶段的软件体系结构及其建模:ABC的目标系统主要通过组装可复用构件来实现,即:根据设计阶段产生的软件体系结构模型,选取、鉴定、适配资产池中已有的构件实现体,在通过一致性校验后,组装成可发布的软件系统.如果在资产池中找不到合用的构件,ABC可将构件描述转换成UML 模型或C++和Java代码框架,由开发者完成构件制作并将之存入资产池,最终组装到目标系统.
(4)部署阶段的软件体系结构及其建模:基于构件的软件系统往往运行于特定的构件运行支撑平台,如CORBA/CCM(Common Object Request Broker Architecture/CORBA Component Model)平台、J2EE/EJB(Java2Platform Enterprise Edition/Enterprise JavaBeans)平台、.NET/COM(Component Object Model)平台或Web Services平台等.这些软件系统必须经过部署才能正常运行,而部署所需的信息较为繁杂,往往需要部署人员手工填写.实践发现,大部分部署信息在系统设计与实现阶段已经存在,只需经过必要的转换或融合即可对其进行复用.为此,ABC定义了软件体系结构部署模型(其主要信息由设计模型与实现模型导出),支持以直观的图形方式添加少量的信息,并实时显示目标环境的资源与负载情况,从而实现自动化的部署.
(5)维护与演化阶段的软件体系结构及其建模:从某种意义上来说,ABC方法可以看成对软件体系结构模型连续、迭代的细化、映射和转换,在每一次细化和转换后,软件体系结构的语法和语义信息变得更加精确与完整.到了维护与演化阶段,运行时模型刻画了系统在运行时刻的实际状态,因而具有系统最精确和完整的信息,该模型被称为运行时软件体系结构(Runtime Software Architecture,RSA).基于运行平台的管理机制,RSA可以实时地反映出系统运行时刻的真实状态,并且,直接操作RSA就可以实现对软件系统的在线维护与演化.
568
中国科学:信息科学第44卷第5期Feature name: String description: Text binding-state: 3V-Boolean optional: Boolean
Feature-Model Relation
Refinement 1 1 0..1 parent child Requires Excludes XOR OR
requirer requiree 1 1 involved 2 VP-variant-constraint
1 0..1variation-point
variant 0..11..* refined-to refined-from 1..*
Constraint
state: 3V-Boolean formula: CNF *
* feature relation Interaction
1 source Influence 1 target 1 source 1 target 0..1 0..1 图6
ABC 特征模型元模型Figure 6The meta-model of ABC feature model
为了支持上述过程,ABC 方法实现了特征建模工具、软件体系结构建模工具、元建模工具、构件代码框架生成工具、服务组装工具、构件库管理系统、以及作为构件运行支撑平台的软件中间件等一系列的工具和平台.ABC 方法和工具已在北京2008奥运会信息系统建模、某军队信息化系统设计与建模、某商业银行信贷风险管理系统开发等项目中得到验证性应用.
需要指出的是,软件体系结构作为软件设计阶段的核心制品,其在设计、实现、甚至部署阶段的意义和作用已有不少研究.例如,美国卡耐基梅隆大学的David Garlan 教授、美国加州大学埃尔文分校的Richard Taylor 教授、英国帝国理工的Je?Krama 教授等领导的团队近20年来一直致力于软件体系结构的研究.与之相比,从软件复杂性控制的角度看,ABC 方法的特色在于:1)在分解方面,强调软件体系结构的基本成分是“构件”,而不是粒度更小且常常在代码级别进行复杂性控制的“对象”,并且将构件之间的连接也作为与构件同等地位的一阶实体(?rst class entity);2)在分层方面,强调通过约束和连接子对运行支撑平台进行体系结构级别的抽象,以充分利用运行支撑平台的能力来实现性能、可靠、安全等系统级质量需求;3)在分步方面,强调在同一概念框架下针对需求分析阶段和维护演化阶段存在的高层结构复杂性,通过将软件体系结构引入这两个阶段,揭示了这些复杂性之间的关系,并通过相应的建模方法实现复杂性控制.
2.1面向特征的需求建模
在“将软件体系结构引入需求阶段”思想的指导下,ABC 方法采用特征模型作为组织软件需求的结构化模型,对特征模型的结构、语义、验证方法、以及基于特征模型的软件体系结构设计等问题进行了研究.
(1)特征模型元模型
特征模型可以抽象为一组特征以及特征之间的一组依赖关系,如图6所示.在定义特征模型结构的过程中,ABC 方法主要关注两个问题[8]:为了实现对需求的共性/变化性建模、需求复用、及软件设计的有效支持,特征模型应该捕获特征之间何种类型的依赖关系,以及如何在特征建模过程中有效地识别出这些依赖关系？569
梅宏等:ABC:一种全生命周期软件体系结构建模方法
ABC方法定义的特征模型包含特征和特征之间的4种依赖关系[9].特征是一种具有用户/客户价值的软件特点,其在内涵上指代了由一组具有紧密关联的单个需求构成的集合.特征之间的依赖关系包括:精化(Re?nement)、约束(Constraint)、影响(In?uence)和交互(Interaction).精化关系提供了组织特征的基本方式:通过精化关系,不同粒度/抽象层次的特征被组织成层次结构.约束刻画了特征在绑定状态上的依赖关系:一方面,约束关系提供了一种对需求的变化性进行限制的机制;另一方面,约束关系也为保证特征模型定制结果的完整性和一致性提供了判断依据.影响和交互分别刻画了特征在软件规约层次上的静态和动态依赖关系:这两种关系主要用于进行基于特征模型的软件体系结构设计.
ABC方法定义的特征模型还关注了不同依赖关系之间的关联.依赖关系之间存在关联的主要原因在于:不同类型的特征依赖关系之间并非完全独立,而往往是从不同视角对同一对象进行建模的结果.例如,精化和约束是存在于问题空间的两种依赖关系,影响和交互是存在于解空间的两种依赖关系;影响和交互分别从静态和动态的视角对特征在软件规约层次上的依赖关系进行了刻画.ABC方法特征模型所关注的依赖关联包括:由精化导致的约束之间、约束与交互之间的依赖关联,以及影响与交互之间的依赖关系.通过依赖关联,可以从一种已识别的依赖关系快速识别出其他类型的依赖关系,从而提高依赖关系分析活动的效率.依赖关联的建模在客观上也能够提高特征模型的易维护性:当一种依赖关系发生变化后,可以通过关联对与其相关的其他依赖关系做出相应的调整,从而保证特征模型包含信息的一致性.
(2)可定制的需求建模机制
特征模型提供了一种具有良好可定制性的需求建模机制.传统的需求建模机制由于缺乏对可定制性的显式考虑,不能有效地支持从需求建模结果中抽取出一组相对独立的需求子集,从而导致这些建模机制无法满足基于定制的需求复用活动的要求.为了提高需求的可定制性,需要明确的一个基本问题是:需求定制的基本单元是什么？针对该问题,ABC方法认为,将软件对外表现出的特征作为需求定制的基本单元,并采用面向特征的思想对需求进行建模,是提高需求可定制性的一种有效手段[10].基于特征和特征模型的概念,ABC方法将传统的缺乏可定制性的软件需求组织方式转变为一种面向特征的树形组织方式,并显式建模树形结构中节点(特征)之间的约束关系.采用这种建模机制,可以将特定应用领域的需求建模为相应的特征模型,并通过对特征模型的定制对其中包含的需求进行复用:对于特征模型的任何定制结果(即:特征模型所包含特征的一个子集),只要不破坏特征之间的约束关系,即可被认为是一个合法的需求子集.这种方式为解决需求复用问题提供了一条现实可行的途径.
(3)基于命题逻辑的特征模型形式化机制与验证方法
针对特征模型的语义问题和自动验证问题,ABC方法提出了将特征模型转换为相应的命题逻辑表示的完整方案,并以此为基础提出了验证特征模型及其定制结果的3条形式化准则[11]:特征模型的可满足性、特征的可绑定性以及可删除性.这3条验证准则能够完整、准确地检测出特征模型及其定制结果中存在的异常和不一致这两种类型的缺陷.
针对验证优化问题,ABC方法发现了特征模型中存在的原子集合、伪可选特征、及验证无关特征等3种现象[11,12]:原子集合包含了一组在特征模型定制过程中始终具有相同绑定状态的特征;伪可选特征在语法上表现为可选特征,在语义上则体现为死特征或必选特征;验证无关特征不会对特征模型及其定制结果的验证带来任何影响.在此基础上,ABC方法提出通过合并原子集合特征和消除验证无关特征,缩减特征模型验证问题中变量数目的方法.这种验证优化方法可作为一种预处理技术,与传统的特征模型验证算法相结合,从而提高验证算法的规模可扩展性.
570
中国科学:信息科学第44卷第5期
图7从特征模型向软件体系结构模型的变换
Figure7Transformation from feature model to software architecture model
(4)特征模型到设计阶段体系结构的变换方法
针对特征模型到软件体系结构的变换问题,ABC方法提出了一种以特征操作化(Feature Opera-tionalization)和责任分配(Responsibility Assignment)为手段的高层软件体系结构设计方法[13],如图7所示.特征操作化旨在将特征所指代的需求操作化为可编程实现的软件规约,并使用责任对软件规约进行模块化:通过操作化,一个特征的实现被具体化为一组责任及其之间存在的交互.责任分配旨在将由特征操作化产生的责任分配至构件:通过责任分配,同一特征操作化产生的责任可能会被分配至不同的构件,从而导致责任之间的交互转变为构件之间的交互;不同特征操作化产生的责任则有可能会分配至同一个构件,从而导致不同特征在实现层次上的交织.通过特征操作化和责任分配,即可产生特征模型对应的高层软件体系结构,即:一组构件以及构件之间的交互关系.该变换方法对基于特征模型的软件设计的实施提供了一个系统化的操作指南,并能在设计产生软件体系结构的同时建立需求阶段与设计阶段制品之间的追踪关系,从而为软件的维护和演化积累必要的信息资源.
2.2设计阶段的软件体系结构建模
ABC方法中设计阶段体系结构模型的主要概念和建模元素包括:构件和构件类型、连接子和连接子类型、配置、约束、以及设计决策(如图8所示).ABC设计阶段体系结构具有典型的软件体系结构模型的所有要素:完成计算功能的构件、保障构件之间交互的连接子、对交互拓扑结构进行描述的系统配置以及从系统全局角度出发需要满足的各种约束.
在此基础上,ABC设计阶段体系结构模型还具有以下特点:
(1)区分类型和实例
构件和连接子是ABC体系结构的基本组成元素,其中:构件主要负责进行业务层面的计算,连接子主要对构件之间的交互进行抽象.对构件和连接子的显式区分是区别体系结构描述语言和其他建模语言的一个重要因素.构件和连接子的内在特性是由其类型决定的,即:一个构件的类型决定了该构
571
梅宏等:ABC:一种全生命周期软件体系结构建模方法Assets Configuration Component Connector SA
Connector
instance Component instance 1..* 1..*
1..* instantiatedFrom
reusedBy
Decision
Constraint 1..* 1..* Instances 1..* 1..* 1..* Link
1..*
0..1
COTS
implement
instantiatedFrom
图8
ABC 体系结构模型概览Figure 8An overview of ABC software architecture model
件的计算能力,一个连接子的类型决定了该连接子的通信能力.区分类型和实例具有两个优点:一,提高模型的可验证性;二,提高构件类型和连接子类型的可复用性.
(2)兼容复用和构造
构件类型和连接子类型是潜在的可复用资产(Asset),有可能在不同的软件体系结构模型中进行复用.与可复用资产相对的即是设计时新构造的资产.虽然新构造的资产在设计完毕也可能成为可复用资产,但对某一软件体系结构模型而言,新构造的资产与可复用资产具有一个本质的区别:前者可以根据需要随时进行修改,而后者则是一个不可修改或可有限修改的黑盒实体(COTS).这种区别对构件的组装会产生截然不同的影响:对已存在的可复用构件进行组装有可能产生失配的问题,而对新构件的组装则不会产生失配问题(如果发现有不适合的地方,可以随时对新构件进行必要的修改).鉴于可复用资产和新构造资产的上述区别,ABC 体系结构模型对这两种类型的资产进行了显式的区分.但对设计者而言,无论是哪一类资产,它们均符合ABC 构件模型和连接子模型.
(3)简洁有效的配置
配置(Con?guration)决定了构件之间的交互拓扑结构.ABC 体系结构模型是面向构件组装的体系结构模型,因此它采用了一种简洁直观的方式来描述构件之间的组装方式,即:用松耦合的Link 来确定构件的交互方式.Link 的语义可类比为演员承担角色.演员是对构件计算功能的抽象,角色则是对连接子通信能力的抽象.通过恰当的Link 定义,设计者就能依据目标系统的需求指定系统中的每个构件应该承担的角色.因此,ABC 体系结构模型中的配置由一系列Link 组成.
(4)可扩展的约束
软件体系结构对复杂性建模和控制的一个主要方面在于:它允许设计者在系统开发早期对系统的整体性质进行分析,以便尽早发现潜在的设计问题.支持这种分析的一个重要基础是体系结构模型对约束(Constraint)的建模(如:安全、事务、响应时间等非功能性约束的建模).ABC 体系结构模型提供了灵活的约束描述方式,允许设计者根据特定的非功能约束扩展已有的描述方式,以便为基于体系结构的系统分析提供必要的约束信息[14].
(5)支持设计决策
体系结构设计决策(Architectural Design Decision)对解决软件开发和演化中的“知识蒸发”、“设572
中国科学:信息科学第44卷第5期
计腐化”等问题具有重要作用.但相关的研究主要关注于设计决策及其理由的表示,而缺乏对设计决策与体系结构设计方法集成的有效支持.由于这种缺乏,对决策与理由的建模往往不会对软件设计产生直接的指导或帮助,因此也很难应用到软件工程实践中.针对这种问题,ABC通过问题、方案、决策、理由等4个概念,采用3种建模原则对设计决策进行建模[15].一、决策抽象原则:从决策的视角认识体系结构,并将体系结构设计限定于对系统高层和全局关键问题的决策,忽略细节性的或能够在后续开发中解决的问题.二、问题分解原则:将体系结构设计作为对一组体系结构层次关键问题的求解;因此,从全局设计目标到这些问题的分解是体系结构设计的首要步骤,而设计的实现则依赖于对这些问题的解决方案的合成.三、知识复用原则:将软件设计相关知识而不是特定的设计制品作为复用的对象;实现复用的方式则是利用已有的知识解决新的体系结构设计问题.
2.3实现阶段的软件体系结构建模
ABC方法强调基于构件组装的软件复用.也就是说,体系结构设计中的构件、甚至连接子都可通过复用已有的软件制品来实现.因此,在实现阶段,软件体系结构建模的核心就是构件模型和连接子模型.
(1)构件模型
ABC构件模型从构件使用者的角度,定义了一个面向组装的软件模型.它在业务层面上对各种不同实现类型的软件实体进行抽象,使得各种软件实体能够通过统一的规约,在业务层面上进行交互(在实现层面上的交互依赖于模型之间转换规则的设计和特定运行平台的支持).ABC构件模型具有两种类型的接口:对外提供的接口和需要外部提供的接口.对这两种接口的显式建模使得构件成为一个相对独立的软件实体.在这两种接口中,对外提供的接口对构件模型而言是必须的,而是否需要外部提供的接口则取决于构件的实现方式.
ABC构件模型还可以包含内部结构.包含内部结构的部件称为复合构件.与之相对的其他构件称为原子构件.复合构件的内部结构可以具有独立的描述方式.但一般而言,设计者大多将复合构件作为一个子系统看待,其内部结构则被看作是该子系统的体系结构.因此,可以直接采用ABC体系结构模型对复合构件的内部结构进行建模(见图8).由于复合构件的内部结构中还可能包含复合构件,因此,在一般意义上,这种复合结构可以包含任意层数的嵌套,从而支持设计者对一个复杂构件进行不断的精化.采用这种方式定义复合构件也意味着ABC体系结构可以将自身封装为一个更大粒度的构件,供其他应用使用.同时,构件的多层次嵌套也在一定程度上体现出知识制品具有的分形复杂性以及基于分层的复杂性控制手段.
(2)连接子模型
连接子是对构件之间交互的抽象.对大型复杂系统而言,构件之间的交互往往对系统的整体性质有重大影响.绝大多数软件体系结构模型都把连接子看作是一种与构件具有同等重要性的一阶实体.与构件模型类似,ABC连接子模型也是一种面向黑盒构件组装的模型.连接子的设计者仅仅对构件的外部可见特性进行抽象,因此在设计连接子内部结构时就不能对参与构件的实现细节做出任何假定. ABC连接子模型主要由连接子的外部规约和内部规约两部分组成.
外部规约定义了参与交互的构件承担的各种角色.一般而言,构件的角色可以分为两类:一类是交互的发起者,另一类是交互的响应者.每种角色可以分别定义具体参与交互的构件的类型,常见的有方法、事件、消息等;此外还可以为角色定义多重性,即:可以允许多少个实例参与交互.只有满足角色要求的构件才能正确的进行交互.
573
梅宏等:ABC:一种全生命周期软件体系结构建模方法
Deployable packages Build goals Partition system Install system Evaluate result
Re-deploy
图9基于软件体系结构的应用部署过程
Figure9Software architecture based application deployment
内部规约定义了连接子对构件交互的处理细节,主要包括通信链路、时序编排和监控设施三部分[16]:
?通信链路是对进行通信的构件对的抽象,每个通信链路都有各自所使用的通信协议,常见的包括过程调用、远程过程调用、消息传递等.通信链路的定义是必须的,是构件交互得以顺利进行的基础.
?对于复杂的构件交互,ABC连接子模型还允许设计人员定义构件之间的交互时序,即:多个构件交互顺序、并发等信息.构件交互时序的定义有助于设计者在体系结构层次对系统的行为进行分析和验证,从而判断系统结构是否满足特定的质量属性.
?ABC连接子还可以对构件交互进行监控,即:在构件交互前或者交互后进行特定的处理.这也体现了将构件和连接子分离的好处:可以一一种松耦合的方式对交互进行特定的处理.这不仅有利于系统的维护,还有助于相关处理机制的复用.例如,可以定义一个对普通过程调用进行加密的连接子,设计者既可以整体复用该连接子,也可以复用该连接子内部使用的监控设施.
2.4部署阶段的软件体系结构建模
构件系统在运行之前,一般都必须根据运行环境的特点进行一定的配置,并将其安装至运行环境中.这一过程称为软件部署,是构件化软件开发与运行之间的一个重要阶段.随着对软件系统服务质量要求的提高,以及计算机处理能力、网络带宽、存储容量的快速提升,软件部署面临着三类问题:软件日益庞大,难以理解;部署信息分散,收集过程烦琐而重复;网络运行环境复杂、多变.为了帮助部署人员更好地理解系统并复用开发阶段的丰富信息,ABC将开发阶段的软件体系结构引入部署阶段[17],极大降低了软件部署所面临的结构复杂性.
如图9所示,ABC方法支持的部署过程分为5个活动:
(1)建立部署目标:在部署之前,部署者需要对系统在部署之后所要达到的目标有清晰的定位.根据软件体系结构中的约束,部署者抽取出对系统运行时刻的要求,并综合考虑技术与非技术因素,建立部署后系统所要达到的目标.
(2)拆分系统:为了能更好地利用资源、提高性能,系统往往需要被拆分成多个部分,每个部分分别安装到不同的计算节点上.作为对软件总体结构的描述,软件体系结构能够帮助部署者在较高层次上快速理解系统中的构件以及构件之间的交互和依赖关系,分析它们对运行时刻的要求.而对网络环境的监测,可以辅助部署者明确地了解待部署系统的运行环境,从而充分考虑各种实际因素的影响.部署者在软件体系结构的指导下,明确了底层运行环境之后,根据部署目标进行权衡,把系统拆分成若干个可安装到不同计算节点的部分.在拆分的过程中,部署者可以使用已有的部署原则,考虑影响部署的关键因素,从而做出合理的决策.
(3)安装系统:主要包括两个子活动.一、信息配置:系统在能够正常运行之前,需要将一些必须的信息添加到构件运行平台上;这些信息称为部署信息,包括构件运行时刻绑定的名字、所需资源的
574
中国科学:信息科学第44卷第5期
声明、资源入口等等.系统设计阶段和实现阶段的软件体系结构模型中包含了丰富的语法、语义信息.通过对这些信息的转换或融合,即能得到大部分的部署信息.此时只需添加少量的运行平台特定的信息,即可完成系统中的信息配置活动.二、打包:完成拆分和信息配置后的系统各个部分,需要打包并传送到各个具体的计算节点上去进行进一步的安装活动.
(4)评估部署结果:在把系统部署到各个特定节点之后,需要对系统进行一段时间的运行测试;然后,部署者根据得到的运行数据对部署结果进行评估.评估活动包含两个方面:一方面,部署者需要对部署目标与部署结果进行对比,判断新系统部署后能否满足预先设定的部署目标.另一方面,部署者需要对比其他已部署系统的部署目标和运行情况,判断新系统的部署是否破坏了这些系统的功能或者降低了它们的服务质量.
(5)重部署:当评估结果表明此次部署没有达到要求时,就需要对相关系统进行重部署.重部署包含三种可能的情况.一、部署信息配置不当.这往往会造成系统虽然能够正常运行,但却无法达到部署目标.例如,对某些构件配置了不必要的高安全服务,影响了系统的整体性能.此时,需要重新进行信息配置,再次打包传送与评估.二、对系统的拆分不合理.这会造成整个系统的性能不符合部署目标中的要求.因此,需要对系统进行重新拆分,再次安装和评估部署结果.三、多次进行部署评估后,发现总是未能达到预定的部署目标,或达到了目标的部署结果并不能满足系统真正的运行要求.此时,很有可能是部署者原先设定的部署目标过高或过低,因此需要重新调整部署目标,再拆分系统、重新安装、以及重新评估部署结果.
2.5维护与演化阶段的软件体系结构建模
据Gartner统计,软件维护的成本占到整个软件生命周期成本的50%～80%.软件维护主要对现有系统进行有限、受控的改变,是一种不可避免的演化式开发[18].维护的关键在于对现有系统的理解:既包括对源码、文档、运行状态、工作环境等各种系统成分的理解,也包括对触发维护的原因、可实施的维护动作、具体的维护计划、维护后的效果等各种过程成分的理解.
本质上,软件维护需要以变化为中心,综合性地认识与刻画软件系统的运行机理与性质.ABC将软件体系结构从开发阶段引入运行阶段,在可执行代码以及运行支撑环境之上,建立了运行时软件体系结构(RSA)模型.主要优点包括三点.首先,在线维护与演化的基本目标是系统的功能及其质量,因此,可通过软件体系结构及其质量来描述和考察.其次,在线维护与演化对运行系统的改变是受限的,具体表现为系统可以被感知或理解的内容有限,以及可以实施的适应性调整有限.这种限制性可以完整准确地表述为软件体系结构的模型成分,包括构件、连接子、配置、约束、风格等.其三,在线维护与演化在一般意义上是一种“监测(Monitor)—分析(Analyze)—决策(Plan)—实施(E?ectuate)”的过程,在具体操作上则可以落实为对软件体系结构的“在线获取—系统分析—配置规划—动态重配—校验确认”这样一种过程[19,20].
如图10所示,从软件体系结构的角度可以将在线维护与演化的结构复杂性归结为4种基本性质:
(1)反射性(Re?ection):RSA与目标系统的运行状态和行为之间具有因果关联关系,即:目标系统运行状态和行为的变化会立即导致其RSA的相应变化,反之亦然.该性质在软件体系结构层次上明确了在线维护与演化的范围,能够保证变化和调整在模型与系统之间的一致性和准确性;
(2)变化性(Dynamism):RSA通过模型查询与转换全面准确地描述了反射性所能感知的变化和计划实施的调整,如对构件、连接子、约束的增加、删除、修改.从时序看,反射性描述了运行系统某个时刻的状态和行为表征,变化性则描述了运行系统在某个时间段内的状态变迁与行为;
575
梅宏等:ABC:一种全生命周期软件体系结构建模方法Polymorphism T r u s t w o r t h i n e s s D y n a m i s m
Reflection
Software
Architecture
Model
Effectuate
Monitor Plan
Analyze
图10
基于体系结构的在线维护与演化Figure 10Software architecture based online maintenance and evolution
(3)多态性(Polymorphism):RSA 在对运行系统进行维护与演化的过程中呈现出不同的内容甚至不同的形态.该性质反映了维护与演化的一个重要现象,即:系统功能、质量目标、任务分工、执行时间等不同因素要求从不同角度、不同层次理解目标系统.多态性可以表示为反射性和变化性在一段时间内的累积结果;
(4)可信性(Trustworthiness):RSA 通过分析与测试来校验运行系统的功能、性能、可靠、安全等指标是否符合用户预期.
基于上述性质,ABC 监测活动利用RSA 的反射性收集系统运行信息,并将这些信息展现为RSA 的变化性描述;分析活动评估反射性和变化性所表述的系统状态和行为,如果评估结果为功能或质量需进一步完善和优化,则激活规划活动,否则终止此次维护[21];规划活动首先针对分析活动的评估结果,找到监测活动的变化性描述中与功能或质量问题相关的变化,给出适应性调整方案并生成相应的变化性描述;控制活动则将规划活动生成的变化性描述转换成反射性操作并执行,最终调整实际系统并对效果进行评估.
如前所述,ABC 方法在2006年基本成型[7].其后,随着互联网技术与应用模式的蓬勃发展,ABC 方法对其中出现的一些理念和技术进行了借鉴和吸收.特别地,我国学者从软件形态的角度考察开放、动态、多变的Internet 环境对软件理论、方法和技术的挑战,提出了网构软件的概念[7,22,23].在网构软件理念的指导下,ABC 方法近几年来针对互联网软件的开发、维护和演化进行了进一步的探索.限于篇幅,本文着重介绍3个方面的工作进展:基于群体协同的特征建模与演化―将基于Web 的群体智能的思想引入需求阶段,解决ABC 特征建模活动对领域专家的强依赖性问题和特征建模结果的持续演化问题;模型驱动的运行时软件体系结构自动生成―通过模型驱动的代码生成和模型自动同步技术,解决ABC 运行时体系结构需要针对不同系统进行手工开发的问题;体系结构模型逆向恢复和追踪―通过程序理解和数据挖掘技术,解决ABC 方法难以直接应用到遗产系统的问题.
3基于群体协同的特征建模与演化
面向特征的需求建模方法提供了一种建模领域需求及其空间多样性的有效途径.但对于互联网环576
中国科学:信息科学第44卷第5期
境中的软件需求获取问题,该方法还存在两点不足.首先,大多数特征建模方法隐含地假设:在特定领域内存在一个或若干个关于本领域的全知者(即,领域专家),他们能够有效捕获并建模领域需求及其空间多样性.然而,在软件应用领域层出不穷、不断演化与相互融合的现状中,这一假设过于乐观,在多数情况下并不成立.其次,大多数的特征建模方法对领域需求的演化缺乏有效的支持.这将导致特定领域的特征模型在建立之后,由于不能持续地演化,而无法准确反映领域的发展现状,从而逐渐丧失其价值.ABC提出基于群体协同的特征建模与演化方法,旨在将面向特征的需求建模方法与群体协同的思想相结合,建立一种面向特征、基于群体协同的领域需求建模方法.在此基础上,期望通过构建基于Web的群体协同支撑环境,实现对大规模、长周期、持续性的领域需求捕获、建模与演化这3个活动的有效支持.该方法的核心思想如下:
首先,在传统针对单一建模者的面向特征的需求建模方法的基础上,应用“基于Web的人类群体协同”的思想,以Web空间作为软件应用领域中利益相关者群体的公共环境,利用利益相关者个体的显式建模行为和各种隐式行为对公共环境作出相应的改变,并通过改变后的环境刺激个体在其中发生新的行为,从而导致公共环境发生新的变化,进而在群体中形成具有高度可伸缩性的“环境激发效应(Stigmergy)”型的间接协同行为[24].
其次,应用“个体利益使能”的思想,构建针对特征建模问题的具体协同机制,使得群体中的任一个体,只要其自己对环境进行持续的探索和贡献,就能够获得单靠其个体能力无法构建和维护的、具有持续演化性的个性领域特征模型,从而使其能够从群体协同中获得个体利益,并在个体利益的驱动下持续地参与到群体协同中,进而实现群体协同的可持续性.
最后,通过持续性的群体协同,形成一种群体中所有个体均能通过“各尽其能”而“各得其所欲”的和谐生态系统.该系统包含的一种重要成分即是存在于群体公共环境中的、面向特定领域、且持续演化的需求知识资源.
如图11所示,基于群体协同的特征建模与演化是一个开放系统:其输入是来自每个个体所在的系统外部环境中的各种刺激(包括利益及其他多样性的信息刺激);其输出是个体从群体协同中获得的利益(即,个体形成的个性领域需求知识).该系统的主要构成包括:群体公共环境、个体私有环境、个体(个体行为)、及其之间的相互关系.该系统的动态特征表现为:个体在系统外部环境和群体公共环境的刺激下,表现出直接(通过对公共环境的探索或贡献)或间接(通过对个体私有环境的建立和维护)作用在公共环境上的各种行为;大量个体的行为经过不断的聚合后,对公共环境造成持续的改变,从而形成个体与环境之间的信息正反馈回路,并在宏观上表现出“环境激发效应”型的群体协同行为.
该方法具有4个特点.第一,规模可扩展.在环境容量的允许范围内,支持任何规模的用户群体进行协同,且用户可以随时加入群体协同或从其中退出.第二,无中央控制.不存在一个中央节点对参与用户的活动进行控制或协调:用户以一种完全自发的方式与其他用户发生间接交互.第三,涌现.通过用户个体之间发生的大量间接交互,在量变的基础上产生质变,涌现形成当前用户群体的需求模型.第四,持续演化.通过涌现形成的用户群体需求模型不是一个静态的制品,而会随着用户之间间接交互的不断发生而持续演化.这种持续演化一方面会不断提高群体协同的质量,另一方面则能适应用户需求自身具有的演化性.
基于上述分析,ABC方法对已有的特征模型进行了扩展和增强,形成了一种面向群体的需求模型,支持用户群体通过基于间接交互的协同对群体需求进行建模[25].具体而言,引入支持“自定义结构”的模型扩展机制,使得群体中的每一个体可以根据自己的需求,对特征的属性、特征属性的取值以及
577
梅宏等:ABC:一种全生命周期软件体系结构建模方法Individual
environment Individual environment Group
Environment Behavior Behavior
act on Integration stimulate stimulate Individual E x t e r n a l s t i m u l u s Individual output Individual output
System boundary
E x t e r n a l s t i m u l u s
Positive
feedback
Positive feedback Individual
act on act on act on
图11
基于群体协同的特征建模与演化示意图Figure 11Collaboration-based feature modeling and evolution
特征/属性之间的关系进行自由定义;引入支持“独立增量叠加”的模型扩展机制,使得群体中的每一个体可以在已有建模制品的基础上进行独立和增量式的建模,而所有个体的建模结果又能通过叠加的方式实时融合为一个整体的需求模型;在上述扩展机制的基础上,形成了基于特征模型的用户群体需求模型,并建立了该需求模型的存储模型.
基于上述研究结果,开发了支持群体协同的Web 支撑环境,并通过真实群体和仿真群体两种方式对该方法的效果进行了初步的验证.在面向真实群体的实验中,一个包含4个成员的群体在3小时内对一个软件系统的需求进行了建模,形成了113个特征.虽然该方法对协同式建模的具体过程并没有做出严格的限制,但实验发现,整个协同式建模的过程可以大致分为两个阶段:在头脑风暴阶段中,参与者的主要工作集中在新特征的创建,最终结果中的大多数特征都是在该阶段被创建出来的;在评估阶段中,参与者主要关注对冗余特征的消除、对不清晰特征的改进、对缺失特征的创建、对特征之间关系的创建和调整,以及对他人创建的特征的引用等.在最终结果中,每一参与者所引用的特征占其创建或引用的特征总数的57.5%至79.8%.平均而言,对于每一个参与者,在其认同的所有特征中,有三分之二的特征都由他人创建.在面向仿真群体的实验中,将参与者的行为抽象为创建、查看、思考、选择与拒绝、空闲等几种基本动作,并用Markov 链对用户行为的概率特点进行建模.同时,为每个参与者赋予不同的能力,并基于能力的不同为其建立相应的个性知识库.在此基础上,对以下3种群体的协同建模行为进行了仿真:专家群体(由5个具有高能力的专家组成)、混合群体(由2个专家和150个普通个体组成)、普通群体(由250个普通个体组成).结果显示,在这3个群体中,普通群体建模出的特征要远远多于专家群体(例如,在整个仿真过程的1/10时刻,专家群体建模出了114个特征,混合群体建模出了503个特征,普通群体则建模出了639个特征).同时,实验结果还揭示了一个现象:普通群体中不同个体创建的特征数量体现出长尾分布的特点(在每一次仿真中,普通群体中总会有极少数个体,其创建的特征的数量要远大于其他个体创建的特征的数量).
578
中国科学:信息科学第44卷第5期Runtime architecture infrastructure
Runtime architecture generation framework
Generates code
Customizes and reuses System modeling Architecture modeling
Access
model System model Architecture model
Sys-arch relation Sys-Arch-Sync
generator General engine for arch-arch-sync
System Sys-arch synchronizer Inherent runtime architecture Arch-arch synchronizer Runtime archiecture
图12
模型驱动的运行时体系结构构造过程概览Figure 12Model-driven construction of runtime software architecture
4模型驱动的运行时软件体系结构自动生成
运行时体系结构目前广泛用于企业计算、桌面应用、移动计算等不同类型的软件系统中,用以支持监测、维护、重配置、自适应等不同类型的运行时管理工作[26～29].这些工作的核心是:针对不同的目标系统和不同的运行时管理方式,开发合适的运行时体系结构基础设施,以维护体系结构和目标系统之间的因果关联,即:系统的变化实时体现在体系结构中元素及其属性的变化上,而对体系结构的修改也会导致系统的实时变更.这种因果关联保证系统管理者可以通过读写高层运行时体系结构的方式实现对底层系统的监测和调整.
但现有工作多采用硬编码的方式构造运行时体系结构.这种方式的构造过程繁琐、难以复用,构造后的运行时体系结构难以扩展、维护,在很大程度上影响了运行时体系结构在实践中的深入应用.具体表现为:首先,在开发运行时体系结构基础设施的过程中,需要考虑系统的底层管理能力、体系结构元素的表示,以及二者之间因果关联的定义与维护等复杂问题,而手工实现这些功能的编码量非常大,也容易出错.其次,手工编码的运行时体系结构基础设施中各种功能的代码交织在一起,难以理解、维护和复用.其三,由于缺乏对运行时体系结构及其与底层系统之间关系的清晰定义,管理者往往难以正确理解和有效使用运行时体系结构.特别地,由于不同的开发者对于因果关联缺乏一致、严格的定义,而具体运行时体系结构基础设施因果关联的维护逻辑则隐藏在实现代码中,因此有可能导致管理者错误理解运行时体系结构的行为,进而导致不恰当的管理操作.
为此,ABC 方法提出了一个通用的、自动化的运行时体系结构建模方法与支撑框架.根据开发者提供的模型,支撑框架自动生成相应的运行时体系结构基础设施.在系统运行过程中,该基础设施利用系统底层管理能力维护符合开发者描述的运行时体系结构,并根据开发者提供的系统与体系结构之间的关系维护二者之间的因果关联[30].
如图12所示,建模过程中包括系统建模和体系结构建模两个方面.系统建模描述目标系统对外提供的管理信息的类型及管理方式;建模结果包括系统模型(System Model)和访问模型(Access Model):579
梅宏等:ABC:一种全生命周期软件体系结构建模方法
表1运行时体系结构模型与代码规模
Table1Runtime software architecture and the code scale
System Management Capability model View Relation Generated Additional
ID Case
model map(loc)element(loc)code(loc)information
1JO2nAS-C230528310291572702438kB compiled
2PLASTIC-CS613547175691261800lines+102000lines
3JO2nAS-CS30528310177324117?
4Eclipse1923178443911209?
5IOT291526736208732?
loc:lines of code
系统模型描述目标系统对外提供的管理能力;访问模型描述如何使用目标系统提供的管理能力对系统进行管理操作.体系结构建模定义体系结构视图中的元素类型,以及体系结构视图元素与系统元素之间的关系;其建模结果分别称为体系结构视图模型和关系模型.ABC提供了一组建模语言来辅助开发者创建和维护这些模型.开发者仅需手工完成最上层的系统建模和体系结构建模这两个活动.
运行时体系结构的关键特征是因果关联.而对于不同的运行时体系结构而言,其因果关联的区别在于指导因果关联维护的系统与体系结构之间的关系.根据系统与体系结构之间关系的不同特点, ABC将运行时体系结构分成两类:原生运行时体系结构(Inherent Runtime Architecture)和运行时体系结构视图(Runtime Architecture),这样有助于在建模和实现过程中做到关注点分离.
原生运行时体系结构是系统模型的实例,它按照系统自身的结构描述系统状态(可理解为对系统设计时软件体系结构的实例化),但提供标准的模型读写操作.在为一个目标系统构造运行时体系结构时,技术上首先要能够正确读写该系统的运行时信息.由于不同系统提供用于读写这些信息的底层管理能力在调用方式上存在较大的差异,因而需要首先对这些异构的系统管理能力进行适配.ABC方法通过将系统的运行时信息映射为原生运行时体系结构的方式实现这一适配.通过经典的模型驱动代码生成技术,ABC方法根据用户建立的模型(Access Model和System Model)自动生成系统适配器(Sys-Arch Synchronizer)的实现代码.
运行时体系结构视图主要用来描述符合不同管理层次或角度的体系结构模型.在原生运行时体系结构基础上构造运行时体系结构视图的关键在于模型间的同步.为此,ABC方法提供了一种通用的同步机制,能够基于两个体系结构模型(System Model和Architecture Model)和二者之间的关联模型(Sys-arch Relation)进行配置,获得特定系统的原生体系结构与视图之间的同步器(Arch-Arch Synchronizer).
ABC运行时体系结构自动生成工具均在Eclipse Modeling Framework(EMF)框架的基础上实现,具体实现细节见文献[30,31].如表1所示,ABC为不同的目标系统构造了一系列面向不同管理方式的运行时体系结构.其中,JO2nAS-C2是在开源应用服务器JO2nAS上构造的符合UCI C2风格的运行时体系结构,PLASTIC-CS和JO2nAS-CS分别是在Windows Mobile移动中间件PLASTIC和应用服务器JO2nAS上构造的符合CMU Rainbow客户/服务器风格的运行时体系结构,Eclipse-ABC 和IOT-ABC则是在开源集成开发环境Eclipse和物联网设备上构造的符合ABC风格的运行时体系结构.通过分析这些运行时体系结构实例在构造过程的模型规模和生成代码的规模,可以评估本方法对运行阶段软件复杂性控制的效果.对于系统模型和体系结构模型,给出了其中模型元素的总和(包580
中国科学:信息科学第44卷第5期
括类、属性和关联).对于访问模型,给出了其中mapping的个数以及所有mapping的总代码行数之和.对于关系模型,给出了QVT代码的总行数.对于生成代码,给出了针对不同系统和体系结构生成的、用于体系结构表示和系统调用等功能的代码总行数.
从表中数据可以看出,开发者需要提供的模型在规模上远小于生成的运行时体系结构支撑代码.在系统建模方面,除JO2nAS以外,其他实例中系统模型的规模都不超过50个模型元素.而JO2nAS 系统模型可在自动推理出的系统模型基础上通过简单的调整和精化得到[32],因此实际工作量并不大;其次,管理能力模型只关注如何调用系统底层管理方法,因此其规模远小于生成后的支撑代码规模;最后,由于视图模型和关系模型抽象程度较高,模型规模也就更小.表中每个实例自动生成的代码都在1万行左右甚至更多,实例1的代码将近3万行.文献[26]中指出一个典型的C2风格运行时体系结构基础设施,编译后的规模达到38kB;文献[27]中指出实现一个C/S风格的运行时体系结构,在10万行代码的Rainbow框架基础上,仍需要编写2000行代码.这从另一个角度证明实现实例1～3的确需要较大的工作量.从代码生成率(生成代码行数/模型元素个数)的角度看,每个模型元素平均生成26行java代码.因此,模型驱动的方法有效提高了运行时体系结构的构造效率.
模型驱动的开发方式除提高开发效率外,也提高了可复用性.复用形式有两种:整个制品的复用;制品中相关内容的复用.例如,如果为JO2nAS系统构造一个基于C/S结构的运行时体系结构,其中目标系统和体系结构风格分别在实例1和实例2中定义过,因此构造实例3时,可以直接复用实例1的系统模型和访问模型,以及实例2的体系结构模型,然后仅需要重新定义新的关系模型.
5体系结构模型逆向恢复和追踪
现实中存在大量的遗产软件系统.这些软件系统不但可能长期存在,甚至还需要不断进行维护和演化以适应新的环境.由于这些软件不是基于ABC方法进行开发的,因此难以直接用ABC方法来实现自动化的维护与演化.针对这个问题,我们对ABC方法进行了进一步的扩展,使其能够支持遗产软件系统的维护与演化.从软件复杂性控制的角度看,基于ABC方法进行软件开发时,除了最终运行的软件,开发过程中还产生了包括软件体系结构在内的一系列用于“分步”控制复杂性的软件制品,而遗产软件系统往往缺少这些软件制品.我们的基本思路是:以遗产软件系统的代码为基础,通过软件分析[33],辅助逆向建立遗产软件系统的软件体系结构模型,并进而逆向恢复ABC方法所需要的其他软件制品(特别是与遗产软件系统的维护与演化有关的软件制品),从而使得遗产软件系统的维护与演化可以在ABC方法的支持下完成.具体而言,ABC方法探索了多种软件分析技术,以实现从代码到设计的逆向追踪、以及从代码到需求的逆向追踪.
完成从代码到设计的逆向追踪的首要目标是逆向恢复遗产软件系统的体系结构.针对这一问题,需先识别代码中的构件,并在此基础上恢复软件体系结构[34,35]:将遗产软件系统抽象为一个有向带权图,以迭代的方式逐步考察图中不同粒度的子图,并通过独立性度量选取独立性高的子图作为构件候选者.在迭代过程中,每次迭代得到的候选构件将被抽象为下一次迭代的图中的一个顶点.该有向图的每个顶点代表一个类,每条边代表类之间的关系,边的权代表类间的依赖程度.以该图为基础,先根据图的大小确定每次迭代考察的子图的最大规模k,然后对图进行迭代分析.每次迭代考察输入的图的所有规模小于k的连通子图,采用独立性度量函数计算每个子图的独立性,选取其中独立性高于阈值d的子图作为候选子图(对应于候选构件),然后将候选子图抽象为一个顶点,并对输入的图进行重构,形成一个规模较小的新图,以新图作为下一次迭代的输入,重复进行迭代直到重构得到的新图的
581
梅宏等:ABC:一种全生命周期软件体系结构建模方法
Analyzing component version comments Matching component
versions
Aggregating
rules
Rules for
component
evolution
Version before evolution
Version
after
evolution Middle
version
1
Middle
version
2
Middle
version
3
Component under evolution
Rules between versions
Rules between
versions
Rules between
versions
图13构件演化规则挖掘
Figure13The mining of component evolution rules
规模小于k.由于构件是通过迭代的方法识别出来的,且在组成结构上也具有层次关系:越晚识别出来的构件间的相互关系越紧密.这种层次化的组成关系经过精化后,即被作为通过逆向恢复产生的软件体系结构.
为了帮助遗产软件系统的维护与演化,需要挖掘构件的使用规约[36,37],以便在维护和演化过程中避免开发人员对构件的误用.由于构件使用规约蕴含在构件的使用代码中,如果一个遗产软件系统中的构件使用代码不够充足,就需要联合多个遗产软件系统进行挖掘.针对一个目标构件,分析每个使用该构件的代码片段,将其表示为一个对构件中函数的调用序列,然后通过综合分析这些调用序列,挖掘出共性子序列,作为使用该构件应满足的约束关系.由于构件的使用代码可能分散在多个代码块甚至多个函数中,通过程序分析将分散的构件使用代码合并成统一的使用代码;由于构件中同一个函数可能涉及多个使用规则,进一步引入聚类技术以将涉及相同使用规则的调用序列聚在一起进行挖掘,从而提高了约束关系挖掘的效率和准确性.为了应对构件使用代码缺乏的情况,利用自然语言处理技术对构件文档进行分析,进一步辅助构件约束关系的挖掘:首先分析软件库文档,从中提取出每个函数的描述和类之间的继承关系;然后利用自然语言处理技术从函数的描述里抽取动作—资源对;最后基于特定的模板自动生成构件的使用规约.
在遗产软件系统的维护与演化过程中,构件本身也可能发生演化或者更替,当构件的演化或更替导致构件的使用规约也发生变化时,其他的部分也需要进行相应的修改以适应构件的这种变化.因此,需要挖掘构件使用规约的变迁或对应关系[38,39],当一个构件演化成(或被替换成)另一个构件时,可用于检查对原有构件的使用是否满足演化后(替换后)构件的使用规约;如果不满足,则需要调整系统对该构件的使用.对于构件发生演化的情况,通过分析构件的演化历史挖掘构件使用规约的变迁:如图13所示,针对构件的每次修改识别该次修改导致的构件使用规约的变迁,然后将这些识别出来的变迁迭加起来得到演化前后构件规约的变迁.在分析每次修改导致的构件使用规约的变迁时,综合考虑以下三方面的信息:开发人员提交修改时的文本说明、构件中相关函数在构件代码中的调用及被调
582
中国科学:信息科学第44卷第5期Feature descriptions Final
specific
functions
Initial specific functions Recovered
connections Final relevant
functions and
traces
BRCG
Source code Function descriptions Retrieving
connections Extracting function
descriptions 1.Acquiring initial specific connections
between features and functions
3.Determining relevant functions and traces BRCG
constructing
BRCG pruning
Determining initial specific
functions Analyzing relevant functions 2.
Acquiring initial specific functions 4.Determining final specific functions
图14
静态特征定位Figure 14Static feature locating
用信息、构件中相关函数演化前后的相似程度.实验结果表明,该方法的准确率超过95%,明显高于现有的同类方法.针对构件发生更替的情况,通过分析已发生构件更替的软件,挖掘不同构件使用规约间的对应关系:将构件更替前后的构件使用代码中的多种依赖关系分别表示成两个图,然后基于两个代码片段中的相似代码,对两个图进行对比分析,识别构件更替前后对应的接口,并进而推导出构件使用规约在更替前后的变迁.实验结果表明,该方法可以取得较高的准确率.
针对从代码到需求的逆向追踪,需要逆向建立代码与软件特征的关联关系[40,41]:对于大多数软件系统的代码,标识符和注释中的文本信息往往体现了程序基本单元与软件特征的对应关系,而程序的结构信息则体现了开发人员如何组织程序基本单元以实现相应的软件特征;基于这种联系,就可以通过代码静态确定与每个软件特征相关联的代码(即特征定位).如图14所示,分析软件文档和程序代码中的文本信息,利用信息检索技术确定初始关联关系,并进一步分析程序静态结构,对初始的关联关系进行精化和扩充,从而完成特征定位.基于该技术,维护人员不需要额外维护软件特征以及软件体系结构与程序代码之间的关联关系,而可以在需要时通过自动分析获得这种关联关系.实验结果表明,这种静态特征定位技术的准确率超过90%.由于许多软件维护与演化活动需要依据错误报告开展,进一步将针对代码的特征分析延伸到错误报告的分析,重点关注重复错误报告的检测[42],其实质是分析错误报告是否涉及相同的软件特征.实验结果表明,综合分析代码结构信息和文本描述信息可以大幅提高重复错误报告检测的准确率.6结束语
本文总结了作者在过去十余年对全生命周期软件体系结构建模的研究与实践,并重点介绍了近几年在协同式特征建模、运行时体系结构生成以及逆向建模方面的最新进展.随着云计算、移动互联网、
583
《软件体系结构》期末复习题 简答题： 1、软件体系结构建模的种类有： 结构模型、框架模型、动态模型、过程模型、功能模型。 2、“4+1”视图模型从5个不同的视角包括： 逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。 3、构件：是具有某种功能的可重用的软件模板单元，表示了系统中主要的计算元素和数据存储。 连接件：表示构件之间的交互。 配置：表示构件和连接件的拓扑逻辑和约束。 端口：表示构件和外部环境的交互点。 角色：定义了该连接交互的参与者。 4、画出“4+1”视图模型图，分析各部分的原理和功能。 5、软件体系结构风格： 是描述某一特定应用领域中系统组织方式的惯用模式。 6、软件体系结构 （Software Architecture） 软件体系结构以组件和组件交互的方式定义系统，说明需求与成品系统之间的对应关系，描述系统级别的可伸缩性、能力、吞吐量、一致性和兼容性等属性。软件体系结构由组件、连接件和属性组成。 7、分层系统的优点有： 1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解； 2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层； 3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可
以定义一组标准的接口，而允许各种不同的实现方法。 8、分层系统的缺点有： 1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来； 2）很难找到一个合适的、正确的层次抽象方法。 9、 B/S体系结构的优点有什么？ 答：1）基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。 2）B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。 10、B/S体系结构的缺点有什么？ 答：1）B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。 2）B/S体系结构的系统扩展能力差，安全性难以控制。 3）采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构。 4）B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。 11、DSSA 答案：DSSA就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构 11、软件体系结构的动态性主要分为： 交互式动态性、结构化动态性、体系结构动态性等三类。 12、请画出基于构件的动态系统结构模型画。 13、软件产品线 产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。这些系统遵循一个预描述的方式，在公共的核心资源(core assets)基础上开发的 14、SOA 即service-oriented architecture，面向服务架构。它是一个组件模型，它 将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接 口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于 实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的 系统中的服务可以以一种统一和通用的方式进行交互。 14、RIA
第一章：1、软件体系结构的定义 国内普遍看法： 体系结构=构件+连接件+约束 2、软件体系结构涉及哪几种结构： 1、模块结构（Module） 系统如何被构造为一组代码或数据单元的决策 2、构件和连接件结构（Component-And-Connector，C&C） 系统如何被设计为一组具有运行时行为（构件）和交互（连接件）的元素 3、分配结构（Allocation） 展示如何将来自于模块结构或C&C结构的单元映射到非软件结构（硬件、开发组和文件系统） 3、视图视点模型 视点（View point） ISO/IEC 42010:2007 (IEEE-Std-1471-2000)中规定：视点是一个有关单个视图的规格说明。 视图是基于某一视点对整个系统的一种表达。一个视图可由一个或多个架构模型组成 架构模型 架构意义上的图及其文字描述（如软件架构结构图） 视图模型 一个视图是关于整个系统某一方面的表达，一个视图模型则是指一组用来构建 4、软件体系结构核心原模型 1、构件是具有某种功能的可复用的软件结构单元，表示了系统中主要的计算元素和数据存储。 2.连接件(Connector)：表示构件之间的交互并实现构件 之间的连接
特性：1)方向性2)角色3)激发性4)响应特征 第二章 1、软件功能需求、质量属性需求、约束分别对软件架构产生的影响 功能性需求：系统必须实现的功能，以及系统在运行时接收外部激励时所做出的行为或响应。 质量属性需求：这些需求对功能或整个产品的质量描述。 约束：一种零度自由的设计决策，如使用特定的编程语言。 质量原意是指好的程度，与目标吻合的程度，在软件工程领域，目标自然就是需求。 对任何系统而言，能按照功能需求正确执行应是对其最基本的要求。 正确性是指软件按照需求正确执行任务的能力，这无疑是第一重要的软件质量属性。质量属性的优劣程度反映了设计是否成功以及软件系统的整体质量。 系统或软件架构的相关视图的集合，这样一组从不同视角表达系统的视图组合在一起构成对系统比较完整的表达
1面向对象编程中是如何体现封装性的？ 封装是把过程和数据包围起来，对数据的访问只能通过已定义的界面。 2重载和重写的含义 重载是发生在一个类中，方法名相同，参数不同 重写（覆盖）是子类继承父类，子类可以通过重写的方法隐藏继承的方法 3 什么是接口回调，过程细节是什么？ 概念：把可以实现某一接口的类创建的对象的引用赋给该接口声明接口变量，那么该接口变量可以调用被类实现（重写）的接口方法。 4试举例说明什么是组合关系和依赖关系 组合（关联）关系：A类中成员变量是用B类声明的对象。公司--职员 依赖关系：A类中某个方法的参数是用B类声明的对象，或某个方法返回的数据类型是B类的对象 5抽象类和接口，区别是什么？如何应用 抽象类：抽象类中有抽象方法；抽象类中不能用new运算符创建对象；抽象类的对象做商转型对象 接口：（1）接口中只可以有public权限的抽象方法，不能有非抽象方法； （2）接口由类去实现，即一个类如果实现一个接口，那么他必须重写接口中的抽象方法 （3）接口回调 区别：接口中只有常量，不能有变量；抽象类中既可以有常量也可以有变量； 抽象类中也可以有非抽象方法，接口不可以。 应用：定义抽象方法：public abstract void 方法名(); 在子类实现抽象方法：public void 方法名(){} 接口：public interface 接口名{}接口只负责定义规则，不负责任何实现；实现交给实现接口的类 (6)面向对象的六条基本原则包括： 开闭原则，里式代换原则，单一职责，依赖倒转、迪米特法则（接口隔离）。 (7)什么是设计模式？ 设计模式是从许多优秀的软件系统中总结出的成功的可复用的设计方案。是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性 (8)什么是框架？框架与模式的区别有哪些？ 框架是针对某个领域，提供用于开发应用系统的类的集合。 区别：层次不同、范围不同、相互关系
目录
1.引言 [对于由多个进程构成的复杂系统，系统设计阶段可以分为：架构设计（构架设计）、组件高层设计、组件详细设计。对于由单个进程构成的简单系统，系统设计阶段可以分为：系统概要设计、系统详细设计。本文档适用于由多个进程构成的复杂系统的构架设计。] [架构设计说明书是软件产品设计中最高层次的文档，它描述了系统最高层次上的逻辑结构、物理结构以及各种指南，相关组件（粒度最粗的子系统）的内部设计由组件高层设计提供。] [系统：指待开发产品的软件与硬件整体，其软件部分由各个子系统嵌套组成，子系统之间具有明确的接口； 组件：指粒度最粗的子系统； 模块：指组成组件的各层子系统，模块由下一层模块或函数组成；] [此文档的目的是： 1）描述产品的逻辑结构，定义系统各组件（子系统）之间的接口以及每个组件（子系统）应该实现的功能； 2）定义系统的各个进程以及进程之间的通信方式； 3）描述系统部署，说明用来部署并运行该系统的一种或多种物理网络（硬件）配置。对于每种配置，应该指出执行该系统的物理节点（计算机、网络设备）配置情况、节点之间 的连接方式、采用何种通信协议、网络带宽。另外还要包括各进程到物理节点的映射； 4）系统的整体性能、安全性、可用性、可扩展性、异常与错误处理等非功能特性设计； 5）定义该产品的各个设计人员应该遵循的设计原则以及设计指南，各个编程人员应该遵循的编码规范。 ] [建议架构设计工程师与组件设计工程师共同完成此文档。] [架构设计说明书的引言应提供整个文档的概述。它应包括此文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 1.1目的 [简要描述体系结构文档的目的。]
第一章 1.根据自己的经验，谈谈对软件危机的看法 答：软件危机是指软件生产方式无法满足迅速增长的计算机需求，开发和维护过程出现的一系列问题。 它主要由以下几个原因导致：（1）软件自身特点 （2）开发人员的弱点 （3）用户需求不明 （4）缺乏正确理论指导 （5）开发规模越来越大 （6）开发复杂度越来越高 可以通过软件生命周期的模型和软件工具的使用来缓解危机，通过程序自动化和 软件工业化生产的方法实现软件标准化的目标，进一步缓解软件危机带来的影 响。 软件危机有利有弊，除了带来许多麻烦，也给我们带来许多挑战，克服危机的过 程，我们在技术上和创新上都有了一个提升，也算是间接为软件产业的发展做了 贡献。 2.什么是软件重用，软件重用的层次可以分为哪几个级别 答：软件重用，是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。可以分为三个层次： （1）代码重用（2）设计结果重用（3）分析结果重用 3. 什么是可重用构件相对于普通的软件产品，对可重用构件有何特殊要求 答：可充用构件表示软件重用过程中，可重用的软件构件元素。 可重用构件的特殊要求： （1）可重用构件应该具有功能上的独立性与完整性； （2）可重用构件应该具有较高的通用性； （3）可重用构件应该具有较高的灵活； （4）可重用构件应该具有严格的质量保证； （5）可重用构件应该具有较高的标准化程。 4.基于构件的软件开发的优势是什么面临哪些困难和挑战 答：优势：基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降 低了软件开发的费用 困难和挑战：没有可依据的参考，可用资源和环境缺乏，开发难度高，而各方面需求 增长速度与日剧增，更新和升级的跟进是一个不小的挑战.此外，在同一系统采用多 个开发商提供的构件，它们之间的兼容性可能是开发过程中所要面对的一个严峻的问 题 5.描述三种应用最为广泛的构件技术规范COM、CORBA和EJB各自的特点 答：COM：COM无需重新编译，对象就可以增添新的功能，还能够透明地向另一个过程或另一台机器上的对发送RPC调用； CORBA：CORBA用IDL来描述对象接口，可以满足异种语言间的通信问题。
房产物业管理信息系统架构设计方案 2015 年7月 版本控制
一、前言 二、架构设计 2.1架构分析 2.2架构定义 2.3架构说明 2.4软件逻辑结构 三、具体功能简述 3.1自定义工作流解决方案 3.2多语言解决方案 3.3消息发布/订阅系统方案 3.4报表&打印方案 四、系统平台&支撑组件 五、系统网络结构 六、开发管理层面
一、前言 一个企业级的商业软件能够满足用户需要、正常运行、易于维护、易于扩展，必须拥有一个良好的软件架构支撑。本文主要是分析和构建一个企业级商业软件架构。 二、架构设计 2.1架构分析 企业级的商业软件架构在技术层面的要求主要体系在高性能、健壮性和低成本。 ●高性能 对于企业级商业软件来说，软件架构需要尽可能地使软件具有最高的性能，支持最大的并发性。 ●健壮性 企业级的商业软件要求软件是可靠的和无缺陷的。现在的架构一般是，服务器模式的。软件的可靠和健壮主要依赖与服务器。服务器的稳定通过良好的代码和完备的测试能够解决这个问题。 ●低成本 企业级商业软件还有一个很重要的要求：低成本。软件架构要求简单、易掌握，复杂度低，易于维护和扩展，易于测试。 2.2架构定义 本架构以XML为整个系统的交互接口，包括系统架构内部和外部。整个系统分为界面展示层，流程控制层和数据存储层。 2.3架构说明 系统架构 图 Erp架构中各核心服务之间满足松散耦合特性，具有定义良好的接口，可通过拆分与组合，
可以有针对性地构建满足不同应用场景需求的Erp应用系统。 2.3.1 适配器 在集成环境中需要复用已有的应用系统和数据资源，通过适配器可以将已有应用系统和数据资源接入到ERP应用系统中。 通过适配器可以实现已有资源与ERP系统中其它服务实现双向通讯和互相调用。首先通过适配器可以实现对已有资源的服务化封装，将已有资源封装为一个服务提供者，可以为ERP应用系统中的服务消费者提供业务和数据服务，其次通过适配器，也可以使已有资源可以消费ERP应用系统中的其它服务。 2.3.2 资源仓库 资源仓库主要功能是提供服务描述信息的存储、分类和查询功能。对于广义的资源仓库而言，除了提供服务类型的资源管理外，还需要提供对其它各种资源的管理能力，可管理对象包括：人员和权限信息、流程定义和描述、资源封装服务、服务实现代码、服务部署和打包内容、以及环境定义和描述信息。 资源仓库首先需要提供服务描述能力，需要能够描述服务的各种属性特征，包括：服务的接口描述、服务的业务特性、服务的质量特征(如：安全、可靠和事务等)以及服务运行的QoS属性。 2.3.3 连通服务 连通服务是ERP基础技术平台中的一个重要核心服务，典型的连通服务就是企业服务总线(Enterprise Service Bus，ESB)，它是服务之间互相通信和交互的骨干。连通服务的主要功能是通信代理，如服务消费的双向交互、代理之间的通信、代理之间的通信质量保障以及服务运行管理功能等。 连通服务还需要保证传输效率和传输质量。连通服务一般应用于连接一个自治域内部的各个服务，在自治域内部服务都是相对可控的，所以连通服务更多应该考虑效率问题。 2.3.4 流程服务 流程服务是为业务流程的运行提供支撑的一组标准服务。业务流程是一组服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用。业务流程可以由不同粒度的服务组成，其本身可视为服务。 流程服务是业务流程的运行环境，提供流程驱动，服务调用，事务管理等功能。流程服务需要支持机器自动处理的流程，也需要支持人工干预的任务操作，它支持的业务流程主要适用于对运行处理时间要求不高的，多方合作操作的业务过程。 2.3.5 交互服务
福建农林大学计算机与信息学院 实验报告 课程名称：软件设计与体系结构 姓名：陈宇翔 系：软件工程系 专业：软件工程 年级：2007 学号：070481024 指导教师：王李进 职称：讲师 2009年12月16日
实验项目列表
福建农林大学计算机与信息学院实验报告 学院：计算机与信息学院专业：软件工程系年级：2007 姓名：陈宇翔 学号：070481024 课程名称：软件设计与体系结构实验时间：2009-10-28 实验室田实验室312、313计算机号024 指导教师签字：成绩： 实验1：ACME软件体系结构描述语言应用 一、实验目的 1）掌握软件体系结构描述的概念 2）掌握应用ACMESTUDIO工具描述软件体系结构的基本操作 二、实验学时 2学时。 三、实验方法 由老师提供软件体系结构图形样板供学生参考，学生在样板的指导下修改图形，在老师的指导下进行软件体系结构描述。 四、实验环境 计算机及ACMESTUDIO。 五、实验内容 利用ACME语言定义软件体系结构风格，修改ACME代码，并进行风格测试。 六、实验操作步骤 一、导入Zip文档 建立的一个Acme Project，并且命名为AcmeLab2。如下图：
接着导入ZIP文档，导入完ZIP文档后显示的如下图： 二、修改风格 在AcmeLab2项目中,打开families下的TieredFam.acme.如下图： 修改组件外观 1. 在组件类型中，双击DataNodeT; 在其右边的编辑器中，将产生预览；选择Modify 按钮，将打开外观编辑器对话框。 2. 首先改变图形：找到Basic shape section，在Stock image dropdown menu中选 择Repository类型. 3. 在Color/Line Properties section修改填充颜色为深蓝色。 4. 在颜色对话框中选择深蓝色，并单击 [OK]. 5. 修改图形的边框颜色为绿色 7. 单击Label tab，在Font Settings section, 设置字体颜色为白色,单击[OK] 产生的图形如下图：
1. 软件架构概述 1.1 什么是软件架构 ◎软件架构的概念很混乱。如果你问五个不同的人，可能会得到五种不同的答案。 ◎软件架构概念主要分为两大流派： 组成派：软件架构 = 组件 + 交互。 决策派：软件架构 = 重要决策集。 ◎组成派和决策派的概念相辅相成。 1.2 软件架构和子系统、框架之间的关系 ◎复杂性是层次化的。 ◎好的架构设计必须把变化点错落有致地封装到软件系统的不同部分(即关注点分离)。 通过关注点分离，达到“系统中的一部分发生了变化，不会影响其他部分”的目标。◎软件单元的粒度： * 粒度最小的单元通常是“类”。 * 几个类紧密协作形成“模块”。 * 完成相对独立的功能的多个模块构成了“子系统”。 * 多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“系统”。
* 一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统”。 ◎软件单元的粒度是相对的。同一个软件单元，在不同场景下我们会以不同的粒度看待它。◎架构(Architecture)不等于框架(Framework)。 框架只是一种特殊的软件，框架也有架构。 ◎可以通过架构框架化达到“架构重用”的目的，如很多人都在用 Spring 框架提供的控制反转和依赖注入来构建自己的架构。 1.3 软件架构的作用 ◎如果一个项目的系统架构(包括理论基础)尚未确定，就不应该进行此系统的全面开发。 -- Barry Boehm,《Engineering Context》 ◎一个缺陷充斥的系统，将始终是一个缺陷充斥的系统。 -- Timothy C. Lethbridge,《面向对象软件工程》 ◎软件架构设计为什么这么难？ 因为它是跨越现实世界与计算机世界之间鸿沟的一座桥。 软件架构设计要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。 需求 -> 架构设计 -> 软件架构 -> 系统开发 -> 软件系统 ~~~~~~~~ ~~~~~~~~
一次 就项目管理方面而言，软件重用项目与非重用项目有哪些不同之处。 答：使用软件重用技术可减少重复工作,提高软件生产率, 缩短开发周期。同时，由于软构建大多经过严格的质量认证，因此有助于改善软件质量，大量使用构建，软件的灵活性和标准化程度可得到提高。 2、实际参与/组织一个软件重用项目的开发，然后总结你是如何组织该项目的开发的 答：参加了一个网页管理系统的开发，该项目重复使用已有的软件产品用于开发新的软件系统，以达到提高软件系统的开发质量与效率，降低开发成本的目的。在过程中使用了代码的复用、设计结果的复用、分析结果的复用、测试信息的复用等。 3、为什么要研究软件体系结构？ 答：1.软件体系结构是系统开发中不同参与者进行交流和信息传播的媒介。 2．软件体系结构代表了早期的设计决策成果。 3．软件体系结构可以作为一种可变换的模型。 4、根据软件体系结构的定义，你认为软件体系结构的模型应该由哪些部分组成？ 答：构件()可以是一组代码，如程序的模块;也可以是一个独
立的程序(如数据库的服务器)； 连接件()是关系的抽象，用以表示构件之间的相互作用。如过程调用、管道、远程过程调用等； 限制()：用于对构件和连接件的语义说明。 5、在软件体系结构的研究和应用中，你认为还有哪些不足之处？ 答：（1）缺乏同意的软件体系结构的概念，导致体系结构的研究范畴模糊。 （2）繁多，缺乏同意的的支持。 （3）软件体系结构研究缺乏统一的理论模型支持。 （4）在体系结构描述方便，尽管出现了多种标准规范或建议标准，但仍很难操作。 （5）有关软件体系结构性质的研究尚不充分，不能明确给出一个良体系结构的属性或判定标准，没有给出良体系结构的设计指导原则，因而对于软件开发实践缺乏有力的促进作用。（6）缺乏有效的支持环境软件体系结构理论研究与环境支持不同步，缺乏有效的体系结构分析、设计、方针和验证工具支持，导致体系结构应用上的困难。 （7）缺乏有效的体系结构复用方案。 （8）体系结构发现方法研究相对欠缺。 二次
1、封装是指把对象的（A ）结合在一起，组成一个独立的对象。 A．属性和操作 B．信息流 C．消息和事件Ｄ．数据的集合 2、封装是一种（C ）技术，目的是使对象的生产者和使用者分离，使对象的定义和实现分开。 Ａ．工程化Ｂ．系统维护Ｃ．信息隐蔽Ｄ．产生对象3、面向对象方法中的（D）机制是子类可以自动地拥有复制父类全部属性和操作。Ａ．约束Ｂ对象映射Ｃ．信息隐蔽Ｄ．继承 4、使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法（B ）。 A．继承 B．多态性 C.约束 D.接口 5、UML 的软件以（A）为中心，以系统体系结构为主线，采用循环、迭代、渐增的方式进行开发。 A. 用例 B.对象 C.类 D.程序 6、UML 的（ B ）模型图由类图、对象图、包图、构件图和配置图组成。 A. 用例 B. 静态 C. 动态 D. 系统 7、UML的（ C ）模型图由活动图、顺序图、状态图和合作图组成。 A. 用例 B. 静态 C. 动态 D.系统 8、UML的最终产物就是最后提交的可执行的软件系统和（ D ）。 A．用户手册Ｂ.类图Ｃ.动态图Ｄ.相应的软件文档资料 9、在UML的需求分析建模中，（ B ）模型图必须与用户反复交流并加以确认。Ａ. 配置Ｂ. 用例Ｃ.包Ｄ. 动态 10、可行性研究分析包括经济可行性分析、技术可行性分析和（ B ）。 A.风险可行性分析 B.法律可行性分析 C.资源可行性分析 D.效益可行性分析 11、UML的客户分析模型包括（ A ）模型、类图、对象图和活动图组成。 A.用例 B.分析 C.属性 D.系统 12、UML客户需求分析使用的CRC卡上“责任”一栏的内容主要描述类的（C ）和操作。 A.对象成员 B.关联对象 C.属性 D.私有成员 13、UML客户需求分析产生的系统模型描述了系统的（ D ） A.状态 B.体系结构 C.静态模型 D.功能要求 14、在UML的需求分析建模中，用例模型必须与（ B ）反复交流并加以确认。 A.软件生产商 B.用户 C.软件开发人员 D.问题领域专家 15、在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（ A ）。 A.活动图 B.状态图 C.配置图 D.构件图 16、活动图中的分劈和同步接合图符是用来描述（ A ） A.多进程的并发处理行为 B.对象的时序 C.类的关系 D.系统体系结构框架 17、UML的系统分析进一步要确立的三个系统模型的是（B ）、对象动态模型和系统功能模型。 A．数据模型 B．对象静态模型Ｃ．对象关系模型D．体系结构模型18、UML的客户需求分析、系统分析和系统设计阶段产生的模型，其描述图符（B）。 A．完全相同 B．完全不同 C．不可以通用 D．稍有差异 19、类和对象都有属性，它们的差别是：类描述了属性的类型，而对象的属性必须有（C ）。
1.面向对象的方法优势体现在（ABD ） A．简化软件开发过程 B．支持软件复用 C．提高软件运行效率 D．改善软件结构 2.用户界面设计中的三条“黄金规则”是（ABC ） A．使系统处于用户控制之中 B．减少用户的记忆负担 C．保持界面的一致性 D．保证用户的易学性 3.用户界面的分析和设计过程是迭代的，其中包括的活动是 （ABCD ） A．用户、任务以及环境的分析和建模 B．界面设计 C．界面实现 D．界面确认 4.界面确认需要注意三个方面（ABC ） A．界面正确完成了用户的任务，适应用户的任务变化 B．易学性和易用程度 C．用户的接受程度 D．用户的习惯 5.用户界面分析时通常采用的信息获取方式包括（ABCD ） A．用户会谈 B．销售人员信息采集 C．市场分析 D．用户支持人员信息收集 6.（C ）把完成一个特定功能的动作序列抽象为一个过程名和参数表 A．数据抽象 B．动作抽象 C．过程抽象 D．类型抽象 7.（A）把一个数据对象的定义抽象为一个数据类型名 A．数据抽象 B．动作抽象 C．过程抽象 D．类型抽象 8.软件体系结构设计需要考虑以下（ABCD ）
A．适用性 B．结构稳定性 C．可扩展性 D．可复用性 9.模块设计时应该考虑（AB ） A．模块功能独立 B．模块信息的隐藏 C．模块接口的简单 D．模块实现简单 10.一个完整的软件设计的主要活动包括有（ABCD ） A．体系结构设计 B．界面设计 C．模块/子系统设计、 D．数据模型、过程/算法设计等 11.模块化是指把一个复杂的问题分割成若干个可管理的小问题后，更易 于理解，模块化正是以此为依据的，在划分模块的过程中应该考虑到（ABC ） A．模块的可分解性、可组装型 B．模块的可理解性、连续性、 C．模块保护 D．尽可能低分割模块，使得问题的难度降到最 1.什么是软件工程？构成软件工程的要素是什么？ 软件工程是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护过程，即将工程化应用于软件开发和管理之中，对所选方法的研究。软件工程的要素由方法、工具和过程组成。方法支撑过程和工具，而过程和工具促进方法学的研究。 2.什么是软件生存周期？软件开发过程模型与软件生存周期之间是何关 系？ 软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程叫软件生存周期。软件开发过程模型表示软件开发中各个活动的安排方式，出来软件开发各个活动之间关系，是软件开发过程的概括，是软件工程的重要内容，其为软件管理提供里程碑和进度表，为
软件架构设计说明书 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
目录
1.引言 [对于由多个进程构成的复杂系统，系统设计阶段可以分为：架构设计（构架设计）、组件高层设计、组件详细设计。对于由单个进程构成的简单系统，系统设计阶段可以分为：系统概要设计、系统详细设计。本文档适用于由多个进程构成的复杂系统的构架设计。] [架构设计说明书是软件产品设计中最高层次的文档，它描述了系统最高层次上的逻辑结构、物理结构以及各种指南，相关组件（粒度最粗的子系统）的内部设计由组件高层设计提供。] [系统：指待开发产品的软件与硬件整体，其软件部分由各个子系统嵌套组成，子系统之间具有明确的接口； 组件：指粒度最粗的子系统； 模块：指组成组件的各层子系统，模块由下一层模块或函数组成；] [此文档的目的是： 1）描述产品的逻辑结构，定义系统各组件（子系统）之间的接口以及每个组件（子系统）应该实现的功能； 2）定义系统的各个进程以及进程之间的通信方式； 3）描述系统部署，说明用来部署并运行该系统的一种或多种物理网络（硬件）配置。对于每种配置，应该指出执行该系统的物理节点（计算机、网络设备）配置情况、节点之间的连 接方式、采用何种通信协议、网络带宽。另外还要包括各进程到物理节点的映射； 4）系统的整体性能、安全性、可用性、可扩展性、异常与错误处理等非功能特性设计； 5）定义该产品的各个设计人员应该遵循的设计原则以及设计指南，各个编程人员应该遵循的编码规范。 ] [建议架构设计工程师与组件设计工程师共同完成此文档。] [架构设计说明书的引言应提供整个文档的概述。它应包括此文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
《软件体系结构》教学大纲 一、课程概述 《软件体系结构》是根植于软件工程发展起来的一门新兴学科，目前已经成为软件工程研究和实践的主要领域。体系结构在软件开发中为不同的人员提供了共同交流的语言，体现并尝试了系统早期的设计决策，并作为相同设计的抽象，为实现框架和构件的重用、基于体系结构的软件开发提供了有力的支持。 作为计算机科学与技术专业软件工程方向的重要专业课程，本课程主要系统地介绍软件体系结构的基本原理、方法和实践，全面反映软件体系结构研究和应用的最新进展。既讨论软件体系结构的基本理论知识，又介绍软件体系结构的设计和工业界应用实例，强调理论与实践相结合。 本课程的先修课程为“软件工程”。 二、课程目标 1．知道《软件体系结构》这门学科的性质、地位、研究范围、学科进展和未来方向等。2．理解该门学科的主要概念、基本原理和策略等。 3．掌握软件体系结构的建模方法、描述方法，通过对不同软件体系结构风格的掌握，能够采用正确的基于体系结构的软件开发。 4．能够把所学的原理应用到具体的实践中去，培养学生发现、分析和解决问题的能力等。 三、课程内容与教学要求 这门学科的知识与技能要求分为知道、理解、掌握、学会四个层次。这四个层次的一般涵义表述如下： 知道———是指对这门学科和教学现象的认知。 理解———是指对这门学科涉及到的概念、原理、策略与技术的说明和解释，能提示所涉及到的教学现象演变过程的特征、形成原因以及教学要素之间的相互关系。 掌握———是指运用已理解的教学概念和原理说明、解释、类推同类教学事件和现象。 学会———是指能模仿或在教师指导下独立地完成某些教学知识和技能的操作任务，或能识别操作中的一般差错。 教学内容和要求表中的“√”号表示教学知识和技能的教学要求层次。
第一章： 1.根据自己的经验，谈谈对软件危机的看法。 软件危机是指软件生产方式无法满足迅速增长的计算机需求，开发和维护过程出现的一系列问题。 以下几个原因导致：（1）软件自身特点 （2）开发人员的弱点 （3）用户需求不明 （4）缺乏正确理论指导 （5）开发规模越来越大 （6）开发复杂度越来越高 可以通过软件生命周期的模型和软件工具的使用来缓解危机，通过程序自动化和软件工业化生产的方法实现软件标准化的目标，进一步缓解软件危机带来的影响。 软件危机有利有弊，除了带来许多麻烦，也给我们带来许多挑战，克服危机的过程，我们在技术上和创新上都有了一个提升，也算是间接为软件产业的发展做了贡献。 2.什么是软件重用，软件重用的层次可以分为哪几个级别？ 软件重用:是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。可以分为三个层次： （1）代码重用（2）设计结果重用（3）分析结果重用 3.什么是可重用构件？相对于普通的软件产品，对可重用构件有何特殊要求？ 可充用构件表示软件重用过程中，可重用的软件构件元素。 可重用构件的特殊要求： （1）可重用构件应该具有功能上的独立性与完整性； （2）可重用构件应该具有较高的通用性； （3）可重用构件应该具有较高的灵活； （4）可重用构件应该具有严格的质量保证； （5）可重用构件应该具有较高的标准化程。 4.基于构件的软件开发的优势是什么？基于构件的软件开发面临哪些挑战和困难？ 优势：基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装，更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低了软件开发的费用困难和挑战：没有可依据的参考，可用资源和环境缺乏，开发难度高，而各方面需求增长速度与日剧增，更新和升级的跟进是一个不小的挑战.此外，在同一系统采用多个开发商提供的构件，它 们之间的兼容性可能是开发过程中所要面对的一个严峻的问题 挑战和困难： （1）在同一系统采用多个开发商提供的构件，它们之间的兼容性可能是开发过程中所要面对的一个严峻的问题； （2）采用随处可以购买到的构件可能会使开发出来的软件产品丧失技术上的独创性和市场上的竞争力； （3）第三方的构件开发商可能歇业，这会使购买的构件失去维护服务。这些都是在购买第三方构件进行软件开发时无法回避的问题，因此需要对这些风险进行充分的估计。 5.简述3种应用最为广泛的构件技术规范COM、CORBA和EJB的各自特点。 CORBA的特点： （1）实现客户与服务对象的完全分开,客户不需要了解服务对象的实现过程以及具体位置。 （2）应用程序间的统一接口。
架构设计则为满足架构需求的质量属性寻找适当的战术。对如何实现特定的质量属性感兴趣。质量需求指定了软件的响应，以实现业务目标。我们感兴趣的是设计使用设计模式、架构模式或架构策略创建设计的“战术“。 是什么使一个设计具有了可移植性，一个设计具有了高性能，而另一个设计具备了可集成性？实现这些质量属性依赖于基本的设计策略。我们将对这些称之为“战术”的设计决策进行分析。战术就是影响质量属性响应控制的设计决策。战术集合称为“架构策略”。架构模式以某种方式将战术打包在一起。 系统设计是由决策集合组成。对设计师来说，每个战术都是一个设计选择。例如，其中一个战术引入了冗余，以提高系统的可用性。这是提高可用性的一个选择但是不是唯一选择。 我们将每个系统质量属性的战术组织为层次形式，但是每个层次只是为了说明一些战术，而且任何战术列表都肯定是不完成的。 1.可用性战术 恢复和修复是可用性的重要方面，为了阻止错误发展成故障，至少能够把错误限制在一定的范围内，从而使修复成为可能。维持可用性的所有方法包括某种类型的冗余，用来检测故障的某种类型的健康监视，以及当检测到故障时某种类型的恢复。有些情况下，监视或恢复是自动进行的，有时需要手动。 我们事项考虑错误检测，然后分析错误恢复，最后讨论错误预防。 1>错误检测 用于识别错误的3个战术是命令/响应、心跳和异常
⑴命令/响应。一个组件发出一个命令，并希望在预定义的时间内收到一个 来自审查组件的响应。可以把该战术用在共同负责某项任务的一组组件内。客户机也可以使用这种战术，以确保服务器对象和到服务器的通信路径在期望的性能边界内操作。可以用一种层级形式组织“命令/响应”错误探测器，其中最底层的探测器对与其共享一个处理器的软件进程发出命令，较高层的错误探测器对较低层的探测器发出命令。与所有进程发出命令的远程错误探测器相比，这种战术所使用的通信带宽更少。 ⑵心跳。一个组件定期发出一个心跳消息，另一个组件接收听该信息。如 果心跳失败，则假定最初的组件失败，并通知错误纠正组件。心跳还可以传递数据。例如，自动柜员机定期向服务器发送一次交易日志。该消息不仅起到心跳的作用，而且传送了要处理的数据。 ⑶异常。识别错误的一个方法就是遇到了异常。 命令/响应和心跳战术在不同的进程中操作，异常战术在一个进程中操作。 异常处理程序通常将错误在语义上转换为可以被处理的形式。 2>错误恢复 错误恢复由准备恢复和修复系统两部分组成。 ⑴表决。运行在冗余处理器上的每个进程都具有相同的输入，它们计算发 送给表决者的一个简单的输出值。如果表决者检测到单处理器的异常行为，那么就中止这一行为。表决算法可以是“多数规则”或“首选组件“或其他算法。该方法用于纠正算法的错误操作或者处理器的故障，通常用在控制系统。每个冗余组件的软件可以由不同的小组开发，并且在不同平台上执行。稍微好一点情况是在不同平台上开发一个软件组件，但是这
课程设计报告专业年级2014级软件工程2班课程名称软件设计与体系结构设计题目图书销售管理系统指导教师郑宇 学生姓名吴勇 学号20142205042026 设计成绩 教务处制 2017年06月12日
目录 1. 系统开发背景 (3) 1.1 概述系统 (3) 2需求分析 (3) 2.1可行性分析 (3) 2.2系统前台分析 (4) 2.3系统后台分析 (5) 2. 系统设计约束 (6) 2.1 系统运行环境 (6) 2.2 系统接口约束 (7) 2.3系统质量约束 (8) 2.4 系统隐含约束 (9) 3. 系统设计策略 (9) 3.1 系统关键技术 (9) 3.2 系统扩展策略 (10) 3.3 系统复用策略 (10) 4. 系统总体结构 (10) 4.1 系统逻辑设计 (12) 4.2 系统用户接口逻辑设计 (12) 4.3 系统物理设计 (12) 5. 结论 (13) 6参考文献 (16)
1. 系统开发背景 1.1 概述系统 经过图书销售管理系统的制作，可以实现对图书的在线查找，销售，以及在线管理等功能，此系统的优势在于系统简单却功能强大，,扩充能力好以及能够方便的跨地域操作等性能，能很好的搭建起用户和卖家之前的桥梁，操作简单。 本系统包括图书展示，新书发布，图书展示等一系列服务，同时提供图书推荐、图书分类、图书检索等便捷服务，方便用户寻找合适的图书。 本系统适用范围广，不管是个人还是企业都可以通过平台进行图书的销售与购买，通过合法验证后即可进行相干操作。 2需求分析 2.1可行性分析 1.要求 “中国图书销售信息系统”必须适应中国国情，符合国家各种政策法规，信息指标体系满足标准化要求。实现企业在互联网上对图书的销售。具体实现有：会员注册和登录、图书查询、网上发表评论、管理员维护功能加强。本软件在保证质量的前提下实现资金最小化投入。 2.目标 在先进的计算机技术支持下，运用所学的计算机软件开发知识以及企业开拓互联网图书市场的迫切需要所开发的图书销售信息系统，进行日常的图书销售管理，包括：1．便捷的购书流程 2. 方便的后台管理 3．人性化的操作界面
电子知识 软件架构(4) 1.分层架构：分层架构是使用最多的架构模式，通过分层使各个层的职责更加明确，通过定义的接口使各层之间通讯,上层使用下层提供的服务。分层分为：严格意义上的分层，一般意义的分层。严格意义的分层是n+1层使用n层的服务。而一般意义的分层是上层能够使用它下边所有层的服务。领域驱动设计的分层定义：UI层，UI控制层，服务层，领域层，基础设施层。 2.MVC架构：MVC架构相信做软件的都听说，主要是为了让软件的各部分松耦合，现在好多根据MVC思想构建的框架如：Spring MVC,Structs2,https://www.doczj.com/doc/4910895099.html, MVC等。MVC是Model View Control的简写，他的原理是什么那，比如拿web来举例吧。当一个web请求来了以后View接收这个请求，随即把请求转发给Control进行处理，Control通过分析请求的类型等信息决定加载哪些Model，当Model加载完成以后Control通知Model已经加载完毕，这是View就去读取Model数据进行显示自己。MVC还有一个衍生架构叫MVP,因为MVC的View跟Control和Model都有耦合关系所以为了解除View和Model之间的关系，View不直接读取Model而是通过Control来转发View 需要的数据。还有一个衍生架构叫MVVP,就是增加了一个ViewControl的层，用来辅助视图的生成，这样View的功能更加简单只是用来显示不包含其它的功能，而且有了ViewControl 使多视图或替换视图很方便。MVP微软的WPF就是使用这种架构。 3.微内核架构：微内核架构就是做一个稳定通用的内核，也就是给软件设计一个强劲的心脏。如果需要更多功能通
软件系统的架构设计方案 架构的定义 定义架构的最短形式是：“架构是一种结构”，这是一种正确的理解，但世界还没太平。若做一个比喻，架构就像一个操作系统，不同的角度有不同的理解，不同的关切者有各自的着重点，多视点的不同理解都是架构需要的，也只有通过多视点来考察才能演化出一个有效的架构。 从静态的角度，架构要回答一个系统在技术上如何组织；从变化的角度，架构要回答如何支持系统不断产生的新功能、新变化以及适时的重构；从服务质量的角度，架构要平衡各种和用户体验有关的指标；从运维的角度，架构要回答如何充分利用计算机或网络资源及其扩展策略；从经济的角度，架构要回答如何在可行的基础上降低实现成本等等 软件系统架构(Software Architecture)是关于软件系统的结构、行为、属性、组成要素及其之间交互关系的高级抽象。任何软件开发项目，都会经历需求获取、系统分析、系统设计、编码研发、系统运维等常规阶段，软件系统架构设计就位于系统分析和系统设计之间。做好软件系统架构，可以为软件系统提供稳定可靠的体系结构支撑平台，还可以支持最大粒度的软件复用，降低开发运维成本。如何做好软件系统的架构设计呢？ 软件系统架构设计方法步骤 基于体系架构的软件设计模型把软件过程划分为体系架构需求、设计、文档化、复审、实现和演化6个子过程，现逐一简要概述如下。 体系架构需求：即将用户对软件系统功能、性能、界面、设计约束等方面的期望（即“需求”）进行获取、分析、加工，并将每一个需求项目抽象定义为构件(类的集合)。
体系架构设计：即采用迭代的方法首先选择一个合适的软件体系架构风格(如C/S、B/S、N层、管道过滤器风格、C2风格等)作为架构模型，然后将需求阶段标识的构件映射到模型中，分析构件间的相互作用关系，最后形成量身订做的软件体系架构。 体系架构文档化：即生成用户和研发人员能够阅读的体系架构规格说明书和体系架构设计说明书。 体系架构复审：即及早发现体系架构设计中存在的缺陷和错误，及时予以标记和排除。 体系架构实现：即设计人员开发出系统构件，按照体系架构设计规格说明书进行构件的关联、合成、组装和测试。 体系架构演化：如果用户需求发生了变化，则需相应地修改完善优化、调整软件体系结构，以适应新的变化了的软件需求。 以上6个子过程是软件系统架构设计的通用方法步骤。但由于软件需求、现实情况的变化是难以预测的，这6个子过程往往是螺旋式向前推进。 软件系统架构设计常用模式 目前软件领域广泛使用的软件系统架构模式，主要有层次化架构设计、企业集成架构设计、嵌入式架构设计和面向服务的架构设计模式。 层次化架构设计模式：分层设计是一种最为常见的架构设计方案，能有效地使系统结构清晰、设计简化。MVC模式是当今最为流行的多层设计模式。该模式把一个应用的输入、处理、输出流程进行分离并抽象为控制器(Controller)、模型(Model)、视图(View)三个模块，实现了业务逻辑层、数据库访问层和用户界面层