中国电信业务平台集中监控系统规范_总体规范分册.ppt

上传人:laozhun 文档编号:2235742 上传时间:2023-02-04 格式:PPT 页数:30 大小:1.24MB
返回 下载 相关 举报
中国电信业务平台集中监控系统规范_总体规范分册.ppt_第1页
第1页 / 共30页
中国电信业务平台集中监控系统规范_总体规范分册.ppt_第2页
第2页 / 共30页
中国电信业务平台集中监控系统规范_总体规范分册.ppt_第3页
第3页 / 共30页
中国电信业务平台集中监控系统规范_总体规范分册.ppt_第4页
第4页 / 共30页
中国电信业务平台集中监控系统规范_总体规范分册.ppt_第5页
第5页 / 共30页
点击查看更多>>
资源描述

《中国电信业务平台集中监控系统规范_总体规范分册.ppt》由会员分享,可在线阅读,更多相关《中国电信业务平台集中监控系统规范_总体规范分册.ppt(30页珍藏版)》请在三一办公上搜索。

1、业务平台集中监控系统规范,总体规范分册,中国电信集团公司,业务平台集中监控系统规范 总体规范分册,目,录,1.文档说明.31.1.编制说明.31.2.适用范围.31.3.规范文档.31.4.起草单位.41.5.解释权.41.6.版权.42.综述.42.1.背景.4,2.1.1.2.1.2.,业务平台维护管理现状.4关键问题.5,2.2.目标.6,2.2.1.2.2.2.2.2.3.,总体目标.6业务目标.6IT 目标.6,2.3.系统定位.72.4.范围.82.5.内容说明.83.业务功能框架.94.数据模型.114.1.目标.114.2.概述.114.3.建模原则.12,4.3.1.4.3.

2、2.4.3.3.,抽象平台共性,体现平台差异.12分层网络建模.12提取平台功能差异数据.13,4.4.方法论.14,4.4.1.4.4.2.4.4.3.,自上而下的与自下而上相结合的纵向分析方法.14多业务平台的横向分析方法.14基于 SID 的模型元素的分析方法.14第 1 页 共 30 页,业务平台集中监控系统规范 总体规范分册,4.4.4.,基于设计模式的模型设计方法.15,4.5.核心配置模型.20,4.5.1.4.5.2.4.5.3.,高层模型.21业务平台核心概念模型.22物理资源核心概念模型.23,5.系统集成关系.236.实施原则与演进思路.256.1.实施目标和原则.25,

3、6.1.1.6.1.2.,建设目标.25实施原则.25,6.2.系统演进规划.277.附录.297.1.附录一 规范编写人员.297.2.附录二 术语.29第 2 页 共 30 页,业务平台集中监控系统规范 总体规范分册,第 3 页 共 30 页,1.文档说明,1.1.编制说明,业务平台是电信网提供业务的核心设备,其管理对于保障向客户提供的业务服务质量十分重要,需要规范和指导业务平台集中监控系统的建设,并以此推动业务平台提供标准的北向管理接口,使其符合中国电信的运行维护需求。本规范为中国电信建设业务平台集中监控系统提供依据。本规范的编制是在充分研究中国电信业务平台的基础上,吸收了广东、福建等建

4、设经验成果。本规范是业务平台集中监控系统总体规范,全面、概括地阐述了系统的功能架构、核心数据模型以及实施演进策略等内容。,1.2.适用范围,本规范适用于中国电信集团公司及下属省(市)电信公司进行业务平台集中监控系统的规划和建设,为系统建设、升级改造、系统演进提供指导和依据。,1.3.规范文档,业务平台集中监控系统规范集为中国电信业务平台集中监控系统的建设提供,了统一的规范和标准,包括如下文档:,1)中国电信业务平台集中监控系统规范 总体规范分册,总体描述业务平台集中监控系统的功能架构、数据模型、实施策略等内容。为其他规范分册的指定提供框架和依据,同时也是各个分册内容的总结,便于读者对业务平台集

5、中监控系统有个总体的认识。,2)中国电信业务平台集中监控系统规范 业务功能分册,从业务需求出发,明确了业务平台集中监控系统的管理范围,规范了业务平台集中监控系统应具备的系统功能,为中国电信业务平台集中监控系统的规划、建设提供基本功能要求。,3)中国电信业务平台集中监控系统规范 数据模型分册,规范了业务平台集中监控系统的核心数据模型,即监控对象配置模型。并且通过研究众多主流业务平台的具体监控需求,提炼了参考的配置模型、性能数据模型和故障数据模型,以规范和指导业务平台集中监控系统的设计、开发。,随着研究的深入,以后将提供接口规范、测试规范等分册。,业务平台集中监控系统规范 总体规范分册,第 4 页

