（计算机应用技术专业论文）面向企业质检领域的可适应性软件建模.pdf

摘要 软件体系结构作为描述系统高层设计和实现更广范围内软件重用的手段，其重要性 远远超过了特定算法和数据结构的选择与设计，并己成为软件工程领域研究的一个热 点。其中，研究特定领域体系结构是软件体系结构的最新研究领域之一。 企业质检领域的质量检验数据管理是比较复杂的一部分：品种繁多，数据量大，而 且业务经常发生变化。为克服需求动态变化而造成的不稳定状态，提高软件质量和柔性， 企业质检领域的软件体系结构必须具有较强的可适应性。 论文首先系统地阐述了软件体系结构的定义、起源、研究内容和意义，并对特定领 域的软件体系结构( d s s a ) 进行了讨论，阐明了研究d s s a 的现实意义。然后简要介绍 一些主要的可适应性思想和方法及建模技术。之后在这些理论的基础上提出了一个基于 企业质检领域软件体系结构的可适应性软件模型o d m s l 。0 。最后结合一个应用实例 陕西秦岭水泥股份有限公司质检中心系统对模型做了进一步的阐述。 q d m s l 0 模型具有很强的软件可适应性，可广泛用于包括水泥、化工、食品等行业 的质量数据管理领域的建模和实现，实现该领域内软件体系结构的复用。 关键词：软件体系结构：d s s a ：可适应性：o d n 8 a b s t r a c t n o w a d a y s s o f t w a r ea r c h i t e c t u r eh a sb e c o m eo n eo ft h eh o t s p o t si ns o f t w a r ee n g i n e e r i n g f i e l d a sam e a n so fr e p r e s e n t i n gt h es y s t e md e s i g na tah i g hl e v e lo fa b s t r a c t i o na n d i m p l e m e n t i n gt h es o f t w a r er e u s ei naw i d e ra r e a , s o f t w a r ea r c h i t e c t u r eb e c o m e s am u c hm o r e s i g n i f i c a n ti s s u et h a nt h ec h o i c ea n dd e s i g no fs p e c i f i ca l g o r i t h m sa n dd a t as t r u c t u r e s ，o f w h i c h d o m a i n s p e c i f i cs o f t w a r ea r c h i t e c t u r e ( d s s a ) i so n e & t h e n e w e s tr e s e a r c hf i e l d s q u a l i t yd a t am a n a g e m e n ti ne n t e r p r i s em a n u f a c t u r ei s ac o m p l e xp r o b l e m ：t o om a n y c a t e g o r i e s ，t o om u c h d a t aa n d c h a n g e sh a p p e n t o oo f t e n i no r d e rt oc o n q u e ri t si n s t a b i l i t yd u e t oe n v i r o n m e n ta n dt h ed e m a n do f e n t e r p r i s e sa n de n h a n c ei t sf l e x i b i l i t ya n d q u a l i t y , s o f t - w a r e a r c h i t e c t u r ei nt h ef i e l do fe n t e r p r i s e q u a l i t yd a t am a n a g e m e n ti sr e q u i r e dt o o w ns t r o n g e n o u g ha d a p t a b i l i t y t h i sp a p e rf i r s tp r e s e n t st h ed e f i n i t i o n s ，o r i g i n ，r e s e a r c hd i r e c t i o n sa n di m p o r t a n c eo f s o f t w a r ea r c h i t e c t u r ea n dt h e nt h e s eo fd s s a i ta l s oi n t r o d u c e ss o m ea d a p t i v ei d e a sa n d m e t h o d s o nt h eb a s i so fa b o v et h e o r i e s , t h i sp a p e rp r o v i d e sad s s a - b a s e da d a p t i v em o d e l q d m s l 0 a tl a s t ，i tf u r t h e re l u c i d a t e st h em o d e lt h r o u g ha na p p l i c a t i o n q u a l i t y m a n a g e m e n t c e n t e rs y s t e mo f q i n l i n gc e m e n tp l a n ti ns h a n x i q d m s i 0 h a ss t r o n gs o f t w a r ea d a p t a b i l i t ya n dc a nb ew i d e l yu s e di nt h em o d e l i n ga n d r e a l i z a t i o no fe n t e r p r i s e q u a l i t y d a t am a n a g e m e n ts y s t e m si ns u c hi n d u s t r i e sa sc e m e n t ， c h e m i c a l ，f o o d ，e t c ，i m p l e m e n t i n g t h er e u s eo fs o f t w a r ea r c h i t e c t u r ei nt h i sf i e l d k e y w o r d s ：s o f t w a r ea r o hit e c t ur e ，d s s a 。a d a p t a b iii t y q d m s 面向企业质检领域的可适应性软件建模 前言 软件设计与艺术设计有相似之处。如果设计者抛弃了成熟的思想、方法和原则，不 规范软件开发活动过程，那么整个系统设计是失败的，很容易导致混乱，甚至不符合基 本需求。实际上，软件在生命周期内还在不断地修改和演化，前期设计中的混乱会恶性 扩散，导致不可控制的灾难。 从6 0 年代的软件危机开始，至6 新世纪的前夜，不少思想和方法被研究人员们所注目， 如我们熟悉的软件工程，信息工程，软件复用，面向对象，软件体系结构，构件技术等 1 等。这些思想、方法和原则都随着新的应用环境而不断发展着。其中，软件体系结构是 当今软件工程的重要研究领域之一。d e w a y n ep e r r y 在2 0 0 0 年8 月北京举行的w c c 2 0 0 0 软件理论与应用技术专题研讨会上的专题报告中指出“1 ：“软件体系结构的核心问题和它 对软件工程的根本影响的源泉在于，它有助于把软件系统的基本结构特征与算法和数据 结构的设计划分开。我们把软件体系结构看作是制作和发展软件系统的第一重要因素， 软件体系结构使我们能更好地设计软件系统。” 另一方面，步入信息社会后，信息系统的建模和实现一直是软件工程研究和开发人 员不断探索的方向。企业信息系统的开发和应用仍然不尽人意。为克服因企业信息系统 开发环境和企业需求动态变化而造成的不稳定状态，提高软件质量和柔性，企业信息系 统的软件体系结构必须具有优秀的可适应性，以保护企业的投资并且为软件的后期维护 打下良好的基础。 我们在实施企业e r p 项目时，发现企业生产部门的原燃材料、半成品、产品的质量检 验数据的管理是比较复杂的一部分：品种繁多，数据量大，而且业务经常发生变化。为 解决这种动态需求变化，我们提出了一种基于特定领域企业质检领域的可适应性软 件体系结构模型q d m s i 0 ，并成功地应用在陕西秦岭水泥股份有限公司质检中心系统中。 q d m s i 0 通过抽取业务元数据，在运行时由用户进行配置，并与程序实现滞后绑定，从 而动态生成检验数据的管理界面。当业务发生变化时，可由展终用户自行配置适应，无 需修改源程序，具有很强韵业务可适应性，得到用户的充分肯定。 本篇论文结构如下； 本文共分五章，第一章中对软件体系结构的理论作以概述，并对特定领域的软件体 ” 系结构进行讨论；第二章中简要介绍一些主要的可适应性思想和方法及建模技术；在第 三章中提出一种面向企业质检领域的可适应性软件模型q d m s i 0 ；第四章结合一个应用 实例陕西秦岭水泥股份有限公司质检中心系统对q d m s i 0 做了进一步的阐述；第五 章总结全文并提出下一步的工作。 面向企业质检领域的可适应性软件建模 1 软件体系结构概述 从某种程度而言，软件设计和构造一个复杂的建筑结构有一定的相似之处，这就是 只有少数人能很好的完成它，并且随着项目所涉及的人员和内容的增多而使项目的成功 率降低。在整个设计过程中，选择一个比较好的整体结构和构造规则是一个设计成功的 关键。对于一些建筑结构如桥梁、房屋等，一些自然法则限定了设计者的选择范围，同 样也使设计者有了一定的规律可循。但是对于软件设计而言，这些规律和限制就要少得 多同时也灵活得多，这样就导致设计者难以把握。此外，为适应主观和客观环境的变化， 软件在它的生命周期中要经历多次修改变动，这是另一个导致软件设计复杂性增大的原 因。 随着软件系统大小和复杂性的增加，在软件设计过程中人们面临的问题不再是考虑 软件系统的功能问题，而是面临要解决更难处理的非功能性需求，如系统性能问题、可 适应性问题、可靠性问题、可复用性问题等等。特别从8 0 年代起，对软件系统的具有 挑战性的任务是要求软件系统能适应不断发生的变化。这里设计的已不仅仅是每个功能 模块的算法和数据结构的设计与实现，而是涉及系统的熬体性问题。要在系统设计的最 初阶段决策系统涉及的总原则和确定整个系统的总体框架，以指导系统设计的展开，保 证开发工作能达到项目的当前目标，并能在软件系统的整个生命周期中保持系统体系结 构可以很方便的进行维护和调整以适应所发生的变化。一个非常重要的概念一“软件系 统的体系结构”代表了这种系统的整体性问题。 1 1 什么是软件体系结构 那么，软件体系结构是什么呢? 软件体系结构是一个复杂软件系统的高层结构；它 高度抽象，超越了算法和数据结构；它的两个基本着眼点是系统结构和需求与实现之间 的交互；它是一个用于理解系统级目标的框架结构。对于如何定义软件体系结构，目前 还没有一个能够普遍接受的定义，不同的研究者和学术团体对它有各自不同的定义。比 较经典的定义有： d e w a y n ep e r r y 和a l e xw o l f 在1 9 9 2 年曾这样定义。1 ：软件体系结构是具有一定形 式的结构化元素( e l e m e n t s ) 。这一定义注重区分过程元素( p r o c e s s i n ge l e m e n t s ) 、 数据元索( d a t ae l e m e n t s ) 和连接元素( c o n n e c t i n ge l e m e n t s ) 。 m a r ys h a w 和d a v i dg a r l a n1 9 9 5 年提出软件体系结构是软件设计过程中的一个 层次，这个层次超越计算过程中的算法设计和数据结构设计。因此设计和说明总体系统 结构作为一个新问题被提出来。软件体系结构由4 个部分组成：构成系统的元件的描述， 元件之间的相互作用，指导元件组成的模式，以及这些模式的约束。 g a r l a n 和p e r r y 于1 9 9 5 年4 月作为客座编辑在i e e et r a n s a c t i o no ns o f t w a r e e n g i n e e r i n g 的软件体系结构专辑上发表的定义被公认为比较权威的定义：一个程序 或系统的构件的结构，构件之间的关系，以及开发全过程中决定设计和演化的基本原则 和指南。 面向对象方面的权威以及标准建模语言u m l ( u n i f i e dm o d e l i n gl a n g u a g e ) 的制定 者b o o c h ，r u m b a u l g h 和j a c o b s o n 于1 9 9 9 年提出了定义”1 ：软件体系结构是一系列重要 2 耍鱼垒些堡垒塑堡塑要望堡丝鏊壁堡堡 的设计决策：软件系统的组织，构成系统的结构化元件和这些元件接口的选择，以及元 件间协作的行为，将结构化和行为化的元件组成递增的更大子系统的过程和指导这种系 统组织的体系结构风格即元件及其之间的接口、协作和组成。该定义对于理解用扩 展u m l 表示软件体系结构有大的帮助。 通过研究上面的定义，我们可以将软件体系结构划分为三个基本的关键概念：构件、 连接件、配置。 1 ) 构件 构件( c o m p o n e n t s ) ，或者称为元件( e l e m e n t s ) ，是计算或数据存储的单位，就像 化学中的原子和分子。在软件体系结构中常见的构件有：层、过滤器、抽象数据类型a d t 、 客户、服务器等。它可以是简单型或复合型，例如一个系统本身就可以看成一个复合型 的构件。 2 ) 连接件 连接件( c o n n e c t o r s ) 是构件之间的交互及其控制这些交互的规则，就像化学中的 化学键。有的是简单交互，如过程调用、共享变量访问；有的是复杂的和语义丰富的交 互，如c s 协议、数据库访问协议。 3 ) 配置或约束拓扑结构 可以用一幅图来描述系统的软件体系结构。该图由构件和连接件连接而成，用来表 示配置或约束( c o n f i g u r a t i o n so rc o n s t r a i n s ) 。它以特定的拓扑结构反映了一个软 件体系结构的基本准则( r a t i o n a l e ) 。 图1 显示了个编译器的软件体系结构拓扑结构图，它具有管道过滤器风格。在 这种风格中，管道就是构件，过滤器就是连接件。 图1 ：软件体系结构的拓扑结构实例 f i g u r et ：a ne x a m p l eo fs o f t w a r ea r o h i t e o t u r e st o p o l o g y 但是，无论这些定义有何不同，都仅仅是从开发者的角度来观察问题，忽略了作为 软件生存周期组成部分的软件体系结构应该同时关注的其它重要方面。因为从不同的系 统开发阶段和不同的系统角色的角度出发，软件体系结构的表现、所关注的焦点以及角 色需求都是不同的。在表1 中列出了不同的角色所关注的闯题。 面向企业质检领域的可适应性软件建模 表1 ：系统不同角色关注的问题 t h ep r o bie m sc o n c e r n e db ydif f e r e n ts y s t e ms t a k e h oid e r s 角色 客户 最终使用者 体系结构设计师 开发者 维护人员 关注要点 时间和成本估计；可行性和风险管理；修正需求；跟踪进度 实现和需求的一致性i 用户界面；适应未来需求的变化；性能、 可靠性、操作性等 修正需求；平衡分析；体系结构的完整性和一致性 详细的设计细节；选择和组合构件的指南；和现有系统保持兼容 软件修改指南；体系结构演化指南；和现有系统保持兼容 因此，我们可以将上述四个定义理解成软件体系结构的经典定义，而它广义的定义 应该包括下面三个部分： 1 ) 软件和系统的构件( 元件) 、连接件和约束( 规则) 的集合； 2 ) 从系统不同的角度出发，各种角色( s t a k e h o l d e r ) 的需求的集合； 3 ) 用构件、连接件和约束描述一个系统，以及在实现这个系统时如何满足各种角色的 需求的规则( r a t i o n a l e ) 。 1 2 软件体系结构的发展 系统体系结构的发展与计算机的抽象水平的发展是同步的。为了更好地理解软件体 系结构，让我们先来看一下计算机科学中抽象技术的发展。 1 高级编程语言 当数字计算机在2 0 世纪6 0 年代出现的时候，软件是用机器语言编写的，出现的汇 编语言、助记符和宏替换可以说是最早的软件抽象技术。到了5 0 年代后期，高级语言 的出现和数据结构的使用使得编制复杂的软件成为可能。这些高级语言的编译器可以帮 助程序言发现程序中隐含的一些复杂错误，编译器的这些方便的特性也刺激了程序员使 用高级语言的热情。高级语言的发展促进了模块化等抽象技术的进一步发展。 2 数据结构与算法 数据结构与算法从程序中分离促进了程序设计工作的极大发展。人们在从事大部分 计算机应用时，不必时时都重新发明。而可以直接利用或改造那些经过充分分析的数据 结构和算法，从而大大加快了程序设计的发展。 3 结构化程序设计 进入6 0 年代，开发大型软件面临前所未有的困难。1 9 6 8 年，e d s g e rd i j k s t r a 提 出：建立一个成功的系统必须从软件的划分和结构入手，而不仅仅把它看成是一个单一 的程序。他首先提出了一种层次结构。在这个结构中，程序被划分到不同的层中，位于 某一层的程序只能和邻近的层中的程序进行通讯。d i j k s t r a 通过这种结构化程序设计方 法( s t r u c t u r a lp r o g r a m m i n g ) 将整个复杂系统完美得展现出来，同时降低了开发和维 护的难度。从那时起，软件设计从侧重于编码转向侧重于结构化设计。 4 软件结构 堕塑垒、业堕垒塑塑竺亘垩窒丝竺堡堡堡 从7 0 年代初开始，软件工程的思想和方法得到了广泛的应用，c a s e 日益兴盛，软 件复用思想日臻成熟。1 9 7 2 年，d a v i dp a r n a s 将d i j k s t r a 的结构化设计思想进一步发 展，提出了信息隐藏模块的思想，后来叉接连提出了软件结构( s o f t w a r es t r u c t u r e ) ( 1 9 7 4 ) 和程序族( 1 9 7 5 ) 。一个程序族是有实际意义的一族软件的集合，每个软件都 遵循结构化的设计思想。在程序族的基础上，人们又提出了“软件生产( 产品) 线” ( p r o d u c tl i n e ) 的理论。程序族使高层次的软件复用成为现实。 5 软件体系结构 随着软件系统变得更加复杂，软件设计的核心渐渐超越了传统的“算法+ 数据结构= 程序”的计算设计模式，取而代之的是系统的总体结构的设计和规范。p e r r y 和w o l f 在1 9 9 2 年发表的论文“f o u n d a t i o n sf o r t h es t u d yo f s o f t w a r ea r c h i t e c t u r e s 川”被认为奠定 了软件体系结构学科的基础。论文为软件体系结构给出了第一个正规的定义并以语言编 译器为例子阐述了顺序和并行两种体系结构。p e r r y 和w o l f 相信9 0 年代是研究软件体 系结构的时代0 3 。1 9 9 6 年，s h a w 和c a r l a n 的书s o f t w a r e a r c h i t e c t u r e ：p e r s p e c t i v e so n a n e m e r g i n gd i s c i p l i n e 。1 让人们对软件体系结构有了一个全面的认识，软件体系结构的研 究也迅速发展起来。 可以看到，软件体系结构是作为软件工程发展的一个阶段存在的。随着软件工程的 发展，提供给开发者的抽象程度将越来越高。 1 3 软件体系结构的作用 美国南加州大学( u s c ) 的b a r r yb o e h m 曾经说过；“一个软件系统的开发如果没有 体系结构及其基本准则，这个工程就不是一个完整的系统开发。描述一个软件体系结构 就可以用于系统开发和维护的全过程。” 软件体系结构在软件生存周期的各个阶段都起着重要的作用。 它可作为不同角色间通信的手段； - 它降低了设计决策的难度： - 它方便了系统的维护； - 它为系统提供了一个可移植( 复用) 的抽象模型。 1 3 1 软件体系结构可作为不同角色间通信的手段 在软件系统生存周期中有许多角色参与，包括客户、用户、项目经理、代码设计人 员、测试人员、系统维护人员等。他们分别关心软件体系结构的不同方面或者同一方面 的不同角度。例如，用户关心的是系统能否满足他们的需要并且是可靠的；客户关心的 是软件体系结构的实现能否控制在预算和时间安排之内；项目经理担心的问题是这个软 件体系结构能否很好地使整个项目小组的成员分工合理、互相独立等。体系结构为这种 复杂的大型软件系统的表示、交流提供了通用的语言，使不同的角色之间更好地相互理 解，朝着共同的目标前进。有了软件体系结构这种作为角色之闭通信的媒介，大家就可 咀通过各自关心的角度来获取相应的信息，据此进行软件开发。 1 3 2 软件体系结构代表了系统前期的设计决策成果 软件体系结构在软件的生存周期的最初产生，蕴含了系统前期的设计决策，并在很 s 堕塑垒兰竺壁垒塑苎塑旦重窒丝墼堡垄竖 大程度上决定了系统以后的总的开发方向，它在软件设计的实现开始后就难以改变甚至 无法改变，因而显得十分重要。开发一个大型的软件系统，如果缺乏软件体系结构的 导，建成后很难满足用户在性能上和行为上的设计要求，并且难以适应未来的变化。趋 可以通过下面的讨论详细说明。 软件体系结构为设计者提供了实现的约束( 规则) 一个体系结构定义了一套实现的约束。体系结构的实现就是将这些约束所代表的拱 策展示出来。体系结构是通过元件( 构件) 的连接表示的，实现就必须将这些构件变威 计算机实现的实体，同时还要展现出它们之间的交互方式。 - 软件体系结构描述了项目开发和维护的组织结构 软件体系结构不仅描述了待开发软件的结构，而且将这种结构划分作为团队开发时 任务分配的依据。这样开发出来的系统自然具有其软件体系结构所展示的特征。在软件 开发过程中，团队中的每个成员将它作为交流的语言；在软件部署之后，系统维护时它 又成为了系统升级和演化的依据。 软件体系结构能够影响系统的目标质量属性 系统能否达到预期的质量目标，很大程度上依赖于软件体系结构的设计好坏。有两 类质量属性；一类是通过软件运行及其效果的观察可以测量的，例如性能、安全性、可 靠性等；另一类是通过观察系统的运行不能够测量，但是在系统的开发和维护过程中能 够体现出来的，例如可适应性，重用( 复用) 性等。 当然，要保证系统的目标质量，仅仅有一个好的软件体系结构是不够的。因为质量 保证是在系统整个生存周期都要考虑的问题，而体系结构设计仅仅是这个生存周期的一 个阶段。同时，系统的生存周期服从螺旋形模型，是一个反复迭代的过程，体系结构的 设计要进行多次。 i 通过对体系结构的分析和评估可以对系统进行质量预测 可以说，软件体系结构不仅反映了人们希望的系统是什么样子，而且还允许人们通 过对它的分析和评估来考察这样的结构对系统的实现会发生什么事先没有预料到的事 情。这就意味着设计者可以在系统设计的前期就进行目标系统的质量预测。 一软件体系结构可以作为从总体上把握整个系统的基础 正是由于软件体系结构的高层次抽象，软件的结构以及系统的构件之间交互的高层 描述通常可以作为向项目组中的新成员进行总体介绍的工具，使他们迅速的把握整个系 统。 1 3 3 软件体系结构可以帮助进行系统维护 软件生存周期中有8 0 的成本花费在系统维护阶段脚，而在进行系统维护时有约4 7 的时间用于对原有系统的理解”，。当系统变动时，系统维护人员必须使其风险降到最低， 同时还要确定改动的顺序。谁先改动，谁后改动，这些都要根据系统软件的构件之间的 关联、依赖性、性能和行为来决定。建立一个体系结构级的系统框架可以使我们更加有 计划性地做出正确的判断。 1 3 4 软件体系结构可以作为一个可移植的抽象复用模型 软件复用是指重复使用“为了复用目的而设计的软件”的过程。软件复用是在软件 6 面向企业质检领域的可适应性软件建模 开发中避免重复劳动的解决方案，它充分利用过去应用系统开发中积累的知识和经验， 提高了软件生产的效率和质量。依据复用的对象，可以将软件复用分为产品复用和过程 复用”1 。产品复用指复用已有的软件构件，通过构件集成( 组装) 得到新系统。过程复 用指复用已有的软件开发过程。产品复用现在已经被广泛应用，产品复用的实质就是代 码复用或构件复用。而实际上，编码消费仅仅是一个项目时间和费用开销的1 0 - 1 5 ，更 多的花费是在规格说明、设计和文档上”1 。因此，将复用过程引入早期开发和维护活动， 实现过程复用，能够最大限度地发挥复用的作用，使在重用结构化的决策和系统组件的 同时还可以重用工作结构，评估体系，团队组织，测试计划，集成方案，文档和其它劳 动密集型资产。 体系结构级别的复用为建立具有相似需求的系统提供了一个高层的抽象模型，使过 程复用成为现实。当体系结构的决策用于多个系统的时候，它就实现了所谓的“可移植” 性。通过对软件体系结构的研究，有利于发现不同系统在较高级别上的共同特性。特别 重要的是，在基于复用的软件开发中，为复用而开发的软件体系结构可以作为一种大粒 度的、抽象级别较高的软件构件进行复用，而且软件体系结构为设计重用和在更高层次 上的构件的重用提供了必要的上下文( c o n t e x t ) ，对于成功的复用具有非常重要的意义。 产品线系统( p r o d u c tl i n es y s t e m ) 是美国卡内基一梅隆大学软件工程研究所 ( c m u s e i ) 提出的软件产品开发的组织方式。产品线集中体现了软件复用思想，尤其 是过程复用。产品线管理包含了在一个特定应用领域内一族软件产品的创建和演化，它 的核心是软件构件的重用，软件体系结构充当了用于装配系统的可重用软件构件 ( s o f t w a r ec o m p o n e n t ) 的集成机制。但是由于过程复用的复杂性，一般产品线系统都 是基于特定领域的。在特定领域内的软件构件的重用可以明显的降低系统开发成本。现 在对特定领域的软件体系结构( d s s a ) 的研究成为了一个热点，例如北京大学的青鸟生 产线( - t b 3 ) e l 。 总之，软件体系结构的研究提供一个用于记录产品族范围内可重用设计信息的结构 化存储体。在软件体系方面豹工作可以被看成是将产品族成员的公共信息代码化，以便 产品族的每个成员可以继承这种高层的设计决策而不必重新构建和描述。在软件体系结 构领域，所有的工作可以被看成是朝着建立一个基于体系结构原则的软件开发模板前 进。 1 4 软件体系结构的视角 对于同一座建筑，住户、建筑师、内部装修人员和电气工程师有各自从不同的视角。 这些视角反映了建筑物的不同方面，但它们彼此都有内在的联系，而且合起来形成了建 筑物的总体结构。通过前面对软件体系结构的定义，我们知道软件体系结构反映了系统 的总的结构，因此它和建筑物一样，存在不同的角度来反映系统的体系结构。 而且，当面对一个复杂的系统时，必须从多个角度来考虑问题。在处理体系结构时 我们通常只考虑系统功能方面的需求，而实际上除了功能需求，物理分布、过程通讯和 同步等等也必须在体系结构一级加以考虑。这些来自不同方面的需求就形成了软件体系 结构的不同视角。 每种不同的视角说明了系统中不同角色或参与者( s t a k e h o l d e r ) 各自所关注的焦 点。每个视角都可以看成是一幅软件蓝图，同时具有自己的标记方法，可以选择自己的 面向企业质检领域的可适应性软件建模 体系结构风格。 然而，所有视角并不是完全独立的，不同视角之间的元素在一定的规则下是相关联 的。 从1 9 9 0 年开始，r a t i o n a l 公司的p h i l i p p ek r u c h t e n 对软件体系结构的不同视角 进行了专门的研究，并于1 9 9 5 年在i e e e 上提出了“体系结构的4 + i 视角模型”( t h e4 + 1 v i e w m o d e lo f a r c h i t e c t u r e ) “”。它们是逻辑视角、进程视角、物理视角、开发视角， 另外加上场景。4 + 1 视角模型为理解复杂系统的软件体系结构提供了一个简单和易于理 解的方式。它从5 个不同的角度来描述软件。每个角度都显示了模型系统的一个具体方 面。 下面依据目前广泛采用的k r u c h t e n 的4 + 1 视角模型对软件体系结构的视角加以说 明。 逻辑视角 逻辑视角，或称为概念视角，主要是用来支持对系统功能需求的抽象描述，也就是 系统所提供给终端用户的服务。它与问题域紧密相连，是系统工程师与领域专家之间有 效的交流媒介。逻辑视角强调问题空间各实体间的相互作用关系，一般采用面向对象技 术来表达。例如r a t i o n a l 的b o o c h 方法用类图和类模板来描述系统，主要的构件是类， 其风格为面向对象的风格。对于数据驱动的应用程序，可用非形式化的实体关系图来描 述。 开发视角 开发视角，或者说模块视角，是最常见的设计软件体系结构的角度。它侧重于实际 软件模块的组织。这种视角下的基本构成单位是模块，可以用模块和子系统图来描述开 发视角。 根据系统中模块的组织方式，开发视角可以采取不同的形式。开发人员可以按照项 目的开发和维护需要将模块组织成子系统的形式。例如，可以根据维护的需要按照信息 隐藏的标准来组织模块。另外一种形式则是按照设计的需要将模块组织成层次结构，相 邻层之间可以进行通信。层次系统的设计通常限制在4 至6 层之间。 大多数情况下。开发视角应同时考虑开发难度、软件管理、重用性和普遍性，以及 由工具集、编程语言带来的限制等相关的内部需求。开发视角是各种活动的基础，如需 求分配、团队工作分工、费用评估和计划、项目进展监测、软件的重用性、安全性和移 植性等。它还是建立产品线的基础。 _ 进程视角 如果说开发视角是处理系统的静态方面，那么进程视角则侧重于系统的运行特征， 即系统的动态属性。进程视角，又称协作视角，主要考虑一些非功能性的需求，如性能 和有效性。它主要解决系统的并发和分布，以及系统的完整性和容错能力，同时也定义 在逻辑视角中的各个类的操作如何分布到不同的控制之中。 进程视角中的结构化构件是进程。进程是一组形成可执行单元的任务，是具有自己 线程控制的指令序列。在系统运行期间，进程可以启动、关闭、恢复和重新配置等等， 必要时可以和其它进程保持通讯和同步。 这个视角可以用于评测系统的性能和基于进程问通信模式下的运行时调度。 面向企业质检领域的可适应性软件建模 _ ，_ _ - _ _ _ h _ _ _ _ _ - - - _ _ 一一 一物理视角 物理视角描述如何将软件映射到硬件上，通常要考虑系统的性能、规模和容错性等。 当软件运行在不同的结点上时，各角度中的构件都直接或间接地对应于系统的不同结点 之上。因此，从软件到结点的映射要有较高的灵活性同时这种映射关系直接影响系统 的性能。 一场景 上述四种视角从不同的侧面反映了系统的体系结构。逻辑视角和开发视角表示了静 态系统结构，而进程视角和物理视角描述了动态的或者运行时的系统结构。对于逻辑视 角和开发视角的区别目前仍然是争议的对象“”。对于不同类型的系统，软件体系结构模 型侧重的角度也不同。例如，对于管理信息系统，更侧重于逻辑和开发视角，而实时系 统则关注于进程和物理视角。 虽然四种视角相对独立，但是根据一定规则可以实现从一种视角到另一种视角的转 换，不同视角下的元素能够实现“连接”。图2 显示了4 + 1 视角模型中各种视角的含义 及其之间的联系。 最终用户程序员 系统集成人员系统工程师 图2 ：4 + 1 视角模型 f i g u r e2 ：t h e4 + 1 v i c wn o d e lo fa r c h i t e c t u r e 由图2 可见，最终用户关心的是逻辑视角，主要是功能方面的描述；程序员则从开 发视角出发，关心的是软件管理；系统集成人员往往从进程视角出发，关注体系结构的 性能、规模和容量等；系统工程师则从体系结构的物理角度出发，考虑系统的拓扑结构、 分发、安装以及远程通信。当然，我们并不要求所有的体系结构都要有上面四种视角。 通过图2 ，还可以看到。为了将前面四种视角联系起来，增加了一个场景视角。四 种视角的元素通过一些重要场景更普遍的用例( u s ec a s e $ ) 的实例来无缝地 ( s e a m l e s s l y ) 协同工作。场景的实质是描述系统功能的脚本。从某种意义上说场景是最 重要的系统需求抽象。在开发体系结构时它可以帮助设计者找到体系结构的构件及这 些构件之间的相互作用关系；在体系结构设计完成后可以起一个说明作用，同时作为体 系结构原型测试的出发点。基于4 + 1 视角模型的软件体系结构的开发被u s c 称为“场景 ( 脚本) 驱动的迭代体系结构设计方法”。场景可以用文本表示，也可以用图形来表示。 1 5 基于软件体系结构开发过程 在1 3 节详细分析了软件体系结构在系统生存周期全过程的重要性。也正是因为如 此，在开发复杂的系统( 如产品线系统) 时，基于软件体系结构的开发方式成为了必然 面向企业质检领域的可适应性软件建模 的选择。 为了使软件体系结构的各个研究方面和内容有机地结合，必须给出一个基于软件体 系结构的开发过程模型，如图3 所示。 图3 ；基于软件体系结构的开发过程 f i g u r e3 ：d e v ej o p m e n tp r o c e s sb a s e do ns o f t w a r ea r c h i t e c t u r e 必须指出的是，开发一个大型软件系统是不可能一蹴而就的，它往往是图3 中各个 阶段不断反复的迭代过程，构成一个螺旋型模型。 1 6 研究特定领域的软件体系结构的意义 在特定领域下的软件复用更容易获得成功 一方面，由于软件体系结构是一个高层的、超越算法与数据结构的抽象模型，因而 寄希望基于这样一个通用框架开发出一个实际的系统是不现实的，很可能既人为地增加 了开发的复杂性，又使体系结构过于抽象；另一方面，如果我们将注意力放在具有许多 相同属性的一类特定领域的系统上，就可以既降低体系结构框架的复杂性，使之更具有 实用性，又可以更好地使这个框架用于该领域内的其它系统之中，实现过程复用。 在特定领域下的软件开发更具备可行性 软件开发的方式经历了三个发展阶段，如图4 所示。 堕塑垒些堡垒塑塑堕要垩查丝鏊! 垄塑一一 图4 ：软件开发方式的演变 f i g u r e4 ：e v o l v e m e n to fs o f t w a r ed e v e l o p m e n t 传统的软件开发：就是简单地寻求一个从问题空间直接到解决方案空间的映射 的过程。它直接面向的是算法和数据结构。 基于软件体系结构的系统开发：实际上是从系统解决方案空间中分离出一个描 述系统框架结构的抽象层。通过抽象层，间接地将问题空间映射到解决方案空间。但是， 这仅仅是一个理论上的期望值。由于问题空间的复杂性，抽象的复杂性和实现的复杂性， 它并不具备可操作性。 基于特定领域的软件体系结构的开发方法：如果我们将考虑问题的出发点降低 些。首先将问题空间划分为不同的领域( d o m a i n ) ，然后通过基于特定领域的软件体 系结构的开发方法实现在这个领域的解决方案。国内外的学者纷纷提出自己的这方面的 研究成果n 2 州，实践也已经证明这种方法的可行性“”1 。 1 7 什么是特定领域的软件体系结构 1 7 1 特定领域的软件体系结构的定义 l o c k h e e dm a r t i n 公司的w i l lt r a c z 对特定领域的软件体系结构做的经典定义m 3 是： “特定领域的软件体系结构( d o m a i n s p e c i f i cs o f t w a r ea r c h i t e c t u r e ，简称d s s a ) 是一系列用于特定类型任务( 领域) 的、可以在整个领域被多次复用的软件构件的集合， 它们通过标准的结构( 拓扑结构) 组合起来共同构建一个成功的应用。” 实际上，d s s a 不仅是软件构件的集合，而且还包括了工作结构、评估体系、团队组 织、测试计划、集成方案、文档和其它劳动密集型资产，这些都是可以用于软件复用的。 1 7 2o s s a 的组成 d s s a 由领域模型、参考需求、参考体系结构3 个主要信息元素以及框架环境支持 工具、抽取和评估工具组成( 参见图5 ) 。其中： 领域模型是对一个领域内部实体和流程的描述，是一个问题空间内的模型。领域模 1 1 面向企业质检顿域的可适应性软件建模 型包含客户需求说明、场景、领域字典、上下文图、实体关系图、叛磊磊面砺磊鬲顶 图、对象模型等8 个部分。 参考需求用于整个领域，它包含问题空间的定义属性( 功能需求) 和解决方案空间 的限制属性或约束( 非功能需求、设计需求、实现需求) 两部分。 参考体系结构是对一个领域内所有系统的标准的、通用的描述。参考体系结构建立 在参考需求的基础之上，具有可复用性、可扩展性和可修改性的特点。领域内应用系统 的软件体系结构是它的一个实例。 此外，每种信息元素都有自己的支持工具。 。，基三d 8 登箜软件开发过程分为两个步骤；d s s a 本身的建立和基于d s s a 的应用开发。 苎! ，一篓二食步骤的核心是建模，即建立一个在领域内可复用的体系结构模型；第三不 誉竺萎壁对实际系统的开发过程，它直接利用已有的d s s a 模型。基于d s s a 的蔽祥开袅 垄惹垄塑( c o n c u r r e n t ) 、递归的( r e c u r s i v e ) 、反复的( i t e r a t i v e ) 过程：墓二芩蕞 旋型模型( s p i r a lm o d e l ) 。 一“ ，妾堡旦d s s a 方法进行应用开发之前，必须先构建好d s s a 本身，即建立组成d s s a 墼孽喜元量，包括警警篓型堂参考体系结构，并进行参考需求的分析。同时还要构造支 持工具、建立d s s a 的支撑环境。它们是基于d s s a 的应用开发的前提。 。一、 面向企业质检领域的可适应性软件建模 1 8 1 1 领域分析 建立领域模型的过程称为领域分析。领域分析的工作主要是在一个特定的问题空间 内，在系列相似的系统中定义、捕捉和组织对象及其操作，并使用标准的语法对它们 进行描述，使它们在创建新系统时可以复用。 建立领域模型的基本信息来源( 输入) 是客户需求说明和场景循设方案。客户 需求说明和场景都是非正式的用户需求，它们都只针对闯题空间，从总体上描述了某个 领域内需要解决的问题。即划分了领域的边界。 领域模型的表示( 输出) 是一系列的领域字典、上下文图、e - r 图、数据流图、状 态转换图等。建立状态转换模型后，领域分析师应该返回到领域字典的建立步骤，扩充 字典表，并重新建立e r 图、数据流模型和状态转换图。最后，作为领域分析的结束， 建立对象模型。 可见，领域分析是一个螺旋上升过程。 1 8 1 2 参考需求分析 参考需求是作用于整个领域的需求，具有普遍性和共性。参考需求分析主要集中于： _ 非功能需求分析，如安全性、容错性、响应时间等； 。 _ 设计需求，即设计决策，主要是软件体系结构的风格的选择，由此风格引出的构件 接口的风格和主用户界面风格，以及在此风格下的性能和成本的评估； - 实现需求，即实现决策，如编程语言、开发平台、硬件设旅、运行平台等。 参考需求分析也遵循螺旋型模型。 1 8 1 3 参考体系结构设计 参考体系结构是针对一个领域的体系结构，具有普遍性，主要用于进行体系结构复 用。参考体系结构的设计是个不断分解的过程。它和本章中讨论的软件体系结构设计 遵循同样的设计方法。 参考体系结构的设计过程也是一个螺旋型上升的过程。 1 8 2 基于d s s a 的应用开发 我们通常所说的基于d s s a 的应用开发是指在d s s a 开发环境下进行的应用系统的开 发。一个应用系统是特定领域内的系统的实例。 基于d s s a 的应用开发步骤及其相关的支持工具如图6 所示。 面向企业质检领域的可适应性软件建模 图6 ；基于d s s a 的应用开发过程 f i g u r e6 ：d e v ej o p i n gp r o o e s sb a s e do nd s s a 从图6 可以看出，基于d s s a 的应用开发过程分为两步；应用需求分析和应用设计 与开发。可以根据系统不同角色的观点，来描述基于d s s a 的应用开发环境，如图7 所 示，它是一个三层视图。 囤7 ；三层d s s a 开发环境 f i g u r e7 1 t h r e e l a y e rd a v e i o d i n ge n v ir o n m e n to fd s s 1 4 面向企业质检领域的可适应性软件建模 综上所述，软