免费智能真题库 > 历年试卷 > 系统分析师 > 2016年上半年 系统分析师 上午试卷 综合知识
  第36题      
  知识点:   遗留系统的处理策略   继承
  关键词:   继承        章/节:   系统运行       

 
遗产系统(Legacy System)的演化策略分为淘汰策略、继承策略、改造策略和集成策略。具有(36)特点的系统适合用继承策略演化。实施该策略时,应(37)。
 
 
  A.  技术含量低,具有较低的业务价值
 
  B.  技术含量较低,具有较高的商业价值,目前企业的业务尚紧密依赖该系统
 
  C.  技术含量较高,基本能够满足企业业务运作和决策支持的需要
 
  D.  技术含量较高,业务价值低,可能只完成某个部门(或子公司)的业务
 
 
 

 
  第37题    2016年上半年  
   64%
遗产系统(Legacy System)的演化策略分为淘汰策略、继承策略、改造策略和集成策略。具有(36)特点的系统适合用继承策略演化。实..
  第64题    2022年上半年  
   53%
遗留系统 (Legacy System)是指任何基本上不能进行修改和演化以满足新的业务需求变化的信息系统。针对遗留系统的再利用问题,通..
  第63题    2022年上半年  
   61%
遗留系统 (Legacy System)是指任何基本上不能进行修改和演化以满足新的业务需求变化的信息系统。针对遗留系统的再利用问题,通..
   知识点讲解    
   · 遗留系统的处理策略    · 继承
 
       遗留系统的处理策略
        遗留系统(Legacy System)也称为遗产系统,它是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。遗留系统应该具有以下特点:
        (1)系统虽然完成企业中许多重要的业务管理工作,但已经不能完全满足要求。一般实现业务处理电子化及部分企业管理功能,很少涉及经营决策。
        (2)系统在性能上已经落后,采用的技术已经过时。如多采用主机/终端形式或小型机系统,软件使用汇编语言或第三代程序设计语言的早期版本开发,使用文件系统而不是数据库。
        (3)通常是大型的系统,已经融入企业的业务运行和决策管理机制之中,维护工作十分困难。
        (4)系统没有使用现代系统工程方法进行管理和开发,现在基本上已经没有文档,很难理解。
        在企业信息系统升级改造过程中,如何处理和利用遗留系统,成为新系统建设的重要组成部分。处理的恰当与否,直接关系到新系统的成败和开发效率。
               遗留系统的评价方法
               对遗留系统评价的目的是为了获得对遗留系统更好的理解,这是遗留系统演化的基础,是任何遗留系统演化项目的起点。评价方法由一系列活动组成:
               (1)启动评价。评价是为了获得对遗留系统足够深度的理解,从技术、商业和企业角度对系统的理解为系统处理策略提供基础。
               (2)商业价值评价。商业价值评价的目标是判断遗留系统对企业的重要性,可以在概要和详细两个级别上进行遗留系统的商业价值评价。
               (3)外部环境评价。系统的外部技术环境是指硬件、支撑软件和企业基础设施的统一体。
               (4)应用软件评价。应用软件评价也有两个级别,分别是系统级和部件级。
               (5)分析评价结果。评价活动将产生硬件、支撑软件、企业基础设施和应用软件的特征值矩阵,这些特征值体现了遗留系统当前的技术因素,其加权平均值代表了系统的技术水平。
               遗留系统的演化策略
               遗留系统的演化方式可以有很多种,根据系统的技术条件、商业价值以及维护和运行系统的组织特征不同,可以采取继续维护、某种形式的重构或替代策略,或者联合使用几种策略。究竟采用哪些策略来处理遗留系统,需要根据对遗留系统的所有系统特性的评价来确定。
               (1)淘汰策略。遗留系统的技术含量较低,且具有较低的商业价值。对这种遗留系统的演化策略为淘汰,即全面重新开发新的系统以代替遗留系统。完全淘汰是一种极端性策略,一般是企业的业务产生了根本的变化,遗留系统已经基本上不再适应企业运作的需要;或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价,发现将遗留系统完全淘汰,开发全新的系统比改造旧系统在成本上更合算。对遗留系统的完全淘汰是企业资源的根本浪费,我们应该善于“变废为宝”,通过对遗留系统功能的理解和借鉴,可以帮助新系统的设计,降低新系统开发的风险。
               (2)继承策略。遗留系统的技术含量较低,已经不能满足企业运作的功能或性能要求,但仍具有较高的商业价值,目前企业业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时,需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性,新老系统必须并行运行一段时间,再逐渐切换到新系统上运行。要做到对遗留系统的继承,必须对系统进行分析,得到旧系统的功能模型和数据模型,这种分析可以部分代替或验证系统的需求分析。如果遗留系统的维护文档已经不完全了,而我们又必须解析系统的功能模型和数据模型,那将是一项十分艰巨的任务。这时可使用有关系统重构的CASE(Computer-Aided Software Engineering,计算机辅助软件工程)工具,通过分析系统的代码产生出系统结构图或其他报告。
               (3)改造策略。遗留系统的技术含量较高,本身还有较大的生命力,且具有较高的商业价值,基本上能够满足企业业务运作和决策支持的要求。这种系统可能建成的时间还很短,对这种遗留系统的演化策略为改造。这些改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求,对遗留系统本身不做改变。数据模型的改造指将遗留系统的旧数据模型向新数据模型的转化。
               (4)集成策略。遗留系统的技术含量较高,但其商业价值较低,可能只完成某个部门(或子公司)的业务管理。这种系统在各自的局部领域里工作良好,但对于整个企业来说,存在多个这样的系统,不同的系统基于不同的平台,不同的数据模型。对这种遗留系统的演化策略为集成。在集成过程中,可采用由互连系统构成的系统的体系结构,遗留系统可作为从属系统来描述。
 
       继承
        继承可以在类型的级别上进行,也可以在表级别上进行,下面分别介绍。
               类型继承
               如希望在数据库中对那些是学生和教师的人分别存储一些额外的信息。
               由于学生和教师是人,所以可以使用继承。在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子表也可以让一个人既是老师又是学生的环境是很有用的。因此,去掉第二个一致性约束是有用的。
               子表可以采用无须复制所有的继承字段的有效方式进行存储,通常有如下两种方式:
               .每一个表只存储主码(可能是从父表中继承来的)和局部定义的属性。继承属性(主码之外的)不需要存储,因为它可以基于主码与父表连接得到。
               .每一个表存储所有继承的和局部定义的属性。当插入一个元组时,它仅仅存储在它被插入的那个表中,在它的每个父表中推断它的出现。因为不需要连接,所以可快速访问元组的所有属性。不过,一旦没有第二个一致性约束(即一个实体可能出现在两个子表中而不在它们的公共子表中出现),这种表达将导致信息重复的问题。
   题号导航      2016年上半年 系统分析师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第36题    在手机中做本题