6、 共 30 页,1.4.起草单位,本规范起草单位为中国电信集团公司负责起草。,1.5.解释权,本规范的解释权归中国电信集团公司。,1.6.版权,本规范的版权归中国电信集团公司。,2.综述,2.1.背景,2.1.1.业务平台维护管理现状,增值业务平台通常由增值服务软件应用和业务承载硬件设备/网络两大部分组成。其中业务承载硬件又包括服务器设备、存储设备、平台内部互联网络、与交换/移动/数据等业务承载网络互联的专用网络设备等四大部分内容。做好增值业务专业运行维护管理需要将应用软件平台维护和硬件设备/网络维护两大部分工作有机地融合,二者缺一不可。,由于各类增值服务属于新兴转型业务,因此具体业务平台的维

7、护管理模式在集团以及各省间存在很大差异。在用户需求增长、技术更新、竞争加剧等因素驱动增值业务不断发展的同时,各类增值业务服务平台的数量不断增加,不同业务平台需要专人通过不同的监控管理终端进行维护管理,同时不同业务平台的操作维护、监控管理以及业务数据制作等维护管理方式各不相同,这些都直接导致增值业务专业的运维管理工作量不断增长。现有各业务平台的能力提供主要是面向业务对外提供服务方面的能力,平台自身维护管理功能一般通过自带的管理模块实现。但现有大多数平台的网管功能较为薄弱,业务监控、设备管理、性能分析、数据统计等方面的功能无法满足现有维护工作需要。,从对运维流程支持能力方面进行分析,现有的各业务平

8、台对业务开通流程以及业务保障流程的支持力度有限,没有同已投入使用的集团大客户故障一站式受理系统、集团运维生产指挥网站以及各地已完成的电子化维护流程管理系统实现数据共享,现有各增值应用产品在集团与省公司间、各省公司间以及各省内部完,业务平台集中监控系统规范 总体规范分册成全程全网运维层面上指挥调度需要长时间、多级别的协调工作。资源管理方面,现有的各业务平台主要是以配置数据管理功能为主,并没有对平台内部的各类资源进行抽象建模,采集管理。以集团新建的 IDC 资源管理及经营支撑系统为例,该系统已要求对全国各 IDC 内的各种资源数据进行抽象建模,录入管理,但该系统与各省正在推广使用的资源管理系统间缺

9、乏数据接口,无法实现数据同步以及流程对接。省级、本地网级层面的业务平台与各地正在推广使用的资源管理系统间同样缺乏数据接口,数据同步以及流程对接问题同样存在。告警集中管理方面,现有各厂商业务平台的北向数据接口缺乏统一、规范化的定义,如果要完成告警数据的及时上发,需要另行组织接口研发。很多情况下,各类平台故障需要通过巡视厂商的业务平台,或者人工接收用户申告发现并干预,不利于实时集中监控管理,无法有效缩短排障时间。2.1.2.关键问题通过对中国电信增值业务维护管理现状的分析可以发现,目前增值业务平台的维护管理主要以原厂商提供的系统自维护功能为主,在一定程度上可以满足对各自平台设备的维护管理需求,但是

10、由于增值业务发展迅速,各项增值业务平台的维护工作分部门协同开展,这些都极大加重了增值业务维护管理工作的广度与难度,现有系统平台薄弱的维护手段给维护管理工作带来许多困难和问题。具体描述如下:,1.2.3.4.,不同厂商业务平台的自带维护管理模块无法统一管理其他厂家平台的业务运行情况,造成管理系统繁多,耗费人力资源。多数厂商的维护管理模块没有对设备、网络层面的告警和性能数据进行采集、处理,并通过直观的图形界面呈现,同时各业务平台目前大多仅管理业务信息,不能管理承载业务的设备、主机、数据库运行状态。新增业务平台需要新增监控终端和监控人员。目前部分厂商系统平台的增值业务服务质量数据获取和分析处理操作复

11、杂,影响监控、分析管理工作效率,当班维护人员无法根据业务服务质量的情况变化及时调整和优化增值业务平台性能。新的业务在原有的业务平台上推出的,不同增值业务的网管系统不能有效进行告警关联性分析,势必会影响故障定位的时间,不利于缩短故障修复时间。第 5 页 共 30 页,业务平台集中监控系统规范 总体规范分册,5.6.7.,与资源系统缺乏数据接口,不同厂商系统平台对外提供的数据接口缺乏统一、规范化的定义,平台间互联或者数据共享需要单独开发实现,容易造成各系统间接口复杂繁多,数据相对封闭、共享困难,与其它系统间的数据一致性保障困难。各厂商应用平台的开发能力参差不齐,不同平台的维护管理手段融合较为困难,

