(计算机系统结构专业论文)基于配置的表示层统一设计框架的研究与实现.pdf_第1页
(计算机系统结构专业论文)基于配置的表示层统一设计框架的研究与实现.pdf_第2页
(计算机系统结构专业论文)基于配置的表示层统一设计框架的研究与实现.pdf_第3页
(计算机系统结构专业论文)基于配置的表示层统一设计框架的研究与实现.pdf_第4页
(计算机系统结构专业论文)基于配置的表示层统一设计框架的研究与实现.pdf_第5页
已阅读5页,还剩51页未读 继续免费阅读

(计算机系统结构专业论文)基于配置的表示层统一设计框架的研究与实现.pdf.pdf 免费下载

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

摘要 随着当前企业应用的快速发展,对软件的需求越来越高。在企业应用软件开 发中,用户界面的开发占有的工作量很大。提高用户界面的开发效率无疑是提高 整个软件开发效率的有效手段。 用户界面开发研究主要集中在用户界面自动生成工具的开发和基于模型的 界面自动生成技术的研究上。当前的一些模型和工具在一定程度上促进了用户界 面工程理论和实践的发展。但很多模型和工具是用于直接描述用户界面,即是一 种用户界面的编码手段,缺乏从抽象界面描述到具体界面实现的转化支持。它们 仅是针对界面设计界面,没有将界面的设计开发融入到软件开发的整体架构中 去,无法支持软件开发的全过程。 本文将用户界面的自动生成技术融入到软件开发的整体架构中去,结合统一 数据模型和统一界面控制器技术实现表示层的统一框架。框架是近几年出现的软 件重用的方法,它与构件、设计模式在软件重用的思想上一脉相承,提倡在设计 和分析层面上的重用。 界面自动生成采用自适应模板技术,将用户界面划分为不同的功能区域,每 个功能区域由一个自适应模板来实现和管理。 统一界面控制器从整体的角度对界面控制管理,包括界面生命周期管理、界 面流管理及事件处理。它作为表示层的主控制部件与应用层的业务处理器直接对 话,是表示层与应用逻辑连接的桥梁。 统一数据模型是数据的抽象表示。它摈弃传统的面向对象的设计思想,将对 象的属性以及属性的数据操作特性抽象抽取出来,作为数据的一种抽象表示方 式,可以代表所有的数据对象。 本文介绍了框架的设计和实现,并给出一个简单的应用实例。 关键词框架;自适应模板:元数据;统一数据模型;统一界面控制器 a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to fe n t e r p r i s ea p p l i c a t i o n s , t h es o f t w a r eb e c o m e s m o r ed e m a n d i n g i ne n t e r p r i s ea p p l i c a t i o ns o f t w a r ed e v e l o p m e n t , t h eu s e ri n t e r f a c e d e v e l o p m e n th a sah u g ew o r k l o a d u n d o u b t e d l y ,i m p r o v et h ee f f i c i e n c yo ft h e d e v e l o p m e n to fi i s e q r i n t e r f a c ei sa l le f f e c t i v ew a yo fi m p r o v i n gt h ee f f i c i e n c yo f s o f t w a r ed e v e l o p m e n t n o w :t h er e s e a r c ha n dd e v e l o p m e n to fu s e ri n t e r f a c ei sf o c u s e do nt h e d e v e l o p m e n to ft o o l sf o rg e n e r a t i n gu s e ri n t e r f a c ea u t o m a t i c a l l ya n dt h er e s e a r c ho f m o d e l b a s e du s e i i n t e r f a c ea u t o g e n e r a t i o n t h e s et o o l sa n dm o d e l si n c r e a s e dt h e d e v e l o p m e n to fb s e ri n t e r f a c eb o t hi nt h e o r ya n dp r a c t i c e b u ts o m em o d e l sa n d t o o l si so n l yu s e dt od e s c r i b et h el l s e ri n t e r f a c e t h e ya r ej u s tw a y so fc o d i n gu s e r i n t e r f a c e t h e y d on o tp u tt h ed e v e l o p m e n to fu s e ri n t e r f a c ei n t ot h ee n t i r e a r c h i t e c t u r eo ft h es o f t w a r ed e v e l o p m e n t ,u n a b l et os u p p o r tt h ee n t i r es o f t w a r e d e v e l o p m e n tp r o c e s s t h i sp a p e rr e a l i z e dap r e s e n t a t i o nl a y e rf r a m e w o r k i ti n t e g r a t e st h et e c h n o l o g y o fu s e ri n t e r f a c ea u t o - g e n e r a t i o ni n t ot h ee n t i r ea r c h i t e c t u r eo fs o f t w a r ed e v e l o p m e n t a n di tp r o p o s e su n i f o r n li n t e r f a c ec o n t r o l l e ra n du n i f o r i l ld a t am o d e lf o rm a n a 百n g t h eu s e ri n t e r f a e ea n di t sd a t ai nau n i f o i t nw a y f r a m e w o r ki sah o tt o p i ci ns o f t w a r e e n g i n e e r i n gf i e l d i t sd e v e l o p e db a s e do nt h es a m et h o u g h t so fs o f t w a r er e u s ea s c o m p o n e n t sa n dd e s i g np a t t e r n s t h ea p p r o a c ho fu s e ri n t e r f a c e a u t o g e n e r a t i o n r i s e st h e t e c h n i q u e o f s e l f - a d a p t i n gt e m p l a t e , p a r t i t i o n st h eu s e ri n t e r f a c ei n t os e v e r a ld i f f e r e n tf u n c t i o n a r e a s ,e a c ha r e ai sr e a l i z e da n dm a n a g e db ya s e l f - a d a p t i n gt e m p l a t e u n i f o r mi n t e r f a c ec o n t r o l l e rm a n a g e sd i f f e r e n ti n t e r f a c e si nt h es a m ew a y i t m a n a g e st h el i f ec y c l eo f t h ei n t e r f a c ea n dt h ee v e n ti nt h ei n t e r f a c e i tl i k e sab r i d g e b e t w e e np r e s e n t a t i o nl a y e ra n dd o m a i nl o g i cl a y e r , a st h em a i nc o n t r o lc o m p o n e n t s o f t h ep r e s e n t a t i o nl a y e rc o n t a c tw i t lt h eb u s i n e s sa p p l i c a t i o np r o c e s s o rd i r e c t l y u n i f o r md a t am o d e li st h ea b s t r a c tp r e s e n t a t i o no fd a t ai ti sd i f f e r e n tw i t ht h e t r a d i t i o n a lo b j e c t o r i e n t e dd e s i g r u n g ,t a k i n gt h ea t t r i b u t eo ft h eo b j e c t sa n di t s o p e r a t i n gc h a r a c t e r i s t i c st o g e t h e r i tc a nr e p r e s e n te v e r yd a t ao b j e c t t h i sp a p e ri n t r o d u c e st h ed e s i g na n dr e a l i z a t i o no ft h ef r a m e w o r k ,a n dg i v e sa s i m p l ee x a m p l ew i mi t su s e k e y w o r d e : f r a m e w o r k :s ef - a d a p tn gt e m pia t e :m e t a d a t a :u nf o r md a t a m o d e i :u n i f o r mi n t e r f a o ec o n t r o i i e r i i 原创性声明和关于论文使用授权的说明 原创性声明 本人郑重声明:所呈交的学位论文,是本人在导师的指导下,独 立进行研究所取得的成果。除文中已经注明引用的内容外,本论文不 包含任何其他个人或集体己经发表或撰写过的科研成果。对本文的研 究做出重要贡献的个人和集体,均已在文中以明确方式标明。本声明 的法律责任由本人承担。 论文作者签名:皇f 麦日期:塑虹幺 关于学位论文使用授权的声明 本人完全了解山东大学有关保留、使用学位论文的规定,同意学 校保留或向国家有关部门或机构送交论文的复印件和电子版,允许论 文被查阅和借阅;本人授权山东大学可以将本学位论文的全部或部分 内容编入有关数据库进行检索,可以采用影印、缩印或其他复制手段 保存论文和汇编本学位论文。 ( 保密论文在解密后应遵守此规定) 论文作者签名: 导师躲出乱日期:弛绻 第1 章引言 软件技术的研究和发展经历了这样的过程:结构化编程,面向对象编程,面 向对象分析和设计,面向架构的分析和设计,面向模式的架构分析和设计。目前, 分层架构是被广泛接受认可并行之有效的一种架构思想,分层就是对系统进行分 而治之的管理。分层的优点在于每个层次功能明确,逻辑清晰,上层只需要了解 相邻的底层的细节,大大降低了层之间的耦合度。在这样的分布式分层应用系统 中,高层的策略不会因为底层细节的变化而受到影响。典型的三层结构为:表示 层( p r e s e n t a t i o nl a y e r ) 、领域逻辑层( d o m a i nl o g i cl a y e r ) 、数据层( d a t as o u r c e l a y e r ) a 其中,表示层是软件的用户接口部分,目前主流的表现形式是图形化的用户 界面。对于用户来说,软件就是看的见的界耐”,表示层用户界面的重要性不言 而喻。软件的开发中,表示层工作量很大,特别是当今中间件,组件满天飞的时 代,功能代码的编写量越来越少,而界面开发在软件开发中所占的工作量越显的 大了。 为促进软件的开发效率,提高软件的开发质量,对表示层图形界面开发的研 究越来越受到人们的重视。由于图形用户界面自身的特性,现有的软件工程方法 缺少对用户界面设计描述的直接支持。使用u m l 语言描述用户界面时描述相 当复杂,制约了图形用户界面的开发效率和质量,使开发人员难以快速有效地进 行图形用户界面的设计和开发。为提高图形用户界面的开发效率和质量,许多界 面模型被提了出来。这些模型分为概念模型和陈述模型两类。概念模型主要有 p a c 模型、m v c 模型等,直接针对界面、描述简洁,但是无法支持全过程性开发。 陈述模型服务于基于模型的工具,种类较多,支持全过程开发,支持界面自动化 生成,描述能力强大,但是模型设计过程过于复杂,模型整合比较困难。此外还 有许多优秀的用户界面开发工具,如:图形用户界面生成器( g u ib u i l d e r ) ,用 户界面管理系统( u s e r i n t e r f a c e m a n a g e m e n ts y s t e m ,u i m s ) ,用户界面开发环境 ( u s e ri n t e r f a c ed e v e l o p m e n te n v i r o n m e n t s ,u i d e ) ,界面工具包( u s e ri n t e r f a c e t o o l k i t s ) ,界面开发工具( i n t e r f a c ed e v e l o p m e n tt o o l s ) 等。 以上这些界面模型和界面开发工具在一定程度上提高了界面的开发效率,促 进了界面自动生成技术的发展。但是它们仅仅是针对界面而设计界面,没有将界 面的开发融入到软件开发的整体架构中去,无法支持软件开发的全过程。为此, 本文将界面的生成和管理技术与数据处理技术相结合,研究实现表示层的统一框 架,并提出了基于自适应模板的界面自动生成技术和统一数据模型技术。 1 1 界面生成技术研究现状 由于用户界面在软件开发中的重要性,使得人们对它的研究产生了极大的兴 趣。目前,对于界面生成技术的研究主要集中在两个方面:用户界面自动生成工 具和基于模型的界面生成技术【2 3 1 。 优秀的用户界面生成工具有许多,如:m bu i d e s 、g e n e x u s 、v i s u a lc a s e 、 基于u m l 的r e t i o n a lr o s e 以及国内北大青鸟的c a s e 工具系列等h 。这些工 具都在一定程度上取得了很大的成功。正是因为这些成功为用户界面的研究带来 了希望。并且有的用户界面自动生成工具,如,m bu i d e s 中的m a s t e r m i n d 、 t e l l e a g h 、t r i d e n t 等还得到了广大用户的认可和好评【5 1 。但是这些自动生成工具 只支持规定的活动和用户界面同等重要的应用功能的交互。这也是它们所不能被 广泛应用的主要原因一通用性太差,专用性太强。交互式系统基于模型的开发方 法通过将用户界面分解成一些独立的模型组件强调地指出了这一缺陷。交互系统 中基于模型的方法是以一个普通的模型库系统的分析、设计和实施为基础的。它 不同于普通的软件工程方法,设计者可以创建含义和关联能够通过传递代码获得 的模拟组件。在基于模型的方法中,设计者创建严格的系统属性并且进行分析、 优化和合成这些模型从而得到运行系统。基于模型的用户设计器中的个模型就 是用户界面一些独立连接部分的陈述说明。通过将用户的精力集中到一个用户界 面的独立的方面上,这样一个模型就可以通过专业的符号体系来表示。这恰恰就 说明了使用基于模型的用户界面开发方法进行界面开发比其它的方法更加容易 而且易于维护】。 基于模型的用户界面开发方法是一种用高层次模型规范来自动生成用户界 面的方法。模型支持表示与应用的分离,比形式化方法3 】直观且易于理解,大大 提高了应用系统开发质量和开发效率。界面模型大致分为概念模型和陈述模型 【引。 概念模型典型的有s e e h e i m p l ,m v c t ”! p a c t “1 模型。s e e h e i m 模型是一种 基于语言的模型,基于词法、语法和语义划分的逻辑结构决定了它处理的对话交 互逻辑是线性的、可预见的,为其他的u i m s ( u s e ri n t e r f a c em a n a g e m e n ts y s t e m ) 模型奠定了理论基础。m v c 和p a c 模型属于多代理模型,其思想是把界面及 界面元素看作由应用部分、对话控制部分和表示部分组成,每一部分又是一个或 多个a g e n t ( 代理) 的集合体。概念模型着重描述了界面构成以及界面元素间的 逻辑控制关系,为抽象界面模型到实际界面的转换提供了良好的理论基础和体系 结构模型。 陈述模型通过任务模型( t a s k m o d e l ) 、用户模型( u s e r m o d e l ) 、领域模型 ( d o m a i nm o d e l ) 、对话模型( d i a l o gm o d e l ) 和表现模型( p r e s e n t a t i o nm o d e l ) 1 2 t 等不同抽象层次的陈述性模型来表达和把握界面的需求和构成,典型的有 h u m a n o i d t 切、m o b i d 【1 习等基于模型的用户界面设计环境。 以上这些模型和工具在用户界面描述或生成方面各有独特的见解,分别从不 同的角度体现了应用和表示分离的思想,极大的促进了用户界面工程理论和实践 的发展。但很多模型和工具是用于直接描述用户界面,即是一种用户界面的编码 手段,不支持从需求分析到模型设计直至编码的全过程,缺乏从抽象界面描述到 具体界面实现的转化支持,没有将界面的开发融入到软件开发的整体架构中去, 无法支持软件开发的全过程。 1 2 主要研究工作 在实际应用中,界面是复杂的、个性化的,而且它很可能会随着用户需求的 变化而变化。这就要求界面的设计过程要有很强的柔性,可以适合不同用户需求 的变化,满足软件设计的开放闭合原则【l ”;设计的系统要有较强的鲁棒性,尽量 减少变化所带来的扰动范围,使界面的变化对系统的影响尽可能的降低,以减少 开发成本。 为解决界面开发中的以上问题,本文从实际应用角度出发,研究从抽象界面 描述到具体界面的转化,提出了基于自适应模板的界面自动生成技术。它实现了 语义和表示的分离,能有效隔离界面变化对系统的扰动。同时,本文将此界面自 动生成技术与框架技术相结合,研究表示层统一设计框架的实现。 表示层是人机交互的接口。一个完整的表示层框架除了界面的展示功能还必 须提供交互功能,包括数据的输入输出和用户事件的传递功能。为此,本框架使 用了统一数据模型和统一界面控制器机制,实现对界面、界面所操纵的数据以及 事件流的统一管理。 1 3 本文结构 本文第一部分是引言,给出了课题提出的背景,介绍了界面生成技术的研究 现状和课题的主要研究工作。 第二部分介绍框架技术和设计模式,并详细介绍了基于自适应模板的界面自 动生成技术采用的m v c 模式。 第三部分是表示层框架的具体设计方案。 第四部分是界面自动生成技术的实现,统一数据模型和数据网关以及统一界 面控制器的实现。 第五部分给出一个简单的框架应用实例。 最后是总结和展望。 4 第2 章框架与设计模式 随着软件规模的不断扩大,软件开发与维护的成本也越来越高,软件复用技 术应运而生。软件复用是指重复使用“为了复用目的而设计的软件”【1 4 】的过程。根 据复用的粒度,软件复用可以分为低层复用和高层复用。低层复用只重用了部分 程序代码,而高层复用则重用了设计概念和大量的代码。随着面向对象技术的日 趋成熟,像类库和函数库这样低层次的复用己经不再适合于特定领域大型软件生 产的需求。为了最大限度的提高软件的复用性,不仅要重用代码而且要重用相似 的分析和体系结构。设计模式和面向对象框架的研究与开发也就应运而生了。 2 1 设计模式 设计模式( d e s i g np a t t e r n ) 简单的讲就是可以复用的设计范例a 是某种场景 下你可以套用的一种解决( 设计) 方案。可以说,在面向对象程序设计的演化过程 中,设计模式是最为重要的一步。它是一种可以解决特定类型问题的手法。 2 1 1 设计模式的定义 c h i r s t o p h e ra l e x a n d e r 认为每一个模式描述了一个在我们周围不断重复发生 的问题,以及该问题的解决方案的核心:这样你就能一次又一次地使用该方案而 不必做重复劳动o ”1 。尽管a l e x a n d e r 所指的是城市和建筑模式,但他的思想也 同样适用于面向对象设计模式。 d i r k r i e h l e 和h e i n z z 0 1 1 i l g h o v e n 认为,模式是一种在特定的、非任意的环 境中不断反复出现的具体形式的抽象n “。这种观点更具有通用性,它没有把模 式的概念限定在软件设计领域也没有限制模式的特殊使用方式。 e r i c hg a l l l m a 等“四人组”( g o f :g a n go f f o u r ) 把模式强调为设计模式,认 为设计模式是对那些被用来在特定场景下解决一般设计问题的类和相互通信的 对象的描趟”】。 2 1 2 设计模式的分类 设计模式这个术语通常用来指在软件架构、设计和实现方面的任何模式。很 多人根据这三种概念层次把设计模式分为架构模式( a r c h i t e c t u r a lp a t t e r n s ) 、设 计模式( d e s i g np a t t e r n s ) 和惯用法( i d i o m s ,有时也称为编码模式) 。在( ( p a t t e m o r i e n t e ds o f t w a r e a r c h i t e c t u r e ) ) 这本书中这三种类型的模式定义如下f 1 8 】: 架构模式:表达了软件系统的基本组织结构,它提供了一套预定义的子系统, 详细说明了它们的责任,包括了组织子系统间关系的规则和指导原则“。 设计模式:描述了解决特定背景下一般设计问题的通信构件的结构。 惯用法:针对编程语言的底层模式,描述了怎样用某种特定编程语言实现构 件的某些方面或构件间的关系。 这三种模式的区别在于它们处于不同的抽象层次。架构模式是高层的抽象, 关心的是大规模的构件或子系统,系统的全局特性和机制,影响一个软件系统的 所有核心结构和组织。设计模式具有中等规模的粒度,它充实了予系统的结构和 行为以及它们之间的关系,并不影响整个系统的结构,但是定义了子系统和构件 的微小架构。惯用法模式是特定的范例或特定的编程技术,完善了构件的结构或 行为的低层的内部或外部的细节。 d i 虫m e h l e 和h e i n zz t i t l i g h o v e n 对设计模式有类似的划分,但他们是从分 析、设计和实现这三个方面划分,分别为概念模式( c o n c e p t u a lp a t t e r n s ) 、设计 模式( d e s i g n p a t t e r n s ) 和编程模式( p r o g r a m m i n g p a t t e r n s ) 。 2 1 3 经典设计模式 e r i c hc r a m l n a 等“四人组”介绍了2 3 个经典的设计模式( 简称为g o f 模式) , 从另外两个角度来组织这些设计模式n 7 1 。第一是目的准则,即模式是用来完成什 么工作的。模式依据其目的可分为创建型( c r e a t i o n a l ) 、结构型( s t r u c t u r a l ) 和 行为型( b e h a v i o r a l ) 三种。创建型模式与对象的创建有关;结构型模式处理类 或对象的组合;行为型模式对类或对象怎样交互和怎样分配职责进行描述。第二 是范围准则,指定模式主要是用于类还是用于对象。类模式处理类和子类之间的 关系,这些关系通过继承建立,是静态的,在编译时刻便确定下来了。对象模式 处理对象间的关系,这些关系在运行时刻是可以变化的,更具动态性。具体如下 表所示。 的 刨建型结构型行为型 范目 类 f a c t o r ym e t h o d a d a p t e r ( 类) i n t e r p r e t e r 、t e m p l a t e m e t h o d 对象 a b s t r a c tf a c t o r y 、 a d a p t e r ( 对象) 、 c h a i no f r e s p o n s i b i l i t y 、 b u l l d e r , b r i d g e ,c o m p o s i t e , c o m m a n d ,i t e r a t o r , p r o t o t y p e 、d e c o r a t o r 、f a f a d e 、 m e d i a t o r 、m e m e n t o 、 s i n g l e t o nf l y w e i g h t 、p r o x y o b s e r v e rs t a t e 、s t r a t e g y 、 s i t e r w a l t e rz i m m e r 把这些设计模式划分为三个层次:基本设计模式和技术,如 a d a p t e r ,c o m p o s i t e ,p r o x y 等;解决典型问题的设计模式,如b r i d g e ,c o m m a n d , o b s e r v e r 等;应用域相关的设计模式,如i n t e r p r e t e r 。设计模式的层次化等于承 认了存在“特定领域”的设计模式,这和g a m m a 等人在创立设计模式时的思想有 一些出入,因为g a m m a 等人认为设计模式是应该充分通用的。实际上当前新 的模式主要是这种“特定领域”的设计模式。 2 1 4 表示层设计模式 表示层是连接客户端和业务层的桥梁。表示层请求处理机制可以接收许多不 同类型的请求,这些请求分别需要不同类型的处理。客户端通过表示层对业务层 的服务进行调用,业务层通过表示层将处理结果回送、展示给客户端。表示层的 设计中要优先考虑的问题是可扩展性问题。 j 2 e e 中典型的表示层设计模式如下表所示: 模式名简单描述 i m e r c e p t i n g f i l t e r ( 截取过滤器) 提供请求的预处理和后处理方案 f r o n tc o n t r o l l e r ( 前端控制器)提供请求处理的集中控制器 v i e wh e l p e r ( 视图助手) 将与表示层无关的逻辑封装到助手组件中 c o m p o s i t e v i e w ( 复合视图) 由原子的子组件创建复杂视图 s e r v i c et ow o d 【e r ( 工作者服务) 由分发者组件前端控制器视图助手模式组 合而成 d i s p a t c h e r v i e w ( 分发者视图)类似于工作者服务模式把许多动作推迟到 视图处理 2 1 5w c 设计模式 m v c ( m o d e l - v i e w - c o n t r o l l e r ) 2 0 ,2 1 ,2 2 】,模型一视图一控制器的设计模式是 x e r o xp 八r c 在八十年代为编程语言s m a l l t a l k 一8 0 ( s m a l l t a l k ,最早的一种面向对象 的编程语言,给开发者提供了一个快速开发面向对象系统的工具) 提出的一种设 计模式。m v c 模式并不是j 2 e e 行业人士标新立异的,但却在j 2 e e 平台上真正 的找到了它的价值。被推荐为s u n 公司j 2 e e 平台的设计模式,并且受到越来越 多的开发者的欢迎。 顾名思义,m v c 模式主要由3 个部分组成:模型( m o d e l ) ,视图( v i e w ) 和控 制器( c o n t r o l l e r ) ,它定义一个应用程序中三层之间的清晰分隔。m v c 的核心就 是要做到三级甚至多级的松散耦合。它把应用分成三部分,分别为模型、视图和 控制,并且尽量降低各部分间的藕合。每一部分处理特定的任务,并负责完成与 其它部分的通信。 其中,模型部分是应用程序的数据和业务规则的集合,通常称为应用程序的 业务逻辑,代表了商业数据和访问及修改数据的操作。当数据发生改变时,它要 负责通知视图部分,并且提供视图查询状态的能力,另外,它还向控制提供应用 功能。模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被 多个视图重用,所以减少了代码的重复性。 视图是对模型的展示。模型进行操作之后,其结果就是通过视图来显示的。 视图访问模型的数据,并且当模型的数据发生变化时更新模型的显示。视图还把 从用户那里得到的信息传给控制部分。m v c 能使应用程序处理很多不同的视图, 在视图中,其实没有真正的处理发生,只是作为一种输出数据并允许用户操作的 方式。 控制部分是定义应用程序对用户输入或模型层中的更改做出反应的方法,通 常称为应用程序逻辑。它分发用户请求和选择表现视图,还负责解释用户输入, 进而调用模型的功能。控制部分根据用户交互和模型的状态选择要显示的视图。 一个应用程序一般为相关的功能选择一个控制。一旦用户想对模型进行处理时, 它不能直接去执行模型,而是通过控制器来问接地实现。控制器能从视图中取值, 然后将相应的值传给模型进行处理。控制器接受用户的输入并调用模型和视图去 完成用户的需求。当用户通过视图发送请求时,它只是接收请求并决定调用哪个 模型组件去处理请求,然后确定用哪个视图来显示模型处理返回的数据。控制器 连接不同的模型和视图去完成用户的需求,给定一些可重用的模型和视图。控制 器可以根据用户的需求选择模型进行处理,然后选择视图将处理结果显示给用 户。 m v c 模式是一种架构模式,但它主要用来解决用户界面及界面上数据操作 之间的问题,因此也可以说它是表示层的设计模式。在应用系统开发的表示层设 计中应用非常广泛。 m v c 模式有很多的优点,但也有它的不足之处。m v c 的优点表现在以下几 个方面: ( 1 ) 可以为一个模型在运行时同时建立和使用多个视图。变化传播机制 可以确保所有相关的视图及时得到模型数据变化,从而使所有关联的视图和控制 器做到行为同步。 ( 2 ) 视图与控制器的可接插性,允许更换视图和控制器对象,而且可以根 据需求动态的打开或关闭、甚至在运行期间进行对象替换。此模式为其进一步 的专门化模式( 如p a g ec o n t r o l l e r ,页面控制器和f r o n tc o n t r o l l e r ,前端控制器) 奠定了基础 ( 3 ) 模型的可移植性。因为模型是独立于视图的,所以可以把一个模型独 立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修 改。 可以不夸张地说,自从有了m v c 结构,软件界面有了较为优化的设计理论。 m v c 的不足表现在以下几个方面: ( 1 ) 增加了系统结构和实现的复杂性。对于简单的界面,严格遵循m v c , 使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作, 降低运行效率。 ( 2 ) 视图与控制器间的过于紧密的连接。视图没有控制器的存在,其应用 是很有限的,反之亦然,这样就妨碍了他们的独立重用。 ( 3 ) 视图对模型数据的低效率访问。依据模型操作接口的不同,视图可能 需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也 将损害操作性能。 9 ( 4 ) 它还增加了用户界面代码的事件驱动特性,调试用户界面代码会变得 更加困难。 本文的表示层框架采用了m v c 模式的设计思想,同时又针对m v c 模式的 不足进行了改进,并以统一性为目标,设计出统一界面控制器和统一数据模型机 制。它们的使用,使得不同的视图对应统的数据模型,不同的视图采用同样的 管理方式,实现了表示层框架的统一性。 2 2 框架 框架是指一种可复用的部分实现的软件制品,它能够被组装或实例化扩展以 生成特定的应用。软件框架有利于实现领域内构架层次较大粒度的设计复用,以 提高应用开发中复用的比例,从而保证复用活动的成功率,降低应用开发的成本。 2 。2 。1 框架的定义 目前关于框架的定义较多,尚未形成一个完整而精确的定义。很多文献从不 同角度对框架做如下的一些定义: j o h n s o n 和f o o t e 早在2 0 世纪8 0 年代末对框架的定义是:框架是表现为解 决一类特定问题的抽象设计的一组类【”】。 f i r e s m i t h 对框架的定义田j :框架是由一些相互协作的类组成的一个集合, 它捕获了实现特定应用领域的公共需求和设计的主要机制和小尺度的模式。 e r i c hg a m m a 等人认为 1 7 , 2 4 1 :框架是构成一类特定软件可复用设计的一组相 互协作的类。框架规定了你的应用的体系结构。它定义了整体结构,类和对象的 分割,各部分的主要责任,类和对象怎么协作,以及控制流程。框架预定义了这 些设计参数,以便于应用设计者或实现者能集中精力于应用本身的特定细节。框 架记录了其应用领域的共同的设计决策,因而框架更强调设计复用,尽管框架常 包括具体的立即可用的子类。 北京大学杨芙清教授从构件的角度认为口1 :框架由一组互相协作的构件组 成,通过这些构件及其协作关系定义了应用系统的体系结构。这些成员构件通常 是子框架、类树或类,大多以抽象的形式出现,实现细节放在具体子类中,构成 了一个抽象设计,不同的具体子类可产生对设计的不同实现。框架作为构件使得 用户可以复用设计,用户通过具体子类的嵌入而在框架中加入特殊功能。 综合上述观点可以看出框架是一种软件重用技术,是一个应用软件系统的部 分或整体的可重用设计,具体表现为一组抽象类以及其实例( 对象) 之间的相互 作用方式。 2 2 2 框架的分类 框架具有领域性,根据所面向的问题领域不同,框架主要分为三类【2 6 1 :应用 框架( a p p l i c a t i o n f r a m e w o r k ) 、领域框架( d o m a i n f r a m e w o r k ) 、支持框架( s u p p o r t f r a m e w o r k ) 。 应用框架封装了各种专门的技术或功能并可应用于不同领域的应用开发。例 如e t + + 图形用户界面框架 2 7 1 ,还有大家熟悉的m f c ( m i c r o s o f tf o u n d a t i o n c l a s s e s ,微软基本类库) 以及i f c ( j a v a f o u n d a t i o nc l a s s e s ,j a v a 基本类库) , 其中j f c 是充分利用了面向对象技术进行设计开发的并且运用了各种面向对象 设计模式。 领域框架为某个特定问题域的实现提供了专门的解决方案和功能,如各种生 产控制系统框架、银行或报警系统框架、通信服务系统框架等等。很多领域应用 软件是为某个部门或厂家定制的,开发往往是从头开始,而领域框架的使用将最 大限度地复用已有的设计经验与解决方案,降低开发成本与开发时间,并且可以 提高系统的可靠性和可维护性等等。 支持框架提供一些与计算机底层相关的特殊服务,如内存与文件系统的管 理、设备驱动、分布式计算支持服务等。 这三类框架都可以为应用开发者提供相应的设计复用,减轻代码的编写与维 护工作。通常是开发某个特殊领域的面向对象框架,以致力于提高领域应用的开 发效率。 为了开发灵活的、可复用的软件系统,面向对象设计方法主要运用两种基本 的复用机制:继承( i n h e r i t a n c e ) 和组合( c o m p o s i t i o n ) 。根据框架实际应用中运 用这两种机制的差别,框架一般可分为以下三类:白盒( w h i t e b o x ) 框架、黑盒 ( b l a c k - b o x ) 框架和两者的混合框架。 白盒框架指的是主要通过类继承机制而应用于具体应用系统开发的那些框 架,也称为体系结构驱动框架。那些主要通过框架中已有对象或构件的配置组合 而应用于具体系统开发的框架则称为黑盒框架。白盒框架有较好的可扩展性与灵 活性,可以方便地改变被复用的实现,但是它破坏了封装性,使用困难,框架用 户必须知道框架的所有内部结构细节。黑盒框架使用简单,复用性好,易于实现 运行时刻的动态绑定,而框架用户只需了解框架的基本体系结构和热点,但是由 于它隐藏了内部细节,因而缺乏灵活性与可扩展性,并且这种框架的开发难度比 较大【2 s 】。因此,框架在大多数情况下是白盒框架和黑盒框架两者的一种混合形式, 同时提供类继承与对象组合这两种复用机制,以达到简单易使用、灵活可扩展的 目的。j i l l e sv a ng u r p 和j a nb o s c h 提出一种混合框架的概念结构,将框架中的元 素分为白盒框架元素与黑盒框架元素两类。白盒框架元素表示框架中的抽象部 分,包括各种接口与抽象类等元素:黑盒框架元素是各种继承于白盒框架中的元 素并提供实现的各种构件和类。 根据框架的使用范围框架可以分为系统结构框架( s y s t e mi n f r a s t r u c t u r e f r a m e w o r k s ) 、中间件集成框架( m i d d l e w a r ei n t e g r a t i o nf r a m e w o r k s ) 和企业应用 框架( e n t e r p r i s ea p p l i c a t i o nf r a m e w o r k s ) 。系统结构框架用于简化开发可移植的、 高效的系统体系结构,比如操作系统框架、通讯系统框架,以及用户界面设计框 架和语言处理工具等。中间件集成框架通常用来集成分布式应用程序和相关组 件。它们可以增强软件开发人员开发模块化、可重用软件的能力,并且将软件无 缝集成到分布式应用环境中。企业应用框架集中于广泛的企业应用领域,它们是 企业商务活动的基石,与前面两种框架不同,企业应用框架的开发和购买都比较 昂贵,但是它们能带来丰厚的投资回报,因为它们直接支持最终用户开发,相反 系统结构框架和中间件集成框架则主要集中在软件的内在开发。 本文所研究的框架,是一种轻量级的系统架构框架,针对企业应用软件开发 中表示层开发设计的复杂性问题,给出了较好的、统一的解决方案。它混合使用 了白盒框架和黑盒框架,同时又具有中间件集成框架的特性。 2 2 3 框架的优点 框架的开发可以给使用框架的开发人员提供四个方面的优点:模块性 ( m o d u l a r i t y ) 、可重用性( r e u s a b i l i t y ) 、扩展性( e x t e n s i b i l i t y ) 、和反向控制 ( i n v e r s i o no f c o n t r 0 1 ) 【”。 框架使用稳定的接口封装了具体的实现,从而增强了框架的模块性。框架使 用这种机制将具体实现的影响和改变局部化,从而提高了软件产品的质量。局部 化的好处在于减少了理解和维护具体实现的精力。 通过框架提供的稳定接口增强了软件产品的可重用性。当创建新的应用程序 时,可以重用框架中定义的通用组件。这些通用组件由具有丰富领域知识和程序 设计经验的程序员设计开发,它们满足一定应用领域的需求。使用通用组件避免 了软件产品中这些部分重新设计带来的风险。可重用框架组件的使用也相应提高 了程序员开发软件产品的效率,同时又保证了软件产品的质量、性能、可靠性和 互用性。 框架通过提供一种“钩子”方法提高它的扩展性,这些方法允许应用程序扩展 框架稳定的接口,它们将稳定的接口和特定应用中可变的行为分离开来。框架的 这种特性保证了能够方便地为新的应用提供新的服务和特性。 反向控制是框架运行时的一个特点。框架需要采用“注册通知叽制处理应用 程序流程,以满足框架能够处理领域中的所有应用的要求。首先,特定的应用应 当向它使用的框架注册需要框架处理的程序流程部分,随后,在特定的应用程序 运行后,某个已经注册了的程序流程运行条件满足时,框架使用它的派发机制通 知应用程序执行该程序流程。反向控制保证了应用开发的简单性和扩展性。特定 的应用只须关注于它需要实现的商业逻辑和触发商业逻辑运行条件的开发,而将 复杂的底层触发机制交给框架统一处理。 2 3 设计模式和框架的关系 软件框架是设计模式的特例化,它总是针对一个特定的应用领域。软件框架 是用某种程序语言来书写。设计模式代表了在软件开发过程中特定场景下解决重 复发生的问题的方案。每一个设计模式都集中于一个特定的面向对象设计问题或 设计要点,描述了什么时候使用它,以及使用的效果和如何取舍。一个使用设计 模式的框架比不用设计模式的框架更可能获得高层次的设计复用和代码复用。它 们最主要的不同在于如下二个方面: n 设计模式比框架更抽象。框架能够用代码表示,而设计模式只是其实例 才能表示为代码。框架的威力在于它们能够用程序设计语言编写,不仅可以被学 习,还能被直接执行和复用。从这个意义上说,框架是个物理实体,而设计模式 是个逻辑实体。框架可以看成是一个或多个设计模式解决方案的物理实现,而模 式则指导如何实现这些方案。 2 ) 设计模式是比框架更小的体系结构元素,一个典型的框架都包含多个设 计模式,而反之决非如此。 3 1 框架比设计模式更加特例化。框架总是针对一个特定的应用领域,而设 计模式基本可以被用于任何应用。 设计

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论