精华内容
下载资源
问答
  • 国家减排空间系统总体架构设计
  • 系统总体结构设计

    千次阅读 2020-02-16 04:25:08
    系统总体结构设计     系统设计工作应该自顶向下地进行。首先设计总体结构,然后再逐层深入,直至进行每一个模块的设计。总体设计主要是指在系统分析的基础上,对整个系统的划分(子系统)、机器...


    系统总体结构设计

        系统设计工作应该自顶向下地进行。首先设计总体结构,然后再逐层深入,直至进行每一个模块的设计。总体设计主要是指在系统分析的基础上,对整个系统的划分(子系统)、机器设备(包括软、硬设备)的配置、数据的存贮规律以及整个系统实现规划等方面进行合理的安排。

    一、系统设计的任务

    1. 系统设计的概念

    系统设计又称为物理设计,是开发管理信息系统的第二阶段,系统设计通常可分为两个阶段进行,首先是总体设计,其任务是设计系统的框架和概貌,并向用户单位和领导部门作详细报告并认可,在此基础上进行第二阶段――详细设计,这两部分工作是互相联系的,需要交叉进行,本章将这两个部分内容结合起来进行介绍。

    系统设计是开发人员进行的工作,他们将系统设计阶段得到的目标系统的逻辑模型转换为目标系统的物理模型,该阶段得到工作成果――系统设计说明书是下一个阶段系统实施的工作依据。

    2.系统设计的主要内容

    系统设计的主要任务是进行总体设计和详细设计。下面分别说明它们的具体内容。

    (1) 总体设计

    总体设计包括系统模块结构设计和计算机物理系统的配置方案设计。

    <1>系统模块结构设计

    系统模块结构设计的任务是划分子系统,然后确定子系统的模块结构,并画出模块结构图。在这个过程中必须考虑以下几个问题:

    如何将一个系统划分成多个子系统;

    每个子系统如何划分成多个模块;

    如何确定子系统之间、模块之间传送的数据及其调用关系;

    如何评价并改进模块结构的质量。

    <2>计算机物理系统配置方案设计

    在进行总体设计时,还要进行计算机物理系统具体配置方案的设计,要解决计算机软硬件系统的配置、通信网络系统的配置、机房设备的配置等问题。计算机物理系统具体配置方案要经过用户单位和领导部门的同意才可进行实施。

    开发管理信息系统的大量经验教训说明,选择计算机软硬件设备不能光看广告或资料介绍,必须进行充分的调查研究,最好应向使用过该软硬件设备的单位了解运行情况及优缺点,并征求有关专家的意见,然后进行论证,最后写出计算机物理系统配置方案报告。

    从我国的实际情况看,不少单位是先买计算机然后决定开发。这种不科学的、盲目的做法是不可取的,它会造成极大浪费。因为,计算机更新换代是非常快的,就是在开发初期和在开发的中后期系统实施阶段购买计算机设备,价格差别就会很大。因此,在开发管理信息系统过程中应在系统设计的总体设计阶段才具体设计计算机物理系统的配置方案。

    (2) 详细设计

    在总体设计基础上,第二步进行的是详细设计,主要有处理过程设计以确定每个模块内部的详细执行过程,包括局部数据组织、控制流、每一步的具体加工要求等,一般来说,处理过程模块详细设计的难度已不太大,关键是用一种合适的方式来描述每个模块的执行过程,常用的有流程图、问题分析图、IPO图和过程设计语言等;除了处理过程设计,还有代码设计、界面设计、数据库设计、输入输出设计等。

    (3) 编写系统设计说明书

    系统设计阶段的结果是系统设计说明书,它主要由模块结构图、模块说明书和其它详细设计的内容组成。


    系统设计的方法与工具

    系统设计的工作复杂又细致,总体设计阶段需要进行系统模块结构设计,要将一个大系统分解成不同层次、多个模块组成的系统,在详细设计阶段要在模块结构设计的基础上,给出每个模块实现方法的细节,并对模块的输入、输出和处理过程作详细描述,以便在系统实施阶段进行程序设计时可以把这个描述直接“翻译”成用某种程序设计语言书写的程序。系统设计在技术上有相当的难度,为此需要有一定的设计方法和设计工具来指导。70年代以来,出现了多种设计方法,其中结构化设计方法是较为典型的方法,本章将对该设计方法进行论述并介绍几个常用的设计工具。

    一、结构化设计的方法

    结构化设计(STRUCTURED DESIGN, 简称SD)方法是使用最广的一种设计方法,由美国IBM公司的W·STEVENS、G·MYERS和L·CONSTANTINE等人提出。该方法适合于软件系统的总体设计和详细设计,特别是将一个复杂的系统转换成模块化结构系统,该方法具有它的优势。在使用过程中可将结构化设计方法与结构化分析(SA)方法及编程阶段的结构化程序设计方法(SP)前后衔接起来,SD方法具有以下特点:

    1. 相对独立、功能单一的模块结构

    结构化设计的基本思想是将系统设计成由多个相对独立、功能单一的模块组成的结构。由于模块之间相对独立,每一模块就可以单独地被理解、编写、测试、排错和修改,从而有效地防止错误在模块之间扩散蔓延,提高了系统的质量(可维护性、可靠性等)。因此,大大简化了系统研制开发的工作。

    2. “块内联系大、块间联系小”的模块性能标准

    “模块内部联系要大,模块之间联系要小”,这是结构化设计中衡量模块“相对独立”性能的标准。事实上,块内联系和块间联系是同一件事的两个方面。系统中各组成成分之间是有联系的,若把联系密切的成分组织在同一模块中,块内联系高了,块间联系自然就少了。反之,若把密切相关的一些组成成分分散在各个模块中,势必造成很高的块间联系,这将影响系统的可维护性。所以,在系统设计过程中一定要以结构化设计的模块性能标准为指导。

    3. 采用模块结构图的描述方式

    结构化设计方法使用的描述方式是模块结构图。例如,图6-2-1示了一个计算工资的模块结构图。

    图6-2-1  计算工资的模块结构图

    系统模块结构设计

    总体设计的另外一个主要内容是合理地进行系统模块结构的分析和定义,将一个复杂的系统设计转为若干个子系统和一系列基本模块的设计,并通过模块结构图把分解的子系统和一个个模块按层次结构联系起来。下面来介绍如何进行模块的分解、如何从数据流图导出模块结构图以及模块结构图的改进。

    一、模块分解的原则和依据   

    系统逻辑模型中数据流图中的模块是逻辑处理模块,模型中没有说明模块的物理构成和实现途径,同时也看不出模块的层次分解关系,为此在系统结构设计中要将数据流图上的各个逻辑处理模块进一步分解,用模块结构图确定系统的层次结构关系,并将系统的逻辑模型转变为物理模型。

    1.“耦合小,内聚大”的基本原则

    在结构化设计中,采用自顶向下,逐步细化的方法将系统分解成为一些相对独立、功能单一的模块。如何度量模块之间的独立性呢?

    在一个管理信息系统中,系统的各组成部分之间总是存在着各种联系的,将系统或子系统划分成若干模块,则一个模块内部的联系就是块内联系,而穿越模块边界的联系就是块间联系。由于模块之间的互相联系越多,模块的独立性就越少,因此,引入模块耦合和内聚的概念。

    耦合表示模块之间联系的程度。紧密耦合表示模块之间联系非常强,松散耦合表示模块之间联系比较弱,非耦合则表示模块之间无任何联系,是完全独立的。

    内聚表示模块内部各成分之间的联系程度。

    一般说来,在系统中各模块的内聚越大,则模块间的耦合越小。但这种关系并不是绝对的。耦合小使得模块间尽可能相对独立,从而各模块可以单独开发和维护。内聚大使得模块的可理解性和维护性大大增强。因此,在模块的分解中应尽量减少模块的耦合,力求增加模块的内聚。

      2.对子系统或模块进行划分的依据

    一个合理的子系统或模块划分,应该是内部联系强,子系统或模块间尽可能独立,接口明确、简单,尽量适应用户的组织体系,有适当的共用性。也就是上面所说的“耦合小,内聚大”。按照结构化设计的思想,对模块或子系统进行划分的依据通常有以下几种:

    (1)按逻辑划分,把相类似的处理逻辑功能放在一个子系统或模块里。例如,把“对所有业务输入数据进行编辑”的功能放在一个子系统或模块里。那么不管是库存、还是财务,只要有业务输入数据都由这个子系统或模块来校错、编辑。

    (2)按时间划分,把要在同一时间段执行的各种处理结合成一个子系统或模块。

    (3)按过程划分,即按工作流程划分。从控制流程的角度看,同一子系统或模块的许多功能都应该是相关的。

    (4)按通信划分,把相互需要较多通讯的处理结合成一个子系统或模块。这样可减少子系统间或模块间的通讯,使接口简单。

    (5)按职能划分,即按管理的功能。例如,财务、物资、销售子系统,或输入记帐凭证、计算机优解子系统或模块等等。

    一般来说,按职能划分子系统,按逻辑划分模块的方式是比较合理和方便的,图6-4-1表示了按这种方式划分所组成的系统。

    图6-4-1  子系统按职能、模块按逻辑划分所形成的系统

    详细设计

    进行了系统的总体设计后即可在此基础上进行系统的详细设计了,即各种输入、输出、处理和数据存储等的详细设计。下面分别介绍详细设计的内容。

    一、代码设计

    代码是用来表示事物名称、属性和状态等的符号。在管理信息系统中,代码是人和机器的共同语言,是系统进行信息分类、校对、统计和检索的依据。代码设计就是要设计出一套能为系统各部门公用的、优化的代码系统,这是实现计算机管理的一个前提条件。

    1. 代码设计的原则

    代码设计是一项重要的工作,合理的编码结构是使管理信息系统具有生命力的重要因素。设计代码的基本原则是:

    (1) 具备唯一确定性。每一个代码都仅代表唯一的实体或属性。

    (2) 标准化与通用性。凡国家和主管部门对某些信息分类和代码有统一规定和要求的,则应采用标准形式的代码,以使其通用化。

    (3) 可扩充且易修改。要考虑今后的发展,为增加新代码留有余地。当某个代码在条件或代表的实体改变时,容易进行变更。

    (4) 短小精悍即选择最小值代码。代码的长度会影响所占据的内存空间、处理速度以及输入时的出错概率,因此要尽量短小。

    (5) 具有规律性、便于编码和识别。代码应具有逻辑性强,直观性好的特点,便于用户识别和记忆。   

    2.分类方法

        目前最常用的分类方案有两种,一种是线分类方法,一种是面分类方法。在实际应用中根据具体情况各有其不同的用途。

        线分类方法:首先给定母项,然后下分若干子项,由对象的母项分大集合,由大集合确定小集合,最后落实到具体对象

        特点:结构清晰,容易识别和记忆,易查找;

              适应于手工系统;

        缺点:结构不灵活,柔性差。

              机关党政生产经营 … …

           线分类时要掌握两个原则:唯一性和不交叉性。

        例:公司生产组织结构,如图6-5-1所示。

    图6-5-1  公司生产组织结构

        面分类方法:它主要从面的角度来考虑分类

        面分类的特点:

        柔性好,面上的增、删、改很容易;

        可实现按任意组配面的信息检索,对机器处理有良好的适应性;

        缺点是不易直观识别,不便于记忆。


    系统设计报告

        系统设计阶段的成果是系统设计报告, 其主要是各种设计方案和设计图表,它是下一步系统实现的基础。

    一、系统设计的成果

        系统设计阶段的成果归纳起来一般有 (点击这里观看“各开发环节之间的关系”动画演示)

        1.系统总体结构图(包括总体结构图,子系统结构图,计算机流程图等)。

        2.系统设备配置图(系统设备配置图: 主要是计算机系统图,设备在各生产岗位的分布图,主机、网络、终端联系图等)。

        3.系统分布编码方案(分类方案、编码系统)。

        4.数据库结构图(DB的结构,主要指表与表之间的结构,表内部结构(字段、域、数据字典等)。

        5.HIPO图(层次化模块控制图、IPO图等等)。

        6.系统详细设计方案说明书

    二、系统设计说明书的组成

    1.引言

     

    (1) 摘要   系统的目标名称和功能等的说明

    (2) 背景

    l 项目开发者

    l 用户

    l 本项目和其它系统或机构的关系和联系

    (3) 系统环境与限制

    l硬件、软件和运行环境方面的限制

    l保密和安全的限制

    l有关系统软件文本

    l有关网络协议标准文本

    (4) 参考资料和专门术语说明

     

    2.系统设计方案 

    (1) 模块设计

    l系统的模块结构图

    l各个模块的IPO图(包括各模块的名称、功能、调用关系、局部数据项和详细的算法说明等)

    (2) 代码设计

    l各类代码的类型、名称、功能、使用范围和使用要求等的设计说明书

    (3) 输入设计

    l输入项目

    输入人员(指出所要求的输入操作人员的水平与技术专长,说明与输入数据有关的接口软件及其来源)

    l主要功能要求(从满足正确、迅速、简单、经济、方便使用者等方面达到要求的说明)

    l输入校验(关于各类输入数据的校验方法的说明)

    (4) 输出设计

    l输出项目

    l输出接受者

    l输出要求(所用设备介质、输出格式、数值范围和精度要求等)

    (5) 文件(数据库)设计说明

    l概述(目标、主要功能)

    l需求规定(精度、有效性、时间要求及其它专门要求)

    l运行环境要求(设备支撑软件,安全保密等要求)

    l逻辑结构设计(有关文件及其记录、数据项的标识、定义、长度和它们之间的关系)

    l物理结构设计(有关文件的存贮要求、访问方法、存贮单位、设计考虑和保密处理等)

    (6) 模型库和方法库设计(本系统所选用的数学模型和方法以及简要说明)

    (7) 安全保密设计

    (8) 物理系统配置方案报告

    l硬件配置设计

    l通信与网络配置设计

    l软件配置设计

    l机房配置设计

    (9) 系统实施方案及说明

    l实施方案

    l实施计划(包括工作任务的分解、进度安排和经费预算)

    l实施方案的审批(说明经过审批的实施方案概况和审批人员的姓名)

    3.案例   

    序号模块名称主要用途
    1无线寻呼管理信息系统-系统设计说明书    研究开发5-10万用户寻呼机管理信息系统,它可以进行普通寻呼服务;漫游寻呼服务;群呼服务;试机服务;定时服务;系统管理;运行管理。 
    2库存管理系统-系统设计说明书    研发库存控制系统的主要目的:1)为顾客订货提供更好的服务;2)控制库存水平;3)决定向厂家订货的时间和批量。
    3百货商店业务管理信息系统-系统设计

    实现登记、整理数据,处理核对顾客订货单;向经理提供各种业务统计报表;提供各级查询;销售、采购、会计各部门的业务数据处理实现自动化。

    4铁道财务会计管理信息系统-系统设计    运用系统的方法以计算机和现代通信技术为基本信息处理手段和工具的,能为全国铁道财务会计核算、管理、决策提供信息服务的人—机系统。
    5高校选课辅助决策    本选课系统能够使学生在INTERNET上自主、便捷、准确地进行全校性课程选择的一种软件。学生在选择选修课前,可以上网进行查询,当学生输入其学号与密码后,系统便调出其所有相关信息,包括已修课程、已修课程的成绩、专业培养计划、全校性可选课程,系统进行综合分析后,得到一些可行的方案,供选课学生参考,并提出合理建议。
    6条形材料选材优化    要制造器件,必须先制造一定的零件,而这些零件又由某种原材料截取而得到。例如:用某一种条形材料锯成数种需要的零件,求最少的用料数量。使用<<运筹学>>线性规划的思想和解决方法。

        


    https://blog.csdn.net/aa2397199142/article/details/50686499

    展开全文
  • 系统总体结构设计.doc

    2021-10-10 16:54:49
    系统总体结构设计.doc
  • 各种系统架构图与详细说明

    万次阅读 多人点赞 2018-09-15 17:49:59
    如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。...
      1. 共享平台逻辑架构设计

    如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面:

    1 应用系统建设

    本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。

    2 应用资源采集

    整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。

    3 数据分析与展现

    采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。

    4 数据的应用

    最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。

    综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相关架构进行描述。

     

      1. 技术架构设计

    如上图对本次项目整体技术架构进行了设计,从上图我们可以看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。

      1. 整体架构设计

    上述两节,我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明,通过上述设计,我们对整体项目的架构图进行了归纳如下:

    综上,我们对整体应用系统架构图进行了设计,下面我们将分别进行说明。

        1. 应用层级说明

    整体应用系统架构设计分为五个基础层级,通过有效的层级结构的划分可以全面展现整体应用系统的设计思路。

    基础层

    基础层建设是项目搭建的基础保障,具体内容包含了网络系统的建设、机房建设、多媒体设备建设、存储设备建设以及安全设备建设等,通过全面的基础设置的搭建,为整体应用系统的全面建设良好的基础。

    应用数据层

    应用数据层是整体项目的数据资源的保障,本次项目建设要求实现全面的资源共享平台的搭建,所以对于应用数据层的有效设计规划对于本次项目的建设有着非常重要的作用。

    从整体结构上划分,我们将本次项目建设数据资源分为基础的结构型资源和非结构型资源,对于非结构型资源我们将通过基础内容管理平台进行有效的管理维护,从而供用户有效的查询浏览;对于结构型数据,我们进行了有效的分类,具体包括政务公开资源库、办公资源库、业务经办资源库、分析决策资源库、内部管理资源库以及公共服务资源库。通过对资源库的有效分类,建立完善的元数据管理规范,从而更加合理有效的实现资源的共享机制。

    应用支撑层

    应用支撑层是整体应用系统建设的基础保障,根据本次招标文件相关需求,我们进行了相关面向服务体系架构的设计,通过统一的企业级总线服务实现相关引用组件包括工作流、表单、统一管理、资源共享等应用组件进行有效的整合和管理,各个应用系统的建设可以右下基于基础支撑组件的应用,快速搭建相关功能模块。

    由此可见,应用支撑层的建设是整体架构设计的核心部分,其关系到本次项目的顺利搭建以及今后区劳动局信息化的发展。

    应用管理层

    在3.3.3图中的设计中,应用管理层有效的承接了我局原有应用系统分类标准,将实际应用系统分成了八个应用体系,在实际应用系统的建设中,我们将全面传承原有应用分类标准规范的基础上实现有效的多维的应用资源分类方法,不仅如此,整体应用系统也可以通过多维的管理模式进行相关操作管理,如按照业务将应用系统进行划分,包括劳动管理和保险管理等。

    应用管理层是实际应用系统的建设层,通过应用支撑层相关整合机制的建立,我们将实现应用管理层相关应用系统的有效整合,通过统一化的管理体系,全面提升我局应用系统管理效率,提升服务质量。

    展现层

    整体应用功能将通过门户方式进行展现,架构分别设计了内网门户和外网门户,不同的应用人员通过登录可以实现相关系统的应用和资源的浏览查询操作。

    1. 3.2准体系规范说明

    大型的应用工程项目的建设必须遵照严格的标准体系建设规范,根据本次项目实际需求,我们通过三个规范体系对项目进行合理的保障,具体包括了安全标准管理系统、标准规范体系以及运行管理体系。

    通过相关标准的制定、安全架构的保障以及管理规范的建设可以保障整体应用系统的设计、搭建、运维等全流程性工作。

    1. 3.3应用用户设计

    通过分析,我们将整体应用系统面向人群分为四类,具体包括广大公众、区内委办局、局内相关部门以及用人单位,不同对象通过访问不同门户可以进行全面的服务保障。

    1. 3.4系统建设总结

    在3.3.3图中对本次项目整体应用系统建设需求同样也进行了归纳,项目整体分为三个主体建设,即:共享信息平台的搭建、原有应用系统的改造以及新的应用系统的搭建。

    共享信息平台的建设旨在全面整合相关应用系统资源,实现有效的浏览、查询检索机制,整体数据通过规范化的元数据管理机制,实现有效的梳理存储,为今后资源的整合奠定基础。不仅如此,在实际项目建设中还将引入商业智能应用模块,实现对共享资源的智能化分析,从而为决策预警等提供有力依据。

    原有业务系统改造则是实现原有应用系统相关流程等的优化配置,并通过有效的数据梳理改造为信息资源的共享奠定良好的基础。本次项目中需要改造系统包括:政务公开系统、办公自动化系统、公众服务系统以及综合管理系统。

    新的业务系统的建设则是要全面提升现阶段我局整体办公效率,继续加强信息化建设,通过更加全面合理的应用系统的建设,提升我局整体服务水平。本次项目需要建设系统包括:业务经办系统、社会保险系统、土地储备系统、企业监督系统、劳动监察系统、劳动关系与仲裁系统、就业和失业管理系统以及综合管理系统。

    1. 3.5应用接口管理

    本次项目建设还涉及到整体应用系统与外部相关系统接口的管理,实际应用接口包括与税务接口、与财政部门接口、与民政部门接口、与基层单位接口与公安部门接口以及与其他部门的接口。

    通过有效的接口管理机制,实现资源的互联互通,从而更加有效的提升我局无纸化办公机制,全面加强我局整体工作效率。

      1. 系统整体逻辑架构

    规划一个成熟先进的北京市卫生人才交流服务中心网站平台系统框架是一切技术工作的先决条件,是奠定系统性能的基础,是至关重要的。

    因此,本项目建设应首先考虑设计和建立一个统一的北京市卫生人才交流服务中心门户网站系统技术体系,能够支持政府信息资源的整合、管理及门户网站群的建设,提供统一的内容管理、资源整合、安全管理构架,并提供对应用服务的统一调度和管理,同时,系统体系结构应分层组织,系统功能模块化,系统集成松耦合,方便业务应用的修改、重用和部署,满足系统未来弹性扩展的要求。

    系统逻辑框架如下图所示。

    整体系统包括三个体系一个平台进行全面保障,其中三个体系包括:

    1. 运行管理体系;
    2. 标准规范体系;
    3. 安全保障体系;

    具体平台根据新闻局实际需求建设网站群支撑管理平台,平台保障了相关招标文件中的采集管理、内容管理、统计管理、安全管理等功能需求,对于整体应用平台的支撑则通过中科软多年门户建设经验总结完成的相关应用组件包括工作流管理、元数据管理、电子表单等进行保障。

        1. 各主要组成部分概要描述
    1. 数据层

    对结构化数据和非结构化数据进行调度和存储。结构化数据包括:XML 和DBMS。非结构化数据包括:文本文件、音视频文件、office 系列文件、图形图像文件及ZIP、PDF、SWF等其他格式文件等,在数据接口上支持WebService 模块化组件。

    1. 支撑层

    支撑层通过应用服务器,提供对系统应用层强大的支持,包括:电子表单、工作流、元数据管理、安全审计等功能。并通过WEBSERVICE接口服务支持外部资源对内容管理基础数据以及内容管理对外部数据资源的应用数据集成。

    1. 应用层

    应用层是政府门户网站群非常重要的组成部分,是对信息处理的重要环节,按功能的不同可以分为:信息发布管理、网站群管理、系统管理、外挂组件管理、交互功能、多媒体信息管理、内容聚合:RSS等。

    1. 展现层

    政府门户网站群的最终表现是一组具有相同标准和相同规范体系的网站群体系。它涵盖主站、各级子网站、各类专题子网站等,同时系统为应用层的不同应用提供信息资源的不同表现形式,包括有Web、RSS等。

    1. 接入层

    实现客户通过浏览器来访问表现层以获取信息资源。

      1. 系统技术架构

    系统技术架构框架如图所示。

      1. 总体架构设计

    应用系统总体架构图

    如上图所示,本项目将采用数据与应用大集中的架构,即国际收支平衡管理管理信息系统只部署在国家外汇管理局,相关数据也集中存储在总局的国际收支平衡整合库中。整个系统采用B/S的结构,在进行数据清洗、转换,即ETL的时候会采用C/S结构,整个架构主要包括如下内容:

    1、构建应用支撑平台,提供统一的人员、组织机构和权限管理,提供支持各种复杂业务系统的开发和组装框架,实现单点登录和目录服务,并提供对应用系统的运行监控,数据的备份恢复等功能。

    国际收支平衡管理信息系统的各个子系统以及外汇局应用支撑平台门户都是基于应用支撑平台开发、组装和运行的。

    2、数据整合与交换系统是整个国际收支平衡管理信息系统的基础,负责将从外汇局内部(主要是现有的业务系统或者业务数据)和外汇局外部(主要是共建部委的共享数据)的相关外汇数据采集、清洗、转换,并通过数据传输通道汇总至统一的国际收支信息的整合数据库中。

    各分支局数据通过数据传输通道上传到国家外汇管理局,由数据整合和交换系统接收并处理数据,最终也汇总至总局的整合数据库中。

    数据交换将以成熟、稳定的第三方产品为基础进行设计和开发。

    3、开发新版国际收支网上申报系统,实现涉外收入申报业务网上受理,方便企业申报业务;建立与银行系统的接口,满足与银行的数据交换;方便银行的查询和审核操作。

    网上申报数据将统一存储至网上申报数据库,并通过数据整合与交换系统与国际收支统计监测系统进行数据集成,同时申报数据最终汇总至总局的整合数据库中。

    网上申报系统将与外汇局的“一站式”网上服务平台集成,申报主体和银行将通过服务平台登录系统,进行申报、审核、查询统计等操作。

    外汇局人员也可通过服务平台或者外汇局的应用支撑平台门户登录系统,进行对申报数据的核查、查询统计操作。

    4、在数据整合与交换系统上建设统计分析系统,根据基础指标和统计分析指标将整合数据库中的信息动态生成各类统计分析报表(如国际收支平衡表、国际投资头寸表、结售汇统计报表等)。

    统计分析系统将利用数据仓库和多维联机在线分析技术,在对国际收支平衡状况的需求分析的基础上,提供面向主题的多种分析模型和分析方法,从多个角度分析国际收支平衡的状况和存在问题。统计分析结果将存储至外汇局数据仓库系统,为决策支持系统提供数据支撑,并可以通过BI工具在外汇局应用支撑平台门户进行展现。此外,统计报表信息通过数据整合与交换平台与金宏工程其他共建部委进行“共享”。

    5、在统计分析系统和总局数据仓库的基础上建设决策支持系统,通过基础指标,统计分析指标和统计分析系统产生的结果,借助OLAP分析模型工具,产生决策支持信息和预警信息,进行经济分析和预警,辅助外汇管理政策的制定。

    各类统计分析模型、预警模型将统一存放到“模型库”中,方便分析人员使用。此外还提供一套机制建设“知识库”,存储有关外汇管理的各类信息。

    (2)-(4)这几个系统在支撑平台的数据整合与交换基础上提供统一的数据交换接口,同时支持以XML作为统一的数据接口格式。

    6、建设外汇局应用支撑平台门户,通过门户对所有的系统进行统一管理,并且将统计分析、决策支持的结果和其他应用软件的功能模块通过信息集成门户提供给外汇局的领导、业务人员使用。

    外汇局应用支撑平台门户就是建设在应用支撑平台门户基础上。

    7、国际收支平衡管理系统与金宏共享平台、国际收支平衡共享数据库物理隔离,国际收支平衡管理系统中的数据通过涉密网和业务网之间的数据交换系统交换到金宏内网上的国际收支平衡共享数据库中,向共建部委提供数据服务。从共建部委获得的数据也通过涉密网和业务网交换系统,进入数据整合与交换系统中。

      1. 系统架构

    国际收支网上申报系统技术架构图

    企业用户可以通过“一站式”信息服务门户访问国际收支网上申报系统,完成涉外收支业务的申报,申报信息由数据管理模块通过特定的数据接口交换到银行业务系统,在银行业务系统进行审核。审核过后的结果信息再经过数据管理模块交换到网上申报系统供企业用户查询。

    企业用户需要在银行业务系统完成账户开户,定时由银行业务系统交换到网上申报系统供企业用户登录。

      1. 系统架构

    统计分析系统技术架构图

    1、统计分析系统的数据来源于数据仓库,通过条件查询模块从数据仓库得到满足用户的基础数据,由数据统计模块来对这部分基础数据进行汇总统计;

    2、汇总统计的数据根据外汇局用户的需要可以由报表定制模块利用原有的报表工具实现对国际收支平衡表、国际投资头寸表、结售汇统计报表、外债余额简表的设计以及利用Cognos的BI工具完成展现以及经过OLAP分析转化成多维数据;

    3、针对预先设计好的数据模型以及辅助模型管理模块来产生分析结果,供外汇局用户制定决策。

      1. 系统架构

    决策支持系统技术架构图

    1、决策支持系统利用从数据仓库获得的基础数据完成报表和查询,生成日、月、季报表供外汇局用户查询浏览;

    2、通过ASL规则引擎对基础数据进行分析,以风险模型为依据生成分析报告;

    3、利用数据挖掘模型对基础数据进行处理得到模型数据,与ASL分析信息共同生成分析报告,供外汇局用户来进行营运监管的管理;

    4、“知识库”的信息同时也提供给营运监管模块来进行运作。

      1. 总体架构

    国资委国有资产监督管理系统总体架构图

    国资委国有资产监督管理系统的总体框架主要包含六个层次,即基础平台层、数据资源管理层、应用支撑层、业务实现层、门户展现层、终端接入层。

    1.基础平台层:国资委IT基础平台主要包括网络系统、主机、存储系统、安全系统、配套的软件等。网络系统分为业务内网、业务外网和互联网。业务内网与业务外网物理隔离,互联网与业务外网通过防火墙配置实现逻辑隔离。

    2.数据资源管理层:数据资源管理层主要由数据库组成,其中结构化数据库主要包括管人、管事、管资产、纪检监督业务数据库、共享数据库、基础数据库、原有系统数据库及其它信息资源库等。非结构数据库主要是由一些文件型的数据构成。信息资源库主要是应用系统的数据库,它是业务应用信息系统的组成部分和数据中心的基础。

    3.应用支撑层:应用支撑层主要包括应用开发平台 (基础数据管理、报表管理、工作流管理、表单工具、门户引擎、规则引擎、工作流引擎、用户权限管理、目录服务、内容管理、接口管理、预警平台)和中间件(应用服务器、消息中间件、WEB服务器)。通过建设应用支撑平台,实现界面集成、应用集成、数据集成及流程集成,通过四个集成来达到国资委所有系统的集成效果。

    4.业务实现层:主要包括四大核心业务应用系统和数据中心。

    国资监管应用系统主要包括企业国有资产产权登记子系统、上市公司国有股权监督管理子系统、企业国有产权交易监督管理子系统、企业财务状况监督子系统设计、中央企业财务绩效评价子系统、中央企业财务预决算管理子系统、企业国有资产统计评价子系统、企业财务信息查询分析子系统、中央企业人员管理子系统、中央企业业绩考核子系统、中央企业重大投资管理子系统、中央企业经济运行监督子系统、纪检监察管理子系统等。

    国有资产数据中心:主要包括元数据注册器、信息资源数据库、信息资源目录体系、信息资源交换体系等。国有资产信息资源库是数据中心的基础,为国资委业务监管提供数据支持,包括企业基本信息数据、企业绩效评价数据、企业人员管理数据、企业财务数据、国有产权数据、资产统计数据、企业重组与规划投资数据、纪检监察数据、政策法规文献数据和其他业务数据十大类。作为统一信息资源平台,国有资产信息资源库对国资委各类共享数据提供统一的存储和管理,是国资委委内各厅局之间以及与其它政府机关之间进行数据交换和共享的基础平台,为各类业务的开展提供完整、统一和准确的数据支持。

    5.门户展现层:门户展现层主要由国资委数据采集门户构成、互联网门户、业务内网门户、业务外网门户组成。

    6.终端接入层:中央企业、地方国资委、上市企业(含国有股)、其它部门及公众通过统一的身份认证、权限管理登录数据采集门户、国资委业务外网门户、国资委互联网,并实现统一的入口、出口和单点登录。

    其中,中央企业、地方国资委、上市企业(含国有股)通过在线填报或离线填报(利用数据采集终端)的方式在数据采集门户上进行数据填报,数据采集门户及业务外网与内网物理隔离,通过应用支撑平台提供的数据交换组件实现内、外网的数据传输和交换。其它部门(包括金宏工程相关部门)也是通过应用支撑平台提供的数据交换组件实现内、外网的数据传输和交换。社会公众登录国资委互联网网站进行国资监管信息查询和交互。

    除此之外,贯穿着六个层次的还有国资委信息安全保障体系、项目实施与运维管理,和相关的标准体系和管理规范。

      1. 系统逻辑结构

    国资监管信息系统主要作用体现为国资监管业务服务。一期工程建设6大应用系统,形成10个信息资源库。其总体逻辑结构图如下:

    图5-1总体逻辑结构图

    通过四大业务系统(共计13个子系统)覆盖国资委管资产、管人、管事、资产监督的四大业务。

    其业务核心就是实现国有经济布局以及国有资产的增值保值。

    实现国有经济布局,具体是通过产权登记系统,掌握所有国有股权的分布情况。通过上市公司国有股权交易监督和其他企业国有股权交易监督系统,对国有股权的交易进行监控,随时了解国有经济的布局情况,并加以控制。通过资产统计、企业财务监督、中央企业预决算管理,等3个系统,全面获得企业的实际财务资产情况。

    另外通过中央企业经济运行管理系统,掌握中央企业的经济运行情况以及行业经济运行分析,从而对中央企业重大投资进行管理和监控,确保了解国有经济布局的运行情况和进行调整。

    实现国有资产的增值保值,具体措施是通过管人来实现,通过中央企业人员管理系统,后备、任命、管理企业管理者。通过企业绩效考核系统来评价、更换人员,来实现国有资产的增值保值。但不是简单的通过管人来实现国有资产增值保值,任命、考核,需要从资产管理、资产监督、企业运行情况等三个方面不断地获取信息,对管理者进行监督和引导,即使发现问题,确保国有资产的增值保值。

    通过13个业务应用系统覆盖四大业务职能,为解决目前监管业务中信息采集的问题、信息沟通的问题,需要建设13个业务应用系统统一的数据采集系统、信息发布系统。

    针对13个业务应用,形成了10大国有资产信息资源库,包括监管企业方面获得的6种信息:

    • 企业基本信息
    • 企业产权信息
    • 企业财务信息
    • 企业人员信息
    • 企业重组与规划投资信息
    • 其他业务信息

    以及国资委监管产生的4种信息:

    • 政策法规信息
    • 国有资产统计信息
    • 企业业绩考核信息
    • 纪检监察信息
      1. 系统体系结构

    本项目总体技术框架建立要遵循“整合资源,信息共享”、“统一架构,业务协同”的原则,应用系统采用多层架构,以信息资源库和公共服务为基础进行开发,实现资源和服务的共享,实现业务层和展现层的分离。总体技术框架如下图所示:

    图5-2 国资委国有资产监督管理系统总体技术框架

    总体框架主要包含六个层次:

    国资委IT基础设施:主要包括网络、服务器、存储系统、配套的系统软件、数据库和机房等。网络系统为内、外网物理隔离的双网结构。IT基础设施是国资委国有资产监督管理系统的基础平台。

    国有资产数据中心:主要包括元数据注册器、信息资源数据库、信息资源目录体系、信息资源交换体系等。国有资产信息资源库是数据中心的基础,为国资委业务监管提供数据支持,包括企业基本信息数据、企业绩效评价数据、企业人员管理数据、企业财务数据、国有产权数据、资产统计数据、企业重组与规划投资数据、纪检监察数据、政策法规文献数据和其他业务数据十大类。作为统一信息资源平台,国有资产信息资源库对国资委各类共享数据提供统一的存储和管理,是国资委委内各厅局之间以及与其它政府机关之间进行数据交换和共享的基础平台,为各类业务的开展提供完整、统一和准确的数据支持。

    国资委应用系统支撑平台:主要包括由表单工具、系统集成组件、内容管理工具、工作流组件、消息交换工具、应用中间件、统一用户管理和其他组件工具构成的应用支撑平台,从整合、协同、管理和服务四个方面对业务系统的开发、部署和运行进行支持。

    国有资产监督管理业务应用信息系统:主要包括搭建在应用支撑平台上的基础应用组件、通过基础应用组件组合成的企业国有资产产权登记子系统、上市公司国有股权监督管理子系统、企业国有产权交易监督管理子系统、企业财务状况监督子系统设计、中央企业财务绩效评价子系统、中央企业财务预决算管理子系统、企业国有资产统计评价子系统、企业财务信息查询分析子系统、中央企业人员管理子系统、中央企业业绩考核子系统、中央企业重大投资管理子系统、中央企业经济运行监督子系统、纪检监察管理子系统。

    应用数据库:主要是应用系统的数据库,是业务应用信息系统的组成部分。

    国资委信息发布系统:主要包括国资委内网消息发布、外网消息发布和互联网消息发布。

    除此之外,贯穿着六个层次的还有国资委信息安全保障体系、技术支持与运行维护体系。同时,国资委信息化相关的标准、规范、政策、法规也将在“国有资产监督管理系统”项目建设中必须加以重视,并积极推进。

    展开全文
  • 学生信息系统分析设计阶段所必需用到的结构功能,对与信息系统的分析具有重要作用。
  • windows 系统总体结构

    千次阅读 2013-11-15 16:14:54
    windows总体结构的关键系统组件,如下,它并没有显示各种驱动程序的的层次。  windows结构简图 用户模式和内核模式用线分割开来,上方代表用户模式进程,线下组件代是内核模式的操作系统服务。用户模式的线程...

    windows总体结构的关键系统组件,如下图,它并没有显示各种驱动程序的的层次。

                                               windows结构简图


    用户模式和内核模式用线分割开来,上方代表用户模式进程,线下组件代是内核模式的操作系统服务。用户模式的线程在一个受保护的进程地址空间中执行(当它们在内核模式执行时,可访问系统空间)。因此,系统支持进程,服务进程,用户应用程序,环境子系统都有各自的私有进程地址空间。

    四种基本的用户模式的进程简要描述如下:

    系统支持进程:固定的(或硬件指定的)系统支持进程,如登录和会话管理器,并不是windows的服务,他们不是由服务控制管理器来启动的。

    服务进程:服务进程宿纳的是windows服务,服务的运行通常要独立于用户登录。许多windows服务器应用,如sql server也包含了一些以windows服务方式来运行的组件。

    用户应用程序:有6种类型,windows 32位,windows 64位,windows3.1 16位,ms-dos 16位,posix 32位或os/2 32位。

    环境子系统:实现了操作系统环境的支持部分,这里的环境指操作系统展示给用户或程序员的个性化部分。windows nt最初有3个环境子系统,windows、posix、os/2,windows xp以后基本的产品中只有windows子系统随产品发布。


    在windows下,用户程序并不直接调用原始的windows操作系统服务,相反,他们通过一个或多个子系统动态链接库(DLLs)来发起调用。子系统DLL的角色是,将一个文档化的函数转化为一些恰当的内部(通常未文档化)windows系统服务调用。这个转化过程可能会——也可能不会——向正在为用户应用程序提供服务的环境子系统进程发送一个消息。


    内核模式组件包含下列部分:

    windows执行体:包含基本的操作系统服务,如内存管理、进程线程管理、安全性、I/O、网络和跨进程通信。

    windows内核:由一组低层次的操作系统功能构成,如线程调度,中断和异常分发,以及多处理器同步。他也提供了一组例程和基本对象,执行体的其余部分利用这些例程和对象实现更高层次的功能。

    设备驱动程序:既包括硬件设备驱动程序,也包括文件系统和网络驱动程序。其中,硬件设备驱动程序将用户的I/O函数调用转换为特定的硬件设备I/O请求。

    硬件抽象层:是一层特殊的代码,把内核、设备驱动程序、windows执行体的其余部分,跟与平台相关的硬件差异隔离开来。

    窗口和图形系统:实现了图形用户界面函数,比如对窗口的处理,用户界面控件,以及绘制等。

    下图列出系统核心组件文件名:


    可移植性(支持多种硬件体系结构和平台)

    两种方法实现可移植性:

    第一,windows分层设计,系统低层部分是与处理器体系结构相关,或与平台相关,这些部分被隔离到独立的模块中,所以系统的高层部分可以不考虑体系结构之间的差别,也不用关心硬件平台的差异。两个关键组件为系统提供了可移植性,他们是内核和硬件抽象层。与体系结构相关的功能在内核中实现,如线程环境切换;在同一体系结构中,不同系统间有差异的功能则在硬件抽象层实现,比如不同的主板。

    第二,windows绝大部分代码用C编写,少部分是C++。只有那些需要直接与系统硬件通信的部分(中断陷阱处理器),或者对性能极度敏感的操作系统部分(环境切换),才使用汇编语言编写。不仅在内核和硬件抽象层有汇编代码,而且在系统其他核心部分也有汇编代码,如实现了互锁指令的例程,以及本地调用设施中的一个模块。既可能在windows子系统内核模式部分,也可能在某些用户模式库中,如ntdll.dll中的进程启动代码。


    对称多处理器

    多任务是指在多个执行线程之间共享同一个处理器的操作系统技术。当计算机拥有多个处理器的时候,她可以同时执行多个线程。因此,单处理器操作系统只不过是看起来好像同时执行多个线程,但多处理器系统可以真正做到同一时刻处理多个线程,每个处理器上执行一个线程。

    windows是一个对称多处理操作系统,在这些处理器中没有主次之分,系统和用户线程可以被调度到任何一个处理器上运行,且所有处理器共享同一内存地址空间。

    而非对称多处理器系统中,系统选择其中一个处理器来运行操作系统内核代码,而其他处理器只运行用户代码,如下图。

                                                                              对称与非对称的比较


    所支持的处理器数目取决于windows版本,不同版本内核或硬件抽象层文件有差异。安装的时候,安装程序将正确的文件选择出来,拷贝到本地的"\windows\system32"目录中。为确定哪些文件应该被拷贝,可参见文件"\windows\repair\setup.log",他列出了所有要被拷贝到本地系统磁盘的文件,以及将他们从发布介质上拷贝到哪个目录中。


    可伸缩性

    多处理器的一个关键问题是可伸缩性。多处理器系统中,竞争资源和其他性能问题比在单处理器系统中复杂得多,必须在系统设计的时候考虑清楚。windows集以下几个特性于一身,对其成功起到至关重要作用。

    ● 能在任一个可用的处理器上运行操作系统代码,也可以同时在多个处理器上运行系统代码;

    ● 在单个进程内执行多个线程,这些线程可以在不同处理器上并行执行;

    ● 内核内部以及设备驱动程序和服务器进程内部的细粒度同步,使得多个组件可以在多个处理器上并行执行;

    ● 诸如I/O完成端口之类的编程机制,使得可以实现高效的多线程服务器进程,并且这样的程序在多处理器系统上有很好的伸缩性。

    并且,windows的可伸缩性在不断进步,以适应更多变化。


    疑问,系统编码用C/C++/汇编,那么在被引导入内存之前通过什么手段将系统代码编译为二进制机器码?


    展开全文
  • 矿井瓦斯实时智能监控系统总体结构设计.pdf
  • 电子商务系统总体结构与设计.pptx
  • 系统架构图 总体架构图 系统架构图 功能架构图 技术架构图 各种架构图的说明介绍 各种架构图的说明介绍
  • 采煤机智能控制系统总体结构设计.pdf
  • 系统架构图

    万次阅读 2018-08-03 11:48:57
    该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。  简单说明: 1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境 ...

    转载自:https://www.cnblogs.com/firstdream/p/7145481.html    作者:有梦就能实现

    发布一企业技术架构图,供大家参考。

     

    该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。

     简单说明:

    1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境                            

    2.企业集成平台是以基础业务应用为基础服务于上层平台和基础业务应用的高度集成平台         

    3.数据中心是企业公共数据的集中管理比如用户数据、企业编码,可以通过数据集成平台或服务集成平台分发给其他应用     

     

    项目做了不少,都没画过架构图,这次被要求画图,画的很丑,请大家看图本身包含的系统架构信息

    一、架构整体图

      

       1、核心是两库一线

      1.1 接口总线

        所有算法功能抽象成接口,其中大部分接口的方法都是泛型方法,是为了解决某一大类问题的

      1.2 代码库

        代码库包含现接口总线中接口的各种实现

      1.3 应用库

        提供用户的界面或者提供给外部的服务

        是通过容器配置调用算法库中的代码来实现的各种应用          

     

    二、应用关系图

           1、应用通过配置从应用库中组装出自己的应用系统

           2、应用本身之外的东西尽量使用拦截器处理(授权访问、权限数据推送、异常处理、缓存、日志等)

           3、使用消息队列做高并发应用支撑(秒杀类似应用)

           4、使用分布式任务系统做周期作业、数据维护、数据计算等

     

     

    ENode架构图

     

    什么是ENode

    ENode是一个.NET平台下,纯C#开发的,基于DDD,CQRS,ES,EDA,In-Memory架构风格的,可以帮助开发者开发高并发、高吞吐、可伸缩、可扩展的应用程序的一个应用开发框架。

    • 开源项目地址:https://github.com/tangxuehua/enode
    • 作者博客地址:http://www.cnblogs.com/netfocus/category/496012.html
    • QQ交流群号:185916873
    • 微信公众号:ENode

    ENode框架特色

    1. 一个DDD开发框架,完美支持基于六边形架构思想的开发
    2. 实现CQRS架构思想,并且框架提供C端命令的处理结果的返回,支持同步返回和异步返回
    3. 内置Event Sourcing(ES)架构模式,让C端的数据持久化变得通用化
    4. 聚合根常驻内存,in-memory domain model
    5. 聚合根的处理基于Command Mailbox, Event Mailbox的思想,类似Actor Model, Actor Mailbox
    6. 严格遵守聚合内强一致性、聚合之间最终一致性的原则
    7. Group Commit Domain event
    8. 基于聚合根ID+事件版本号的唯一索引,实现聚合根的乐观并发控制
    9. 框架保证Command的幂等处理
    10. 通过聚合根ID对命令或事件进行路由,做到最小的并发冲突、最大的并行处理
    11. 消息发送和接收基于分布式消息队列EQueue,支持分布式部署
    12. 基于事件驱动架构范式(EDA,Event-Driven Architecture)
    13. 基于队列的动态扩容/缩容
    14. EventDB中因为存放的都是不可变的事件,所以水平扩展非常容易,框架可内置支持
    15. 支持Process Manager(Saga),以支持一个用户操作跨多个聚合根的业务场景,如订单处理,从而避免分布式事务的使用
    16. ENode实现了CQRS架构面临的大部分技术问题,让开发者可以专注于业务逻辑和业务流程的开发,而无需关心纯技术问题

    晚上把公司应用的架构结合之前研究的东西梳理了下,整理了一张架构规划图,贴在这里备份

    下面是个人理解的做架构的几个要点:

    1、系统安全

    这是首要考虑的,以这张图为例,网络划分为3个区:

    a) DMZ区可以直接公网访问,也可以 与App Core区互通,但不能直接与DB Core区互通 (通常这里放置 反向代理Web服务器)

    b) App Core区能与DMZ区、DB Core区互通,但是无法直接从公网访问 (通常这里放置 应用服务器、中间件服务器之类)

    c) DB Core区仅与App Core区互通 (通常这里放置 核心数据库)

    2、尽量消除单点故障

    上图中,除了“硬件负载均衡”节点外,其它节点都可以部署成集群(DB有点特殊,传统RDBMS要实现分布式/集群还是比较困难的,要看具体采用的数据库产品,并非所有数据库都能方便的做Sharding),Jboss本身可以通过Domain模式+mod_cluster实现集群、Redis通过Master/Slave以Sentinel方式可以实现HA、IBM MQ本身就支持集群、FTP Server配合底层储存阵列也可以做到HA、Nginx静态资源服务器自不必说

    3、成本

    尽量采用开源成熟产品,jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的选择。硬件负载均衡通常成本不低,但是效果明显,如果实在没钱,域名解析采用DNS轮询策略,也能达到类似效果,只不过可靠性略差。

    4、Database问题

    常规企业应用中,传统关系型数据仍然是主流,但是no-sql经过这几年发展,技术也日渐成熟了,一些非关键数据可以适当采用no-sql数据库,比如:系统日志、报文历史记录这类相对比较独立,而且增长迅速的数据,可以考虑存储到no-sql db甚至HDFS、TFS等分布式开源文件系统中。

    如果系统数据量级达到单机RDBMS的上限,尽早考虑Sharding方案,目前mysql在这方面比较成熟,其它数据库就不好说了。

    5、性能

    web server、app server这些一般都可以通过集群实现横向扩张,满足性能日常增长的需求。最大的障碍还是DB,如果规模真达到了DB的上限,还是考虑换分布式DB或者迁移到“云”上吧。

     

    HBase 系统架构图

      

      组成部件说明   Client:      使用HBase RPC机制与HMaster和HRegionServer进行通信      Client与HMaster进行通信进行管理类操作      Client与HRegionServer进行数据读写类操作      Zookeeper:      Zookeeper Quorum存储-ROOT-表地址、HMaster地址      HRegionServer把自己以Ephedral方式注册到Zookeeper中,HMaster随时感知各个HRegionServer的健康状况      Zookeeper避免HMaster单点问题      HMaster:      HMaster没有单点问题,HBase中可以启动多个HMaster,通过Zookeeper的Master Election机制保证总有一个Master在运行      主要负责Table和Region的管理工作:      1 管理用户对表的增删改查操作      2 管理HRegionServer的负载均衡,调整Region分布      3 Region Split后,负责新Region的分布      4 在HRegionServer停机后,负责失效HRegionServer上Region迁移      HRegionServer:      HBase中最核心的模块,主要负责响应用户I/O请求,向HDFS文件系统中读写数据

      

      HRegionServer管理一些列HRegion对象;     每个HRegion对应Table中一个Region,HRegion由多个HStore组成;    每个HStore对应Table中一个Column Family的存储;      Column Family就是一个集中的存储单元,故将具有相同IO特性的Column放在一个Column Family会更高效

      HStore:      HBase存储的核心。由MemStore和StoreFile组成。      MemStore是Sorted Memory Buffer。用户写入数据的流程:

      

      Client写入 -> 存入MemStore,一直到MemStore满 -> Flush成一个StoreFile,直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除 -> 当StoreFiles Compact后,逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个Region,Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上,使得原先1个Region的压力得以分流到2个Region上。 由此过程可知,HBase只是增加数据,有所得更新和删除操作,都是在Compact阶段做的,所以,用户写操作只需要进入到内存即可立即返回,从而保证I/O高性能。

      HLog      引入HLog原因:      在分布式系统环境中,无法避免系统出错或者宕机,一旦HRegionServer意外退出,MemStore中的内存数据就会丢失,引入HLog就是防止这种情况      工作机制:      每个HRegionServer中都会有一个HLog对象,HLog是一个实现Write Ahead Log的类,每次用户操作写入Memstore的同时,也会写一份数据到HLog文件,HLog文件定期会滚动出新,并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后,HMaster会通过Zookeeper感知,HMaster首先处理遗留的HLog文件,将不同region的log数据拆分,分别放到相应region目录下,然后再将失效的region重新分配,领取到这些region的HRegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。

      HBase存储格式      HBase中的所有数据文件都存储在Hadoop HDFS文件系统上,格式主要有两种:      1 HFile HBase中KeyValue数据的存储格式,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile      2 HLog File,HBase中WAL(Write Ahead Log) 的存储格式,物理上是Hadoop的Sequence File

      HFile

      

      图片解释:     HFile文件不定长,长度固定的块只有两个:Trailer和FileInfo      Trailer中指针指向其他数据块的起始点      File Info中记录了文件的一些Meta信息,例如:AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等      Data Index和Meta Index块记录了每个Data块和Meta块的起始点      Data Block是HBase I/O的基本单元,为了提高效率,HRegionServer中有基于LRU的Block Cache机制      每个Data块的大小可以在创建一个Table的时候通过参数指定,大号的Block有利于顺序Scan,小号Block利于随机查询      每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字,目的是防止数据损坏

      HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项,并且有固定的结构。

      

      KeyLength和ValueLength:两个固定的长度,分别代表Key和Value的长度     Key部分:Row Length是固定长度的数值,表示RowKey的长度,Row 就是RowKey      Column Family Length是固定长度的数值,表示Family的长度      接着就是Column Family,再接着是Qualifier,然后是两个固定长度的数值,表示Time Stamp和Key Type(Put/Delete)      Value部分没有这么复杂的结构,就是纯粹的二进制数据

      HLog File

      

      HLog文件就是一个普通的Hadoop Sequence File,Sequence File 的Key是HLogKey对象,HLogKey中记录了写入数据的归属信息,除了table和region名字外,同时还包括 sequence number和timestamp,timestamp是“写入时间”,sequence number的起始值为0,或者是最近一次存入文件系统中sequence number。     HLog Sequece File的Value是HBase的KeyValue对象,即对应HFile中的KeyValue

      

      结束语:这篇文章是我专门在网上弄下来的,算是hbase部分的终极篇吧,我的服务端的源码系列也要基于这个顺序来开展。

     

     

    一.三层架构图

     

    二.系统各层次职责
    1.UI(User Interface)层的职责是数据的展现和采集,数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为服务(如WebServices)。
    2.BL(Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。
    (1)Business Function 子层负责基本业务功能的实现。
    (2)Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。(Transaction只能在Business Flow 子层开启。)
    3.ResourceAccess层的职责是提供全面的资源访问功能支持,并向上层屏蔽资源的来源。
    (1)BEM(Business Entity Manager)子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。
    (2)DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。
    DB Adapter子层负责屏蔽数据库类型的差异。
    ORM子层负责提供对象-关系映射的功能。
    Relation子层提供ORM无法完成的基于关系(Relation)的数据访问功能。
    (3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。
    注: Service Entrance用于简化对Service的访问,它相当于Service的代理,客户直接使用Service Entrance就可以访问系统发布的服务。Service     Entrance为特定的平台(如Java、.Net)提供强类型的接口,内部可能隐藏了复杂的参数类型转换。
    (4)ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。
    4.Entity侧层跨越UI/BEM/ResourceManager层,在这些层之间传递数据。Entity侧层中包含三类Entity,如下图所示:

     
    三.Aspect
     Aspect贯穿于系统各层,是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。
    1.Securtiy Aspect:用于对整个系统的Security提供支持。
    2.ErrorHandling Aspect:整个系统采用一致的错误/异常处理方式。
    3.Log Aspect:用于系统异常、日志记录、业务操作记录等。

    四.规则
    1.系统各层次及层内部子层次之间都不得跨层调用。
    2.Entity object 在各个层之间传递数据。
    3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。
    4.对于每一个数据库表(Table)都有一个DB Entity class与之对应,针对每一个Entity class都会有一个BEM Class与之对应。
    5.有些跨数据库或跨表的操作(如复杂的联合查询)也需要由相应的BEM Class来提供支持。
    6.对于相对简单的系统,可以考虑将Business Function子层和Business Flow 子层合并为一个。
    7.UI层和BL层禁止出现任何SQL语句。

    五.错误与异常
            异常可以分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被转化为业务执行的结果。
    1.DataAccess层不得向上层隐藏任何异常(该层抛出的异常几乎都是系统异常)。
    2.要明确区分业务执行的结果和系统异常。比如验证用户的合法性,如果对应的用户ID不存在,不应该抛出异常,而是返回(或通过out参数)一个表示验证结果的枚举值,这属于业务执行的结果。但是,如果在从数据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。
    3.在有些情况下,BL层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。
    4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系统异常,并将其解释为友好的错误信息呈现给用户。

    六.项目组织目结构
     以BAS系统为例。
    1.主目录结构:
     
    2.命名空间命名:每个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间,比如,EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。
    3.包含众多子项目的庞大项目的物理组织:
     
    核心子项目Core的位置:

     
    Core子项目中包含一些公共的基础设施,如错误处理、权限控制方面等。

    七.发布服务与服务回调
    以EAS系统为例。
     
    1.同UI层的Page一样,服务也不允许抛出任何异常,而是应该以返回错误码(int型,1表示成功,其它值表示失败)的形式来表明服务调用出现了错误,如果方法有返回值,则返回值以out参数提供。
    2. 如果BAS系统提供了WebService(Remoting)服务,则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供的服务。
    3.如果BAS需要通过WebService(Remoting)回调客户系统,则必须提供仅仅定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现其中的接口,并将其发布为服务,供BAS回调。
    4.当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity,则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意,Entrance和CallBack接口对应服务的方法的参数是强类型的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

     

     

        从上图中可以看出,Android系统架构为四层结构,从上层到下层分别是应用程序层、应用程序框架层、系统运行库层以及Linux内核层,分别介绍如下:

        1)应用程序层

             Android平台不仅仅是操作系统,也包含了许多应用程序,诸如SMS短信客户端程序、电话拨号程序、图片浏览器、Web浏览器等应用程序。这些应用程序都是       用Java语言编写的,并且这些应用程序都是可以被开发人员开发的其他应用程序所替换,这点不同于其他手机操作系统固化在系统内部的系统软件,更加灵活和个    性化。

        2)应用程序框架层

             应用程序框架层是我们从事Android开发的基础,很多核心应用程序也是通过这一层来实现其核心功能的,该层简化了组件的重用,开发人员可以直接使用其提    供的组件来进行快速的应用程序开发,也可以通过继承而实现个性化的拓展。

             a) Activity Manager(活动管理器)

                  管理各个应用程序生命周期以及通常的导航回退功能

             b) Window Manager(窗口管理器)

                  管理所有的窗口程序

             c)  Content Provider(内容提供器)

                  使得不同应用程序之间存取或者分享数据

            d) View System(视图系统)

                  构建应用程序的基本组件

             e) Notification Manager(通告管理器)

                  使得应用程序可以在状态栏中显示自定义的提示信息

             f) Package Manager(包管理器) 

                  Android系统内的程序管理

             g)Telephony Manager(电话管理器)

                  管理所有的移动设备功能

             h)Resource Manager(资源管理器)

                  提供应用程序使用的各种非代码资源,如本地化字符串、图片、布局文件、颜色文件等

             i)Location Manager(位置管理器)

                 提供位置服务

             j)XMPP Service(XMPP服务)

                 提供Google Talk服务 

        3)系统运行库层

             从图中可以看出,系统运行库层可以分成两部分,分别是系统库和Android运行时,分别介绍如下:

             a)系统库

                  系统库是应用程序框架的支撑,是连接应用程序框架层与Linux内核层的重要纽带。其主要分为如下几个:

                  Ø  Surface Manager:

                      执行多个应用程序时候,负责管理显示与存取操作间的互动,另外也负责2D绘图与3D绘图进行显示合成。 

         Ø  Media Framework: 

                      多媒体库,基于PacketVideo OpenCore;支持多种常用的音频、视频格式录制和回放,编码格式包括MPEG4、MP3、H.264、AAC、ARM。

                  Ø  SQLite:

                      小型的关系型数据库引擎 

                  Ø  OpenGL|ES:

                     根据OpenGL ES 1.0API标准实现的3D绘图函数库 

                  Ø  FreeType:

                      提供点阵字与向量字的描绘与显示 

                  Ø  WebKit:

                      一套网页浏览器的软件引擎

                  Ø  SGL:

                      底层的2D图形渲染引擎 

                  Ø  SSL:

                      在Andorid上通信过程中实现握手 

                  Ø  Libc:

                 从BSD继承来的标准C系统函数库,专门为基于embedded linux的设备定制

             b)Android运行时

                 Android应用程序时采用Java语言编写,程序在Android运行时中执行,其运行时分为核心库和Dalvik虚拟机两部分。

                 Ø  核心库

                     核心库提供了Java语言API中的大多数功能,同时也包含了Android的一些核心API,如android.os、android.net、android.media等等。

                 Ø  Dalvik虚拟机

                     Android程序不同于J2me程序,每个Android应用程序都有一个专有的进程,并且不是多个程序运行在一个虚拟机中,而是每个Android程序都有一                个Dalivik虚拟机的实例,并在该实例中执行。Dalvik虚拟机是一种基于寄存器的Java虚拟机,而不是传统的基于栈的虚拟机,并进行了内存资源使用的优化          以及支持多个虚拟机的特点。需要注意的是,不同于J2me,Android程序在虚拟机中执行的并非编译后的字节码,而是通过转换工具dx将Java字节码转成dex格          式的中间码。

        4)Linux内核层 

            Android是基于Linux2.6内核,其核心系统服务如安全性、内存管理、进程管理、网路协议以及驱动模型都依赖于Linux内核。

     

     

    Entity Framework的全称是ADO.NET Entity Framework,是微软开发的基于ADO.NET的ORM(Object/Relational Mapping)框架。

    Entity Framework的主要特点:

    1. 支持多种数据库(Microsoft SQL Server, Oracle, and DB2);

    2. 强劲的映射引擎,能很好地支持存储过程;

    3. 提供Visual Studio集成工具,进行可视化操作;

    4. 能够与ASP.NET, WPF, WCF, WCF Data Services进行很好的集成。

    架构图一

    架构图2

     

     

     

      刚刚来到一家新公司,首先会对项目进行一个大致了解,研究了两天了,有了个总体的把握了,下面就是我这个小菜鸟画的简单系统架构图!  

      有的时候架构庞大的吓人,有的时候架构一眼看穿,但里面却暗藏杀机,真的需要我们去认真学习,揣摩!

      不久前在园子里面看过一篇文章其中说道,设计架构无非就是一个字 → “”,当时看到这个字,想起来还真的是这么一回事,不过这里面去包含了很多的东西,我们现在就是不知道怎么拆,这个也不是一时半会能够了解的,需要我们认认真真的做,慢慢的积累,到时候就知道怎么拆了,而且还拆的很到位,所以加油!

      对于这个拆字园友们也给出了很多的理解,这是只是个人看法!

     

     

     

    Struts2 架构图

    Struts2架构图 


            请求首先通过Filter chain,Filter主要包括ActionContextCleanUp,它主要清理当前线程的ActionContext和Dispatcher;FilterDispatcher主要通过AcionMapper来决定需要调用哪个Action。 
            ActionMapper取得了ActionMapping后,在Dispatcher的serviceAction方法里创建ActionProxy,ActionProxy创建ActionInvocation,然后ActionInvocation调用Interceptors,执行Action本身,创建Result并返回,当然,如果要在返回之前做些什么,可以实现PreResultListener。 


    Struts2部分类介绍 
    这部分从Struts2参考文档中翻译就可以了。 
    ActionMapper 
            ActionMapper其实是HttpServletRequest和Action调用请求的一个映射,它屏蔽了Action对于Request等java Servlet类的依赖。Struts2中它的默认实现类是DefaultActionMapper,ActionMapper很大的用处可以根据自己的需要来设计url格式,它自己也有Restful的实现,具体可以参考文档的docs\actionmapper.html。 
    ActionProxy&amp;ActionInvocation 
            Action的一个代理,由ActionProxyFactory创建,它本身不包括Action实例,默认实现DefaultActionProxy是由ActionInvocation持有Action实例。ActionProxy作用是如何取得Action,无论是本地还是远程。而ActionInvocation的作用是如何执行Action,拦截器的功能就是在ActionInvocation中实现的。 
    ConfigurationProvider&amp;Configuration 
            ConfigurationProvider就是Struts2中配置文件的解析器,Struts2中的配置文件主要是尤其实现类XmlConfigurationProvider及其子类StrutsXmlConfigurationProvider来解析, 


    Struts2请求流程 
    1、客户端发送请求 
    2、请求先通过ActionContextCleanUp--&gt;FilterDispatcher 
    3、FilterDispatcher通过ActionMapper来决定这个Request需要调用哪个Action 
    4、如果ActionMapper决定调用某个Action,FilterDispatcher把请求的处理交给ActionProxy,这儿已经转到它的Delegate--Dispatcher来执行 
    5、ActionProxy根据ActionMapping和ConfigurationManager找到需要调用的Action类 
    6、ActionProxy创建一个ActionInvocation的实例 
    7、ActionInvocation调用真正的Action,当然这涉及到相关拦截器的调用 
    8、Action执行完毕,ActionInvocation创建Result并返回,当然,如果要在返回之前做些什么,可以实现PreResultListener。添加PreResultListener可以在Interceptor中实现,不知道其它还有什么方式? 

     

    短连接聊天服务 ,每半分钟刷新一次..

    客户端可切换3种渲染模式,全位图blit传输:sprite区块和MC

     

     

    架构图:

    模块与模块之间的通信也通过sendNotifcation发送消息。

     

    神仙道寻路方法:

    1. 2点是否可以直接到达,可以,则不走寻路,直接行进 2. 2点不能直接到达,进行寻路,找不到结果,寻找替代点 3. 正常寻路

    关于flash共享库:

    如果a的库里的资源设置了共享资源并设置了一个url 把a发布的swf放到设置的url的位置 b引入a的库里共享的资源..再发布b..这时b会自动从那个设置的url加载a

    浏览器缓存地址:C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files

    网页游戏的swf都加载到这里了。

    <深度排序>

    那就不停的 遍历 更具显示对象的Y 设置它们再容器里面的深度  不知道把同屏显示对象的Y再数组里面排序好 再设置深度 速度快  还是变排序边设置深度快 并且在数组里面排序好 这种方法要速度很好

    把图层封装成一个类。 和NPC和玩家都共同继承一个接口 iworldObject 加一个属性 depth. 创建的时候设置 这个属性。然后sortOn("depth");

    Array.Numberic 啊 默认都是 从小到大排序的 depth 是他的一个属性 npc 也统一有这个属性 然后就不用y轴排序了,看你的 y+height 挺纠结的 统一用 depth 这个属性排序

    这里判断这个 玩家的深度如果已经符合,就不要排序。 setChildIndex 消耗挺大的

     

     

    详解三层架构图

     PS: 在看三层架构的时候,找的了一个我感觉不错的材料,里面有如下一张图,打算详细的解释一下这张图,也总结一下三层的知识

      

    一、系统各层次职责

         1.UI(User Interface)层的职责是数据的展现和采集,数据采集的结果通常以Entity object提交给BL层处理Service Interface侧层用于将业务或数据资源发布为服务(如WebServices)。

        2.BL(Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。

        (1)Business Function 子层负责基本业务功能的实现。

        (2)Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流(Transaction只能在Business Flow 子层开启。)

        3.ResourceAccess层的职责是提供全面的资源访问功能支持,并向上层屏蔽资源的来源。

      (1)BEM(Business Entity Manager)子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。

      (2)DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。

        DB Adapter子层负责屏蔽数据库类型的差异。

        ORM子层负责提供对象-关系映射的功能。

        Relation子层提供ORM无法完成的基于关系(Relation)的数据访问功能。

      (3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。

             注:Service Entrance用于简化对Service的访问,它相当于Service的代理,客户直接使用Service Entrance就可以访问系统发布的服务。Service      Entrance为特定的平台(如Java、.Net)提供强类型的接口,内部可能隐藏了复杂的参数类型转换。

      (4)ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。

        4.Entity侧层跨越UI/BEM/ResourceManager层,在这些层之间传递数据。Entity侧层中包含三类Entity,如下图所示:

      

    二、Aspect

        Aspect贯穿于系统各层,是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。

        1.Securtiy Aspect:用于对整个系统的Security提供支持。

        2.ErrorHandling Aspect:整个系统采用一致的错误/异常处理方式。

        3.Log Aspect:用于系统异常、日志记录、业务操作记录等。

     

    三、规则

        1.系统各层次及层内部子层次之间都不得跨层调用。

        2.Entity object 在各个层之间传递数据。

        3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。

        4.对于每一个数据库表(Table)都有一个DB Entity class与之对应,针对每一个Entity class都会有一个BEM Class与之对应。

        5.有些跨数据库或跨表的操作(如复杂的联合查询)也需要由相应的BEM Class来提供支持。

        6.对于相对简单的系统,可以考虑将Business Function子层和Business Flow 子层合并为一个。

        7.UI层和BL层禁止出现任何SQL语句。

     

    四、错误与异常

             异常可以分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被转化为业务执行的结果。

        1.DataAccess层不得向上层隐藏任何异常(该层抛出的异常几乎都是系统异常)。

        2.要明确区分业务执行的结果和系统异常。比如验证用户的合法性,如果对应的用户ID不存在,不应该抛出异常,而是返回(或通过out参数)一个表示验证 结果的枚举值,这属于业务执行的结果。但是,如果在从数据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。

        3.在有些情况下,BL层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。

        4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系统异常,并将其解释为友好的错误信息呈现给用户。

     

    五、项目组织目结构

        以BAS系统为例。

         1.主目录结构:

     

         2.命名空间命名:每个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的 分类而增加子命名空间,比如,EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。

        3.包含众多子项目的庞大项目的物理组织:

     

    核心子项目Core的位置:

     

     

    Core子项目中包含一些公共的基础设施,如错误处理、权限控制方面等。

    六、发布服务与服务回调

    以EAS系统为例。

     

         1.同UI层的Page一样,服务也不允许抛出任何异常,而是应该以返回错误码(int型,1表示成功,其它值表示失败)的形式来表明服务调用出现了错误,如果方法有返回值,则返回值以out参数提供。

         2.如果BAS系统提供了WebService(Remoting)服务,则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供的服务。

         3.如果BAS需要通过WebService(Remoting)回调客户系统,则必须提供仅仅定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现其中的接口,并将其发布为服务,供BAS回调。

         4.当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity,则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意,Entrance和CallBack接口对应服务的方法的参数是强类型 的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

     

     

     

      之前用一张图分析了Google给出的MVP架构,但是在Google给出的所有案例里面除了基本的MVP架构还有其它几种架构,今天就来分析其中的Clean架构。同样的,网上介绍Clean架构的文章很多,我也就不用文字过多叙述了,还是用一张类图来分析一下Clean架构的这个案例吧。好了,先直接上图!

     

      

     

      上完图,再说一说我对Clean架构的一个理解吧。对比前一篇文章的MVP架构图可以看出,clean在一定程度上继承了mvp的设计思想,但是其抽象程度比mvp更高。初次看这个demo的时候,确实被震撼了一下——原来用Java可以这样写代码!!!跟之前用的一些项目框架和我自己平时写的一些代码对比一下,只能感叹clean的这种设计思想真不是一般的程序员可以想出来的。它对接口、抽象类和实现类之间的实现、继承、调用关系发挥到了一个比较高的层次,它并不是像我们平时写代码那样很直白地写下来,而是充分利用了面向对象的封装性、继承性和多态性,是对面向对象思想的一个高度理解。其实,要说clean复杂,它确实有些难理解,可是如果你真的理解了面向对象思想,那么又会觉得这样的设计完全在情理之中。

     

     

          最近几个月都没有整理Blog,都忙着整理总结之前一段时间做的项目和学习的内容,然后想到把这些东西融合在一起,设计一个开发框架。

    这个框架用到了一些.NET社区比较前沿的技术,比如ORM, IOC容器, AOP拦截等,在.NET 2.0的基础上构建了一个.NET Remoting的分布式开发框架。

    项目开发最关注的就是开发效率,其次是项目的可管理可控性,最后是架构的可扩展性。我希望在我的框架设计中能够将这三者很好的整合在一起。

    大致的思路是:

    1、可扩展性:通过IOC容器的使用降低项目中各个模块之间的依赖性;用领域模式来设计业务核心层,降低业务层对数据层和界面层的耦合度;分布式选择Remoting为主,可以再包装为WebService或者直接发布为WebService。

    2、将敏捷的项目管理思路引入到框架中,框架充分支持TDD测试驱动和运行日志驱动,为敏捷管理提供技术支持。

    3、初步通过AOP技术减少和核心业务无关的系统级代码:如事务处理、异常处理、日志记录等;并在将来为架构提供可视化的代码配置生成工具,以最快的速度构建项目的主体结构,并尽可能大的增大灵活性。

          目前框架的主体已经完成,也重新整理VSS上的项目结构,并重新命名为LightningFramework。正在做细节调整,接下来的时间会逐步完成相关文档和演示程序。下面是主架构图:

    Framework整体架构设计图.jpg

     

    展开全文
  • Windows系统总体架构

    千次阅读 2019-02-22 22:26:33
    作为最流行的的桌面操作系统,Windows系统的发展在经历数次硬件革命之后,其系统架构也基本稳定,微软号称Windows 10是最后一代操作系统,并统一了Windows各版本的底层架构。 Windows系统是分层的架构,主要分为...
  • IT行业软件总体架构图

    热门讨论 2011-03-02 22:03:13
    某软件的总体架构图,文档中有详细的设计分析,图文结合。
  • 系统架构图ppt.pptx

    2020-02-18 14:21:04
    软件架构图文档模板,包含整体架构图系统功能架构,业务架构图系统功能架构,系统总体架构。以ppt形式展现,可以直接编辑。
  • 本文简单介绍了有关智能车的系统总体结构和软件算法。
  • 监管系统架构图

    2018-07-23 21:17:35
    无人机监管系统架构图,描述了基于大数据平台的实时性处理
  • fabric总体架构图

    千次阅读 2018-09-06 19:02:53
    fabric总体架构图 fabric的总体架构分为网络层、核心层、服务层以及接口层。 网络层由多个分布式节点组成。这些节点构成了一个p2p的网络,采用Gossip协议进行节点间互相发现和数据传输,并采用gRPC的框架互相调用...
  • 总体技术架构设计 版本号: V0.9 修订表 版本编号 *变化 状态 简要说明变更内容和变更范围 日期 变更人 批准日期 批准人 *...总体技术架构设计 6 2.1 技术架构 6 2.1.1 架构图 6 2.1.2 架构说明 6 2.2 SFCService Flow
  • 4.1 电子商务系统总体结构;4.1.1 电子商务系统的基本概念;4.1.2 电子商务系统的运行环境;4.1.3 电子商务系统的体系结构;4.1.4 电子商务应用系统;4.2 电子商务系统技术架构;4.2.1 电子商务网络平台;4.2.2 电子商务...
  • 智慧税务总体架构设计及系统平台综合解决方案
  • 总体技术架构设计 版本号: V0.9 修订表 版本编号 *变化 状态 简要说明变更容和变更围 日期 变更人 批准日期 批准人 *变化状态建立修改...6 2.1 技术架构 6 2.1.1 架构图 6 2.1.2 架构说明 6 2.2 SFCService Flow Con
  • java后台系统架构图

    2018-08-19 19:59:06
    java后台系统架构图,有需要的朋友可以下载看看,比较基本。
  • PAGE PAGE # 尝试对一个BC电子商务系统总 ...根据系统分析可画出总体结构功能描述系统总体结构所示 系统的便捷确定要从系统的功能结构图中易于划分系统边界向用户和管理员 两方提供的功能不同所以也会有不同的
  • B2C 电子商务系统总体结构的设计 总体结构设计主要描述系统总体上包括那些商业应用功能以及各个功能模块 和其他子系统之间的关系 一总体逻辑结构 根据系统分析可画出总体结构功能描述系统总体结构所示 ...
  • 总 体 技 术 架 构 设 计 版本号: V0.9 修订表 版本编 * 变化 简要说明变更内容和变更范 日期 变更人 批准日期 批准人...总体技术架构设计 5 2.1 技术架构 5 2.1.1 架构图 5 2.1.2 架构说明 5 2.2 SFC Service Flow Con
  • 系统逻辑架构图

    热门讨论 2012-03-27 21:21:18
    系统逻辑架构图 描述系统的信息管理系统的逻辑架构。
  • 汽车发动机电子节气门总体结构及其智能控制系统设计.pdf
  • LTE系统总体架构

    千次阅读 2017-09-14 16:53:42
    核心网 LTE(4G)网络中的分组域核心网元是MME,S-GW,P-GW。MME、S-GW、P-GW一起被称作4G的核心网:EPC(Evolved Packet Core),其中MME用作移动管理, P-GW链接Internet, S-GW作为用户接入网络做一些路由选择,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 236,402
精华内容 94,560
关键字:

总体系统架构图