联邦企业架构之FEA实施指南（上）

联邦企业架构之FEA实施指南（上）

通过前面的论述，我们可以了解到在接管了FEA的开发之后，OMB先后制定了诸如参考模型、联邦过渡框架以及企业架构评估框架等标准用于为FEA的开发提供帮助。但是FEA的开发并不是最终的目的，美国联邦政府创建的FEA的初衷是为了提高政府整体的信息资源的利用率和效能，并改善政府针对信息技术的投资水平，因而如何开发和应用FEA并使其为上述目标提供价值才是目标所在。为了达到这一目标，OMB于2007年底发表了《FEA Practice Guidance》用以指导如何开发和利用联邦企业架构，从而实现联邦政府性能的改善。

      不论是具有什么样职能的部门都需要寻找能够提升其职能效率和效能的方法，尤其是在信息化技术被普遍使用的今天。为了达到这一目标，各个部门引入了各种理论和技术，并对很多最佳实践经验进行了借鉴。这些被引入的理论和技术可以被划分为多个实践领域（Practice Area），而企业架构正是这些实践领域中的一个。通过将部门的战略目标、部门的投资以及需要达到的可测量的性能改善结合起来，企业架构实践领域可以最大限度将部门的资源、IT投资和系统开发活动的效能发挥出来，从而实现部门的性能目标。企业架构实践领域只是部门所涉及的各项实践领域中的一环，为了达到部门性能的改善，各部门需要将企业架构实践领域与其他各个实践领域进行结合并加以应用，例如战略规划、资金规划和投资控制以及项目管理等。所有这些实践领域都需要在各部门对其效能进行改善的过程中进行适时并适当地使用，而这一改善过程在联邦企业架构实施指南中被称为“效能改善生命周期”（Performance Improvement Lifecycle）。本节的主要内容就是以此效能改善生命周期为背景，详细介绍企业架构是如何在这个背景下被开发和使用的。

1.　　效能改善生命周期

效能改善生命周期

      效能改善生命周期是一个反复迭代的循环过程，在此过程中，各部门通过对各个实践领域进行相互结合，逐步将其制定的各项战略目标进行实现，并最终达到可测量的效能改善。这一生命周期分为三个前后衔接的阶段：架构阶段、投资阶段和实施阶段，而且每个阶段都包含着若干紧密结合的流程。通过这些流程的结合运行，能够为部门带来效能改善的各种需求得以被实现，而这些能够驱动效能改善生命周期行进的原动力或需求来自于两个方面：

• 自上而下的驱动力，即部门为了效能改善而主动制定的战略目标。
• 自下而上的需求，即在实际运行中产生的诸如系统改进等方面的需求。

      这两方面的驱动力并不是毫无关联的，他们的区别主要在于其产生的源头，而一般来讲“自下而上的需求”往往也会变成“自上而下的驱动力”产生的直接原因。

      效能改善生命周期各阶段所包含的各个流程以及阶段转换中涉及到的各个流程的描述总结如下：

阶段	流程描述
架构阶段	开发和维护企业架构，并通过它来为部门当前和未来状态提供共享视图
	对“片段”（Segment）的内容和优先级进行定义，并将其作为企业架构过渡战略的一部分。此过渡战略对各个片段的先后顺序进行了排列。
	开发片段架构（Segment Architecture）。该架构在企业愿景（企业架构与企业架构过渡战略）与针对各个业务与信息管理解决方案的投资和实施之间建立了沟通的桥梁
投资阶段	为从企业架构过渡战略中识别出来的，并在片段架构中描述的各解决方案定义实施和资金策略
	建立方案管理规划（Program Management Plan）来实现在实施和资金策略中定义的各项解决方案
实施阶段	依照方案管理规划执行各个项目
	对项目的执行效果进行评测，检查期望目标的达成情况，并对企业架构和片段架构的开发过程进行反馈，从而促进他们的发展