12、当前缺乏先进的网管手段对业务应用运行情况进行监控,缺乏统一,规范化的应用平台维护,支撑流程。现有应用平台在冗余备份、安全管理方面的机制考虑不够完善,服务器设,备以及服务软件应用平台的故障率高。2.2.目标2.2.1.总体目标本规范的总体目标是:以业务需求为导向,指导中国电信集团及各省公司业务平台集中监控系统建设。2.2.2.业务目标为接应中国电信“以客户为中心、以市场为导向、以效益为目标”的企业战略,适应中国电信向综合信息服务提供商的战略转型思路,业务平台集中监控系统应支撑如下业务目标:1)实现全网业务平台的集中监控管理业务平台集中监控系统应实现对全网业务平台的集中监控管理,包括基础设施资源、

13、基础软件、应用软件以及业务。2)支持以客户为中心的运维思路的转变建立业务平台资源、业务与客户的关联关系,提供客户业务视图,支撑面向客户的差异化服务。2.2.3.IT 目标1)统一的数据模型统一配置模型、性能模型、故障模型,规范数据指标,保证数据在企业范第 6 页 共 30 页,业务平台集中监控系统规范 总体规范分册,第 7 页 共 30 页,围内的共享。,2)全面的系统功能,定义满足实际业务需求的系统功能,提供直观、图形化的功能界面呈现,提升功能的应用价值。3)可扩展的技术架构,遵循分层和复用设计理念,按照组件化、策略化设计原则,建立数据与应用相分离的技术架构,支持新功能快速开发。,4)有效的

14、系统集成,规范系统集成接口,支撑应用系统间的有效互联。,5)易于演进的目标系统架构,目标系统架构应集合现有业务平台监控或 IT 网管系统架构,充分考虑系统的易于演进和实施落地,规划和确定可行的目标系统架构。,2.3.系统定位,业务平台集中监控系统在 OSS2.0 中的定位为专业网管系统,如下图红框所示:,图 2-1 业务平台集中监控系统在 OSS2.0 中的定位,业务平台集中监控系统实现全网业务平台的集中监控管理,建立跨业务平台、,障,性,管,配,管,测,管,商 码,彩 务,事,业务监控层面图 2-2 业务平台集中监控系统覆盖范围2.5.内容说明第一章 文档说明 对本文档的适用范围、相关文档和

15、起草单位等作了说明。第二章 综述 对目前业务平台维护管理现状进行了分析,并明确了规范的目标和范围。第三章 业务功能框架 给出了本规范覆盖的业务功能全视图。第四章 数据模型 阐述了业务平台集中监控系统的建模目标、方法论和核心抽象模型。第五章 系统集成关系 描述了业务平台集中监控系统与外围系统的集成接口关系。第六章 实施原则和演进思路 描述了业务平台集中监控系统的实施原则与演第 8 页 共 30 页,业务功能,业务平台集中监控系统规范 总体规范分册面向业务的配置数据模型,并提供相关监控维护以及影响分析等功能。2.4.范围对于本规范的业务覆盖范围,分为三个维度,分别是业务平台、业务功能、监控层面,如

16、下图所示。其中,业务平台主要包括:智能网、短信、彩铃、商务领航、号码百事通、IPTV、全球眼、IDC 等。业务平台,故,管,理,智能网,.号.,.百.短 铃 领信 航 通,能,理,置,理,试,理,基础设施基础软件应用软件,业务平台集中监控系统规范 总体规范分册进思路。附录一 列出总体规范中出现的关键术语的定义或解释。3.业务功能框架本章主要以业务功能的视角描述业务平台集中监控系统的功能框架,下图为功能全视图。,图 3-1 业务平台集中监控系统功能全视图1、拓扑管理拓扑管理的目的是为被监控的业务网络提供统一的网络拓扑结构和状态信息,使用户能够在拓扑图上直观的掌握整个业务网络的拓扑结构及业务网络设

17、备等运行状态。拓扑管理提供对拓扑图和树图的编辑及浏览功能,编辑的拓扑图和树图作为故障管理、配置管理的拓扑浏览的基础。拓扑能够分层显示业务平台网络的拓扑结构,并提供拓扑节点的级联功能,为用户监视整个网络提供强力的手段。2、故障管理故障管理的目的是使操作维护人员能及时了解业务平台的主机、网络、数据库、中间件、应用软件以及业务出现的异常运行状态,帮助操作人员确定故障原因和故障位置,以便及时纠正问题,保证业务平台设备和网络的正常运行。故障管理主要负责实时采集网元(NE)生成的各种告警报告,以及根据性能门限设置生成各种告警报告,根据时间、告警级别等多种逻辑进行故障过滤;根据网元和第 9 页 共 30 页

