智慧城市顶层设计的基础概念

程大章

(同济大学)

1 顶层设计的由来

2010年10月起，中国突然出现了大量关于顶层设计的各种讨论，把原本在系统工程领域的理念与方法，广泛用于社会与政治的改革。这是因为在中国共产党十七届五中全会通过的《中共中央关于制定国民经济和社会发展第十二个五年规划的建议》中表述了“重视改革顶层设计和总体规划”。之后，中央经济工作会议更明确提出了加强改革顶层设计，在重点领域和关键环节取得突破。“顶层设计”指向宏观的改革，如政治体制改革、经济体制改革、文化体制改革、社会体制改革。而在比较短的时期内形成新的体制，需要在顶层进行一个框架性的设计，从国有企业、财政体制、金融体质、汇率形成机制、法制基础上的市场体系等问题上全面推进改革。

顶层设计是一种从宏观的角度对所涉对象的设计思想、设计目标、设计环境、设计流程、设计内容、设计方法及设计成果的质量检验进行全面的和系统的规划。这一方法具有科学的、清晰的思路，呈现了全面性和系统性，能有效地指导与推进社会、经济、工程等各项工作。

智慧城市的本质是一场社会体制的改革，就支撑其的信息应用系统而言，整体的规划必须进行顶层设计，才能够有效、可持续地得到发展。智慧城市的规划可应用各种技术与方法，其中较为有效的是企业架构（Enterprise Arch）和体系结构（Architecture）。美国联邦政府利用EA的方法论开发了一个联邦政府顶层设计的架构，为它的电子政务建设服务。体系结构则用于军事综合电子信息系统，建立在军事作战时支持指挥员进行计划、指挥和控制部队的一体化指挥、控制、通信、计算机、情报、监视和侦察的信息系统。因此，本文有关顶层设计的方法，主要借鉴企业架构与体系结构。

2 企业架构

企业架构是由系统架构标准的国际权威机构——开放群组提出的，“有效的企业架构对企业的生存和成功具有决定性的作用，是企业通过IT获得竞争优势不可缺少的手段。” 将EA理解为一种自上而下的、涉及到整个组织的，也可以理解为是一种自下而上的、由项目或任务驱动的。

美国联邦CIO理事会把EA定位为一个组织的战略、业务工作和流程，与它的IT战略连接起来。EA采用多种结构模型和视图使之文档化，显示如何去满足一个组织当前和未来的需要，定义了未来某一给定时点上的、必须支持一个组织的业务工作和战略的目标架构。民间机构Meta Group，把EA理解为是一个组织的关键业务、信息、应用、技术战略以及它们对业务功能和流程的影响的一种整体化表述。它关注组织的业务流程、组织结构以及运用什么技术去实施这些业务流程。美国联邦政府CIO办公室则认为EA是一种战略信息资产库，用于定义业务、运营业务所需的信息、支持业务运营所需的技术以及实施新技术，以适应业务需求变化所需的过渡流程。我们可以看到，尽管还没有一个被普遍接受的定义，但是所有的定义都力图说明EA使一个组织的信息、流程和技术与该组织的战略相连接，以保障企业和政府机构具有透明性、一致性、合规性和最大的灵活性。

IT 界在长期的应用推进过程中，逐步体会到成功的企业需要“架构”形成，而不能任其自由发展。战略决定做正确的事，业务架构决定正确、高效地做事。企业架构则是一个涵盖业务和IT全面的企业蓝图设计工具，它可以帮助企业的管理者了解企业的构成和运营，发现问题并不断地改进。

The Open Group是一个厂商中立和技术中立的机构，它基于开放标准和全局互操作性，和客户、供应商、联盟和其他标准团体协同工作，致力于实现企业内部和企业之间集成信息的访问。The Open Group的工作是捕获、理解并处理当前的和正在出现的需求，建立应对策略，分享最佳实践；促进可互操作性，促进达成共识，发展并集成各类规范和开源技术；提供一整套综合服务以加强协会的运作效率以及认证服务。