2.　　企业架构的开发和应用

      从效能改善生命周期中各个流程的描述中我们可以看出，部门效能的改进是多个实践领域相互结合、共同作用的结果，但其中贯穿始终的还是企业架构这一实践领域。企业架构实践领域不仅为整个效能改善生命周期提供部门级的可共享的信息资源、规范和标准，而且企业架构所涉及的框架方法也是此周期能够顺利进行的重要工具。除此之外，效能改善生命周期的演进过程本身也是企业架构逐步细化、专门化的演进过程。在此生命周期中，企业架构起初以部门级的信息整合体的形态出现，经过细化而转变为面向各个具体任务领域的片段架构，并最终体现为包含了各种实现部门目标的方案和项目的解决方案架构。

2.1 架构级别

     企业架构、片段架构和解决方案架构采用不同的详细度，为各个相互关联但关注不同的干系人提供了关于部门的视图。他们之间的关系如下图所示：

不同级别架构对比示意

      企业架构的关注点基本上都落在对于通用或共享资产（战略目标、业务流程、投资、数据、系统或技术等）的识别和组织之上。企业架构往往是以战略目标为原动力的，它有助于一个部门识别其资源的分配与其任务和战略目标是否相适合。从投资的角度来看，企业架构一般被用来促成部门整体IT投资组合的生成。企业架构所面对的干系人包括组织中的所有角色，其中包括决策层和高级执行层的干系人，而他们也是确保组织能够高效地实现其任务的关键力量。

      相比之下，片段架构以业务管理为驱动力，并且为改善对市民的服务交付而提供各种工作制品。此外，与企业架构关注于部门级的信息资源不同，片段架构更关注于部门的核心任务领域、业务服务和用于保障和支持他们的企业服务。从投资的角度来说，片段架构促进了用于具体IT投资的业务案例的产生。片段架构所面对的干系人主要是各个业务的拥有者。片段架构与企业架构并不是毫无关系的，他们在如下三个方面具有关联：

• 片段架构继承了企业架构所使用的框架方法，并根据其面向的核心业务领域和共享服务对该框架方法进行扩展或特化。
• 片段架构重用了在企业架构中定义的各项信息资产，包括数据、通用业务流程和投资、应用和技术等。
• 片段架构遵守在企业架构中定义的各项规范和标准，包括业务战略、法规、标准和效能目标等。

      解决方案架构定义了用于将部门业务功能进行自动化和高效化的IT资产。一个解决方案架构范围往往被限制在一个项目的范围之内，而该项目一般被用来实现系统和业务解决方案的全部或一部分。解决方案架构所面向的干系人一般是系统用户和开发者。解决方案架构也不是孤立存在的，它与上面两种架构也是相互关联的，例如片段架构定义了在核心业务领域或共享服务中所使用的各种接口，而这些接口将在会在各解决方案中被访问；此外在一个解决方案中所采用的各种技术同样也要接受在企业架构中定义的各种技术标准的约束。

2.2　　架构演进

      效能改善生命周期的演进过程实际上也就是各种架构制品的演进过程。为了实现组织的战略目标并达成各项可测量的性能改善，架构开发小组需要与各干系人一起以企业架构为起点协力开发面向组织核心任务领域的片段架构，并将用以实现目标的各个项目用解决方案架构组织起来。在这些架构中片段架构有着承上启下的作用，而且片段架构的开发在整个效能改善生命周期中占据着核心地位。下图展示了在效能改善生命周期的各个阶段中企业架构是如何通过片段架构与用于实现目标的各项目以及效能评测发生关联的：

企业架构在效能改善生命周期中的演进

      如图所示，在效能改善生命周期的架构阶段中，相关干系人需要对企业架构进行开发和维护，并对各面向组织核心业务领域的“片段”进行识别和定义。在投资阶段中，在架构阶段被定义出来的各“片段”被组织成片段架构，同时相关干系人还需要为项目执行制定相关的资金策略，并开发出各个业务案例，从而调整在资金规划和投资控制过程中所制定的投资。在实施阶段，更加详细的项目管理规划被制定了出来，用以指导项目的实施。相关干系人在实施阶段中对各项目进行落实，并对项目的执行情况以及所产生的效果分别进行监督和评测。需要注意的是，在整个效能改善生命周期中，各个干系人在开发片段架构、定义实施和资金战略、创建项目管理规划以及效能评测这些子过程中的活动可能会对企业架构的内容产生影响，因而在上图中这些子过程都具有一条到达起始点的反馈路径。

      与企业架构着眼于整个组织级别的信息资产不同，片段架构所组织的各个片段关注于组织的业务层面以及用于支持各项业务的应用服务层面。片段架构中所组织的内容分为如下三类：