18、,拓扑管理拓扑对象浏览拓扑对象编辑管理功能关联拓扑自动发现测试任务管理测试结果管理测试管理,故障管理告警采集告警预处理告警处理告警过滤告警呈现告警查询告警同步告警关联分析,性能管理性能采集管理性能门限管理性能数据查询实时性能监视告警统计分析性能统计分析综合分析报表自定义统计分析,系统管理设备配置管理系统自身监控备份与恢复规则管理系统数据管理操作维护终端辅助操作维护集中数据修改操作维护,安全管理分权分域管理用户管理角色管理安全策略管理操作日志管理配置信息管理配置信息展现对象关联管理配置管理,业务平台集中监控系统规范 总体规范分册,第 10 页 共 30 页,故障之间内在逻辑联系进行故障关联和根源

19、故障查找;通过内置知识库帮助管理员处理系统故障;告警服务器在完成告警的各种处理后,将告警存入数据库,通知到所有客户端,并以可闻、可视的形式直观的提示维护人员,并提供各种告警查询和统计。3、性能管理,性能管理的目的是对网络、网络单元进行性能监视,采集相关的性能表征参数,报告业务平台设备的状态,评价网络和网络单元的有效性,支持网络分析和网络规划。性能管理必须提供如下功能:性能数据采集和保存、实时性能监视、性能数据查询、数据完整性检查等。,4、配置管理,系统支持对业务平台 IT 设备、网络及其承载的应用软件和业务等的配置管理,能记录准确可靠的配置信息,并提供各个配置项之间关系的信息,如设备从属关系、

20、网络连接关系、业务承载关系等。,5、操作维护管理,集中操作维护的最终目的是要实现对设备的无人值守,加强对业务平台设备、网络等操作维护人员的管理,提高业务平台维护水平,缩短故障历时,保障数据的准确性。操作维护功能应该实现对业务平台的各种网元设备的集中操作维护,包括集中操作终端、集中数据修改等。,6、测试管理,测试管理的目的是使操作维护人员能在日常维护中了解设备和网络运行状,态,帮助操作人员进行故障诊断,保证设备和网络的正常运行。,7、统计分析,系统提供科学、实用的统计报表。在日常的管理过程采集了大量有用的流量数据和状态数据以及各平台的相关业务指标数据等,通过对这些数据的智能分析,为管理人员提供了

21、多种实用的管理统计报表,如:交换机的资源使用报表、端口的流量占有报表、主机的网络流量报表、资源使用报表、逻辑盘或文件系统使用、监控进程资源使用报表等。这些报表为管理人员对资源使用的趋势预测、资源分配提供了良好的参考数据。要求系统提供灵活的报表自定义功能。,8、安全管理,系统通过对用户和网络的安全管理,实现对监控系统的安全访问操作的控制,其主要功能包括:安全策略管理、分权分域管理、角色管理、用户管理、用户登录管理、在线用户管理、日志管理。,9、系统管理,业务平台集中监控系统规范 总体规范分册,第 11 页 共 30 页,系统应提供自身监控、数据管理、规则管理、数据的备份与恢复等功能。,4.数据模

22、型,4.1.目标,统一定义业务平台集中监控的各个监控对象概念,方便业务人员和技术人员之间的沟通,为企业、系统提供统一的数据基础和交互语言,同时进一步规范和指导系统的开发,提供中国电信的信息化管理水平。,具体上,应达到如下目标:,1)以国际标准(TMF 的 NGOSSSID)及中国电信企业标准(DEM)为指导,从资源(包含物理资源和逻辑资源)和服务(包含面向资源的服务和面向客户的服务)开始逐层抽象建模,最终形成基础设施层、基础软件层、应用软件层和业务层四个层次的对象模型。,2)分析当前主流业务平台,从服务层次(内容、服务或通信能力)、服务形式(语音、数据或媒体)、合作方式(电信自己提供或与合作伙

23、伴合作提供)3 个维度构建业务平台特殊的对象和指标体系,提炼共性和差异性,形成适用于各个业务平台的通用监控对象。,3)实现抽象建模的基础设施层、基础软件层、应用软件层和业务层对象的松耦合。也就是说,对于任何一个业务平台的建模,运营商即可以采用所有4 个层次的模型予以表达,也可以选择只用其中一种或两种层次的模型予以表达。,4)由于业务平台监控系统指标体系较为缺乏规范,因此本规范的数据模型部,分也特别描述了性能数据和故障数据部分内容。,4.2.概述,数据模型是结合业务平台集中监控系统功能规范,通过分析、梳理业务平台所涉及的重要业务概念和数据,同时考虑与其他系统数据模型之间的承接关系,建立系统数据模

24、型。,数据模型将分为三部分:配置数据模型、性能数据和故障数据。配置数据模型分为核心概念模型和业务平台的参考配置模型。,核心概念模型约束了基础设施、基础软件、应用软件和业务各层监控对象的,通用配置模型,适用于现有业务平台,也适用于新业务平台。,业务平台参考配置模型。通过分析当前业务平台的特点,建立了针对业务平,业务平台集中监控系统规范 总体规范分册,第 12 页 共 30 页,台的参考配置模型,可以作为系统建设的参考。模型涵盖了智能网、短信、彩铃、商务领航、号码百事通、全球眼、IDC、IPTV 等 8 个业务平台。,性能数据和故障数据均涵盖了 8 个业务平台的参考性能数据和故障数据。可,以作为系