企业架构如同战略规划，可以辅助企业完成业务及IT战略规划。在业务战略方面，可使用TOGAF及其架构开发方法（Architecture Development Method，ADM）来定义企业的愿景/使命、目标/目的/驱动力、组织架构、职能和角色。在IT战略方面，TOGAF及ADM详细描述了如何定义业务架构、数据架构、应用架构和技术架构，是IT战略规划的最佳实践的指引。企业架构是承接企业业务战略与IT战略之间的桥梁与标准接口，是企业信息化规划的核心。

2.1 TOGAF

The Open Group通过与300多家开放群组架构论坛的会员协同努力，在1995年发表了The Open Group Architecture Framework（TOGAF）架构框架，其基础是美国国防部的信息管理技术架构（Technical Architecture for Information Management: TAFIM）。它是基于一个迭代（Iterative）的过程模型，支持最佳实践和一套可重用的现有架构资产，可有效用于设计、评估，并建立组织的正确架构。

在TOGAF中“企业”被定义为有着共同目标集合的组织聚集，这个“企业”可以是政府部门、公司、部门、单个处/科室，或通过共同拥有权连接在一起的地理上疏远的组织链。在“企业架构”中的“企业”不仅可用来表示整个企业，而且可以表示企业内的一个特定领域。在这两个情形中，架构可以跨越多个系统和企业内的多个职能群组。

如果规划目标是集成扩展型的企业，那么这里的“企业”就扩大到伙伴、供应商和客户，以及内部的业务单位。

业务运营模型对决定组织内的“企业架构”具有主要影响，大型公司和政府部门可以由多个企业组成，可以开发及维护一些独立的企业架构来应对每一个企业的运营。这些企业的信息系统经常存在许多共同之处，因此，使用一个共同的架构框架通常会有很大的潜在收获。

开放群组企业架构框架TOGAF支持4 层的企业架构子集：

第一层的业务（或业务流程）架构：定义商业策略，管理、组织和关键业务流程。

第二层的技术架构：描述支持核心部署和关键任务应用的软件基础设施。包括IT安全架构、网络架构、通讯架构、服务器等，以及中间件。

第三层的数据架构：这个描述一个组织逻辑的和物理的数据模型，数据管理资源（内容管理和知识管理）的结构。

第四层的应用架构：描述支持业务架构所需要所要求的应用和应用架构，这种结构为待配置的个人应用系统提供一个蓝图，从他们的交互关系到该组织核心的业务流程。以适应电子商务和电子政务建设项目的在线方式和自我服务方式的数据获取和服务获取。

架构设计是一个复杂的技术过程，而设计异构、多供应商的架构更为复杂。在帮助对架构开发过程的“去神秘化”和“去风险化”方面，TOGAF扮演了重要角色。TOGAF提供了增值平台和协助开发、验收、运行、使用和维护架构的工具，能为使用者建立真正基于开放系统的解决方案，以处理他们的业务议题和需要。

2.2 企业架构的效用

从世界先进国家的发展历程来看，企业架构的采纳和推行，是经济、社会、商业发展到一定阶段的必然产物。随着经济全球化和中国综合实力的增强，企业架构在我国的政府部门/机构和企事业单位中的应用受到的关注。

企业架构的目的是将跨企业的、常为零散的那些遗留流程（人工/自动）优化进一个集成的环境，它可以及时响应变更并有效的支持业务战略。

今天的企业CEO都知道对信息进行有效的管理及利用，是业务成功的关键因素，也是获取竞争优势不可缺少的手段。企业架构能够满足该需求，为响应持续变更的业务环境所需的IT系统的演进，提供战略背景。

良好的系统架构使企业能在IT效率和业务创新之间达成适当的平衡，它允许单个的业务单位在追求竞争优势时平稳地进行创新活动。同时，它确保了组织对集成的IT战略的需要能够被满足，并允许跨越整个扩展企业，实现紧密的合作协同。 企业架构的效用是多方面的，至少体现在3方面。