• 核心业务领域片段（Core Mission Area Segments）
• 业务服务片段（Business Service Segments）
• 企业服务片段（Enterprise Service Segments）

片段类型

      上图展示了联邦政府中各个部门（SBA、EPA、HHS等）所对应的各种片段。其中，核心业务领域片段代表了组织的主要任务方面，而业务服务片段则代表了用以支持组织的各主要业务的通用服务。以上两者对应于联邦参考模型的业务参考模型中的内容。对于企业服务片段来说，它所代表的是用于保障和支持各部门组织的核心业务和业务服务的各种应用服务，而它对应的是联邦参考模型的服务组件参考模型。

片段之间关系示例

      片段架构的开发首先是以针对片段的识别和定义开始，并在企业架构和企业过渡策略的制定过程中得以实现的。由于组织的企业架构的详细程度有可能不足以进行片段的识别和定义，在联邦企业架构实施指南中针对此种情况提出了如下方法和步骤用于应对这种情况：

• 定义业务信息管理需求和架构变更驱动力，并根据其优先级进行排序。
• 定义、审查用于改善组织效能的各个候选方案，并根据其优先级进行排序。
• 将经过优先级排序的候选方案映射到组织的业务模型和服务模型，并由此识别出候选的片段。核心任务领域和业务服务片段会从业务模型中被识别出来，而企业服务片段将从组织的服务模型中被识别出来。
• 根据被选中的片段的范围明确用于片段架构开发的各项资源，包括管理支持、业务和技术专家等。
• 创建片段架构开发团队。

片段识别方法

      经过上述步骤，各个片段以及用于片段架构开发的团队和资源得以被确定，而后组织便可以启动针对片段架构的开发项目。总的来讲，片段的识别和定义过程是一个持续发展的迭代过程，在此过程中各组织需要将自身的企业资产（包括各种系统和IT投资等）通过联邦企业架构参考模型映射成为组织的一个面向片段的视图。这些企业资产的描述信息来自于组织内外，可以看作是该过程得以顺利进行的必要输入，包括组织任务声明、战略目标、相关法律法规、通用或共享的业务和信息需求，以及在FTF中定义的各项跨部门举措。

      片段架构的开发和维护过程又细分为“分析”、“定义”和“操作”三个阶段，并且它们贯穿于效能改善生命周期之内并与此生命周期的三个阶段相互交织，从而使得片段架构能够在整个效能改善生命周期内对其进行支持。

片段架构开发过程

• 分析阶段（Analyze）：定义片段架构的范围和变更需求，概括当前业务和信息管理环境，并在比较高的层次上描述效果改善的机会。
• 定义阶段（Define）：识别出用来支持业务和信息需求的目标片段架构，并概括出各种实现的可能性，包括针对相关跨部门举措的实现。同时在该阶段还需要制定一份过渡战略，其重点在于开发一系列用于IT投资和预算制定的业务案例。
• 操作阶段（Operate）：开发一份用于支持目标片段架构实现的项目管理规划，并将其与项目执行和解决方案开发建立联系。

      如上图所示，片段架构开发和维护过程的各个阶段的活动分布于效能改善生命周期之中并与其各个阶段相互交织成五个步骤：

