免费智能真题库 > 历年试卷 > 系统架构设计师 > 2015年下半年 系统架构设计师 下午试卷 案例
  第5题      
  知识点:   MySQL   表示层   开发过程   Hibernate框架   Java   功能需求   继承   架构设计   市场调研   数据层   数据库

 
【说明】
某信息技术公司计划开发一套在线投票系统,用于为市场调研、信息调查和销售反馈等业务提供服务。该系统计划通过大量宣传和奖品鼓励的方式快速积累用户,当用户规模扩大到一定程度时,开始联系相关企业提供信息服务,并按照信息服务种类和用户投票数量收取费用。
为了降低开发成本和提高开发效率,项目组经过讨论后决定采用轻量级Java EE开发框架设计系统应用架构。在应用架构设计中,除了满足系统主要功能需求,还需要考虑的因素包括:
(1)项目开发采用MySQL数据库存储数据,一但将来可能移植到其它数据库平台;
(2)系统开发过程中尽可能降低或者消除SQL语句开发的工作量;
(3)投票系统中数据之间的关系复杂,需要支持数据对象的聚合和继承等关系。
项目组基于MVC模式设计出了投票系统的架构,包括表示层、业务逻辑层、数据持久层和数据层。在具体讨论数据持久层采用哪种技术方案时,老王建议采用成熟的Hibernate框架,小李则认为iBatis更加灵活,更适合作为投票系统数据持久层开发技术。
 
问题:5.1   请用300以内文字说明什么是数据持久层,使用数据持久层能够为项目开发带来哪些好处?
 
问题:5.2   针对在线投票系统的实际应用需求和要求,项目组应选用哪种技术实现数据持久层?请用200字以内文字说明其采用该技术的原因。
 
问题:5.3   数据持久层是Web应用系统框架中重要的组成部分,主流的数据持久层技术分别基于不同的技术方案,请在表5-1中(1)-(4)处分别根据(a)~(d)所列技术的方案类别填入其序号。
表5-1 数据持久层技术分类