1）高效率的IT运行。 降低的软件开发、支持和维护的成本；增强的应用可移植性；提高的互操作性和更为简单的系统和网络管理；提高的处理关键性的企业议题的能力，如安全；更容易的升级和系统构件的替换。

2）更好的收益，降低了未来投资的风险。降低了IT基础设施的复杂度；使现有IT基础设施投资的回报率最大化；开发、购买和外包IT解决方案的弹性；降低新投资以及IT拥有成本的全面风险。

3）更快、更简单和更便宜的采购。 采购决策更简单，因为在有条理的规划中，管控采购的信息是随时可用的；采购流程更快，最大化采购速度和灵活性而无需牺牲架构的一致性；采购异构、多供应商的开放系统的能力。

企业架构组织内的关键人员（利益相关者）需要通过IT系统进行处理的事务，通过识别和提炼利益相关者的需求，开发显示关注和需求将如何被处理的架构视图，并显示为调和不同利益相关者之间潜在冲突性的关注而做出的权衡。

架构框架是一套基础结构，用来开发大规模的不同架构，它描述了一个用构建块的集合来设计企业目标状态的方法，并显示这些构建块如何搭配在一起。它包含一套工具和共同词汇，提供所建议标准的清单以及符合标准的、可以实现构建块的产品。构建块可以是架构元模型实体的目录清单、矩阵及图表、功能规格、应用模块、软件/硬件产品及其组合。

使用TOGAF设计和实施企业架构的组织确保了其设计和采购的规格，它能促进开放系统的实现，从而使能开放系统的效益并降低风险。寻求“无边界信息流”的组织，能使用TOGAF来定义和实现对企业内或企业间集成信息进行访问的结构和流程。同时，承担或计划承担企业架构的设计者和实施者都可从TOGAF的使用中获益。

研究表明，IT架构的优化可以为企业带来2%的业务增长；业务架构的优化可以带来8%的增长；如果业务和IT能够相互支持，利用总体架构的理念优化的话，甚至可以带来20%的增长。

如果没有企业架构，要考虑和满足所有关注和需求是极为困难的。近年来，随着企业信息化程度的加深，如何建立有效机制使IT与业务融合，即通过更好的IT运营，产生相应的业务价值，提高核心竞争力成为企业迫在眉睫的问题。融合战略发展、业务以及 IT 系统的企业架构（EA），可以帮助企业实现IT效益最大化，通过业务架构蓝图，避免重复投资与信息孤岛。

综上所述，体系结构框架（TOGAF）是一个行业标准的体系架构框架，它能被任何希望开发一个信息系统体系架构的人员与机构自由使用。TOGAF帮助企业大大节约成本，增加业务模式的灵活性，更加的个性化、随需应变，并提高信息系统应用水平，同时推动业务模式创新，带来最佳管理实践。

3 体系结构

体系结构一词在英语中起源于建筑业，用以表示建筑学、建筑式样、建筑物等。计算机硬件、系统工程等领域借鉴建筑学中的思想，提出了计算机体系结构、系统体系结构的architecture概念。

3.1 体系结构的定义

若干有关事物或概念互相联系而构成一个整体称为体系，整体中各个组成部分的搭配和排列称为结构，体系结构研究整体的内涵、外延、层次和关系。体系结构所研究的系统结构通常在较高的抽象层次上，而且不仅仅指系统的物理结构。

国际系统工程理事会（INCOSE）将体系结构定义为：用系统元素、接口、过程、约束和行为定义的基本的和统一的系统结构。

IEEE标准P1471-2000对软件密集系统的体系结构定义为：通过系统部件、部件之间的相互关系及与环境的关系以及指导系统设计和演化的原则体现出来的一个系统的基本结构。

美军C4ISR体系结构框架中将体系结构定义为：系统各部件的结构、它们之间的关系以及制约它们设计和随时间演化的原则和指南。这里的部件不仅包括软件、硬件等物理部件，还包括数据、活动、人员等，体系结构逻辑部件、部件之间的关系包括层次、布局、边界、接口关系等。