• 架构分析（Architecture Analysis）：在此步骤中，架构开发团队需要为企业片段定义一份简洁的愿景，并将其与组织的战略规划相联系，同时架构开发团队需要考虑当前的各种变更驱动力，包括关键战略、法规和各种管理需求，从而识别出能够达到效能改善的各种机会。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 各片段的范围是什么？为了解答这个问题，架构开发团队需要开发一张简洁的概念图与总结性描述，用以对组织各片段的范围以及当前的运营环境进行定义。
      2. 影响各个片段的主要变更驱动力是什么？为了解答这个问题，架构开发团队需要识别并描述新的和修改过的业务需求，以及其他影响片段的变更驱动力。
      3. 当前的系统片段和资源是什么？为了解答这个问题，架构开发团队需要对组织当前的片段状态信息进行编制。这些描述当前状态的信息需要涵盖架构的各个层面（性能、业务、数据、服务和技术），同时还需要包括当前系统、投资，乃至人员情况。除此之外，所收集的信息还需要达到足够的详细程度，从而支持各效能改善机会的发现。
      4. 在当前这些片断中制约其成功的因素有哪些？为了解答这个问题，架构开发团队需要审查当前各片段相关的资产和各变更驱动力，从中寻找能够改善组织效能且能够达到可量测目标的各种机会，并将其通过文档记录下来。
      5. 针对各片段的愿景是什么？为了解答这个问题，架构开发团队需要编制一张简单的图表来阐述组织对各片段的愿景。这张概念图应针对建议的运营环境进行描述，包括为了解决之前已经被记录下来的各种不足以及达成各种可量测效能改善而做出的对于干系人交互方式、业务流程、信息共享、应用、技术等方面的计划变更。除此之外，此概念图还需要一份描述建议的运营环境以及与组织战略目标之间关联的总结性愿景说明文档来进行补充。

• • 此步骤要达到最终效果是：对在后续步骤中将要进行开发的目标片段架构的范围进行定义的各种机会加以明确，并对他们之间的优先级顺序达成共识。
• 架构定义（Architecture Definition）：此步骤的目的是定义各片段将要达到的状态，并开发一份用以达到此状态的过渡计划。此步骤需要在组织的资金规划和投资控制过程开始之前完成。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 各片段的效能改善目标是什么？为了解答这个问题，架构开发团队需要为各个片段建立效能目标，包括目标效能量测以及达到这些目标的时间表。效能改善目标构成了目标片段架构在性能层面的基础，并且它需要与组织企业架构和战略目标相适合，从而将效能目标与组织整体战略目标联系在一起。
      2. 能够达到效能目标的设计方案都有哪些？为了解答这个问题，架构开发团队需要评估和对比各种用于达到效能目标的设计方案。为了达到这个目的，架构开发团队需要参考FTF中定义的各种跨部门举措，从中寻找与片段相关并能够重用的举措。除此之外，架构开发团队还需要进行市场调研，从而对现存的各种资产、系统、组件、服务和最佳实践进行评估，判断其是否能够被重用并被整合到片段架构之中。
      3. 用以组织各片段的目标架构是什么？为了解答这个问题，架构开发团队需要开发目标片段架构，这既包括组织的效能目标，也包括用以支持这些目标实现的业务、数据、服务和技术方面的架构。需要注意的是，目标片段架构需要采用联邦企业架构参考模型进行描述。
      4. 为了达到目标片段架构而需要进行的项目有哪些，以及他们之间的执行顺序是什么？为了解答这个问题，架构开发团队需要开发片段过渡战略。架构开发团队需要使用目标片段架构来识别出当前状态与目标状态之间的差距，并制定出为了弥合这些差距而需要被执行的项目。除此之外，架构开发团队还需要评定这些项目的优先级和依赖关系，并据此决定他们的执行顺序。所有这些活动的结果最终都将被记录到片段过渡战略之中。

