系统架构设计师下午试题Ⅰ模拟1含详细答案.pdf

高级系统架构设计师下午试题高级系统架构设计师下午试题()模拟模拟1 试题一试题一 阅读以下软件架构设计的叙述，根据要求回答问题。 说明 某大型电子商务企业的主要业务之一是网上书城，其主要功能是通过Internet为用户提供各种图书 信息的在线查询、浏览及订购相关图书等多种服务。PH软件公司承接了该大型网上书城系统的升级 改造开发任务。该软件公司的领域专家对需求进行深入分析后，得到的部分系统需求如下。 1用户可能频繁地进行书目查询操作，网上书城需要返回众多符合条件的书目并且分页显示，而且可 能每次查询的内容都不一样。 2网站管理员需要批量对相关书目信息进行修改，并且将更新信息记录到数据库。 3随着该网上书城知名度的不断提升，每天的业务量非常多，网站的用户访问量越来越大，因此对业 务有持续性要求，且要求有限的资源更加合理地规划和使用。 4随着该企业业务规模的不断扩展，网上书城并购了多家其他同类的网上书城，需要将后台异构数据 库系统进行整合。 该软件公司的系统架构师经过多方的研究和论证， 集体提出了采用层次式架构风格设计该大型网上书 城系统，包括表现层、业务逻辑层和数据访问层。 1、问题1 数据访问层负责与应用中的各种数据源打交道，并将它们整合起来，为业务逻辑层提供统一的数据服 务。请对该大型网上书城的4个需求进行分析，结合你的系统架构经验，将表212中每个需求适合选 用的数据访问模式及选择理由填充完整。 表2-12网上书城数据访问层设计 系统需求数据访问模式选择理由 (1)(2) (3)(4) (5)(6) 专用产品(如WebSphere Information Integration等) (7) 2、问题2 业务逻辑的千变万化，使信息系统的开发和维护都变得越来越困难，如何构建灵活高度可扩展性的业 务层便成为亟待解决的问题。结合你的系统架构经验，请用200字以内的文字说明该网上书城业务逻 辑层采用业务容器(Business Container)架构方式的优点。 3、问题3 该网上书城表示层框架的设计，采用基于XML的界面管理技术，实现灵活的界面配置、界面动态生成 和界面定制。结合你的系统架构经验，请用350字以内的文字说明基于XML的界面管理技术的基本思 想及其主要组成部分的功能。 试题二试题二 阅读以下关于系统安全性和数据存储系统架构的叙述，根据要求回答问题。 说明 某市行政审批服务中心大楼内涉及几类网络，分别为因特网(Internet)、市电子政务专网、市电子 政务外网、 市行政审批服务中心大楼内局域网和各部门业务专网。行政审批服务中心网络建设工作组 计划以市电子政务专网为基础，建设市级行政审批服务中心专网(骨干万兆、桌面千兆)。在大楼内 部署5套独立链路，分别用于连接政务外网、政务专网、大楼内局域网、因特网和涉密部门内网。行 政审批服务中心网络结构(部分)如图28所示。 4、问题1 在图28所示的数据交换区中，数据交换服务器通过双链路连接至交换机。在数据交换服务器业务的 峰值时段，一条链路只能传送总业务量的90%，因而需要两条链路同时工作，才能完成数据交换服务 器的全部传送请求。 非峰值时段约占整个工作时间的60%， 只需要一条链路工作就可以传送全部业务。 假定每条链路的可用性为0.9，请计算这两条链路系统(数据交换区中虚线椭圆区域)的平均可用性 (注：请简要列出计算过程)。 5、问题2 电子政务安全体系是一个立体的三维防护体系，图28中的安全接入平台横跨了行政审批服务中心大 楼内所涉及的5个网络系统，需要全系统统一考虑其的IT安全措施和手段。结合你的系统架构经验， 请给出该安全接入平台在系统安全架构方面的主要考虑要点。 6、问题3 针对该行政审批服务中心数据存储系统建设，架构师郭工建议使用FC SAN/IP SAN提供数据安全和 快速数据访问。请用300字以内的文字，简述郭工所提建议中的FC SAN和IP SAN的差别。 试题三试题三 阅读以下关于设计模式应用的叙述，根据要求回答问题。 说明 某软件公司承接了一项面向儿童的模拟游戏软件的开发任务， 该游戏软件主要模拟现实世界中各种鸭 子的发声特征、飞行特征和外观特征。游戏软件需要模拟的鸭子种类及其特征如表213所示 表213鸭子种类及其特征 鸭子种类发声特征飞行特征外观特征 灰鸭 (MallardDuck) 发出“嘎嘎”声 (Quack) 用翅膀飞行 (FlyWithWings) 灰色羽毛 红头鸭 (RedHeadDuck) 发出“嘎嘎”声 (Quack) 用翅膀飞行 (FlyWithWings) 灰色羽毛、 头部红色 棉花鸭 (CottonDuck) 不发声 (QuackNoWay) 不能飞行 (FlyNoWay) 白色 橡皮鸭 (RubberDuck) 发出橡皮与空气摩 擦的声音 (Squeak) 不能飞行 (FlyNoWay) 黑白橡皮颜色 为支持将来能够模拟更多种类鸭子的特征，该公司架构师采用某种设计模式设计的类图如图2-9所 示。在图29中，类Duck描述了抽象的鸭子，方法fly7、quack7和display7分别表示不同种类的 鸭子都具有飞行特征、发声特征和外观特征；类FlyBehavior与QuackBehavior分别用于表示抽 象的飞行行为与发声行为。 /newyfB12/tu/1212/j/sp/gj/xwjs110.AF69C3.jpg 7、问题1 请用350字以内的文字指出该公司架构师所采用的设计模式的具体名称、设计意图及其优缺点。 8、问题2 请用400字以内的文字指出该公司架构师所采用的设计模式的适用性，以及图2-9中需要考虑哪些实 现问题? 9、问题3 设计模式在力度和抽象层次上各不相同。按设计模式的目的划分，可分为创建型、结构型和行为型3 种模式；按设计模式的范围划分，可分为类设计模式和对象设计模式两种。请将下列AJ标记的设 计模式填入到表214中的(1)(5)空缺处。(请用AJ答题) AAbstract Factory模式BAdapter模式CChain of Responsibility模式 DDecorator模式EFactory Method模式FFlyweight模式 GInterpreter模式HIterator模式ITemplate Method模式 JVisitor模式 表2-14设计模式空间 目 的 创建型结构型行为型 范 围 类(1)(2) 对 象(3)(4)(5) 试题四试题四 阅读以下关于UML软件系统建模的叙述，根据要求回答问题。 说明 车载GPS(Global Position System)终端是置于机动车内的实时定位装置，它的应用对象是需 要定位和调度的车辆。车辆可以通过终端与GPS进行实时、准确的定位，并能够通过无线通信网络上 报远程的车辆调度中心。 中心可以通过终端远程监视车行轨迹， 并可在特殊情况下通过终端控制车辆。 同时，终端还装备车载电话，可以在出现特殊情况时及时地通知车辆调度中心。 图210所示为车载终端系统的用例图，对于车载GPS终端系统来说，主要的角色有两个，分别为车 辆调度中心用户和车载终端用户。 /newyfB12/tu/1212/j/sp/gj/xwjs110.B24B5F.jpg 图211所示为车载终端系统中的GSM无线电通信模块的部分状态图，用于与调度中心进行联系。GSM 模块共有4个状态，分别为通话中、有问题、待命和短消息通信中。 /newyfB12/tu/1212/j/sp/gj/xwjs110.B1E16A.jpg 10、问题1 请将以下给出的转换关系填入图1-24所示的适当位置，从而将GSM无线电通信模块状态图补充完整。 转换关系：用户需要语言通话；通话完成；重新连接网络；未找到网络或网络出错。 11、问题2 车载终端用户在遇到特殊情况下通过车载电话(或按键)与调度中心保持通信的处理过程顺序图如图 2-12所示。 结合你的系统架构经验，以及对GPS终端系统的理解，请将下列AF标记的处理过程填入到图2-12 中的(1)(6)空缺处， 并给出通过车载电话(或按键)与调度中心保持通信的正确处理顺序(请用A F表达，例如ABCDEF.。 A语音对话/按下按钮B监听命令 C发送信息到通信模块D要求监听 E通过GSM发送信息F接收成功要求监听信息 12、问题3 建立顶层架构是基于UML对该车载GPS终端系统进行建模的步骤之一。顶层架构的主要目的是为后续 的分析和设计活动建立一种结构和分划，以便开发人员在不同阶段，以及同一开发阶段的不同开发人 员，能够聚集于系统的不同部分。结合你的系统架构经验，请简要说明在该车载GPS终端系统确立顶 层架构的过程中需要综合考虑哪些因素? 试题五试题五 阅读以下关于数据库系统架构方面的叙述，根据要求回答问题。 说明 随着政府职能的转型，XX行业职能主管部门(国家相关部委、各省、市的相关厅、局、委等)机构日 趋精简，但随着国家现代化的发展，业务量反而越来越大。为保证本行业管理工作的质量和效率， 提 高对宏观经济管理与决策的支持能力和对社会公众的公共服务能力，该行业主管部门委托MBI软件开 发公司开发一个XX行业宏观经济数据库管理系统。通过统计业务系统和相关部委自身的行业系统的 信息化建设，提高各自核心业务的应用能力和管理水平，特别是数据中心的建设，对基础业务信息实 施有效管理和有效利用；通过宏观经济数据库应用系统建设，建立起包括宏观经济管理决策支持和宏 观经济基础信息的发布查询等在内的支撑子系统；通过存储备份系统(现场级)的建设，为本行业宏 观经济基础信息资源实施安全、可靠的技术管理。 13、问题1 由于对政府数据的需求是多层次的，从而也要求政府部门信息系统具有较丰富的层次。但是，随着系 统结构、层次的增多，层次间的界限越来越模糊，信息系统建设及维护的成本也就越高。结合你的系 统架构经验， 请用500字以内的文字简要讨论基于数据库(DB.、 数据仓库(DW)和操作数据存储(ODS) 技术的政府信息系统的各自特点。 14、问题2 元数据库的建设与管理是数据仓库概念下数据中心工作模式中的重要环节， 它关系到整个数据中心系 统的结构和运行。结合你的系统架构经验，请用400字以内的文字简要说明元数据库系统所定义和管 理的处理包括哪些内容。 15、问题3 该行业主管部门对待建的数据库应用系统提出了明确的审计要求， 要求保留5年左右的审计跟踪信息。 MBI公司的架构师老张建议，直接在待建的数据库中插入审计跟踪信息以满足这一应用需求，架构师 老郭则建议采用按月分区(Partitioning)和段空间压缩技术来满足这一应用需求。请用400字以 内的文字简要说明这两种数据库审计方案的基本原理。 答案: 试题一试题一 1、 在层次式架构风格中， 数据访问层(数据持久层)主要负责和应用中的各种数据源(如DB2、 Oracle 等关系型数据源、XML数据及其他类型的非关系型数据、Web服务，以及各种特别的遗留系统等)打 交道，并将它们整合起来，为业务逻辑层提供统一的数据服务。架构师在不同的应用场合下可能会选 择不同的数据访问模式，并且还会不断地推陈出新，这里不会也不可能穷尽所有的数据访问模式， 而 只是列举了其中最为典型的几个。在线访问模式、Data Access Object模式、Data Transfer Object模式、离线数据模式，以及对象/关系映射(Object/Relation Mapping)模式是数据访 问层设计中典型的数据访问模式。各种数据访问模式的说明如表215所示。 表2-15各种数据访问模式 数据访问模式说明 在线访问模式 是最基本和最常用的数据访问模式，该 数据访问模式会占用一个数据库连接， 读取数据，每个数据库操作都会通 过这个连接不断地与后台的数据源进行 交互 DAO模式 是标准J2EE设计模式之一，常用这种模 式将底层数据访问操作与高层业务逻辑 分离开。一个典型的DAO实现 通常有以下组件：一个DAO工厂类； 一个DAO接口；一个实现了DAO接口的 具体类(包含访问特定数据 源的数据的逻辑)；数据传输对象(或 称为值对象) DTO模式 是经典EJB设计模式之一。DTO本身是这 样一组对象或是数据的容器，它需要跨 不同的进程或是网络的边界来 传输数据。这类对象本身应该不包含具 体的业务逻辑，并且通常这些对象内部 只能进行一些诸如内部一致性检查和 基本验证之类的方法，而且这些方法最 好不要再调用其他的对象行为 离线数据模式 以数据为中心：数据从数据源获取之后， 将按照某种预定义的结构(如SDO中的 Data图表结构、ADO.NET中 的关系结构)存放在系统中， 成为应用的 中心；离线：对数据的各种操作独立于 各种与后台数据源之间的连接或是 事务；与XML集成： 离线数据集所维护的 数据可以方便地与XMI。 格式的文档之间 互相转换；独立于数据源：该模 式的不同实现定义了数据的各异的存放 结构和规则，这些都是独立于具体的某 种数据源的 O/R映射 其指导思想来源于这样一种现实：大多 数应用中的数据都是依据关系模型存储 在关系型数据库中；很多应用 程序中的数据在开发或是运行时则是以 对象的形式组织起来的。 O/R映射就提供 了这样一种工具或是平台，能够 帮助将应用程序中的数据转换成关系型 数据库中的记录；或是将关系数据库中 的记录转换成应用程序中代码便于 操作的对象 依题意，在网上书城系统应用中，第1个系统需求是用户根据检查条件查询相关的书目，返回符 合条件的书目列表(可能内容非常多，数据量较大)，而且可能每次查询的内容都不一样。通常，针 对用户书目查询这一业务应用，如果查询返回的数据量并不是很大，同时也不频繁，则可以考虑采用 在线访问的模式；如果返回的数据量较大(比如返回众多符合条件的书目并且分页显示)而且较为频 繁，则需要考虑在线访问模式和离线数据模式相结合，通过离线数据的缓存来提高查询性能。 第2个系统需求是网站管理员可能需要批量对相关书目信息进行修改，并且需要将更新的信息返 回至数据库。此类数据应用的特点表现为，与数据库交互的次数并不频繁，但是每次操作的数据量相 对较大；同时，也希望能够使得本地操作有较好的交互体验。针对这种应用情况，往往适合采用离线 数据访问的模式，DTO模式也是不错的选择。如果该网上书城应用系统采用的是IBM WebSphere平 台，则可以使用SDO技术，或者使用Java中的CachedRowSet技术；如果采用的是基于微软的应用 系统平台，则可以采用ADO.NET技术。 第3个系统需求是一个关于“多用户并发访问”的需求， 如何让网上书城应用系统能够处理大规模 的并发用户访问是一个很复杂的问题，涉及应用的架构、采用的软件、相应的配置和应用程序的调优 等方面的问题。对于数据访问层设计，一个常见的方法是使用连接池的模式，以便能够处理更多的用 户请求。如果在网上书城应用系统中使用了IBM WebSphere Application Server(或BEA WebLogic、Tomcat等)应用服务器，则这些应用服务器都提供了连接池的机制。 第4个系统需求是一个关于“整合异构数据源”的需求，因为有了新的、不同类型的数据库系统的 加入，需要和旧的数据库系统进行整合。后台数据系统种类繁多，配置复杂的情况是随处可见的。 可 能这个网上书城在刚刚起步的时候只是用了MS SQL Server 2000来作为后台数据源。后来随着业 务的增加，又有了新的Oracle(或DB2)系统。除此之外，可能还有很多诸如XML文档等需要和已有 的系统集成起来，这些都是令人头痛的问题。在很多实际项目中，经常需要软件开发公司花很大的力 气开发一些导入/导出工具来集成此类数据， 而现在已经有了专门的产品来完成这些任务。 例如， IBM WebSphere InformationIntegration等产品就可以用来支持各种关系型数据源及非关系型数 据源的数据整合。2、业务逻辑层框架位于系统架构的中间层，是实现系统功能的核心组件。 业务逻辑层采用业务容器(Business Container)架构方式，便于系统功能的开发、代码重用和管 理。业务层采用业务容器的方式存在于整个系统当中，可以大大地降低业务层和相邻各层的耦合。 表 示层和业务层的交流是通过业务请求来实现的，表示层代码只需要将业务参数传递给业务容器，之后 就不需要业务层多余的干预，所有业务代码均是在业务容器中运行。如此一来，可以有效地防止业务 层代码渗透到表示层，从而实现了业务层相对于表示层的透明化。3、基于XML的界面管理技 术的基本思想是，用XML生成配置文件及界面所需的元数据，按不同需求生成界面元素及软件界面。 该技术包括界面配置、界面动态生成和界面定制3部分。 界面配置是对用户界面的静态定义，通过读取配置文件的初始值对界面配置。由界面配置对软 件功能进行裁剪、重组和扩充，以实现特殊需求。 界面定制是对用户界面的动态修改过程，在软件运行过程中，用户可按需求和使用习惯，对界 面元素(如菜单、工具栏、键盘命令)的属性(如文字、图标、大小、位置等)进行修改。软件运行结 束，界面定制的结果被保存。 系统通过DOM API读取XML配置文件的表示层信息(初始界面大小、位置等)，通过自定义的数 据存取类读取数据库中的数据层信息，在运行时循环生成界面元素，动态生成界面。界面配置和定制 模块在软件运行前后，通过修改相应的配置文件，就可以达到更改界面内容的目标。 基于XML的界面管理技术实现的管理信息系统，实现了用户界面描述信息与功能实现代码的分 离，可针对不同用户需求进行界面配置和定制，能适应一定程度内的数据库结构改动，只需对XML文 件稍加修改，即可实现系统的移植。 试题二试题二 4、可用性是指网络或网络设备(如服务器等)可用于执行预期任务时间所占总量的百分比。依题意， 试题中只要求计算图28数据交换区中虚线椭圆区域内两条链路系统的平均可用性，因此可以暂不考 虑这两条链路两端交换机端口及网卡的可用性(或者可将这两条链路两端交换机端口及网卡的可用性 假设为1.0)。 由于每条链路的可用性A=0.9，则两条链路同时工作时的可用性为AA=0.90.9=0.81，恰好 只有一条链路可以工作时的可用性为A(1-A)+(1-A)A=2A(1-A)2=20.9(1-0.9)2=0.18。 由于在数据交换服务器业务的峰值时段，一条链路只能传送总业务量的90%，需要两条链路同时 工作，此时这两条链路系统的可用性Af可表示为：Af=(两条链路的处理能力)(两条链路同时工作时 的可用性)+(一条链路的处理能力)(只有一条链路工作时的可用性)。因此在峰值时段，这两条链 路系统的可用性为A峰值时段=1.00.81+0.90.18=0.972。 在非峰值时段，只需要一条链路工作就可以传送全部业务，此时这两条链路系统的可用性为A非峰 值时段=1.00.81+1.00.18=0.99。 由于非峰值时段约占整个工作时间的60%，即峰值时段约占整个工作时间的40%，因此这两条链 路系统的平均可用性为Af=0.4A峰值时段+0.6A非峰值时段=0.40.972+0.60.99=0.9828。5、 电子政务安全体系是一个立体的三维防护体系，其设计出发点是：政务内网(或政务专网等涉密内 网)系统必须保证万无一失；政务外网系统做到适度安全，合理平衡系统运行效率和系统安全； 因特网(Internet)公共服务系统以适用、实用为主。在图28所示的行政审批服务中心部分网络结 构图中，政务专网和经审批通过的涉密部门内网主要用于涉密信息的处理、传输和存储。这两个网络 系统的建设重点是防止泄密，因此应严格按照国家对于涉密信息系统的要求，采取安全措施进行建设 和实施。其主要的安全措施包括加密、访问控制、权限控制和身份鉴别等。 政务外网和大楼内局域网主要完成大多数非敏感的政务管理和服务功能。这两个网络系统的主 要用户是公务员，因此安全重点在于防止与控制公务员异常活动，抵抗和防护来自外部网络的攻击。 除了涉密信息外，大量的电子政务信息都汇聚和存放在这两个网络系统内。确保数据安全是这两个系 统安全的核心内容，具体而言主要包括以下内容。 (1)数据访问范围的控制。 这两个网络系统中处理保存的数据主要是大量反映社会状态的内部信 息，必须确保这些信息只能在这两个网络系统中流转，确保只在指定的职能部门及相关人员之间流动 和处理。 (2)数据完整性的保护。 这两个网络系统中处理保存的大量数据是电子政务业务部门履行管理和 服务职能所必需的，数据是否准确直接影响政府的决策和国家政务的执行，确保数据完整性和准确性 是这两个网络系统安全最重要的工作之一。 (3)系统可用性的保障。这两个网络系统是政府公务员直接使用的网络，其可用性的降低和破坏 将直接影响政府的运行效率，必须保证该系统不会因信息安全事故造成系统停止工作。 Internet公共服务网主要是提供电子政务系统与公众的出入口， 其安全重点在于确保出入口的 安全，防止攻击者通过该网络系统进入电子政务系统，同时确保图2-8中对外服务平台中相关服务器 的高度可用性。 在图28中，安全接入平台横跨了以上5个网络系统，需要全系统统一考虑其的IT安全措施和手 段，具体考虑要点如下。 (1)网络系统对接和信息交换的安全。在图28中，政务专网和涉密部门内网要通过网闸之类的 安全设备与政务外网实现物理隔离，实现了纯数据摆渡，有效地抵抗利用网络协议的攻击，为政务内 网建立起可靠的边界保护。政务外网与：Internet服务网之间可以通过防火墙之类的安全设备实现 逻辑隔离。在政务专网和政务外网分别安装内、外数据交换服务器，这些服务器都采用双网卡配置， 一块网卡接政务内(外)网和另一块接网闸。政务专网与涉密部门内网之间、涉密部门内网与政务外 网之间也做类似的数据交换服务器配置， 使得这些数据交换服务器成为不同网络之间数据传输的唯一 通道，从而进一步加强各个网络系统之间信息交互的安全性。 (2)信息中加带密级和敏感度标记。例如，政务外网与政务内网所有的应用数据都必须带有信息 密级范围和敏感度标识的标记。原则上，不同范围的信息、不同密级的信息不能够自由交换，系统中 应专门设置专用的信息内容检查和权限控制管理设施，用于对系统内信息的流转进行控制和处理。 因 此在政务外网和政务内网应分别建立起基于公钥证书的认证服务器，由其为内、外网各自的数据交换 服务器进行认证，并用认证所产生的会话密钥对所有通过本服务器通道的数据进行标识，从而保证了 通道数据的完整性(不可篡改，更不能发送未经标记的数据)。结合数据摆渡和认证标记技术，在安 全接入平台的底层建立了安全的数据摆渡机制。 (3)严格定义交换的数据。例如，对于政务外网与政务内网的信息交换和交流，只可以采用应用 数据交换的方式，并且要求应用数据必须严格定义，原则上不能够交换可用做程序(或类似功能)的 数据。 (4)设置访问控制。例如，对于政务外网与Internet服务网的信息交换和交流，可以采用网络 层信息交换，设置访问控制的方式进行，典型措施是防火墙。此外还可以考虑使用应用层安全系统和 权限控制系统。例如，采用融合公钥技术或Kerberos认证协议的认证方案，即采用公钥技术作为认 证的手段， 结合Kerberos协议的会话密钥分发机制， 在分发会话密钥的同时， 分发用户的属性证书。 该方案具有公钥体系的强认证特性，避免了Kerberos认证体系中的中心数据库的脆弱性，同时可在 单一的一个协议中完成认证和授权双重功能。并在方案中结合KMI技术，采用属性证书的方式表示 RBAC的访问控制属性，而形成一个单一的单点登录授权体系。 (5)公务员权限管理系统。 公务员统一的权限管理中心对电子政务所涉及的所有公务员用户的权 限进行统一管理， 支持电子政务工程所涉及的所有应用系统。 安全接入平台的安全服务包括登录服务、 授权服务和审计服务。平台上运行的应用软件利用登录服务向平台认证，并通过授权服务向平台的其 他服务(包括应用软件向平台注册的服务)取得授权。 (6)用户管理系统。电子政务信息系统的用户管理分为3类用户的管理：自然人用户的管理； 法人用户的管理；公务员用户的管理。前两类用户的管理是基于相应的职能部门数据库(如居民 可与户口、社保等系统统一)，应全系统统一管理；公务员用户的管理则需要另外建设。公务员统一 管理系统需要同时支持政务内网和政务外网等相关网络系统上的应用。 (7)安全资源管理中心。 安全资源管理中心是用于对电子政务所涉及的所有安全技术手段进行管 理的中心，该中心负责所有信息安全相关设备，软件的配置，安全事件的记录和管理，设备故障的发 现和处置，所有安全相关策略、参数及数据的自动升级、维护和发布。例如，通过安装流量监测和监 管服务器，实现对接入平台运行情况进行安全监测与审计，对接入平台及业务信息进行注册管理、 各 种安全策略管理、流量监测、统计分析和安全审计等。6、存储区域网络(SAN)是一个由存储 设备和系统部件构成的网络。所有的通信都在一个与应用网络隔离的单独的网络上完成，可以被用来 集中和共享存储资源。实现SAN的硬件基础设施的是光纤通道，用光纤通道构筑的SAN由3部分构成， 分别为存储和备份设备(包括磁带库、磁盘阵列和光盘库等)、光纤通道网络连接部件(包括主机总线 适配卡(HBA)、驱动程序、光缆(线)、集线器、交换机、光纤通道与SCSI间的桥接器(Bridge)等)， 以及应用和管理软件(包括备份软件、存储资源管理软件和设备管理软件)。 SAN置于LAN之下，而不涉及LAN。利用SAN不仅可以提供大容量的存储数据，而且地域上可以 分散，并缓解了大量数据传输对局域网的影响。SAN的结构允许任何服务器连接到任何存储阵列，不 管数据放置在哪里，服务器都可以直接存取所需的数据。 相对于传统的存储架构， SAN不必宕机或中断与服务器的连接即可增加存储，还可以集中管理数 据，从而降低总体拥有成本。利用协议技术，SAN可以有效地传输数据块。通过支持在存储和服务器 之间传输海量数据块，SAN提供了数据备份的有效方式。 SAN分为FC SAN、IP SAN和IB SAN等。其中，FC SAN使用专用光纤通道设备，IP SAN使用 通用的IP网络及设备，因此FC SAN与IP SAN相比传输速度高，但价格比IP SAN高。 从应用上来说，相对于IP SAN，FC SAN可以承接更多的并发访问用户数。当并发访问存储的 用户数不多时， FC SAN与IP SAN两者的性能相差无几。 但一旦外接用户数呈大规模增长趋势， FCSAN 就显示出其在稳定性、安全性及高性能等方面的优势。在稳定性方面，由于FC SAN使用高效的光纤 通道协议，因此大部分功能都是基于硬件来实现的。例如，后端存储子系统的存储虚拟通过带有高性 能处理器的专用RAID控制器来实现，中间的数据交换层通过专用的高性能ASIC来进行基于硬件级的 交换处理，在主机端通过带有ASIC芯片的专用HBA来进行数据信息的处理。因此在大量减少主机处 理开销的同时，也提高了整个FC SAN的稳定性。在安全性方面，FC SAN是服务器后端的专用局域 网络，安全性比较高。 采用IP SAN可以将SAN为服务器提供的共享特性及IP网络的易用性很好地结合在一起，且为用 户提供了类似于服务器本地存储的高性能体验。iSCSI是实现IP SAN最重要的技术。在iSCSI出现 之前，IP网络与块模式(主要是光纤通道)是两种完全不兼容的技术。由于iSCSI是运行在TCP/IP 之上的块模式协议，它将IP网络与块模式的优势很好地结合起来，使得lP SAN的成本低于FC SAN。 基于iSCSI标准的IP SAN提供了Initiator与目标端两方面的身份验证(使用CHAP、SRP、 Kerberos和SPKM)，能够阻止未经授权的访问，只允许那些可信赖的节点进行访问，可通过IPSec 确保其数据的安全性。 由于IP技术的普及和发展，利用iSCSI技术搭建的IP SAN可以随着网络延伸至全球任意一个角 落，从根本上解决了信息孤岛的问题。甚至可以通过IP SAN来连接各个FC SAN的孤岛，因此IP SAN 比FCSAN具有更好的伸展性。 试题三试题三 7、依题意，在图2-9中，Duck为抽象类，描述了抽象的鸭子，方法fly()、quack()和display() 分别表示不同种类的鸭子都具有飞行特征、 发声特征和外观特征； 而类RubberDuck、 MallardDuck、 CottonDuck和RedHeadDuck分别描述具体的鸭子种类；类Fly Behavior与QuackBehavior为 抽象类，分别用于表示抽象的飞行行为与发声行为；类Fly NoWav与Fly WithWings分别描述不 能飞行的行为和用翅膀飞行的行为；类Quack、Squeak与QuackNoWay分别描述发出“嘎嘎”声的行 为、发出橡皮与空气摩擦声的行为和不发声的行为。鉴于不同的鸭子种类只是在行为方面有所区别， 且为支持将来能够模拟更多种类鸭子的特征， 该公司架构师最有可能采用策略(Strategy)设计模式 来设计如图29所示的模拟鸭子游戏软件。 Strategy模式定义了一组能够用来表示可能行为集合的类。这些行为可以在应用程序中使用， 来修改应用程序功能。Strategy(策略)模式的设计意图是，定义一系列的算法，把它们一个个封装 起来，并且使它们可相互替换，使得算法可独立于使用它的客户而变化。具体而言，该模式是一种定 义一系列算法的方法，从概念上看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以 相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。Strategy模式的一般结 构如图213所示。 Strategy模式具有以下一些优点和缺点。 (1)另一种子类化方法。Strategy类层次为Context(上下文)定义了一系列的可供重用的算 法或行为。继承有助于析取出这些算法中的公共功能。可以直接生成一个Context类的子类，从而 给它以不同的行为。但这会将行为强制编制到Context中，而将算法的实现与Context的实现混合 起来，从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。最后得到一 堆相关的类，它们之间的唯一差别是它们所使用的算法或行为。将算法封装在独立的Strategy类中 使得架构师可以独立于Context而改变它，使它易于切换、理解和扩展。 (2)在类自身中定义了每一个行为，从而减少了一些条件语句；Strategy模式提供了用条件语 句选择所需行为以外的另一种选择。当不同的行为堆砌在一个类中时，很难避免使用条件语句来选择 合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。 (3)更容易扩展模型，即在不对应用程序进行代码修改的情况下，使该模式具有新的行为。 (4)客户必须了解不同的Strategy。该模式有一个潜在的缺点，就是一个客户要选择一个合适 的Strategy就必须知道这些Strategy到底有何不同。 此时可能不得不向客户暴露具体的实现问题。 因此仅当这些不同行为变成与客户相关的行为时，才需要使用Strategy模式。 (5)Strategy和Context之间的通信开销。无论各个ConcreteStrategy(具体策略)实现的 算法是简单还是复杂，它们都共享Strategy定义的接口。因此很可能某些ConcreteStrategy不 会都用到所有通过这个接口传递给它们的信息；简单的ConcreteStrategy可能不使用其中的任何 信息。这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题， 那么将需要在Strategy和Context之间进行更加紧密的耦合。 (6)增加了对象的数目。Strategy增加了一个应用中的对象的数目。有时可以将Strategy实 现为可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由Context维护。 Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享的Strategy不应在各次 调用之间维护状态。8、在以下情况中，应该使用Strategy模式。 (1)许多相关类只是在行为方面有所区别。“策略”提供了一种用多个行为中的一个行为来配置 一个类的方法。 (2)需要使用一个算法的不同变体。例如，定义了一些反映不同的空间或时间权衡的算法，当这 些变体实现为一个算法的类层次时，可以使用策略模式。 (3)算法使用客户端未知的数据，可使用策略模式以避免暴露复杂的、与算法相关的数据结构。 (4)一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现。将相 关的条件分支移入它们各自的Strategy类中以代替这些条件语句。 依题意，在图2-9中，需要考虑以下一些Strategy模式实现问题。 (1)定义类Duck和类FlyBehavior(或类QuackBehavior)接口。这些接口必须使得类 FlyWithwings、类FlyNoWay、类Quack、类Squeak和类QuackNoWay等能够有效地访问它所需 要的类Duck中的任何数据，反之亦然。一种解决办法是让类Duck将数据放在参数中传递给类 FlyBehavior(或类QuackBehavior)操作，也就是说，将数据发送给类FlyBehavior(或类 QuackBehavior)。这使得类FlyBehavior(或类QuackBehavior)和类Duck解耦。但从另一个 角度考虑，类Duck也可能发送一些类FlyBehavior(或类QuackBehavior)不需要的数据。 另一种解决办法是让类Duck将自身作为一个参数传递给类FlyBehavior(或类 QuackBehavior)，该类FlyBehavior(或类QuackBehavior)再显式地向类Duck请求数据；或 者类FlyBehavior(或类QuackBehavior)可以存储对它的类Duck的一个引用， 这样根本不再需要 传递任何东西。这两种情况下，类FlyBehavior(或类QuackBehavior)都可以请求到它所需要的 数据。但要求类Duck必须对它的数据定义一个更为精细的接口，这将使得类FlyBehavior(或类 QuackBehavior)和类Duck更加紧密地耦合在一起。 (2)将类FlyBehavior(或类QuackBehavior)作为模板参数。例如，在C+中，可利用模板 机制用一个Strategy来配置一个类。然而这种技术仅当下面条件满足时才可以使用：可以在编译时 选择Strategy；它无须在运行时改变。在这种情况下，要被配置的类(如类Duck)被定义为以一个 Strategy类作为一个参数的模板类。使用模板不再需要定义给类FlyBehavior(或类 QuackBehavior)定义接口的抽象类。 把类FlyBehavior(或类QuackBehavior)作为一个模板参 数也使得可以将一个类FlyBehavior(或类QuackBehavior)和它的类Duck静态地绑定在一起， 从 而提高效率。 (3)尽量使类FlyBehavior(或类QuackBehavior)成为可选的对象。即使在不使用额外的 FlyBehavior(或类OuackBehayior)对象的情况下，类Duck也还有意义，那么它还可以被简化。 类Duck在访问类FlyBehavior(或类QuackBehavior)前先检查它是否存在，如果有，那么就使用 它；如果没有，那么类Duck执行默认的行为。这种方法的好处是客户根本不需要处理 FlyBehavior(或类QuackBehavior)对象，除非它们不喜欢默认的行为。9、设计模式主 要用于得到简洁灵活的系统设计，GoF的书中共有23个设计模式，这些模式可以按两个准则来分类： 一是按设计模式的目的划分，可分为创建型、结构型和行为型3种模式；二是按设计模式的范围划分， 即根据设计模式是作用于类还是作用于对象来划分，可分为类设计模式和对象设计模式，如表216 所示。 表2-16设计模式空间 目的 创建型结构型行为型 范围 类 Factory Method Adapter(类) Interpreter Template Method 对象 Abstract Factory Builder Prototype Singleton Adapter(对 象) Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibil ity Command Iterator Mediator Memento Observer State Strategy Visitor 创建型模式是对对象实例化过程的抽象，它通过采用抽象类所定义的接口，封装了系统中对象 如何创建及组合等信息。该模式允许在系统中创建对象，而不需要在代码中标识特定类的类型，这样 用户就不需要编写大量复杂的代码来初始化对象。它是通过该类的子类来创建对象的。但是，这可能 会限制在系统内创建对象的类型或数目。创建型模式主要有Factory Method(工厂方法)、 Abstract Factory(抽象工厂)、Builder(构建器)、Prototype(原型)和Singleton(单独) 等模式。 结构型模式主要用于如何组合已有的类和对象以获得更大的结构，一般借鉴封装、代理或继承 等概念将一个或多个类或对象进行组合和封装，以提供统一的外部视图或新的功能。该模式允许在不 重写代码或自定义代码的情况下创建系统，从而使系统具有增强的重复使用性和应用性能。该模式控 制了应用程序大部分之间的关系，将以不同的方式影响应用程序。结构型模式主要有Adapter(适配 器)、Bridge(桥接)、Composite(组成)、Decorator(装饰)、Fagade(外观)、Flyweight(享 元)和Proxy(代理)等。 行为型模式主要用于对象之间的职责及其提供的服务的分配，它不仅描述对象或类的模式，还 描述它们之间的通信模式， 特别是描述一组对等的对象怎样相互协作以完成其中任意一个对象都无法 单独完成的任务。该模式可以影响一个系统的状态和行为流。通过优化状态和行为流转换及修改的方 式，可以简化、优化并且提高应用程序的可维护性。行为型模式主要有Interpreter(解释器)、 TemplateMethod(模板方法)、Chain of Responsibility(职责链)、Command(命令)、 Iterator(迭代器)、Mediator(中介者)、Memento(备忘录)、Observer(观察者)、State(状 态)、Strategy(策略)和Visitor(访问者)等。 试题四试题四 10、统一建模语言(UML)是面向对象的建模语言，强调两个重要的概念：鼓励将设计描述为许多交 互的对象，而不是一些大的单块代码；至少一些对象对应系统中部分实际的软件或硬件，可以将UML 模型化成系统交互的外部世界，在这种情况下，对象可能与人或其他机器对应。 在图211所示的车载终端系统中的GSM无线电通信模块状态图中，GSM模块共有4个状态，分别 为通话中、有问题、待命和短消息通信中。当GSM模块在通话、待命和短消息通信状态中出现问题时， 会转入错误处理即进入有问题状态。当用户需要语音通话时，转入通话状态，通话完毕后，通信模块 重新回到待命状态。当模块无法处理问题时，可以试图连接网络，上报车辆调度中心，此时模块处于 空闲待命状态。完整的GSM无线电通信模块状态图如图2-14所示。 11、图2-11为车载终端用户通过车载电话(或按键)与调度中心保持通信的处理过程顺序图。其表达 的处理过程如下： 用户通过按下按钮或语音对话试图连接调度中心， 主控器模块接收到连接请求后(或 连接建立后)，就发送相应的信息给通信模块；通信模块负责处理并通过GSM发送消息，调度中心接 收消息成功后要求监听信息，并把该要求返回给车载系统的GSM通信模块；GSM通信模块把该请求信 息(即调度中心的要求监听信息)递交给主模块，主模块把监听命令递交给GSM通信模块，然后可由 GSM通信模块递交给调度中心。12、在初步的业务需求描述已经形成的前提下，基于UML的 需求分析大致可分为以下几个步骤。 利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类 和抽象；形成用例；确定执行者与用例，用例与用例图之间的关系，生成用例图。 利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验 设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模 型和用例出发，研究系统中主要的类之间的关系，生成类图。 上述两个步骤并没有时序关系，它们可以并行展开。其中，顶层架构的主要目的是为后续的分 析和设计活动建立一种结构和分划，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发 人员，能够聚焦于系统的不同部分。顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推 进，框架中的内容不断丰富和翔实，最终演进为完整的面向对象的软件结构。UML包图是表示项层架 构的适当机制。 建立软件系统顶层架构的基本方法是，结合实际需求，从既往的架构设计经验模型中选取适当 者，再进行微调或局部改造。目前有以下几种主要的架构模式。 (1)流程处理模式。流程处理系统以算法和数据结构为中心，其系统功能由一系列的处理步骤构 成，相邻的处理步骤之间以数据流通管道相互连接。该模式仅适合于采用批处理方式的软件系统， 不 适合于交互式系统。 (2)客户/服务器模式。客户端负责用户输入和处理结果的呈现，服务器端则负责后台的业务逻 辑处理。 (3)模型视图控制器(MVC)模式。 该模式将整个软件系统划分为模型、 视图和控制器3个部分。 模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知 视图；视图负责呈现模型的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界 面动作； 控制器负责将用户的界面动作映射为模型中业务处理功能并实际调用之，然后根据模型返回 的业务处理结果选择新的视图。MVC模式特别适合于分布式应用软件，尤其是Web应用系统。 (4)分层模式。该模式将整个软件系统分为若干层次，最顶层直接面向用户提供软件系统的操作 界面，其余各层为紧邻其上的层次提供服务。层次划时分的主要原则是，较易变化的软件部分(例如 用户界面和与业务逻辑紧密相关的部件)置于较高层次，较稳定的软件部分(例如公共的技术服务