(a) BMP, CMP
(b) iBatis/MyBatis
(c) SpringJdbcTemplate
(d) TopLink,JDO,Hibernate
 
 
 

   知识点讲解    
   · MySQL    · 表示层    · 开发过程    · Hibernate框架    · Java    · 功能需求    · 继承    · 架构设计    · 市场调研    · 数据层    · 数据库
 
       MySQL
        MySQL是一个开放源码的小型关联式数据库管理系统,开发者为瑞典MySQL AB公司。MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。
 
       表示层
        表示层以下的各层只关心从源地到目的地可靠地传输数据,而表示层则关心的是所传送信息的语义与语法。它负责将收到的数据转换为计算机内的表示方法或特定程序的表示方法。也就是说,它负责通信协议的转换、数据的翻译、数据的加密、数据的压缩、字符的转换等工作。在OSI/RM模型中表示层的规范具体包括数据编码方式的约定和本地句法的转换。各种表示数据的格式的协议也属于表示层,例如,数据压缩和编码等。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段,与通用软件的开发过程基本一致,都可按照软件工程方法进行,如采用原型化方法、结构化方法等。
        :由于嵌入式软件的运行和开发环境不同,开发工作是交叉进行的,所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的,主要是源代码编写、编译链接等子过程,这些工作都在宿主机上进行,不需要用到目标机。产生应用程序的可执行文件后,就要用到交叉开发环境进行调试,根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高,所以,在对嵌入式系统进行白盒测试时,要求有更高的代码覆盖率。
        最后,要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同,可以固化在EPROM(Erasable Programmable ROM,可擦除可编程ROM)和Flash等存储器中,也可固化在DOC(DiskOnChip)等电子盘中,通常还要借助一些专用编程器进行。
 
       Hibernate框架
        Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以使用对象编程思维来操纵数据库。
        “对象/关系”映射(O/R Mapping)是一门非常实用的工程技术,它实现了Java应用中的对象到关系数据库中的表的持久化。使用元数据(meta data)描述了对象与数据库间的映射。Hibernate是非常优秀、成熟的O/R Mapping框架,它提供了强大的对象和关系数据库映射以及查询功能。Hibernate体系结构如下图所示。
        
        Hibernate体系结构
        Hibernate的核心接口一共有6个,分别为:Session、SessionFactory、Transaction、Query、Criteria和Configuration。这6个核心接口在任何开发中都会用到。通过这些接口,不仅可以对持久化对象进行存取,还能够进行事务控制。下面对这6个核心接口分别加以介绍。
        (1)Session接口。Session接口负责执行被持久化对象的增删改查操作(增删改查的任务是完成与数据库的交流,包含了很多常见的SQL语句)。但需要注意的是Session对象是非线程安全的。
        (2)SessionFactory接口。SessionFactory接口负责初始化Hibernate。它充当数据存储源的代理,并负责创建Session对象。这里用到了工厂模式。需要注意的是SessionFactory并不是轻量级的,因为一般情况下,一个项目通常只需要一个SessionFactory就够,当需要操作多个数据库时,可以为每个数据库指定一个SessionFactory。
        (3)Configuration接口。Configuration接口负责配置并启动Hibernate,创建SessionFactory对象。在Hibernate的启动的过程中,Configuration类的实例首先定位映射文档位置,读取配置,然后创建SessionFactory对象。
        (4)Transaction接口。Transaction接口负责事务相关的操作。它是可选的,开发人员也可以设计编写自己的底层事务处理代码。
        (5)Query和Criteria接口。Query和Criteria接口负责执行各种数据库查询。它可以使用HQL(Hibernate Query Language,官方推荐的Hibernate检索方式)或SQL语句两种表达方式。
 
       Java
        Java语言起源于Oak语言,Oak语言被设计成能运行在设备的嵌入式芯片上。
        Java编译成伪代码,这需要一个虚拟机来对其进行解释,Java的虚拟机在几乎每一种平台上都可以运行。这实质上使得开发是与机器独立无关的,并且提供了通用的可移植性。
        Java把类的概念和接口的概念区分开来,并试图通过只允许接口的多继承来克服多继承的危险。
        Java的异常处理机制与C++的try/throw/catch相类似,但更加严密。在Java中,通过声明轻型线程来处理并发性,这些线程通过副作用和同步协议进行通信。
        Java Beans是组件,即类及其所需资源的集合,它们主要被设计用来提供定制的GUI小配件。
        Java中关于面向对象概念的术语有对象、类、方法、实例变量、消息、子类和继承。
 
       功能需求
        功能需求即网络在用户单位业务中应该提供的功能,可以通过了解用户单位所从事的行业、该单位在行业内的地位以及和其他单位的关系等来确定其功能需求。另外,还可以通过了解项目背景来明确用户单位建网的目的,从而有助于描述详细的功能需求。
 
       继承
        继承可以在类型的级别上进行,也可以在表级别上进行,下面分别介绍。
               类型继承
               如希望在数据库中对那些是学生和教师的人分别存储一些额外的信息。
               由于学生和教师是人,所以可以使用继承。在SQL-99中定义学生和教师类型如下:
               
               Student和Teacher都继承了Person的属性,即name和address。Student和Teacher被称为Person的子类型,Person是Student的超类型,同时也是Teacher的超类型。像属性一样,结构类型的方法也被它的子类型继承。不过,子类型可以通过在一个方法声明中使用overriding method(重载方法)取代原method(方法)的方式重新声明方法,以重定义该方法的作用。
               现在假定要存储关于助教的信息,这些助教既是学生又是教师,甚至可能是在不同的系里。可以利用多重继承(multiple inheritance)的方法来做。SQL-99标准不支持多重继承,然而SQL-99标准是提供多重继承的,尽管SQL-99最终版中忽略了它,但SQL标准的未来版本可能会引入它。基于SQL-99标准的草案来讨论问题。
               TeacherAssistant将继承Student和Teacher的所有属性。由于name和address属性实际上是从同一个来源即Person继承来的,因此同时从Student和Teacher中都继承这两个属性不会引起冲突。但是,一个助教既可能是某个系的学生同时又是另一个系的教师,所以department属性在Student和Teacher中分别都有定义。为了避免两次出现的department之间的冲突,我们可以使用as子句将它们重新命名,如下面的TeachingAssistant类型定义所示:
               
               注意SQL-99只支持单继承,即一个类型只能继承一种类型,使用的语法如例8.35。TeachingAssistant例子中的多重继承在SQL-99中是不支持的。SQL-99标准还需要在类型定义的尾部有一个特别的字段,取值为final或not final。其中,关键字final表示不能从给定类型创建子类型,not final表示可以创建子类型。
               SQL中的一个结构类型的值必须恰好只有一个“最明确类型(most-specific type)”,即每一个值被创建时必须关联到一个确定的类型,称为它的最明确类型。依靠继承,它也与它的最明确类型的每个超类型相关联。举例来说,假定一个实体具有类型Person,同时又具有类型Student,那么这个实体的最明确类型为Student,因为Student是Person的子类型。然而一个实体不能同时既具有类型Student又具有类型Teacher,除非这个实体具有一个如TeacherAssistant那样既是Student子类型又是Teacher的子类型的类型。
               表继承
               SQL-99中的子表(subtable)对应的是E-R概念中的特殊化/一般化。子表的类型必须是父表类型的子类型,因此,父表中的每一个属性均出现在子表中。
               定义子表students和teachers如下:
               
               当我们声明students和teachers作为people的子表时,每一个students或teachers中出现的元组也隐式存在于people中。如果一个查询用到people表,它将查找的不仅仅是直接插入到这个表中的元组,而且还包含插入到它的子表(也就是students和teachers)中的元组。但是,只有出现在people中的属性才可以被访问。
               多重继承也可在表进行。例如,创建一个类型为TeachingAssistant的表:
               
               作为声明的结果,每一个在teaching-assistants中出现的元组也隐式地在表teachers和students中出现,从而也出现在people表中。SQL-99允许在查询中使用“only people”代替people来查询只在people中而不在它的子表中的元组。
               对子表的一致性要求。如果一个子表和一个父表中的元组对于所有的继承属性具有同样的值,则称子表中的元组符合(correspond to)父表中的元组。因此,相符合的元组表示同一个实体。子表的一致性需求为:
               .父表的每个元组至多可以与它的每个直接子表的一个元组符合。
               .SQL-99有一个附加的约束,所有相符合的元组必须由一个元组派生(插入到一个表中)。
               例如,若没有第一个条件,我们就可能在students(或teachers)中有两个元组与同一个人符合。第二个条件排除了people中的一个元组分别符合students和teachers中的一个元组的情况,除非所有这些元组都隐式出现。这是由于一个元组会被插入到一个既是teacher的子表又是students的子表的teaching-assistants表中。
               由于SQL-99不支持多重继承,所以第二个条件实际上阻止一个人既是老师又是学生。即使支持多重继承,这个问题在没有子表teaching-assistants时也会出现。显然,建立一个即使没有teaching-assistants子表也可以让一个人既是老师又是学生的环境是很有用的。因此,去掉第二个一致性约束是有用的。
               子表可以采用无须复制所有的继承字段的有效方式进行存储,通常有如下两种方式:
               .每一个表只存储主码(可能是从父表中继承来的)和局部定义的属性。继承属性(主码之外的)不需要存储,因为它可以基于主码与父表连接得到。
               .每一个表存储所有继承的和局部定义的属性。当插入一个元组时,它仅仅存储在它被插入的那个表中,在它的每个父表中推断它的出现。因为不需要连接,所以可快速访问元组的所有属性。不过,一旦没有第二个一致性约束(即一个实体可能出现在两个子表中而不在它们的公共子表中出现),这种表达将导致信息重复的问题。
 
       架构设计
        WebApp描述了使WebApp达到其业务目标的基础结构,典型使用多层架构来构造,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器,以及可以包含WebApp的业务规则的内容层或模型层,描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器(Model-View-Controller,MVC)结构是WebApp基础结构模型之一,它将WebApp功能及信息内容分离。
 
       市场调研
        市场调研包括考察行业情况和供应商的能力。
 
       数据层
        数据层主要包括银行信息系统的处理对象——客户数据和账务数据。当前,银行普遍采用总行数据大集中的管理模式。为了充分发挥数据大集中管理和综合前置平台的功能,需要对数据分布进行合理规划,明确哪些数据放置在总行数据大集中服务器,哪些数据放置在分行前置平台。银行信息系统中的数据包括:
        (1)客户信息数据。包括授信客户的各种风险评估资料和经营状况资料在内的客户信息数据存放在总行数据大集中服务器上,便于全行集中式风险控制和数据仓库技术的应用。
        (2)综合账务数据。包括对公、对私账务数据,由于账务系统是运行在总行数据大集中服务器上的,所以这些数据全部应存放在总行数据大集中服务器上。
        (3)信用卡账务数据。信用卡系统也运行在总行数据大集中服务器上,所以这些数据也应存放在总行数据大集中服务器上。
        (4)中间业务的客户数据。由于中间业务是本地化特色很强的金融业务,所以中间业务的客户资料数据在不同分行会有不同的表述,很难由总行统一实现,这些数据主要存储在各地分行的前置平台上。
        (5)清算和对账数据。在金融交易中,银行会与金卡、券商等银行客户进行对账,与本地网上支付网关进行对账。在对账时,分支行负责和所有的清算单位(金卡、电信等)对账,主要通过勾对流水的方式来进行处理,然后与总行统一勾对账务信息。所以在下属分行的前置平台应存放清算与对账的交易流水信息。
        (6)地方性安全认证数据。出于对各地安全措施千差万别的考虑,例如,各地分行对公同城通兑方式不同,IC卡安全论证方式不同等,对交易进行合法性校验的安全认证信息最好应存放在下属分行的前置平台,由下属分行负责这些数据的安全。
 
       数据库
        数据库(DataBase,DB)是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储,具有较小的冗余度、较高的数据独立性和易扩展性,并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
   题号导航      2015年下半年 系统架构设计师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第5题    在手机中做本题