• • 此步骤要达到最终效果是：在组织中产生对于目标片段架构和过渡战略的共识。
• l投资和资金战略（Investment & Funding Strategy）：此步骤的目的是为项目执行制定资金战略，并为资金规划和投资控制过程中的投资制定创建相关业务案例。此步骤需要在组织将其预算提交给OMB之前就要完成。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 针对各个项目的资金战略是什么？为了解答这个问题，架构开发团队需要为在片段过渡战略中明确的各个项目制定资金策略。架构开发团队需要与CPIC（资金规划和投资控制）人员紧密合作，通过使用在片段过渡战略中的项目序列计划，为各个项目分析出各种可能的资金策略。这既包括分析各种可能的资金来源，也包括判断各种适用的资金调配方法。资金策略需要考虑整合在目标片段架构中明确的现有投资。架构开发团队和CPIC人员制定的资金策略需要确保在目标片段架构实施时必要的资金已经准备停当。
      2. 用于实现目标片段架构的各项投资的理由是什么？为了解答这个问题，架构开发团队需要为各项用于支持项目实施的投资制定各种业务案例。这些案例包括了来源于架构分析、目标片段架构和项目资金策略的信息。

• • 此步骤要达到最终效果是：产生IT投资组合以及经过批准的资金策略。
• 方案管理与执行（Program Management & Execution）：此步骤的目标是将片段架构和资金战略转化成一份方案管理计划，该计划定义了用于实现目标片段架构的各个项目的性质和范围，以及各个片段、其他组织的举措以及相关的跨部门举措之间的依赖关系。方案管理计划还包括了一份效能改善战略，其中定义了一系列与效能目标相关联的用于维护组织企业架构过渡战略的里程碑。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 如何运用现有资源来达成效能目标？为了解答这个问题，架构开发团队需要开发一份详细且可执行的方案管理计划，用于描述各个实施项目以及为了达成目标片段架构而制定的这些项目之间的逻辑顺序。方案管理计划必须具有足够的详细程度，从而使得项目经历和开发人员能够明晰各个项目的范围、开发周期以及各个实施任务和活动之间的关系。此外，方案管理计划还需要明确其与其他组织的方案以及跨部门举措之间的关系。
      2. 用于实现目标片段架构和达到各效能目标的解决方案的性质是什么？为了解答这个问题，架构开发团队以及相关干系人需要协力执行在方案管理计划中制定的各个项目，并为目标片段架构中的各元素制定解决方案架构。各个项目的执行过程需要遵守组织的项目管理规则，而解决方案架构的定义和实施则需要与组织的系统开发方法相协调。片段架构的各种工作产品可以在系统开发过程中被重用，同时他们也为开发解决方案架构定义了需求和标准。解决方案架构的开发需要与片段架构和企业架构相兼容，并通过组织的治理流程来保证针对标准的兼容和重用。
      3. 向效能目标发展的进程执行情况如何？为了解答这个问题，架构开发团队以及相关干系人需要定义和监督各个效能量测指标以及目标效能评测量，并借此验证效能是否得以改善。

• • 此步骤要达到最终效果是：

1. 1. 1. 产生新的或经过修改的业务和信息管理需求。
      2. 产生用于描述片段架构的开发和实施所带来影响的效能矩阵。

• 片段架构的维护（Segment Architecture Maintenance）：此步骤吸收和同化新的业务和信息需求，并使用他们来更新片段架构的工作产品。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 针对各片段的新的或修正过的变更驱动力是什么？为了解答这个问题，架构开发团队需要更新架构变更驱动力列表。在此过程中，新的或经过修改的变更驱动力将作为片段架构维护活动的输入，并被用来定义新的驱动力对现有片段架构工作制品的影响。架构开发团队还需要对各个自上而下以及自下而上的变更驱动力（包括从业务和信息管理解决方案的开发和实现而来的反馈）进行监督和同化。
      2. 这些新的变更驱动力针对片段架构工作产品的影响是什么？为了解答这个问题，架构开发团队需要对新的变更驱动力进行分析，判断其优先级顺序，并确定各项需求对现有片段架构工作产品的影响。项目经理和架构开发团队还需要制定一份用于更新片段架构工作产品的行动计划来应对各具有优先级的驱动力，并将其中的各项行动纳入到方案管理计划中。这一行动计划应包含用于修改片段架构的片段架构开发流程中的各项元素，并需要被安排来支持各生命周期流程，例如IT投资管理流程。

• • 此步骤要达到最终效果是：为片段架构相关元素的更新分配合适的资源。

软件架构设计（二） 导言