25、统建设的参考。,4.3.建模原则,为达到业务平台集中监控系统的总体目标,系统在数据模型的设计过程,确立了“抽象平台共性,体现平台差异”、“分层网络建模”、“提取平台功能差异数据”三个原则。各原则具体描述如下:,4.3.1.抽象平台共性,体现平台差异,平台的共性和差异性可以从以下两个方面考核:,1、功能层面。根据 ETOM 模型,从业务平台的平台构建到业务运营上看,业务平台整体上都具有“业务开通”、“业务运行”、“业务计费”和“业务保障”四类功能。,2、业务层面。业务平台提供的业务可以从以下几个方面分析:服务层次。服务层次指的是平台提供的服务的层次。可以分为内容、服务和通信能力 3 个层次。,服

26、务形式。服务形式指的是最终客户享受具体服务的形式。可以分为语音、数据和媒体 3 个形式。,合作形式。合作方式指的是业务开展的形式,是否和合作伙伴参与。分为电信自己提供或者与合作伙伴合作提供等方式。,4.3.2.分层网络建模,业务平台从平台的整体构建上分为四个层次:基础设施层、基础软件层、应用软件层和业务层。每一层之间是松耦合的,对于任何一个业务平台的建模,运营商即可以采用所有 4 个层次的模型予以表达,也可以选择只用其中一种或两种层次的模型予以表达。,因此在建模的时候充分考虑了 4 个层次的特点,根据关系重要但松耦合的设,计原则,采用分层建模的方法来构建数据模型。,业务平台集中监控系统规范 总

27、体规范分册,第 13 页 共 30 页,4.3.3.提取平台功能差异数据,由于业务平台监控系统指标体系较为缺乏规范,因此本规范的数据模型除了描述配置对象和配置数据外,还特别描述了性能数据和故障数据部分内容。通过分析配置、性能和故障上的功能差异,结合平台的差异性,构建相应数据指标的时候。构建差异数据时考虑了以下维度:,1)服务层次维度,服务层次指的是平台提供的服务的层次。可以分为内容、服务和通信能力 3 个层次。一个平台可能提供了一到三种层次的服务。内容层次针对的是当平台提供内容服务作为主要的服务内容时,典型的平台比如号百平台、IPTV 平台等。内容层次关注的是提供内容的准确性、及时性、客户满意

28、情况等。,服务层次针对的是平台提供了其他非内容服务的时候,典型的平台比如商企平台、IDC 平台、全球眼平台等。服务层次关注的是提供的服务的准确性、及时性等。,通信能力层次针对的是平台提供的是以增强客户传统通信能力为主的业务的时候,典型的平台比如智能网、彩铃平台、短信平台等。服务层次关注的是提供的通信能力的延时、效率等。,2)服务形式维度,服务形式指的是最终客户享受具体服务的形式。可以分为语音、数据和媒体 3 个形式。一个平台可能提供了一到三种形式的服务。语音服务形式针对的是以语音方式为主提供服务的业务。比如智能网、号百、彩铃平台支撑的各种业务等。以语音方式提供业务时需要考虑语音的接通情况、呼损

29、情况等。,数据服务形式只最普遍的方式,针对的是数据方式为主提供服务的业务。比如彩铃、短信、商企平台、IDC 平台等。以数据服务方式提供业务时需要考虑数据的准确情况、传送效率等。,媒体服务形式针对的是以媒体流方式为主提供服务的业务。比如 IPTV、全球眼等。以媒体服务方式提供业务时需要考虑媒体流的传播特性,需要构建媒体流速率、质量等。,3)合作形式维度,合作方式指的是业务开展的形式,是否和合作伙伴参与。,分为电信自己提供或者与合作伙伴合作提供等方式。,对于电信自己提供的业务,管理接口较少,管理难度较小。,对于与合作伙伴合作提供的业务,管理接口较多,管理难度较大。因此需要再开通、计费、维护、业务运

30、行等多个角度来考虑和合作伙伴的合作,需要监控多个接口。,业务平台集中监控系统规范 总体规范分册,第 14 页 共 30 页,4.4.方法论,4.4.1.自上而下的与自下而上相结合的纵向分析方法,对于业务平台包含的软硬件本身建模时,由于软件时依附于硬件之上的,因此适合使用自下而上的建模方法来抽象基础设施、基础软件和应用软件层次的对象模型。,而对于业务层的对象,由于各个业务提供的功能是由业务本身的特性决定的,因此分析这些业务来构建业务相关的业务功能对象又是自上而下的方法。在考虑每个对象的时候,由于对象的复杂性和 IT 监控规范性较弱的问题,又,需要深入到每一个对象里,逐渐拆分对象并构建对象之间的关