C4ISR系统把指挥员、作战兵器和作战指挥的各要素组合成一个有机的体系，构成现代军队的神经中枢，是夺取信息优势、取得控制信息权的根本保障，是战争中的“兵力倍增器”。

由于智慧城市涉及广泛的社会信息应用系统的协同与互联，需要高度的集中指挥和实时联动，借鉴军事综合电子信息系统的思想与技术是十分有效的。

3.2 体系结构的特征

体系结构在近年来受到了学术界和工程界的高度重视，对此进行了大量的研究与工程实践。

1）复杂系统的抽象表达

由于系统的构成及功能越来越复杂，使得描述系统的难度不断增加。抽象可以有效处理复杂问题，它抽取事物最基本的特性和行为，忽略不必要的细节信息。体系结构在高层次上定义系统的组成其交互关系，隐去系统部件的局部细节信息，提供了一种理解、管理复杂系统的机制。系统设计的抽象不但可使系统的表述变得简单化，而且具有更明确的传递信息能力。系统的用户、设计者、实现者和维护者等在此基础上，都可以就理解系统的有关问题进行交互沟通，形成统一认识。

2）体现系统的顶层及早期的设计决策

顶层及早期的设计决策比底层及后期的详细设计、实现、维护阶段的工作重要得多，对系统生命期的影响范围最大，是整个系统开发成败的关键。

3）约束系统开发人员的实现行为

体系结构是待开发系统的技术规划，系统开发人员在实现系统时必须以体系结构所规定的结构性设计决策为依据，去开发属下的系统部件，按规定的方式实现部件之间的交互，进行系统的详细设计和实现。实现约束是由系统级做出，部件的实现者必须遵从自己所负责部件的约束。在工程中，体系结构设计者考虑系统的总体权衡问题，不必掌握系统的所有设计细节和实现技术；部件的开发人员则在体系结构给定的约束条件下进行工作。

4）体系结构是决定系统质量的基础

系统的质量可分为两类情况，第一类是通过观察系统来度量，如功能、性能、可靠性、互操作性等；第二类是无法通过观察系统来度量，只能由考察开发活动或维护活动来确定，包括可维护性等问题，如可移植性、可复用性等。体系结构方面的决策，如部件的层次、功能的划分等，会影响系统的某些质量特性，对其权衡都要在体系结构中得到体现。当然，系统的详细设计与实现等也会影响系统的质量特性，体系结构仅是保证系统达到其需求的质量特性的一个必要条件。

5）系统开发的组织结构取决于体系结构

体系结构规定了待开发系统的结构，直接确定开发组织工作的分解与组织结构。而且，开发组织的成员之间要按照部件的接口规格说明进行交互与工作推进。

6)在一定的时间段内相对保持稳定

通常，任何系统不会随着用户需求的变化、技术的进步而不断升级、演化，这无论是对C4ISR系统还是智慧城市来说都是普遍的情况。体系结构虽然随着时间的推移会发生变化，但是这种变化与体系结构所实现的子系统的变化相比要缓慢得多。系统可能发生的变动可以分为局部的、非局部的和体系结构级的。局部的是指只要修改单个部件本身；非局部的是指要修改多个部件，但不影响到基础不影响到基础体系结构；体系结构级是指会影响各部件的相互关系，甚至要改动整个系统。由于具有稳定性，一个设计良好的体系结构可以在相当长的时间内保证系统可能发生的变动是局部的或非局部的。如果一个系统经常发生体系结构级的变动，那么它的体系结构设计是失败的。

7）体系结构支持体系可重用

在理想的情况下，体系结构描述的各个组成部分都是被独立定义的，因此，可以在不同的场合中得到重用。体系结构重用有两种：一种是体系结构级重用，即同一体系结构可被应用于有类似需求的其他系统，开发出多种不同的系统；另一种是部件级重用，即体系结构设计者利用体系重用，以节约研制经费，提高设计效率和可靠性。