流程

 

　　描述关键流程的概览图：

 

 

　　架构设计活动位于开发和需求的中间。虽然需求这个阶段主要是业务分析人员的责任，但是架构师也会参与这个活动的一些详细任务。随后，架构师在创建逻辑架构中首先创建一个大概的逻辑架构，这个时候不考虑技术因素。这步是从需求到物理架构的一个跳板。物理架构是需要考虑技术因素的。逻辑架构会做为逻辑详细设计执行的任何详细设计的输入。

 

　　在需求、逻辑架构、逻辑详细设计的基础上，架构师对这种架构凝练并最终产生物理架构。物理架构作为物理详细设计执行的任何详细设计的输入。物理详细设计会成为实现的基础。详细设计和实现并不是架构师的职责。但需要架构师在需要的时候为这些团队提供指导。

 

　　架构设计可以看作是战略上的设计，而详细设计可以看作是战术上的设计。

 

　　下面详细的看一下其中的部分活动

 

　　定义需求活动中的任务：

 

 

　　这个任务从收集利益相关者的需求开始，它关注于了解各种各样利益相关者的需求。这些需求为架构师提供了需要设计系统的范围的一个初始的指示，在整理常用词汇完成后，架构师非常关注定义系统上下文。因为他定义了与系统交互的外部元素，如最终用户和外部系统。在这个上下文基础上，概要说明功能需求和非功能需求。架构师不仅对关键的功能性需求感兴趣，还应对系统质量（性能）、解决方案约束（非功能性需求）感兴趣，处理非功能性需求通常比处理功能性需求有挑战性。

 

　　在某种程度上，架构师参与整个定义需求以确保需求能够按照可能的技术、在制定的时间和预算内可以实现的方式来制定。就我们关心的需求任务而言，指定需求优先级与架构师关系特别大，架构师要保证优先级受那些能使架构尽可能快速稳定的需求和风险的影响。高优先级的需求会在细化功能性需求和细化非功能性需求中进行细化。接下来，架构师在更新软件架构文档中正式的编写架构上重要需求的概要文档。最终以和利益相关者复审需求结束。

 

　　创建逻辑架构活动中的任务：

 

 

　　基于最高优先级的需求，架构师在个定义架构概图中概要的说明候选的解决方案，架构概览定义了架构的整体轮廓。概要说明功能性元素和概要说明部署元素同时进行，接着根据组件，他们的关系和交互精炼这个轮廓。检验架构确保功能性元素和部署元素一致，尤其是确保跨这些元素的任何要点都被适当的处理。在构建架构证明中架构师关注证明架构的某些方面，概念证明提供了一个工具来减少某些与架构相关的风险。接下来，架构在系统功能性元素和细化部署元素中得到细化。确认架构确保架构像声明那样满足需求，还确保项目上的一些考虑，如资源，进度和预算约束。然后，架构师在更新软件架构文档这个任务中编写一个不依赖于平台的架构的概要。由此形成的架构描述用来和利息相关人员沟通架构，这些相关人员包括设计人员，程序员，分析人员，项目经理，维护人员和支持人员。最后，在和利益相关者复审架构中使大家对架构达成一致意见。

 

　　创建物理架构于创建逻辑架构任务完全一样，只不过创建物理架构需要考虑技术因素。

 

　　当然，这些顺序并不是一个必须遵守的顺序（仅仅是一个比较合适的顺序），在需要的时候可以重新回到这些任务。

 

 

 

 

 

分类: 软件架构设计

ArcGIS Engine中的Symbols详解

尊重劳动成果，转载请注明来源。

