免费智能真题库 > 历年试卷 > 系统架构设计师 > 2013年下半年 系统架构设计师 上午试卷 综合知识
  第28题      
  知识点:   新旧系统的分析和比较   继承
  关键词:   继承        章/节:   系统开发基础知识       

 
遗留系统的演化可以采用淘汰、继承、改造和集成四种策略。若企业中的遗留系统技术含量较高,业务价值较低,在局部领域中工作良好,形成了一个个信息孤岛时,适合于采用(28)演化策略。
 
 
  A.  淘汰
 
  B.  继承
 
  C.  改造
 
  D.  集成
 
 
 

 
  第27题    2013年下半年  
   39%
以下叙述中,(27)不属于可行性分析的范畴。
  第37题    2015年下半年  
   53%
对于遗留系统的评价框架如下图所示,那么处于“高水平、低价值”区的遗留系统适合于采用的演化策略为( )。
 
   知识点讲解    
   · 新旧系统的分析和比较    · 继承
 
       新旧系统的分析和比较
        新旧系统分析和比较的主要目的包括:
        (1)评估旧系统存在的问题,评估升级旧系统的价值和升级的代价。
        (2)在项目可行性分析和方案设计阶段,通过分析旧的系统,寻找旧系统中存在的主要问题,为新的系统的设计目标提供参考。
        (3)在新系统方案确定后,进行新旧系统比较以便验证新系统的设计是否完备。
        (4)理解新旧系统之间的差异、确定新旧系统转换的技术路线。
               分析原则
               为了明确旧系统完成的功能,需要对旧系统进行建模。对旧系统的建模,可使用类似数据流图、数据字典这样的工具进行高阶的业务建模。旧系统的分析结果可以是若干高阶的数据流图、功能点清单和性能清单等。其中描述了旧系统的主要工作过程、功能和问题。
               (1)比较新旧系统。通过比较新旧系统的逻辑模型、并参考新系统的目标和规模、可以确定新旧系统的主要差异。对新系统提出的要求至少包括:新系统必须实现旧系统的基本功能;新系统必须改正旧系统存在的问题,包括错误、缺陷;新系统应提供全新的功能和性能、并覆盖需求和分析阶段发现的软件需求。
               (2)复查问题。完成新系统设计后,复查在分析旧系统阶段发现的全部问题定义、并根据新系统的设计模型比较系统规模、功能改变、性能改进、与预期的开发目标之间的关系等,检查是否存在系统分析师对系统的误解、或在新方案设计中没有涵盖的潜在问题。
               (3)控制规模。对旧系统的分析和建模,应控制在一个较小的开销规模上。因为新旧系统比较的目的主要是发现和复查问题,而不是得到旧系统的详细设计。
               转换策略
               根据新旧系统比较的结果,可以得到未来新系统建设完成后的转换策略。通常新旧系统的转换有直接转换、逐步转换和并行转换3种主要的策略。
               (1)直接转换策略。新系统是完全重构的系统,可能采用了全新的技术平台和软件来构建、或者用户业务和使用方式发生了剧烈变化,对原有系统只能进行抛弃处理。采用这种策略的优点是新系统能够非常灵活地适应业务需要,功能齐全、结构合理、系统稳定、扩展性强,整个软件系统的利用率比较高。但也存在着一些问题,主要是:
               .新旧系统之间的转换代价比较大;
               .由于需要一套比较完整的业务需求,开发新系统的周期比较长,一次性投资巨大,未经广泛使用并证明是成熟可靠的新技术平台通常具有一定的技术风险;
               .旧系统通常积累下了大量的业务数据、必须将业务数据的录入、转换、检查以及在新系统中的重建作为重要的工作进行考虑,尽量减小在新旧系统转换的时候对用户现有业务的冲击;
               新旧系统转换还需要考虑诸如:维持新系统运行的日常开销、由于使用习惯改变带来的学习时间、培训人员的成本等因素。
               (2)逐步转换策略。逐步转换策略又称为分段转换、向导转换、试点过渡法等。这种策略是部分继承原有系统,部分进行新系统的更新和开发的技术路线,每成熟一部分新系统软件,就更新一部分旧系统软件,最终采取渐进的方式,过渡到新的软件平台上来。这种策略的优点是,新旧系统的转换震动比较小,用户容易接受,但也由于是采用渐进式,导致新旧系统的转换周期加长,同时由于需求的变化,给新系统的稳定造成比较大的影响。在转换过程中,需要开发新旧系统之间的接口、还需要制订阶段性的转换目标和计划。
               (3)并行转换策略。这种策略是在一定的阶段并行使用新旧系统,将同样的业务在新旧系统中都完成一次。然后在确认新系统已经可以稳定工作后、停止旧的系统和全面启用新系统。并行转换策略会较多增加用户的工作量,并且难以控制新旧系统中的数据变化,因此很少使用。
               :对于现有信息系统比较稳定、能够适应自身业务发展需要的建设单位、或新旧系统转换风险很大(例如:订票系统或银行的中间业务系统),可以采用渐进方式;对于现有信息系统本身就存在问题,比如已经不能满足业务需要,存在安全、性能等方面问题的,应采用直接转换策略。
 
       继承
        继承可以在类型的级别上进行,也可以在表级别上进行,下面分别介绍。
               类型继承
               如希望在数据库中对那些是学生和教师的人分别存储一些额外的信息。
               由于学生和教师是人,所以可以使用继承。在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子表也可以让一个人既是老师又是学生的环境是很有用的。因此,去掉第二个一致性约束是有用的。
               子表可以采用无须复制所有的继承字段的有效方式进行存储,通常有如下两种方式:
               .每一个表只存储主码(可能是从父表中继承来的)和局部定义的属性。继承属性(主码之外的)不需要存储,因为它可以基于主码与父表连接得到。
               .每一个表存储所有继承的和局部定义的属性。当插入一个元组时,它仅仅存储在它被插入的那个表中,在它的每个父表中推断它的出现。因为不需要连接,所以可快速访问元组的所有属性。不过,一旦没有第二个一致性约束(即一个实体可能出现在两个子表中而不在它们的公共子表中出现),这种表达将导致信息重复的问题。
   题号导航      2013年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第28题    在手机中做本题