由于体系结构的上述特点，使得它在系统的生命期中有着十分重要的作用，因而体系结构可作为系统的风险承担者相互交流的手段，便于从总体上分析、理解、比较系统；体系结构被系统设计者用作详尽的系统设计规范；体系结构可被用来分析、评价系统的互操作性；体系结构可被用来作为系统集成或演化的依据和指南；体系结构可被用来分析系统的费效比，以辅助采办决策并提高采办、投资决策的科学性。

3.3 多视图建模

当信息系统的功能越来越多，规模越来越大，结构越来越复杂时，给体系结构的设计和描述带来了巨大的复杂性。仅采用一个简单的模型是很难把系统的组成、结构及相互关系等内容描述清楚。尤其是C4ISR系统和智慧城市这类信息系统的体系结构开发涉及各种复杂的业务领域和技术领域，不同领域人员的知识结构存在差异，相互之间的交流困难，传统分析方法难以形成一个全局的，统一的体系结构描述。

多视图建模是人们了解复杂事物体系结构时的一种方法，其基本思想是“分而治之”，将一个复杂问题从各个视角去分解，同时也形成对体系结构的整体描述。如机械制图，将一个空间三维物体向三个不同的正交方向投影，形成该物体的正视图、侧视图和俯视图，通过一定的规则，形成对三维物体的全面描述。若只用其中的任何一个或两个视图，则不能完整地描述物体的概貌。对于复杂信息系统来说，其组成和结构的复杂度给体系结构描述带来很大困难，系统涉及的各类风险承担者（如投资者、设计人员、实现人员、系统工程师、用户、维护人员等）又均与系统的建设与开发密切相关。由于职责和考虑问题的角度不同，使得各人所关注的内容有一定差异，而这些内容又必须在体系结构描述中得以考虑和体现。因此，只有采用多视图的体系结构方法才能得到科学描述。

采用多视图建模方法来全面反映信息系统各类风险承担者的需求和愿望，易于形成对体系结构整体的描述。从各种不同角度对复杂事物的抽象，将一个复杂的事物抽象成多种（类）简单的描述，简化了信息系统体系结构描述过程，降低了描述的复杂度。针对不同风险承担者的特点和关注的问题，多角度描述信息系统的体系结构，使各类人员从不同的角度理解体系结构，便于他们之间的交流，形成对体系描述的共识。

4 体系结构工程

4.1 体系结构工程的组成

体系结构工程在信息系统工程中位于需求分析和系统的详细设计之间，体系结构工程的主要依据是需求分析阶段完成的系统规格说明书。

信息系统体系结构工程是用工程化的原则和方法来开发、维护系统体系结构的有关技术及管理方法，在给定成本、进度的前提下，开发具有可理解、可跟踪、可验证和可修改等特点的，并满足业务功能需求的信息系统体系结构。

信息系统体系结构工程由方法、工具和过程三部分组成。

体系结构工程方法是开发体系结构的技术手段，它支持设计、验证、评价和维护等各阶段的活动。

体系结构工程工具要为体系结构工程方法和体系结构管理提供自动的或半自动的软件支撑环境，是体系结构设计者在开发中智力和体力的扩展和延伸。

体系结构工程过程是在软件工具支持下由体系结构设计者完成的一系列工程活动，它将体系结构工程的方法和工具综合起来进行合理、及时的体系结构开发。过程规定了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理以及体系结构各个阶段开发完成的里程碑等。

4.2 体系结构工程中的角色

体系结构工程中涉及的角色主要有用户、需求工程师、体系结构设计者和系统开发者。虽然有时某个（或多个）人会充当其中的多个角色，但无论从技术的角度还是管理的角度，角色还是需要明确划分。这里的用户是广义的，包括系统的使用者和采办者，他们对开发系统有各种要求。需求工程师通过适当的引导、规格说明、鉴定和证实技术来形成一个用户所需要的系统的精确描述。