Symbols

    ArcObjects用了三种类型的Symbol（符号样式）来绘制图形特征：marker symbols（标记符号），line symbols（线符号），和fill symbols（填充符号）。这些样式同样可以用来绘制elements（元素）图形，比如在地图或制版视图上的图表边线和指北针箭头。第四个样式text symbol（文字符号）是用来绘制标注和其他文本要素的。第五个样式3D chart symbol（图表样式）是用来绘制图表的。在图形元素设置的实例中，一种样式被作为属性赋给所有的元素。图层然而由一个包含一个或多个样式的结合进行绘制。样式（符号）的大小总是指定到一些点上（比如线的宽度），但是几何形状（如线的路径）的大小是由它们本身来决定绘制的。多数情况下，当对象被创建时就已经有了一个默认的样式，因此省去了创建新样式赋给每一个对象的过程，你可以修改一个已经存在的样式。另外一种方式获取样式的方式是用样式文件。ArcObject使用样式文件，可分发数据库存储和访问样式和颜色。有许标准样式，提供了上千种预定义的可用的样式，在安装路径下。利用StyleGallery和StyleGalleryItem两个类，你可以弥补和修改现存的符号样式，这可以使得比重新绘制和创建更高效。你同样可以使用ArcMap的标准样式编辑器，它可以在程序里面使用SymbolEditor类打开。下面的小节将描述怎样利用第一个规则创建一个复杂的符号样式。ISymbol接口提供了对所有符号样式的高等级功能，它允许你使用设置直接绘制一个符号样式。

       更多的附加信息，参见Creating custom symbols

Symbol level drawing

       你可以使用符号等级绘图功能改变图层对象的绘制顺序。在使用符号等级绘制时，你可以控制到是元素按照最基础的一个个样式顺序绘制。这将意味着元素不一定需要以与图层出现在ArcMap表的内容中相同的顺序绘制。使用符号等级绘制，你可以控制一个含控制器绘制元素符号绘制元素的绘制。更多的是，当使用多个样式符号时，你可以控制单个符号层的绘制顺序。

       符号等级绘制在地图套管中最有用。因为它能被用来创建天桥和和地下通道，当线对象有穿过状态时，它是一个非常好的方式展现连接状态。符号等级绘制能够用来更好地表达其他更多的影响和状况。

Join and merge

       下面的图形展示了一个合并样式的效果，它使得对象拥有一致的样式相互连接起来。合并使得有不同样式的对象连接显示。这些变化在使用符号等级对象和接口后场景显示在后台自动实现效果。你可以使用，相对于图层的ISymbolLevels.UseSymbolLevels或相对整个地图的IMp.UserSymbolLevels接口，来切换符号等级绘制的开关。

       使用了地图等级符号绘制的两个示例：

       更多信息，参见：How to use symbol level drawing

 

Marker symbols

       下面的图表展示的是标记符号样式的类结构：

       IMarkerSymbol接口提供了标记样式共同拥有的一些属性：Angle，Color，Size，XOffset，和YOffset。IMarkerSymbol是所有标记样式的原始接口。所有的其他标记接口都继承IMarkerSymbol的属性和方法。这个接口有5个可读可写属性，它们允许你在任何标记样式类中获取和设置基础的属性。Color属性能够被任何IColor类型的对象设置，它的具体影响基于你使用的类型。
       标记样式类的颜色属性设置属性表如下：

       Size属性设置符号整体的高度，包含SimpleMarkerSymbol，CharacterMarkerSymbol，PictureMarkerSymbol和MultiLayerMarkerSymbol类型。对于ArrowMarkerSymbol类型，Size表示长度。基本单位是点。除了PictureMarkerSymbol的默认大小是12外，其他的默认的大小都是8。Angle属性设置角度，单位是度。符号是从水平方向开始向逆时针方向进行旋转。它的默认值是0。XOffset和YOffset属性定义样式绘制时离实际对象的偏移距离。两个属性都是在打印的点中，默认值是0，值可为正和负。负数表示相对于对象向下偏移和向右偏移，当然正数表示向上和向左偏移。Size、XOffset和YOffset在打印机点上1/71英寸大小。
       下面的图展示了一些标记样式：

       标记符号的旋转指定到数学表达中，下图展示了标记符号的旋转：

       下图展示了一些简单的标记样式：
       
       下图展示了一些箭头标记样式：
       
       下图展示了一些图表标记样式：
       
       下图展示了一些图片标记样式：
       
       下图展示了一些多层标记样式：
       
       更多信息，参见：

