当前位置:首页 > 商业/管理/HR > 管理学资料 > 02-企业-EA--应用软件架构设计规范
1企业EA应用软件架构设计规范******20**年01月2企业EA应用软件架构设计规范1范围本规范定义了某企业应用软件应用架构、数据架构、技术架构设计的原则、方法及工具。本规范是某企业应用软件概要设计阶段的指导性文件。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。——TOGAFVersion9;——FEA;——企业信息化或ERP总体架构设计。3架构设计原则3.1总体设计原则3.1.1总体架构指引原则某企业应用软件架构设计以企业信息化或ERP总体架构设计为指引,在概念、术语、架构模型方面与企业信息化或ERP总体架构保持一致,应用架构、数据架构、技术架构设计应与企业信息化或ERP总体架构的应用架构、数据架构、技术架构设计保持良好的衔接。3.1.2敏捷柔性原则某企业应用软件架构设计应以某企业业务战略发展为导向,能够敏捷适应业务发展要求,避免因业务流程改变而导致系统发生大规模调整和改造。3.1.3集成与重用性原则某企业应用软件架构设计应充分考虑与某企业各项信息化基础设施的集成,充分发挥某企业各项信息化基础设施的功能,避免重复设计开发。3.1.4迭代更新原则数据架构和应用架构决定技术架构,三者之间必须能够互相印证、协调一致、迭代更新。应及时建立架构基线,为后续设计、开发建立架构基准。3.2技术选型原则技术选型包括总体技术路线选型、开发平台选型、中间件选型、数据库选型、操作系统选型、开源软件选型。技术选型应从技术可行性、运行维护可行性、进度可行性、经济可行性方面做出综合考虑,应符合某企业总体架构技术要求。各类技术选型详见“附录A:技术选型列表”。33.3偏差处理原则对技术选型的任何偏差,应启动偏差流程。相关技术方案上报信息化工作部。得到批准后,方可执行偏差方案。4数据架构.4.1设计目标定义系统数据主题及主要数据实体,定义数据流向和数据分布策略。4.2设计规范4.2.1定义主题域对业务过程模型、业务能力模型、系统用例等作出分析,参照全局数据模型,定义数据主题域及概念数据实体,主题域的数据实体应高度相关,每项业务能力至少包含一个数据主题域。4.2.2定义逻辑模型结合业务需求,对概念模型数据进一步分解和细化,完成数据概念模型中未涉及的实体属性、主键及约束的定义,进行数据概念模型中的多对多关系的转化,生成关系实体,手工转换数据概念模型中的继承实体,并定义其关联关系。建议采用UML2.0“类图”定义数据逻辑模型。4.2.3定义主数据在本系统及多个系统间共享的基础数据属于主数据,应参照主数据管理平台(SG-MDM)的主数据定义,决定主数据的参照引用关系。4.2.4定义数据流向基于业务流程(通常是1级或2级业务流程模型)、业务能力,定义数据从一个数据主题流向另一个数据主题,包括外部与本系统的数据流向。确保每个外部数据实体至少包含在一个数据流定义。应说明期间数据是如何创建和变化,建议采用如下方式:表1业务流程—数据实体操作矩阵分析示例业务能力/流程活动1业务能力/流程活动2数据实体1CU数据实体2RU数据实体3RD注1:数据操作:C=Create;R=Read;U=Update;D=Delete注2:每个业务活动均应对应一项数据操作注3:业务能力或1级业务流程活动均应做出上述分析。注4:数据实体应只是被创建一次,以保持数据入口的唯一性。基于“业务过程—数据实体操作分析矩阵”,绘制数据流向图。建议采用数据流图表示法(DFD,DataFlowDiagram)或UML2.0“活动图”绘制数据流向图。4.2.5定义数据分布4数据分布确定各业务层级需要何种数据以及数据访问权限,建议采用如下方式:表2数据-地点分析矩阵总部网省地市数据实体1ALL/RSS/CRUDINDV/CRUD数据实体2ALL/RSS/CRUDNA注5:ALL=访问所有数据集合;SS=仅访问子集;INDV=仅访问单个数据实体;NA=不访问注6:数据操作:C=Create;R=Read;U=Update;D=Delete需要注意的是,仅需对业务能力、业务活动涉及的主要数据实体进行数据分布定义。5应用架构5.1设计目标定义应用功能、应用划分和应用边界,根据应用特点,定义应用风格和应用分布。5.2设计规范5.2.1定义应用功能抽取关键用例或关键特性(Feature),通过系统分析,定义交互功能、业务逻辑控制功能、数据维护功能。建议采用“鲁棒图”分析方法识别应用组件。应注意分析识别公共应用功能,如用户认证、用户授权、安全审计等。将分析识别的应用功能,按应用特性进行分组。建议采用如下分类:联机处理类应用、批处理类应用、交互类应用、数据聚集和转换类应用、数据分析类应用。应用分类定义详见“附录B:应用分类定义”。5.2.2定义应用划分将应用功能进行逻辑分组,划分应用,应用划分一般但不限于考虑如下方面:——应用覆盖的业务领域;——功能上的亲和性和数据处理的亲和性;——可靠性方面的要求,将关键功能和非关键功能划分为不同应用,并考虑部署为不同物理节点;——可伸缩性方面的要求,将应用按资源消耗特性分类,并考虑部署为不同的物理节点。应综合考虑各类因素,定义应用功能划分。5典型应用框架Application高级应用Application空间信息服务Application平台支撑应用Application图1应用划分示例5.2.3定义应用边界定义系统间的功能服务交互,应明确交互的信息和交互方式,如批处理文件、异步/同步消息、EDI/XML等。应注意定义系统与呼叫中心、通用企业门户、客户门户、合作伙伴门户、移动终端等的接入渠道。5.2.4定义应用风格基于应用功能划分、应用组件定义和系统边界定义,识别技术特性要求,确定应用风格。建议采用如下方式:表3应用风格决策示例应用/应用模块关键技术需求性能要求数据实时性要求可用性要求数据源可用性应用风格空间信息服务支持多类型客户端无特别要求实时高联机SOA典型应用风格参照详见“附录C:典型应用风格分析”。5.2.5定义应用分布从业务层级维度(总部、分子公司/直属单位、地市/县公司)维度,定义应用功能逻辑分布。6技术架构66.1设计目标基于应用架构、数据架构和非功能性需求,定义系统技术解决方案,包括系统逻辑模型、执行模型、开发模型、运行模型。6.2设计规范6.2.1定义关键技术因素关键技术因素一般来源以下方面:——关键功能需求,关键功能一般指在设计实现上具有代表性,能够覆盖系统各逻辑层次协作关系的应用功能或技术实现上有较高风险的功能;——关键数据需求,数据分布、数据实时性等方面的要求;——质量属性方面需求,应重点考虑性能、可用性、可伸缩性方面的要求和相关约束。充分识别上述关键技术因素,采用“技术影响因素分析”表做出全面分析:表4技术影响因素分析示例因素度量指标和场景可变性相关干系人影响项目影响程度困难和风险可靠性从远程地图服务失败中恢复当远程地图服务访问失败时,在生产环境,正常负荷情况下,在1分钟内如果侦测到其恢复,则需重新建立建连接。当前可变通性:业务专家认为在能够重新建立连接前,可以接受无地理图形展现模式。未来演化性:两年之内,将会购买地图服务的本地复制。可能性:高。对系统设计有较大影响。高中注7:项目影响程度:高、中、低;注8:困难和风险:高、中、低。6.2.2概念验证(POC)基于关键技术因素,及早开展技术验证,确定技术解决方案。应开发可执行的应用原型,验证方案在满足功能和质量属性方面要求的技术可行性。6.2.3定义开发模式基于概念验证结果,进一步从技术可行性、运行维护可行性、进度可行性和经济可行性等方面,确定应用开发模式(如完全定制开发、基于套装软件开发、定制+套装开发等),建议采用如下方式辅助进行分析:表5自建购买可行性分析矩阵可行性准则权重方案概要1方案概要2方案概要37技术可行性得分:得分:得分:运行维护可行性得分:得分:得分:进度可行性得分:得分:得分:经济可行性得分:得分:得分:评分100%根据总体评分结果,选定应用实现开发模式。各个备选方案概要应明确说明自建或购买的策略,包括方案实现所基于的软件,应对一个以上的备选方案概要做出分析。6.2.4定义技术标准、规范基于某企业颁布的信息化技术标准体系,结合应用风格特点,定义应用设计、开发所应遵循某企业、行业、国家或国际标准或规范。6.2.5定义逻辑模型6.2.5.1典型逻辑模型逻辑模型是通过设计系统各类逻辑组件定义应用逻辑构成,通常采用逻辑分层模型。应用逻辑分层设计有利于减少耦合和依赖性、提高潜在的复用性,有助于团队协作开发。典型逻辑层次包括:8展现层应用服务层业务逻辑层基础业务服务层技术服务层基础架构服务层图2典型逻辑层次模型系统逻辑模型建议遵循如下步骤:a)步骤1:选择分层策略;b)步骤2:确定层间交互规则;c)步骤3:识别基础业务服务;d)步骤4:识别公共技术服务;e)步骤5:选择层间通信。6.2.5.2选择分层策略一般意义而言,展现、应用服务、业务逻辑、数据访问逻辑组件划分成独立的层。如果业务逻辑功能需要被多类型客户端所使用,则应划分独立的应用服务层。从应用集成角度、系统重用角度考虑,应划分独立的技术服务层,明确所依赖的技术服务功能,提高系统集成能力,避免重复开发。如数据持久化功能应直接利用开发平台提供的功能,用户认证应利用目录服务提供的功能。如果应用功能需要利用基础架构服务功能,应划分独立的基础架构服务层,明确所依赖的服务功能。如应用服务需要注册到企业服务总线,供外部系统消费,或应用需要通过企业服务总线消费外部系统服务。依赖性基础服务到特定应用lGUI窗口;l报表;lHTMLXML、XSLT、JSP…;l…。l处理表示层请求;l工作流;l会话状态;l视图转换;l数据转换;l…。l处理应用服务层请求;l实现业务规则;l实现业务逻辑。l用于多个业务领域公共业务服务,如GIS公共平台服务、套装软件平台服务等。l高层技术服务,如开发平台服务、目录服务、门户服务、安全性服务等。l低层技术服务,如JVM/CLRRuntime服务、数据库、中间件服务、网络IO服务等。水平分区,如日志子系统、安全服务子系统9应明确定义系统逻辑层次划分,并定义各逻辑层职责,给出每个逻辑层内分区定义。6.2.5.3确定层间交互规则层间交互规则包括层间依赖关系规则和接口类型定义。其中,逻辑层间应单向依赖,避免循环依赖,层间交互方式包括:——自上而下依赖。高层可以依赖于低层,但低层不允许依赖与高层。对于高层组件需根据低层组件变化而做出某种响应的场景,应通过观察者模式或事件模式等设计技术实现;——严格依赖。每一层只能依赖于下一层,这有利于关注点严格分离,下层修改仅影响直接上层。有利于提高系统的灵活性和可伸缩性;——松散交互。高层可以跳过下层直接依赖于底层,但这会导致底层修改直接影响其上的多个层,在小规模应用,即修改不会带来太大的工作量场合,可以考虑此种方式。层间接口类型包括:——抽象接口。通过定义抽象基类或接口类来实现。此种方式增加了系统可测试性;——具体类型。定义具体对象类型表示不同层的接口。此种方式上层直接依赖于下层实现,大型系统不建议采用;——基于消息。层间使用公共数据接口封装操作、数据Schema、错误契约、安全信息、上下文信息等,此种方式有利于支持多种类型客户端,支持跨物理和进程边界进行交互,支持无状态调用,符合SOA架构设计要求,推荐首选此方式作为服务层接口。应根据应用特点和逻辑层水平分区功能设计,确定适当的逻辑层间依赖规则和接口类型。6.2.5.4识别基础业务服务应用架构设计中外部接口功能设计和数据架构中数据流向设计,是基础业务服务设计的重要输入,据此识别需要对外提供的服务和需要消费的外部服务。需要作为公共业务服务提供的功能,应设计成服务组件,此类组件分配到基础业务服务层,并在应用服务层定义服务接口和消息组件,外部系统能够通过企业服务总线消费此类服务;需要消费的外
本文标题:02-企业-EA--应用软件架构设计规范
链接地址:https://www.777doc.com/doc-1888252 .html