31、系。,因此本模型设计采用了自上而下,逐级深入(TOP_DOWN)的设计方法和自,上而下(BOTTOM_UP)的验证方法。,4.4.2.多业务平台的横向分析方法,除了基础设施、基础软件、应用软件和业务 4 个层次自上而下和自下而上相结合的方法外,系统在模型的设计上还要采用多业务平台的横向分析方法。横向分析各个业务平台的差异性和共性。,在横向分析业务平台时,采用了以下两个角度:,1)业务平台的成熟度差异,对于较为成熟的平台,由于平台较为稳定,业务开展相对稳定,改造难度相对较大,因此规范提出的要求适当放松。对于在高速发展期的平台,规范提出的要求适当提高。,2)转型业务平台和传统增值业务平台的差异。转

32、型业务平台例如号百、商企、全球眼、IPTV、IDC 等平台。传统增值业务平台例如智能网、彩铃、短信等平台。,4.4.3.基于 SID 的模型元素的分析方法,信息模型(或称为“数据模型”)是一种抽象,仅提供业务关系的内容的高层,视图。其有助于理解业务的范围和广度,而不是深度。,信息模型的展现方式有多种。NGOSS-SID 关注于创建概念或者分析模型(通常称为“领域模型”或者“语义模型”)。此模型是从业务角度对现实世界对象的表现。,因此,基于 NGOSS-SID 的分析模型包含下列元素:,实体业务关心的对象:,业务平台集中监控系统规范 总体规范分册实体表示相同类型的实例的集合。实体即能够表示物理对

33、象(例如:手机),也能表示概念对象(例如:所有权)。关联实体之间的相互关系:关联表示两个实体之间的关系。关联关系包含聚合关系、继承和泛化等。属性明确定义对象的关键细节:属性表示对象的特性。属性的类型是可选的。使用合成模式(见下一节)能够将复杂的属性分成单独的实体。4.4.4.基于设计模式的模型设计方法模式是针对特定环境下经常出现的有代表性的问题,经过实践验证后的解决方案。它可以帮助复用设计和协助沟通,可以提高信息模型的质量(特别是耦合性和一致性),使模型的结构更为合理,具有良好的适应能力,并能够提供可扩展的结构。4.4.4.1.规格(Specification)模式使用规格模式的目的是将实体规

34、格和实体规格所具有的属性分离开,将属性用单独的实体来描述。引入这种模式的原因在于同一个实体规格的不同类型的实例所具有的属性的种类、数量都不相同,很难用类的属性来表示,因此将实体规格属性用单独的实体来表示,可以提供实体规格所拥有的属性的灵活变化可扩展。规格模式如下图所示:,AnEntitySpec,AnEntityAnotherEntity,1,*,实体的类型通用的属性,和和和和和和属属,SpecificationDescribes图 4-1规格模式第 15 页 共 30 页,业务平台集中监控系统规范 总体规范分册需要对实体进行描述,并且与实体的任何当前存在实例无关时,则使用规格模式。规格实体不

35、表示概念或者对象,而是关于概念或者对象的信息。规格实体用于和对象的种类相关而不是和单个实例相关的业务概念,如:商品目录、规格、处方等。例如:NGN 中的 SG/TG/AG 网元类型可以抽象为相应的网元规格,此规格属性与具体的网元实例无关。4.4.4.2.抽象父类(Abstract Superclass)模式使用抽象父类模式增加父类实体,可以将相似的实体分为一组。将父类实体定义为抽象类,因为其在现实世界中并不存在,是为了建模所需构造。在面向对象的建模中,抽象层次是非常重要的,适当的抽象层次可以使信息模型更为通用和具有良好的扩展能力,通过对子类的扩展可以使模型快速适应业务的变化,而不会对已有的父类

36、和其它实体造成大的影响。抽象父类模式如下图所示:,ThatEntity,ThisEntity,另另另和和另另另This或或That和和AnotherEntity,抽抽和和名名名名和AnAbstractEntityaCommonAttribute,图 4-2,抽象父类模式,抽象模式除了能够实现将子类的通用的属性和方法抽象到父类中实现复用以外,也可以将子类中存在的通用关系抽象到父类层次上,实现关联关系的良好扩展能力。此模式有助于改善模型的模块化(耦合性和一致性)。例如:传输专业中的终端点(TerminationPoint)为 CTP/PTP/GTP 的抽象父类。第 16 页 共 30 页,业务平台

37、集中监控系统规范 总体规范分册与这三类终端点共同的关联可以表示为与抽象父类终端点(TerminationPoint)的关联,且三个子类均具有抽象父类的属性。4.4.4.3.合成(Composite)模式合成模式也称为部分整体模式。该模式将对象组织到树结构中,可以用来描述整体与部分的关系。合成模式能够简化客户操作,使其能够统一地处理单个对象和对象的聚合。当单个对象和这些对象的集合能够互换时,对这种业务概念使用合成模式。合成模式的模型如下图所示:另另另和和另另和和到到另到到、子子或或者另子者,AnotherEntity,ACompoundEntity,ASimpleEntity图 4-3,AnEn