•     How to make a character marker symbol
•     How to make a picture marker symbol
   

  Line symbols

         线符号样式的的类视图如下图所示：
  
         LineSymbol接口拥有两个所有线样式共同拥有的属性：Color和Width。ILineSymbol是线样式共同的原始接口，将继承ILineSymbol所有的属性和方法。接口有两个可读可写属性，在所有的线样式类中允许对其获取和设置。Color属性控制基础线（它不是影响任何存在的装饰线条，请参阅ILineProperties接口）的颜色并且可有任何IColor类型的对象设置。颜色线条除了SimpleLineSymbol默认被设置成中灰色，其他的都默认是黑色。Width属性设置的是所有的线宽度，单位是点。对于HashLineSymbol，Width属性设置的是所有哈西的长度。除了MarkerLineSymbol的默认宽度为8外，所有的线符号的默认宽度都是1。
         线符号表示了一个对象或图形绘制的定义。Straight lines、polylines、curves和outlines都能用线符号进行绘制。下图展示了一些线符号：
  
         一个线符号被打印出来是1/72英寸。下图展示了一个线符号宽度的样例：
  
         更多信息，参见：How to make a cartographic line symbol
   

  Fill symbols

         下图展示了填充符号的类结构视图：
  
         下图展示一些填充符号样式：
  
         IFillSymbol接口呈现了两个属性，Color和Outline，他们是所有填充符号类型都拥有的属性。
  在ArcOjbects中，IFillSymbol被所有的更专业的填充样式类型所继承，有两个可读可写属性。Color属性控制这基本的填充，在下表所示，可以使用IColor类型进行设置。
  
         Outline属性在ILineSymbol中的设置，被绘制到填充的外边框。不同的填充符号表达了一个多边形的面积和边框如何绘制。默认的外边框线是一条SimpleLineSymbol实线，你也可以使用任何类型的线样式作为外边框线。外边框线的中线在对象的边沿上，所以，一个宽度为5的外框线将重叠填充符号可见的数量。
  
         更多信息，参见：

•     How to make a line fill symbol
•     How to make a gradient fill symbol
   

  Text symbols

         下图展示了文字符号样式的类视图：
  
         TextSymbol类提供了一种用来符号化图形元素中的文字、注记、标注等等。文字符号样式不仅仅只是定义了字体。主要接口ITextSymbol、ISimpleTextSymbol和IFormattedTextSymbol控制这文字怎样展现和单个字符的展现方式。TextSymbol支持扩展的ASCII码。
         更多信息，参见：

•     Creating other kinds of custom symbols
•     How to make a line callout
   

  Chart symbols

   

         3DChartSymbol是一个抽象的三种类型的图表符号。它代表了一种标记符号，可以使用ChartRenderer的多个属性来符号化地理数据。虽然它被普遍应用于ChartRenderer，如果所有属性都设置适当，你也可以使用符号作为标记符号符号化单个人对象或元素。
  在图表符号中IChartSymbol被用来计算柱子和饼图片的大小。maximum属性值能被图表用来量算其他属性的值。在创建3DChartSymbol的时候该值总是被设置。当创建一个CharRenderer时，确保你的特征类已经统计完成，你可以统计统计功能设置MaxValue属性到maxmun属性值开始渲染。例如，加入有两个字段用一个图表来渲染，一个包含的值是从0至5，另一个包含的值是从0至10，设置最大值10。
         Value属性包含一组值，指示所有的柱状的的高度和宽度或饼的份额。假如你在CharRenderer中使用ChartSymbol，你不需要设置这个属性。这个值数组将在CharRenderer绘图的过程中，FeatureClass类使用从指定的属性字段的属性值，从每个功能创建一个稍微不同的符号进行重复填充。绘制完成后所有的值被设置成空或0。单独使用ChartRenderer时，在柱状和饼子图中设置你想要使用的数组值。
         更多信息，参见：
         Creating custom symbols

         Creating other kinds of custom symbols

         Sample: Triangle graphic element

 

 

 

标签: ArcGIS, Symbols, 详解