体系结构设计者是体系结构工程的主体，负责依据用户需求设计系统的体系结构，建立体系结构描述。当信息系统规模大、技术复杂时，体系结构开发需要多方面的知识，体系结构设计者应该是精通多个领域的专家。通常是由各个领域的专家组成体系结构设计小组，共同完成体系结构的设计、维护。

系统开发者包括详细设计者、实现者和项目管理者。体系结构描述产生后，由系统开发者来构造系统。体系结构描述是用户需求的体现，是系统设计和实现人员对系统进行详细设计和实现的依据。体系结构设计者是用户、需求工程师与系统开发者的中介，负责沟通用户、需求工程师和系统开发者的认识和见解，起着桥梁的作用。

4.3 体系结构工程的原则

在信息系统体系结构开发过程中必须遵循以下原则：

1）由外到内。即先研究系统的外部问题（环境），把系统上下、左右的关系搞清楚，然后研究系统的内部问题。

2）自顶向下。体系结构开发是由系统用户的需求驱动，开发方法应自顶向下。将整个系统视为一个与外界环境存在着交互作用的“黒箱”，然后进行逐层分解，直到能与具体的物理实现相对应为止。

3）抽象。抽取系统最基本的特性和行为，忽略非基本的细节。采用分层次抽象的办法来控制体系结构开发过程的复杂性和可理解性，以有利于体系结构开发过程的管理。

4）模块化。模块是体系结构中逻辑上相对独立的部分，具有良好的接口定义。模块化有助于隐藏细节和表示复杂的系统，促进重用。

5）可互操作。互操作是系统、设备或业务团队向（从）另一系统、设备或业务团队提供（得到）服务的能力，使用这些能力可有效地协同操作，体系结构开发中要规定系统实现必须遵循的技术标准。

6）标准化。在一个体系结构开发过程中应尽量使用通用的术语和定义，这样便于理解、交流和比较，由不同的人设计的体系结构。

7）可行性。体系结构开发要考虑系统研制的费用、进度和当前技术水平的实际，尽量采用比较成熟的技术、产品和标准，以降低成本，缩短系统研制周期，降低研制风险。

4.4 体系结构工程的阶段划分

根据体系结构所处的状态、特征以及体系结构开发活动的目的和任务，将体系结构工程的活动划分为问题定义、设计、验证、评价和使用维护五个阶段。每个阶段都有相对独立的任务，前一个阶段任务的完成是开始进入后一阶段工作的前提和基础。通常，体系结构工程各阶段之间的关系并不是顺序的，而是带有反馈的迭代过程。

1）问题定义阶段

在开发信息系统体系结构之前，体系结构设计者必须了解其预期的用途和目的。设计一个信息系统，要尽可能地弄清楚对开发体系结构感兴趣的风险承担者（如用户、采办者、设计者、实现者和维护者等）所关心的问题和视角。体系结构的开发目的决定了体系结构设计的范围、时间帧等。体系结构设计的主要依据是信息系统需求分析阶段完成的系统规格说明书，设计者根据系统规格说明书来了解系统需求（系统的目的、任务、范围），熟悉业务人员的职能，对系统的使用要求，理解系统的功能和非功能需求，了解与该系统相关且有交互关系的其他已建、在建系统的情况，系统将来的升级、演化计划等。

同时，体系结构设计者还需要广泛收集领域信息，诸如行业使用的通用术语、业务流程、组织结构、指挥关系、操作规程等背景知识。

在了解体系结构的开发目的、熟悉系统和领域信息的基础上，确定体系结构设计的范围、详细程度和时间帧，制定体系结构开发计划，包括选用资源（如开发工具）、定义任务、确定拟采用的体系结构框架、选择体系结构方法（包括设计方法、验证方法和评介方法等）以及进度安排等。

2）设计阶段

