(计算机软件与理论专业论文)基于模式的ui自动生成的研究与实现.pdf_第1页
(计算机软件与理论专业论文)基于模式的ui自动生成的研究与实现.pdf_第2页
(计算机软件与理论专业论文)基于模式的ui自动生成的研究与实现.pdf_第3页
(计算机软件与理论专业论文)基于模式的ui自动生成的研究与实现.pdf_第4页
(计算机软件与理论专业论文)基于模式的ui自动生成的研究与实现.pdf_第5页
已阅读5页,还剩55页未读 继续免费阅读

(计算机软件与理论专业论文)基于模式的ui自动生成的研究与实现.pdf.pdf 免费下载

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

文档简介

山东大学硕士学位论文 摘要 软件系统的界面生成在软件系统中占有重要地位,一直以来也是人机交互领域的 一个研究重点。目前成熟的界面生成手段主要是基于各种语言平台集成开发环境中的 h n c 廊c eb u i l d c r 。近年来,随着技术和应用的发展,如跨平台的应用程序和移动计算、 普适计算等新需求的出现,传统的界面开发手段已经愈显乏力。在界面生成方面,新 的尝试层出不穷,其中基于模型( m o d c i b 懿c d ) 的界面生成方法作为一种主流研究方 向得到了广泛的研究和发展1 2 】。 本文综合软件工程中设计模式和基于模型界面生成的思想,提出了一种基于u i 设计模式( d e s i 弘p a t t e m ) 【6 ,l 的界面生成方法。文中给出了种三层模式核心模型( 在 此核心模型基础上可以进一步进行扩展引入更多的模式) 。并基于此核心模型给出了 一个界面生成的实现框架,能够基于对上下文的描述自动产生平台无关的界面模型, 在此模型基础上又可以通过映射的方式生成各种平台相关的界面模型从而可以为后 续的软件开发提供便利( 在本系统中将其映射为一种f l a s h 引擎的界面模型并通过该 引擎向用户展示最终仿真结果) ;在对人机交互任务的任务模型建模方面,本文对传 统的u s cc 船e 文本事件流描述进行结构化,然后结合u i 模式的上下文信息对事件流 中的操作步骤进行扩展。这样就可以快速的进行任务建模,并将生成的静态u i 控件 有机的组织了起来,形成了动态的页面。 本文的贡献主要在于:( 1 ) 使得基于模式的界面生成手段得以利用计算机自动实 现,而不仅仅只是作为对开发人员的设计指导手册。( 2 ) 可以基于对模式上下文的描 述生成白适应的u i ,这使得它适合于上下文环境不同的应用环境中。( 3 ) 基于u s e c 船e 事件流结构化的任务模型建模方法,使得本系统适用于软件项目需求分析阶段中概念 验证环节的界面快速生成的需要。 作为研究内容的验证,本文最后给出了一个基于w e b 银行应用的完整的实现系 统,这个实现系统有效的实现上述思想。但是还应该继续丰富u i 模式及其上下文描 述,以及模式的选择算法等。 关键词:u i 设计模式;自适应界面;上下文盛知;u s ec a s e 扩展;u i 自动生成 山东大学硕士学位论文 a b s t r a c t t h eu s 盱h 1 劬c ed c s i 驴p l a y s 觚i l n p o r c a n tr o l ei l lm es o 胁a r cd c v c l o p 啪蚰 锄di th a s 咖e d 舢c ha n c 以o ni l lm eh c ir c s e a r c h 1 1 l em a t u di j ig e n e 咖印p r o a c h n o w a d a y si si r 她r f 缸eb u i l d e rw h i c hi sb a s e do n 也es p e c i f i cp f o g r a 衄i n g1 髓g l l a g e i i l 咒c e my e 哪,、:l ,i mt l l ed c v e l 叩m 锄to fn e wt c c h n o l o g y 锄dt i l ec h a l l e n g c sp o s e db yn 鲫 q u i r 锄e n t ,e 罾p c r v 船i v ec o m p u t i l l g ,t l l e 缸a d i t i o n a iu id e v e l 叩m e n tm e 船u r cs e e m s i l l s u m c i tt o w a r d st l i o s ec l l a t l g e s a m o n gt i l en e wa t 咄n p t s ,t h em o d e l b a s e dt c c l i n i q 眦 h 鼬a l l n c t c dg r c a t 彻t i o n 【2 】 w h e nc o n c 哪l i n g 也ec o n c e p to fd c s i g np a t t e mi na r c h i t c c t i i r e 觚d 行哪 g i n c e r i n g ,w ep r o p o s cad c s i 鲫p a 仕e m 【6 ,9 】b a du ig e n e r a t i o l la p p r o a c ht l l a ti sc o n t c 虹 s e n s i t i v e i nt h i sa f t i c l e ,a 妇e - 1 a y e r c dp 矗t c mc o r em o d e li sg e nt op r a c n c et l l i si d e a ,a t t l l es 锄ct h n ea ni n l p l e m 舶t 丘a m 州r kb 嬲e do nt l l i sc o r em o d e lw i l lb eb r o u g h tf o n l l , w h i c hc g c l i e 栩t cap l a t f b h ni l l d e p 明d e n tl l s e ri l l t e r f a c e 硼t o m a t i c a l l y ,a c c o r 曲1 9 l y ,a v a r i e 哆o fp l a t f 0 咖d 印d e n tu s e r 锄 e r f k em o d c l sc 孤b e 靓s f o n n e dt l l r o u g l lm 印p i n g , w h i c hw i l l i l i t a t em cf o l l o w h l gs o 腑雠d “e l 叩m 吼t a sf o rm ch c it a s km o d e l i n g ,啪 t a l 【et l l e 删i t i o lu s ec 豁e 舾t l l eb 嬲i sw h i c hc a i lc r c a t et 量l em o d e l 姐p i d l y f i r s t l y ,w e 蛐m c t i l r et h ec v e n tn o wo fi t ,孤dn l e n 麟t e i l dt 置l e 钾e n tw i mc o n 把x ti l l f o m l a t i o nb i n d _ m g t l l a t 也es t a t i c u i c o m p o n t c a n b e o 增溉d t o f o 啪出e u ip a g e a n d 出ep a g e f l o w t h em a i l lc o n 研b m i o n sa r ea sf 0 1 1 0 w s : 1 t om a k et l l ep a t t c i l lb 私e du ig 明e m t i o na p p r 0 h 麟e c l l t c sa u t o m a t i c a l l y ,r a m e r t i i 锄t a k c “硇t i l e i t l s 劬l c t i o n f o r m e d c 、,c l o p 既 2 t oc f e g t et h ea d a p 石v eu i b a do n 吐圮c o n t 强t ,w h i c hm a k e s “v e 珂s u i 诅b l cf b f t l l ec o i l t e ) 【ts e n s i t i v ea p p l i c a l i o n s 3 t h eu s ec 髂eb a s e dt a s km o d e l i i l gm e t i l o dc 姐m e c t 岫r e q u i r c m 髓to f m p i du i g 锄吨i o n 泌d e a l 证g 喇t 1 1 吐圮c o n c e p t p r o o f s t a g co f s o 脓a r e d e v c l o p m e n t a n i l l l p l e m 即tc x 锄p l eo f w e bb 邪e db a n ka p p l i c a t i o nw i l lb cg i v e n a tl 嬲tt ot c m 母 m ef e 船i b i l i 坶o f t 增i d e a k e yw o r d :u id e s i g np a t t e m ;a d a p t i v eu i ;c o n t e x ts e n s i t i v e ;u s ec a s ee x t e n d i n g ; u ia u t o g e n e r a t i o n 原创性声明和关于论文使用授权的说明 原创性声明 本人郑重声明:所呈交的学位论文,是本人在导师的指导下,独 立进行研究所取得的成果。除文中已经注明引用的内容外,本论文不 包含任何其他个人或集体已经发表或撰写过的科研成果。对本文的研 究做出重要贡献的个人和集体,均已在文中以明确方式标明。本声明 的法律责任由本人承担。 论文作者签名:兰垒坠日期: 娴s l 妒 关于学位论文使用授权的声明 本人完全了解山东大学有关保留、使用学位论文的规定,同 意学校保留或向国家有关部门或机构送交论文的复印件和电子 版,允许论文被查阅和借阅;本人授权山东大学可以将本学位论 文的全部或部分内容编入有关数据库进行检索,可以采用影印、 缩印或其他复制手段保存论文和汇编本学位论文。 ( 保密论文在解密后应遵守此规定) 论文作者签名;皇生导师签名:筮日 山东大学硕士学位论文 1 1 课题的背景和意义 第一章引言 移动计算和普适计算是近年来出现的一种新的计算模式【6 】。在普适计算环境下, p d a 和移动电话、家用电器等通用设备,及用于医疗、军事、娱乐等方面的专用设备 将广泛的应用在人们的生活环境中协同工作,以快速、高效和便捷的模式为人们提供 服务,而使用这些计算设备的人则感知不到计算机的存在。普适计算环境中各种设备 拥有的资源是不同的和变化的,所有这些都对界面设计和开发提出了很大的挑战,包 括: 移动计算环境下的应用程序运行在不同的平台上,从功能强大的p c 到小型的 移动电话、p d a 等手持设备。当在大尺寸高分辨率的显示环境下,有些应用 程序会因为图标和文字等变得太小,使得鼠标点击和辨认都变得很困难。而 对于小尺寸的显示屏而言,应用程序的菜单、工具条、对话框等几乎沾满了 整个显示区域,使得用户的操作区域变得非常小。 新的输入输出设备在特定的应用环境中使用的越来越多,比如语音识别、手 势识别等。 当用户跨平台执行一个任务时情形会变得更为复杂。比如,某人使用笔记本、 p d a 、手机等软硬件环境截然不同的设备来操作一个应用程序,而当他想通 过异构环境来协同完成某个任务时情形将会变得更加糟糕。 为了应对这一新的需求,传统的u i 开发方法只能为每种应用情形开发其特定的界 面,但这样将引发更多的问题,比如,基于各种平台和使用环境的重复开发带来的界 面一致性和成本问题;还有,基于不同平台的界面开发者水平参差不齐也会使得软件 质量急剧下降;另外,每当一个新的设备引入时还要重复开发基于此设备的界面。因 此,上述的这些原因使得这种方式不仅不切实际有时甚至是不可行的。所以,迫切需 要有一种新的界面开发方法来满足这一新的需求。 另外,在现时的软件市场上,软件开发公司通常采用生命周期模式( 结构化设计 模式) 的开发方法,它是面向功能或过程的方法。其实现技术是结构化系统分析、设 山东大学硕士学位论文 计与结构化程序设计。开发人员通过与相关业务人员交流或直接深入实际工作,根据 原始资料写出用户需求说明草本。经修改,得到相关人员的确定、认可后双方签字, 形成合同式需求说明书。开发人员根据需求说明书进行系统设计、编程。系统实现后 双方组织人员进行测试,然后便进入系统的运行、维护期。利用生命周期模式开发系 统基于两个假设:( 1 ) 用户能清楚地、完整地提供系统要求;( 2 ) 开发者能完整地、严 格地理解和定义要求。但在实际开发中,以上两个假设显然无法满足。首先,用户难 以准确地描述出系统需求:其次,口述具有二义性,这往往使开发人员产生误解,从 而提高了准确定义用户需求的难度。同时,开发者也由于这样或那样的主客观原因, 难以跨越与用户交流的鸿沟。其结果是系统开发完毕后,不能很好地满足用户需求, 达到预期目标,需要经常修改、维护的开销过大,有时甚至造成系统预算严重超支, 系统验收一再拖延,以致开发双方的项目合作破裂。生命周期模式是封闭式的,缺少 灵活性。这在用户需求定义方面尤为突出。为了克服这一缺点,产生了原型开发模式。 该模式基于以下认识:并非一切需求都能在开发前准确预见。参与项目的双方存在 着相互沟通的障碍。大量的反复是不可避免的,并且是必要的。 目前开发原型方法主要是基于未来实现系统的开发,这种方式虽然能够成为交付 版本的一个实现基础,但是也存在原型开发周期长,因用户的需求改变而带来的重复 编码等缺点。因此,在原型系统的开发,尤其是界面生成方面需要一种简单快速的手 段。 在界面开发方面除了传统的基于各种语言平台集成开发环境中的i n t e 血b u i l d c r 外,基于模型的界面开发成为了今年来的研究热点。设计者通过建立一个描述性的模 型来对用户需要系统来完成的任务、系统的功能、系统平台、界面的风格和需求、用 户的特点和偏好、i ,o 设备等进行建模,通过这个模型来生成用户界面。基于模型的 界面开发在跨平台应用、界面风格一致性保持、迭代开发、界面自适应方面有着较为 突出的优点,成为近年来的研究热点。尽管如此,在建模复杂性,使用灵活性,特定 平台的代码生成方面仍有不足。 u i 设计模式给了我们另外一个全新的u i 设计方式。和建筑学与软件工程领域中 设计模式的概念一样,u i 模式也是指可以反复重用的针对特定上下文中某个问题的解 决方案。u i 模式的研究已经有很长时间了,n o 咖锄矩d d r a l e r 嘲在他们经典的日常生 活心理学专著中提到过亚历山大的设计模式,n o 唧锄说他十分欣赏该思想,其它的 2 山东大学硕士学位论文 这方面的研究请见【“,1 2 1 。到目前为止,已经有了超过2 5 0 个的设计模式,但它们仅仅 是作为对设计人员指导性描述出现的。 单独的模式对界面开发中遇到的问题已经很有指导意义了,而当我们将这些模式 彼此关联起来时,就会发现它们更有价值,同时也使得设计知识更加直观的展现在我 们眼前,这些彼此关联的模式称之为模式语言1 ”。 1 2 本文研究的主要内容 本文的研究重点叙述如下: ( 1 ) 综合设计模式和基于模型的界面生成的思想,提出了一种基于u 设计模式 的界面生成方法。文中给出了一种三层的分层模式核心模型( 在此核心模型基础上可 以进一步进行扩展引入更多的模式) 。并基于此核心模型给出了一个界面生成的实现 框架,它能够基于对上下文的描述自动产生平台无关的界面模型。 ( 2 ) 用例( u s ec a ) 是一种描述系统需求的方法,使用用例的方法来描述系统需 求的过程就是用例建模。用例分析已越来越多应用到面向对象的软件项目中来,成为 项目前期需求分析中不可或缺的一步,本文在传统用例规约( u s ec a s p e c m c a t i o n ) 对 事件流描述的基础上加以结构化形成任务模型,并利用它来仿真系统的执行逻辑。 ( 3 ) 在基于u i 模式的界面生成方法中,模式上下文的描述是选择模式生成u i 的基础,这就使得这一方法适合于不同上下文约束环境下人机交互的要求,如移动计 算、普适计算等。 ( 4 ) 基于u s ec a 文本描述建立任务模型的方法使得它很适合需要快速生成界 面的应用场合,如软件需求分析阶段的原型系统开发等。除此之外,基于任务对后台 逻辑的描述能够生成连续的页面流与用户交互,并且在与用户交流时通过预先设定演 示路径能够让用户了解到未来系统运行的全部情况。 1 3 论文组织 第一章为引言,主要介绍了课题的背景和意义,本文的创新点以及论文的组 织结构。第二章介绍了基于u i 设计模式的界面自动生成方面的国内外研究现状以及 u s ec a s e 方面的一些概念。第三章介绍了三层的分层模式核心模型及系统整体实现框 山东大学硕士学位论文 架,该章是本文工作的基础。第四章以u i 控件层为例,详细介绍了基于模式的u i 自 动生成思想。第五章介绍了基于u s ec 髂e 的任务模型建模以及三层核心模型中与之相 关的一些算法实现。作为研究思想的验证,第六章给出了一个实现系统及u i 自适应 的仿真结果。第七章在针对论文所做的工作在进行总结的基础上,给出了一些改进和 展望。 4 山东大学硕士学位论文 2 1 设计模式概念简介 2 1 1 建筑学领域的设计模式 第二章相关工作 设计模式这一概念最早来自于建筑学领域,是由c m s t o p h e ra l 弧a n d 盱首先提出 来的,他对模式的定义是“在菜一背景下某个问题的一种解决方案”每个模式都描述 了一个在我们的环境中会不断重复出现的问题,并进而叙述了这个问题解决方案的要 素,通过这种方式,解决方案能够百万次地反复应用【9 】。a l e x 锄d 盯说一个模式的描述 应该包括四个方面:模式的名称、模式的目的、要解决的闯题、实现方法。他认为模 式可以解决可能遇到的几乎所有建筑问题。他还进一步认为模式可以结合起来解决更 复杂的建筑问题。 2 1 2 软件工程领域的设计模式 2 0 世纪9 0 年代初,一些聪明的开发人员偶然接触到a 1 a n l e r 有关模式的工作。 他们很想知道,在建筑学成立的理论,是否在软件设计中也适用。软件中是否存在不 断重复出现、可以以某种相同方式解决的问题,是否可能用模式方法来设计软件,即 先找出模式,然后根据这些模式创建特定的解决方案。 这些开发人员感到,这两个问题的答案都毋庸置疑是肯定的。接下来要做的,就 是找出一些模式,然后制定出新模式的编录标准。虽然在2 0 世纪9 0 年代初许多人都 在研究设计模式,影响最大的是由g 啪m a 、h e l m 、j o l l l l s o n 和v l i s s i d e s 合著的设计 模式:可复用面向对象软件的基础。为了褒奖他们的重要工作,大家给四位作者取 了一个通行的呢称日o f 。 这本书有以下几个目的:将设计模式的思想应用于软件设计并称它们为设计 模式( d e s i 印p a c m ) 。给出了编录和描述设计模式的一种格式。 编录了2 3 个设计模式。在这些设计模式的基础上推导出了一些面向对象的策略 和方法。g o f 自己并没有创造书中的模式,认识到这一点很重要。相反,他们只是将 软件界已经存在的、反映了( 针对各种具体问题的) 优秀设计经验的模式识别出来。 山东大学硕士学位论文 ( 请注意,这与a l e x a n d e r 的工作是类似的。) 每个模式都按照如下四部分进行描述: 1 模式名称( p a n e mn a m e ) ;一个助记名,它用一两个词来描述模式的问题、 解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较 高的抽象层次上进行设计。基于一个模式词汇表,我们自己以及同事之间就可以讨论 模式并在编写文档时使用它们。模式名可以帮助我们思考,便于我们与其他人交流设 计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。 2 问题口m b i e m ) :描述了应该在何时使用模式。它解释了设计问题和问题存在 的前因后果,它可能描述了特定的设计问题,如怎样用对象表示算法等。也可能描述 了导致不灵活设计的类或对象结构。有时候,问题部分会包括使用模式必须满足的一 系列先决条件。 3 解决方案( s o l u 伽n ) :描述了设计的组成成分,它们之间的相互关系及各自的 职责和协作方式。因为模式就像一个模板,可应用于多种不同场合,所以解决方案并 不描述一个特定而具体的设计或实现,而是提供设计问题的抽象描述和怎样用一个具 有一般意义的元素组合( 类或对象组合) 来解决这个问题。 4 效果( c o n s e q u e n c e 。) :描述了模式应用的效果及使用模式应权衡的问题。尽管 我们描述设计决策时,并不总提到模式效果,但它们对于评价设计选择和理解使用模 式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量,它们也表述 了语言和实现问题。因为复用是面向对象设计的要素之一,所以模式效果包括它对系 统的灵活性、扩充性或可移植性的影响,显式地列出这些效果对理解和评价这些模式 很有帮助。 2 1 3 中的设计模式 在u i 设计模式方面,先后有b o r c h e r s ,以及、bd u y n e 和g 栩h a m 等在论文和出 版的书籍中提到,截至目前总共出现了大概2 5 0 个u ip a t t 锄【1 1 】。 这些模式也是在u i 设计的特定上下文中解决某个常见问题的过程中形成的比较 好的解决方案【1 4 1 。u i 模式的描述也可以分为四个部分:w h a t :该模式的名称以及作 用;u s ew h e n :什么时候使用该模式,也即该模式的上下文环境描述;w h y :使用 该模式的原因,原理;h 啷:解决方案,即如何使用该模式。在【1 3 1 中有着对u i 模式 更为细致的描述,该文主要强调了模式对界面可用性的影响,这些可用性指标包括:交 互速度、使用学习难易度、记忆难易度、使用满意度、需完成任务数量以及使用是否 6 山东大学硕士学位论文 容易出错等几方面。通过描述每一个模式对这些可用性指标的优劣影响,给了使用者 一个客观的评价标准。 随着在g u i 设计和w e b 设计中u i 设计模式的数量日益增多以及使用变得越来 越实用化。对这些模式进行组织和分类变得越来越重要了。这不仅仅有利于选择单独 的模式,也有利于在更大的上下文环境中选择一组模式来解决给定的设计问题。一个 单独的模式可能对设计者来说已经很有价值了,但是当这些模式相互关联起来将会产 生更大的价值,这些相互关联的模式被称为模式语言。正如a l e 船n d c r 在建筑学领域 提出存在从城镇到门窗的模式语言一样,u i 中也存在类似的从高层到底层相互关联的 模式。所不同的是u 中并不存在建筑学中每个层次上都有对应的具体建筑实物,如 城市,街区,房屋等处于不同层次的粒度,这都是由需要解决的建筑学问题所决定的, 这些粒度都是解决特定问题的结果的粒度,只不过在建筑学领域中它们恰好与问题粒 度相对应。在u 领域中,粒度大概就是在整个t o p d o w nu i 设计过程中,每个层次上 面临的不同的设计问题( 商业目标、用户类型、交互任务、用户偏好、技术环境、数据 类型等) 。这些层次从高到底大致可以分为商业目标层、应用类型层、经验层、任务层、 行为层【”j 。 2 1 。4u i 设计模式的应用 目前的u i 设计模式大多数只是一种对软件开发设计人员的指导性说明,然而, 开发人员并不像模式的创建者那样懂得如何的在特定的上下文环境中选择合适的模 式,因此设计一种自动选择使用模式的工具将是解决这一问题的有效手段。 【1 0 堤c o n c o r d i a u i l i v 懿时的一个项目,该项目开发了个面向模式的u i 设计工 具,它对u ip 舭m 的定义描述是基于) m 几的,使用者能够以托拽的方式的使用这 些模式进行u i 设计。 2 2u s ec a s e 事件流简介 用例( u s ec a s e ) 是一种描述系统需求的方法,使用用例的方法来描述系统需求的 过程就是用例建模圆。用例方法最早是由i v aj k b o n 博士提出的,后来被综合到 u m l 规范之中,成为一种标准化的需求表述体系。用例的使用在r u p 中被推崇备至, 整个r u p 流程都被称作是“用饲驱动”( u s e c a s cd f i v e n ) 的,各种类型的开发活动包 山东大学硕士学位论文 括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件,用例模型奠 定了整个系统软件开发的基础。用例模型主要由以下模型元素构成: 参与者( a c t o r ) :参与者是指存在于被定义系统外部并与该系统发生交互的人或其 他系统,他们代表的是系统的使用者或使用环境。 用例s ec 船e ) ;用例用于表示系统所提供的服务,它定义了系统是如何被参与 者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发 生的一段对话。 通讯关联( c 咖m 蚰i c 硝o na 黯o c i a 6 蛐) :通讯关联用于表示参与者和用例之间的 对应关系,它表示参与者使用了系统中的哪些服务( 用例) ,或者说系统所提供的服 务( 用例) 是被哪些参与者所使用的。 用例图使我们对系统的功能有了一个整体的认知,我们可以知道有哪些参与者会 与系统发生交互,每一个参与者需要系统为它提供什么样的服务。用例描述的是参与 者与系统之间的对话,但是这个对话的细节并没有在用例图中表述出来,针对每一个 用例我们可以用事件流来描述这一对话的细节内容。所有可能发生的各种情况( 包括 正常的和异常的) 被称之为用例的场景( s c c t l 撕o ) ,场景也被称作是用例的实例 m g t a l l c e ) 。在用例的各种场景中,最常见的场景是用基本流嬲i cf l o w ) 来描述的,它 是最顺利的一种情况,作为一个实用的系统,我们还必须考虑可能发生的各种其他情 况,对其他场景的描述则是用备选流( a i t 啪a t i v ef l o w ) 来描述。由于这些事件流的描述 也恰好反映了软件系统中人机交互的整个过程,所以用例也可用于人机界面的设计 中。基本流和备选流统称为事件流( e v c n tf l o w ) 。 尽管用例被广泛的用于面向对象的软件工程以及人机交互界面的设计中,可迄今 为止并没有一个良好的统一定义,各式各样的对用例描述大多是以文本叙述形式为 主。在形式化描述方面所作的努力有洲中提到的e s s e 而a lu s ec a s ,以及盼矧中提 到的d e t a i l e du s ec a s e s ,他们都是用一种结构化化或半结构化的格式对传统用例描述 进行了规范。 山东大学硕士学位论文 第三章整体实现与核心模型 以往的u i 设计模式都是作为界面开发设计过程中前人的经验总结,以非结构化的 文本描述形式出现的,其目的是作为对开发设计人员的工作迸行指导以及作为他们之 间的交流工具,并没有成为计算机能够自动选择并执行的u i 设计的有效工具,为了 使得广大开发人员能够更好的利用这些模式,开发一种工具来自动的识别使用这些模 式便成为了当务之急。 本章在总结以往u i 设计模式的基础之上首先给出了基于模式的界面自动生成整体 框架,然后给出了u i 设计模式的形式化定义,并在此定义基础上给出了一种可扩展 的三层模式核心模型,最后介绍了基于核心模型的扩展实例和基于屏幕尺寸上下文约 束的u i 自适应生成实例。 3 1 基于模式的界面生成整体方案 定义l ( 唧m o d e l ) :p l a 响肌h l d e p e n d e mu s e ri n t c l f a c cm o d e l ,即一种抽象的 与具体平台无关的界面模型。 定义2 ( p d i j im o d d ) :p l a t f o 册d e p c n d c mu s 盯i n t c r 蟊l c em o d e l ,即一种具体的 可在各个实现平台上运行的平台相关的界面模型。 图3 1 所示的是本文给出的基于模式的自适应u i 自动生成的整体方案框图。u g e n e m t o r 是该系统的核心模块,km o d e l 是基于u s ec a s e 结构化和扩展首先建立 起来的,当用户要访问应用程序时,位于终端设备中的上下文感知a g e n t 首先将程序 请求和上下文信息( 如屏幕大小,输入输出设备,系统平台等) 发往服务器,紧接着 u ig 胁e m t o f 就会接受到该信息并将它至于c o n t 取tm o d e l 中,接下来对该模型应用 u i 模式,得到p i u i 模型,然后通过对应于各个具体平台的u i 模型映射文件得到p d u i 模型,如d h n 缸,和f l a s h 、j a v a 等( 在我们的实例中是o p c l l l 嬲z i o 的f l a s hu i 模型 【1 3 1 ) 。 山东大学硕士学位论文 图3 1 基于模式的界面生成整体方案 本文在设备上下文方面将以屏幕大小为主要关注点,来阐述u i 自适应问题。因 为它不仅仅典型而且阐述起来也最为直观和明确。而且我们相信,用来处理屏幕大小 上下文的技术也足以用来处理其它类型的上下文。 3 2u i 设计模式的定义 u i 中的设计模式同软件工程中的模式一样都是受到建筑学领域设计模式的启发, 都是用来解决特定上下文中特定问题的可能的最佳方案。 综合【1 1 1 2 ,1 4 l 等关于模式的定义,我们将模式中最核心的部分抽象出来做如下定义: 定义3 ( 设计模式) :u i 设计模式是被证明能够正确地在特定上下文环境中被 用来解决u i 设计问题的较好的解决方案,可以表示为四元组的形式:p a n e m = ( n a m e , c o n t e x t ,w h y s o i u 伽n ) ,以下简称为u i 模式。如图3 2 所示,四个部分分别叙述如 下: 1 0 山东大学硕士学位论文 w h y 骤鬟辫糍码 筐p | 鑫l 协m 习 氐l 妇l 隧参灞 c o n 协x t 图3 2 u 模式 定义4 模式名称( n 枷e ) ,模式的标识,用来区分不同的模式。 定义5 模式上下文( c o n t e x t ) :即与需要解决问题相关的环境描述,在特定的上 下文环境中才能选择特定的模式来解决问题。上下文描述主要包括两种: d e v i c e 玳l a t c d和 d e s i 鲈- 坨l a t c d , 即c o n t 旺t暑 d e “c e _ 他i a t e dc o n t 旺tu d 鹤i g n - 忡i a t e dc o n t 既n 。 d “i - r e l a t e dc o n t e x t :主要是指与设备相关而与任务无关的上下文。在具体 应用中会因为设备的不同而不同,对于所有的任务该部分都是一样的。设备 上下文其实是一种产生u i 所必须考虑的约束,因为我们解决的主要问题是基 于不同设备上下文的u i 自适应生成问题,所以,这类上下文是需要优先考虑 的。 d e s i g n - m l a t e dc o n t e 虹:是与设备无关而与任务相关的上下文描述。对于所有 设备而言该部分都是一样的,如想进行的操作类型,操作的数据对象等,( 这 部分的上下文在建立t 髂km o d e l 的时候就已经存在了) 。最后由这两部分将 共同决定最终的u 类型。 定义6 模式的选择( w h y ) :该部分描述的是当我们进行u i 设计时选择某个模式 的原因,即由上下文得到解决方案的求解过程。可用推理函数表示为r ( c o n t e x o ; p a 仳e m ,其中c o i i t e 】【t 为具体的上下文实例,p a 仕e m 为所选择的模式实例,又因为我 们所关心的是模式应用后的结果,所以推理的过程又可表示为剐c o n t 既t ) = l u t i o n 。 这部分的实现对于计算机自动生成界面而言是至关重要的。 定义7 模式的解决方案( s o i u t i o n ) :该部分用来描述解决u i 设计问题的实现方 案,方案可能只有一个,也可能是多个。值得注意的是,和建筑学中那些城市、街区、 走廊、门窗等可见的解决方案不同。u i 领域的解决方案除了具体的控件如窗体、按钮、 山东大学硕士学位论文 输入框等是可见的以外,还有不可见的部分,如用来形成页面的聚合算法,用来对页 面进行布局的布局方式等等。在我们的方法中就是通过层层u i 模式的使用得到相应 的s o l u t i o n ,最终得到完整的界面实现。 由上述四元组形式定义的模式可以看到,模式的本质其实就是在特定的问题上下 文描述中给出合适的解决办法,如果我们把c o 肿e x t 看成是选择模式的原因的话,那 么s o l u t i o n 则是模式应用的结果。所以,我们认为另一种精简的模式定义也可以是如 下形式的二元组形式:p a t t e m = ( c o n t e x t ,s o l u t i o n ) 。 3 3u i 三层模式核心模型 我们定义的分层模式这一思想主要来自于模式语言【1 1 ,1 2 1 的概念。模式语言是指一 组相互关联的分类模式的集合。它最基本的假设是设计模式总是相互关联的,这一假 设是很自然的,因为模式的总结来自于实际的设计实践中,而具体的设计实践总是相 互关联如u p _ d o w n 设计中从高到底逐步细化的设计步骤,所以模式之间必然有这种 天然的联系,也因如此我们的核心模型也必须从模式语言的角度出发解决整个的u i 设计问题。 以往关于模式语言的研究在模式分类方面( 即层次性) 几乎涵盖了一个应用软件 的方方面面,例如f l l 】关注了从应用程序类型到任务类型再到交互动作类型等多层次的 u i 设计模式问题;此外,在模式之间的关系方面也显得略为繁琐,如定义了类似于面 向对象编程语言中的a g f e g a 廿o n 、s p e c i a l i z a t i o n 、a s s o c i a 廿o n 等。 因为本文研究的出发点是在计算机自动应用u i 模式方面作一个初步的探索,所 以我们在前人工作的基础之上对模式语言在如下方面进行了简化处理: 1 层次性:我们的核心模型只关注那些与界面设计本身相关的模式问题,例 如由哪些交互任务形成一个页面,页面内都有哪些控件来完成这些任务,这 些控件如何布局等,而把任务相关的描述放到单独的任务模型( 协i 【- m o d c l ) 中。 2 模式间的关系:我们将模式间的关系扁平化( n a 位m e d ) ,只保留模式间最 基本的关系a g g 阳g a t i o n ( 聚合) ,即高层模式对低层模式的h 嬲- a 关系,而将 继承( i s - a ) 等关系等略去。 基于上述思想我们首先对现有u i 模式进行总结分类,然后找出各分类之间的关系, 山东大学硕士学位论文 提出了一个以三层模式为核心的模型,基于此模型可以再进行扩展,如面向不同领域 应用程序的扩展( 银行应用、电子商务等) 。 首先给出模型相关几个概念的定义: 定义8 逻辑窗口( i 肼:l o g i i w i n d d w ) z 逻辑窗口是指屏幕中当前窗口可见u i 控件的集合,l w = c o m p o n e n t l ,m p o e n t 2 m p o n e n t 。 。它可能是一个窗口, 也可能是窗口中的某个容器型控件,如选项卡( 1 a bf o l d e r ) 中的某个选项卡页面。我 们针对上下文所需要做的调整就是针对l w 而言的。 定义9 表示单元( p u :p 托s e n t a t i o nu n i t ) :表示单元是指为完成一组特定交互任 务( t a s k ) 的u i 集合,p u = 皿w l ,l w 2 l wn 。每个p u 可能由一个l w 组成,也 可能由若干个【肼组成,比如p u 可能就是一个单独的物理窗口,也可能是向导或选 项卡形式,而其中的每一个页面就是一个l w 。 n i 研 + _ 1m o d e ij i _ j 图3 3 三层模式核心模型 图3 3 所示为三层模式核心模型的示意图,演示的是由扩展上下文描述的任务模型 山东大学硕士学位论文 ( 空心长方形表示任务节点,空心圆圈表示与之绑定的上下文节点) 经过三层模式的 应用得到最终界面的过程。三层的功能分述如下: 表示单元聚合层( p r e n t a t i o nu n i tc o n v e r g i n gl a y e r ) :该层的主要任务是将任 务模型中的人机交互任务以p u 为单位进行划分,从而得到一组在同一个p u 中执 行的任务集合。该层中的s o l 嘶o n 为基于不同上下文p u 聚合算法。该层模式的 精简表示为p = ( 交互任务类型和界面设计可用度,p u 聚合算法) 。 页面布局层( p a g el a y o u tl a y e r ) :该层的主要任务是将p u 按照上下文的约束拆 分成l w ,并将【w 映射为其相应的物理u i 形式( 窗口页或容器) ,再进一步形 成页面的组织结构并对每一页内的控件进行布局,布局的方式包括布局算法和利 用容器型控件对页面控件进行划分和组织,上述两种方式同时也就是该层的 s o l u t i 。该层模式的精简表示为p = ( ( 任务类型、可用度和美观度) ,( l w 对应 的u i 控件、页面l a y o u t 算法) ) 。 控件层( 1 7 ic o m p 曲e tl a y e r ) :和上述两层不一样,由于该层的模式应用结 果将会生成具体的u i 控件,而实际中的u i 控件类型又是多种多样的,所以该层 的模式种类也同样非常丰富。下一章中将以此层为例对基于模式的u i 生成过程进 行详述。该层模式的精简表示为p = ( ( 任务类型、任务所处理的数据类型和数据 的相关属性) ,各种u i 控件) 。 3 4 应用实例 3 4 1 基于三层模式核心模型的扩展实例 图3 4 示意的是在核心模型的基础之上扩展了应用类型层( 上层p a t t c m 对下层 p a t t e 趣的所指的箭头代表h a s - a 关系) 。通常程序的应用领域不同,界面的组织形式、 交互形式和控件选择会有很大不同,比如,银行类网站通常是分为上下左三个f 舢e , 上面的是l o g o 等,左边的操作菜单,而右边的是菜单项操作区,又由于银行业务种 类繁多,且操作不允许出错,所以某个具体的业务交互通常都采取向导( w i 髓r d ) 的 形式来完成( 即p u 划分为的所有l w 都以向导页的形式展现) 。 1 4 山东大学硕士学位论文 银行应用电子商务应用 应用类型层一,一一一一一一 类型1类型2 一! i :;:? :;:,;:;:;:i - n j 聚合层p u ( 寥合方式1 ) p u ( 聚合方式2 ) 页面布局层p 赠。 u 控件层 f fc 锄p o s i 协坩w l 町a u t 户氏一 b l l t t 毗1 b 醴m 锄l 图3 4 基于模式核心模型的扩展 图3 5 反映的是分层模式及每层模式的s o l u t i o n 之间的关系,左侧方框代表模式, 右侧方框为s o l “o n ,可以看到高层模式会用到低层模式,而底层模式形成的s o l u t i o n 又由低到高为高层的s o l u t i o n 所用。 l 应用类型层顶壤u i 结构 i if p u 聚合层p u 聚合方式 i if l 页面布局层:容器烈控馑、布局算磋 l u 控件层 u 控件! 图3 5 分层的u i 模式间的关系 山东大学硕士学位论文 3 4 2 基于屏幕尺寸上下文的模式选择过程 图3 6 基于屏幕尺寸上下文的模式选择过程 图3 6 所示的是基于屏幕大小进行u i 自适应的整个过程。首先,上下文a g e n t 会将具体设备屏幕的尺寸和尺寸大小分类( 大、中、小) 等信息告诉u ig 肌e r a t o r , 然后,每一层都会根据该信息选择合适的模式来生成u i ,其中,模式所处的层次越高 对页面尺寸所作的调整越大,比如在页面布局层我们可以对原来平铺在一页的控件分 组放到不同的选项卡页面中,这样页面尺寸较原来就缩小了好几倍,而u i 控件层通 过选择不同控件对尺寸的调整则要小的多。因为在我们的模型中只有到最后的u i 控 件层中才能得到所有的u i 控件,所以也只有到这一层才能判定生成的界面是否符合 具体上下文的要求,如果不符合,则我们可以选择该层中能够生成小尺寸u i 控件的 模式,如果还不行,则可以递归的到它的高层模式中重复这些步骤直到最终结果复合 要求,如果直到最高层还是不行,我们还可以通过对容器型控件添加滚动条等方法来 解决问题。 3 5 本章小节 本章是本文工作的核心基础,首先在总结前人经验的基础之上给出了模式的形式 山东大学硕士学位论文 化定义,然后以此为基础,提出了以界面设计问题本身为关注点的三层模式核心模型, 并给出了基于此核心模型的u i 自动生成框架。最后绘出了应用层扩展和界面自适应 的示意性实例。在后面的章节中,我们将以u i 控件层为例叙述基于模式的u i 生成的 具体研究内容及其实现。 山东大学硕士学位论文 第四章u i 控件层中的模式 本章我们将以u i 控件层中的模式为例详细的讨论模式的四个部分,解释它们如 何在具体应用中得以实现,随后给出了用以支持模式实现的上下文元模型c o n o e 】【t m e t a m o d e l 和平台无关的u 元模型u i m e t a m o d e l ,最后给出了一个实例,演示本层 中如何由上下文描述应用模式最后实现u i 的过程。 4 1u i 控件层中的模式 根据前面对模式的描述我们知道,上下文环境是决定使用何种p a t t e m 的重要因 素,因为无论是人还是

温馨提示

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

评论

0/150

提交评论