38、tity合成模式,注:当使用物理对象的合成时,他们通常形成树形结构。逻辑对象的合成和规格对象的合成通常形成定向的非循环图形。例如:对于特定的硬件驱动,在一个时刻仅能插到一台电脑上。但是,一类硬件驱动,可以插到很多不同类型的电脑上。例如:传输中的通道包含高阶通道(高阶子网连接)、低阶通道(低阶子网连接)以及捆绑通道(捆绑子网连接)即为合成模式的抽象,能够按照单一的模式处理单个通道以及通道的合成。4.4.4.4.角色实体(Role Entity)模式角色实体模式使对象在给定的场景下表现不同的行为。角色模式是一种基本的模式,其有助于简化模型并使模型能够更加贴切地描述现实世界。固有属性是第 17 页

39、共 30 页,业务平台集中监控系统规范 总体规范分册对象通常具有的属性,基于场景的属性是在特定的环境下与对象有关的属性。角色模式的模型如下图所示:,AnEntityintrinsicAttribute,AnEntityRolevalidFor:TimePeriod,ThisRolecontextualAttribute1,*,1,AnotherEntity,另另另和和另另另另和和到联和和,或或或或其其其和和到联和和(如如如如),图 4-4,ThatRolecontextualAttribute2角色模式,对对象进行建模时,需要了解对象在不同的环境下的不同行为,即:对象如何被使用,而不仅仅考虑对

40、象是什么。在信息模型中,采用实体、实体角色(角色对象)分离的模式,即用两个实体描述概念及其角色会模型对于变更更具鲁棒性并且减少重复性实体是相对固定的,实体扮演的角色是可以独立于实体灵活的变化和扩展。例如:数据专业中的路由器按照接入位置不同可以充当不同的角色,即 PE 或者 CE。4.4.4.5.暂态实体(Temporal State Entity)模式当需要显示实体的状态、每个状态的属性以及实体的暂态或者生命周期时,使用此模式。实体的状态可能随时改变,仅需要保存当前的状态或者需要保存所有历史状态,这取决于业务需求。将需要一直监视的特性分成独立的实体,会比在实体中显示这些属性更加清晰,这就是暂态

41、实体模式。暂态实体模式的模型如下图所示:第 18 页 共 30 页,业务平台集中监控系统规范 总体规范分册,状状另另状状状状。在在在状在在另在在名另为状状,AnotherEntity,1,AnEntitytimeInvariantAttributeReadyActivatingActive,*AbortingCompleting,AnEntityStatetimeVaringAttributevalidFor:TimePeriodCancelledAbortedCompleted,图 4-5,暂态实体模式,注意:此模式和“角色实体”模式很相似,但是表示不同的概念。例如:处于不同状态的订购,关注

42、的属性值有不同。4.4.4.6.自关联(Self Relationship)模式当实体的一个实例可能与同一个对象的其他实例发生关联时使用自关联模式。例如,将个体与其父母联系在一起就能形成族谱。自关联的类型有以下几种:依赖:两个实体具有起始或者终止的依赖关系。例如:活动 1 结束之后活动 2 才能开始;演替(继承):一个或者多个实体能够被一个或者多个其他实体替代。这是一种抽象关系,需要使用下面列出的实际类型之一。替代:一个实体能够替代另一个。例如:活动 1 已经无效,其可以被活动 1A 代替。第 19 页 共 30 页,anEntityDivision,anEntitySuccession,an

43、EntityDependency,anEntitySubstitution,anEntityFusion,AnEntity,*,业务平台集中监控系统规范 总体规范分册分割:一个实体被多个实体代替。例如:活动 1 已经无效,其可以被活动 1A、1B 和 1C 代替。融合:多个实体被一个实体代替。例如:活动 1A、1B 和 1C 已经无效,其可以被活动 1 代替。自关联模式的模型如下图所示:anEntityRelationship*,图 4-6,自关联模式,4.5.核心配置模型第 20 页 共 30 页,业务平台集中监控系统规范 总体规范分册4.5.1.高层模型,资资,物物资资,逻逻资资,0.n,