运用上一阶段确定的设计方法，遵循体系结构工程原则，根据系统规格说明书中的系统需求，有步骤地建立系统的总体结构，确定系统与外界环境之间以及系统内各组成部分之间的接口、通信和信息交换关系，并按照系统规格说明书的要求规定系统实现必须遵循的技术标准。

设计体系结构必须从分析信息系统支持的业务概念开始。体系结构设计内容需要符合某种体系结构框架，设计者按照体系结构框架的要求描述、记录体系结构设计结果，并注意保证体系结构描述内容符合一定的语法规则和语义规则。体系结构设计完成后，还要对体系结构描述进行语法、语义正确性检查和一致性、完备性检查。

3）验证阶段

确定设计阶段得到的体系结构描述是否满足系统的功能需求和非功能需求，初步判断依据体系结构设计出来的系统能否满足业务人员的需求。

4） 评价阶段

信息系统研制过程中需要设计多个备选体系结构方案，每个方案对系统开发的成本、时间、人员、技术、设备等都有特定的用户要求。评价是“主体估测体系来测评客体各种属性的量值及其满足主体需求的效用，以综合判断原定需求满足程度的活动”。根据决策者的要求建立一套评价指标体系，选择合适的评价方法，按照一定的过程评判各种设计方案的优劣，并加以比较分析，为决策者从中选择较优方案提供科学的依据。

5）使用维护阶段

设计好的体系结构用于特定的目的后，体系结构维护则是对体系结构描述进行修改或对系统需求变化做出响应的过程。当发现体系结构描述中的潜伏错误，用户提出修改系统需求，或系统升级演化，都需要对体系结构进行维护。

4.5 体系结构设计方法

体系结构框架是规范化的文挡，只提出体系结构的若干指导原则和基本步骤，并没有为设计体系结构产品提供方法和详细的过程，它规范了体系结构描述，但是其过程仍然是一个复杂的过程，必须用科学的方法指导。针对智慧城市与C4ISR这类系统体系结构产品的设计，需要采用结构化分析方法和面向对象的设计方法。

面向对象的设计方法主要基于UML的信息系统体系结构设计的方法论和根据UML规范开发信息系统产品的程序，实施“自上而下，宽度第一”和“基于事件的交互作用”的基本原则。“自上而下，宽度第一”确保整个体系结构纵向和横向的均衡开发。“基于事件的交互作用”把对象间基于事件的交互作用作为定义机制。不管对象是一个复合系统还是一个软件，输入/输出事件是确定对象行为的重要手段。该方法利用UML的用例图、顺序和扩充顺序表、状态图等来建立体系结构产品。

4.6 体系结构验证评估方法

体系结构验证的主要任务是检查体系结构设计的正确性，确定体系结构描述是否满足系统的功能需求和非功能需求。现有的信息系统体系结构验证方法主要包括专家评审法、可执行验证法和体系结构折中分析方法。

专家评审法是专家依据自己的知识和经验采用阅读的方法检查体系结构设计的正确性。

最常用的可执行验证评估方法是根据体系结构内容构建仿真模型，依托仿真运行环境，通过运行可执行模型来验证评估体系结构。也可直接以部分体系结构产品为基础，建立某种可执行模型，通过在其中加入某些静态信息后，利用该可执行模型进行仿真。经过仿真，来验证体系结构描述中的功能是否按照预期的顺序执行、功能所需要的数据是否能够及时提供。另外，还可以通过仿真搜集系统的性能参数，对体系结构的部分性能参数进行验证和评价。可执行验证法适合验证体系结构的功能需求和部分非功能需求。

ATAM方法是一种验证体系结构非功能需求的方法，它通过对性能、可更改性、可靠性，安全性等多种非功能需求的分析来检查体系结构设计的正确性。该方法能提供了一种确定体系结构设计中多种非功能需求的折中点的方法，为改进体系结构设计提供依据。

5 结束语

企业架构和体系结构是信息系统顶层设计的有效方法，也是综合应用系统工程学的科学方法，将此用于智慧城市的总体和各类应用系统的规划与设计时，可以提高工程质量，降低工程风险。