DK70776349
有爱立信OMT软件支持WIN764位吗
面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。
随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法 OMT(LbjectModellingTechnique)。
这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、 输出数据结构，实际上也包含了所有对象的数据结构。
所以OMT彻底实现了PAM没有完全实现的目标。
不仅如此，OO技术在需求分析、可维护性和可靠性这三 个软件开发的关键环节和质量 指标上有了实质性的突破，彻底地解决了在这些方面存在的严重问题，从而宣告了软件危机末日的来临。
自底向上的归纳 OMT的第一步是从问题的陈述入手，构造系统模型。
从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关 联。
类是具有相似属性和行为的一组具体实例（客观对象）的抽象，父类是若干子类的归纳。
因此这是一种自底向上的归纳过程。
在自底向上的归纳过程中，为使子 类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理。
由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类 的思维规律，因此能更快、更方便地完成任务。
这与自顶向下的Yourdon方法构成鲜明的对照。
在Yourdon方法中构造系统模型是最困难的一步，因为 自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。
而在OMT中这一工作可由一般 开发人员较快地完成。
在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型。
这三个模型一起构成要求解的系统模型。
自顶向下的分解 系统模型建立后的工作就是分解。
与Yourdon方法按功能分解不同，在OMT中通常按服务（Service）来分解。
服务是具有共同目标的相关 功能的集合，如I/O处理、图形处理等。
这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易。
所以OMT也具有自 顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了Yourdon方法中功能分解的困难和不确定性。
OMT的基础是对象模型 每个对象类由数据结构（属性）和操作（行为）组成，有关的所有数据结构（包括输入、输出数据结构）都成了软件开发的依据。
因此Jackson方法 和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。
OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。
更重 要的是，在Jackson方法和PAM方法中，当它们的出发点——输入、输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。
但在OMT中系 统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
需求分析彻底 需求分析不彻底是软件失败的主要原因之一。
即使在目前，这一危险依然存在。
传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种问题。
正是由于这一原 因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改进需求。
在每次改进需求后又形成新的进化原型供用户试用，直到用户基本满意，大大提高了软件的 成功率。
但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。
OMT彻底解决了这一问题。
因为需求分析过程已与系统模型的形成过程一致，开发人员与用户的讨论是从用户熟悉的具体实例（实体）开始的。
开发人员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语言，避免了传统需求分析中可能产生的种种问题。
可维护性大大改善 在OMT之前的软件开发方法都是基于功能分解的。
尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。
但从本质上讲，基于功能分解的软件是不易 维护的。
因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。
更严重的是，在这种软件系统中，修改是困难的。
由于种种原因，即使是微小的修改也可能引入 新的错误。
所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。
正是OMT才使软件的可维护性有了质的改善。
OMT的基础是目标系统的对象模型，而不是功能的分解。
功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。
由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。
更重要的是OMT彻底解决了软件的可维护性。
在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为（虚函数）。
利用这 一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为（即虚函数或虚方法）进行重载，也就是对它们重新定义。
由于不再在原来的程 序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。
OO技术还提高了软件的可靠性和健壮性。
通信中网管维护中心OMT是什么意思
移动通信系统中的基站主要负责与无线有关的各种功能，为MS（移动台）提供接入系统的UM接口，直接和MS通过无线相连接，系统中基站发生故障对整个移动网的影响是很大的。
引起基站故障的原因很多，但大多可归为以下四类，本文结合本人的实际工作对基站故障归纳分析如下： 一，因传输问题引起的故障移动通信虽属于无线通信，但其实际为无线与有线的结合体。
移动业务交换中心（MSC）与基站控制器（BSC）之间的A接口以及基站控制器（BSC）与基站收发信台（BTS）之间的ABIS接口其物理连接均为采用标准的2.048MB/S的PCM数字传输来实现。
另外基站的各部件的稳定工作离不开稳定的时钟信号，而基站的时钟信号是从PCM传输中提取的，爱立信的基站不提供外部时钟输入的端口，这些基站设备是基于采用传统的PDH组网方试而设计的。
目前传输设备正从PDH向SDH逐步过度，而按照SDH的传输体制，由于指针调整的原因，其传送时钟是通过线路码传输，由分插复用器（ADM）专门的时钟端口输出。
如果采用从SDH的随路码流中提取时钟的方法，将会带来诸如失步，滑码，死站的问题。
如新桥站原采用爱立信RBS200设备，传输采用SDH系统，此站自开通以来一直不稳定，后经爱立信工程师到现场检查发现为基站同步不好，建议采用PDH传输系统，或基站采用RBS2000设备，（RBS2000对同步要求较RBS200低），后用RBS2000设备替换原RBS200设备，基站工作正常至今。
日常维护中经常有基站所有或部分载频不稳定，时而退服时而工作的现象，BSC侧对CF测试结果为BTS COMMUNICATION NOT POSSIBLE 或CF LOAD FAILED。
此类故障大都为传输不稳定有误码，滑码而引起的。
当传输误码积累到一定时，BSC无法对基站进行控制，数据装载，此时可在本地模式下通过OMT对IDB数据从新装载，复位后可恢复正常。
二，因基站软件问题引起的故障基站系统中的软件是指挥和管理基站各部件有序，正常工作的。
若基站IDB数据与基站情况不匹配，则基站一定无法正常工作。
如在对北码头基站进行传输压缩（两条压缩为一条）后发现A,B小区工作正常而C小区工作不正常，说明BSC无法与C小区进行通信，于是怀疑与之想邻的B小区的软件设置有误，经查看发现B小区的传输方式被误设为STANDALONE（单独方式），一条传输时ABC各扇区的传输方式应分别设为CASCADE,CASCADE,STANDALONE，将B的传输方式改为CASCADE后基站恢复正常。
三，因基站硬件引起的故障此类故障较常见，现象也较明显，一般有故障的硬件其红色FOULT灯会点亮，但有时不能被表面假象所迷惑。
例如唐闸基站B扇区一载频（TRU）退服，到站后发现此载频的红色FOULT灯和TX NOT ENABLE 灯都亮，于是判断为TRU硬件损坏，更换后故障现象依旧，此时更换TRU就犯了“头痛医头，脚痛医脚”的错误，TRU退服可能为其本身硬件故障也可能为与之相连的其他硬件或连线的故障。
用OMT软件诊断后提示为CU到TRU间的连线故障，检查发现连线松动，重新连接后故障消失。
对此类故障建议先用OMT软件进行故障定位，根据OMT的建议替换单元进行操作，而不能只看表面。
四，因各种干扰引起的故障移动通信系统中的干扰也会影响基站的正常工作，有同频干扰，邻频干扰，互调干扰等。
现在陆地蜂窝移动通信系统采用同频复用技术来提高频率利用率，增加系统容量，但同时也引入了各种干扰。
日常维护中新建站以及扩容站新加载频的频点选取不合理基站将无法正常工作，对此类故障应与网优配合，综合考虑各种因素，选取合理频点，消除以上干扰。
对移动通信系统中基站的各类故障应认真分析，找到其真正原因，才能以最快的速度排除故障，提高网络质量。
BTS上面的RBS亮红灯代表什么意思？RF off 亮红灯或者亮黄灯 是什么...
ifiedModelingLanguage，统一建模语言，主要由Booch、Rumbaugh及Jacobson三人提出，他们三人把自己分别提出的建模方法Booch、OMT、OOSE融合为一种方法称为UML。
Booch在《TheUnifiedModelingLanguageUserGuide》中对UML的定义是“UML是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言”。
可以简单的理解UML是软件建模的一种语言，它的特色是使用图形化的方法来进行软件建模。
UML的特点如下：统一的标准，UML已经被OMG接受为标准的建模语言，而且越来越多的开发人员使用ULM语言进行开发；UML是支持面向对象技术的建模语言；可视化、表示能力强大；独立于过程，UML不依赖于特定的软件开发过程；概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。
我现在刚做中国移动基站维护的 几乎都不知道 请有知道的大虾仔细帮...
展开全部 面向对象软件设计说明书模板 1 概述 1.1 系统简述 对系统要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标 这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。
同时，对于非功能性的需求例如性能、可用性等，亦需提及。
需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。
在随后的文档部分，将解释设计是怎么来实现这些的。
1.3 参考资料 列出本文档中所引用的参考资料。
（至少要引用需求规格说明书） 1.4 修订版本记录 列出本文档修改的历史纪录。
必须指明修改的内容、日期以及修改人。
2 术语表 对本文档中所使用的各种术语进行说明。
如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
3 用例 此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
4 设计概述 4.1 简述 这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose） 4.2 系统结构设计 这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。
最好是把逻辑结构同物理结构分离，对前者进行描述。
别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构 4.2.2 子系统1结构 4.2.3 子系统2结构 4.3 系统界面 各种提供给用户的界面以及外部系统在此处要予以说明。
如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。
如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
4.4 约束和假定 描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。
说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。
这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。
实现的语言和平台也会对系统有约束，同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
5 对象模型 5.1 系统对象模型 提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢？ 在其中应该包含所有的系统对象。
这些对象都是从理解需求后得到的。
要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0..1,*,1..*）。
聚合和继承关系必须清楚地确定下来。
每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述 在这个部分叙述每个对象的细节，它的属性、它的方法。
在这之前必须从逻辑上对对象进行组织。
你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。
在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。
如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。
对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。
对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。
如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。
列出它或者被它调用的方法需要访问或者修改的属性。
最后，提供可以验证实现方法的测试案例。
6.1 子系统1中的对象 6.1.1 对象：对象1 用途： 约束： 持久性： 6.1.1.1 属性描述： 1. 属性：属性1 类型： 描述： 约束： 2. 属性：属性2 6.1.1.2 方法描述： 1. 方法：方法1 返回类型： 参数： 返回值： Pre-Condition: Post-Condition： 读取/修改的属性： 调用的方法： 处理逻辑： 测试例：用什么参数调用该方法，期望的输出是什么…… 7 动态模型 这部分的作用是描述系统如何响应各种事件。
例如，可以建立系统的行为模型。
一般使用顺序图和状态图。
确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。
不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。
7.1 场景（Scenarios） 对每个场景做一则条目，包括以下内容： 场景名：给它一个可以望文生义的名字 场景描述：简要叙述场景是干什么的以及发生的动作的顺序。
顺序图：描述各种事件及事...