44、0.n,物物资资物物逻逻资资,面面资资和面面,1.n,0.n,物物资资名面面资资和面面的的面面,1.n,0.n,逻逻资资和逻面面资资和面面,面面面面和面面,1.n,0.n,面面面面和面面面面面面资资和面面,面面,图 4-7,高层模型,资源(Resource)是数据模型所有实体的抽象基类,所有可管理的实体均从其继承。资源可泛化为物理资源和逻辑资源。物理资源(PhysicalResource)是确实存在的、可见的的有形资源,从物理角度描述资源信息。物理资源包括物理设备、机架、板卡、端口等物理上有形的资源,也包括操作系统、运行进程、文件等确实存在而且用户真实可见的软件实体资源等;逻辑资源(Logic

45、alResource)除物理资源之外的、无形的通信资源和信息服务资源(内容和应用),是从逻辑角度描述资源信息。在本规范里逻辑资源主要是应用软件提供的不可见的应用功能,这些功能是直接提供给业务运行使用的资源。物理资源和逻辑资源之间的关联说明逻辑资源的集合需要特定的物理资源支持。面 向 资 源 的 服 务(ResourceFacingService)和 面 向 客 户 的 服 务(CustomerFacingService)从服务(Service)继承。面向资源的服务定义了对客户非直接可见的特定服务的特征和行为,它是支持面向客户的服务的“内部”服务。物理资源/逻辑资源和面向资源的服务之间的关联表示

46、为了使用面向资源的服务所需要的物理资源/逻辑资源。因为物理资源存在,那么提供资源服务的逻辑资源才能够存在于该物理资源中;在提供面向资源的服务之前,可以先安装使用逻辑资源的物理资源。第 21 页 共 30 页,业务平台集中监控系统规范 总体规范分册4.5.2.业务平台核心概念模型业务平台的核心概念模型如下:,物物资资,面面面面和面面,面面资资和面面,业面业业,基基基基,1.n1,1.n,1,1.n,0.n,基基基基,1.n,1,1,0.n,物物,逻逻资资0.n,1,业面,1.n,1,应应应另 1.n,1.n 应应基基,业面应另,1,1.n,物物,1.n,1,“备注:本规范里,使用红底的模型元素表

47、示该元素是从别的模型图里引入本模型图的概念。”表示rose图红底表示的元素的含义。,图 4-8,业务平台核心概念模型,业务是泛指中国电信向社会提供的服务以及相关的其他面向社会的活动。本规范的业务主要指中国电信提供的面向客户的服务,它和产品有密切的关系。业务功能是指中国电信提供的面向资源的服务,它是针对客户可见的、客户可感知的,与业务开展紧密相关的功能。业务功能体现了对于客户和业务的差异性功能。应用功能是指业务平台本身提供的软件功能,它支撑了业务功能的开展,通常它的功能针对的是所有业务和客户。应用软件指的是业务平台本身提供的软件实体,它包含应用软件运行所需要的应用进程、进程池、接口和重要的应用数

48、据文件等。基础软件指的是业务平台的应用软件运行所必须的基础类软件,这些软件通常都是行业通用的软件,在上层的具体应用软件和下层的基础设施之间建立桥梁,为上层的应用软件屏蔽底层的硬件差异。基础设施指的是业务平台正常运作所必须的纯硬件设备,它可能包含部分与硬件密不可分的软件实体。第 22 页 共 30 页,子者基网,存存基网,业务平台集中监控系统规范 总体规范分册4.5.3.物理资源核心概念模型物理资源包含的对象实体较多,因此本规范有必要对这些实体再进行抽象。抽象后的物理资源核心概念模型如下:物物资资,面面服基网,操操操操,0.n,运运运,运运运运,基基,1.n,安安运1.n,1,基基基基,基网设服

49、,硬基,0.1操作系统(Operating System,简称 OS)是最靠近硬件的一层系统软件。它管理计算机系统的全部硬件资源包括软件资源及数据资源;控制程序运行;改善人机界面;为其它应用软件提供支持等,使计算机系统所有资源最大限度地发挥作用,为用户提供方便的、有效的、友善的服务界面。服务器设备指的是包含操作系统的高性能计算机,它由很多的硬件组成,包含处理器、硬盘、内存、系统总线等,它们通常针对具体的网络应用,具有较强的处理能力、稳定性、可靠性、安全性、可扩展性和可管理性。网络设备指的是使用 TCP/IP 协议的通信设备,包含交换机、路由器、防火墙、入侵检测设备等。存储设备指的是用于存储计算

50、机数据的设备,包含磁盘阵列等。硬件指的是组成基础设施的各类基础硬件,包括板卡、CPU、内存、硬盘等。设备容器指的是容纳硬件设备的容器,包含机架和机框等。5.系统集成关系规范结合核心共享数据在相关系统的归属关系,确定了业务平台集中监控系统与外围系统间的集成关系,如下图所示,在此简单描述了几类接口关系。第 23 页 共 30 页,图 5-1 业务平台集中监控系统接口1)与业务平台 EMS 的关系从业务平台/EMS 获取监控信息针对部分 EMS 管理能力不足(尤其是在基础设施及基础软件的监控方面),建立集中监控手段具有获取业务平台 EMS 所有业务指标的能力,实现业务指标对上层分析系统的统一提供加强

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号