6. Modelo de Informação

6.1. Introdução

O modelo de informação é um dos aspectos mais importantes a se observar em uma TMN e é o ponto de partida para a implementação de uma rede consistente e confiável. O modelo de informação, na realidade, é o conjunto de objetos gerenciados que representam o equipamento (físico ou lógico) que vai ser gerenciado, mas modelado do ponto de vista da gerência que se quer realizar sobre ele. Isso tem a sua base na recomendação M.3020, que especifica uma metodologia para desenvolvimento de modelos de informação.

Antes de entrar no mérito da metodologia propriamente dita, vale a pena incluir aqui algumas definições importantes, como a definição de serviços e funções.

6.2. Serviços de Gerência

Um serviço é uma área de atividade de gerência que provê o suporte a um aspecto de operação. Os serviços, na realidade, são os objetivos a se alcançar com a implementação de uma TMN. Os serviços de gerência listados na M.3200 são:

• administração do usuário
• gerência de provisionamento da rede
• administração de contabilização, cobrança e tarifa
• qualidade de serviços e administração de desempenho de rede
• administração de análise e medições de tráfego
• gerência de tráfego
• roteamento e administração de análise de dígito
• gerência de manutenção
• administração da segurança
• gerência de logística

Os serviços de gerência são decompostos em grupos de conjuntos de funções, conjuntos de funções e funções. A definição de um serviço assegura que todas as funções necessárias à realização daquela atividade serão suportadas pela implementação.

Um grupo de conjunto de funções é uma parte menor do serviço TMN. O serviço de Gerência de Tráfego, por exemplo, visa a obtenção do maior número possível de chamadas completadas com sucesso através da maximização do uso de todos os equipamentos e facilidades disponíveis em qualquer situação de tráfego e ainda do controle de fluxo de tráfego para a utilização da capacidade máxima da rede. O serviço de Gerência de Tráfego possui como grupos de conjuntos de funções a Monitoração do Estado da Rede, Monitoração do Desempenho da Rede e Ações de Controle de Gerência de Tréfego.

6.3. Funções de Gerência

As funções de gerência, conforme definido na recomendação M.3400, são a menor parte do serviço percebíveis pelo usuário deste serviço. Uma função corresponde a uma série de ações sobre um objeto gerenciado a fim de realizar um serviço. As funções podem ser reutilizáveis, ou seja, serviços diferentes podem utilizar as mesmas funções para atingir objetivos diferentes. Um exemplo disto pode ser alguma função de monitoração de desempenho. Esta função pode, por exemplo, ser responsável pela coleta de dados de desempenho e, através de um processo qualquer, pode servir para a indicação de alarmes, quando o desempenho atingir um determinado nível. Portanto temos uma função que serve tanto para desempenho quanto para falhas.

6.3. Metodologia para Definição do Modelo de Informação

Um modelo de informação deve ser definido, então, de forma que os objetos gerenciados suportem os Serviços de Gerência definidos. Portanto podemos visualizar os passos para a definição de um modelo de informação:

Desta forma, o modelo será consistente e suportará os serviços definidos. Iremos agora analisar a forma como os objetos devem ser descritos para escrever o modelo de informação. Para isso, veremos todas as características que devemos definir para os objetos e a forma como eles devem ser descritos (GDMO e ASN.1).

6.4. Modelamento de Objetos

Um objeto gerenciado é uma representação para o sistema de gerência do recurso de telecomunicações a ser gerenciado. Um gerente não "enxerga" um recurso a ser gerenciado, a não ser que ele esteja representado por um objeto. O objeto gerenciado, então, não é apenas uma sintaxe representando um recurso, mas sim a definição da capacidade de gerenciamento do recurso. Utilizando-se técnicas de orientação a objetos, definimos classes, atributos, etc para modelar o recurso a ser gerenciado.

A modelagem orientada a objetos nos traz algumas vantagens e conceitos herdados da orientação a objetos, como por exemplo reutilização das classes, herança, encapsulamento, etc.

A orientação a objeto é extensível aos protocolos e serviços relacionados. O CMIP, por exemplo, utiliza os princípios de orientação a objetos, mas o banco de dados onde a MIB é implementada não precisa utilizar a orientação a objeto (geralmente é um banco de dados relacional). Um objeto gerenciado pode ser visto como uma esfera opaca recobrindo o recurso real, com uma "janela", através da qual a informação de gerenciamento pode passar, conforme pode ser visto na figura 6.3. Esta informação consiste em:

• operações de gerenciamento no objeto
• resultado das operações que retorna
• notificações que podem ser geradas espontaneamente pelo objeto gerenciado quando um evento ocorre no recurso

e corresponde aos elementos do serviço CMIS.

A figura 6.3 nos ilustra o conceito de encapsulamento, muito importante para análise orientada a objetos. A idéia de encapsulamento é justamente esconder os detalhes de implementação do objeto, permitindo o acesso a este apenas através de algumas funções bem definidas. De uma maneira simplista, pode-se fazer uma analogia com um programa de computador, por exemplo. Quando se faz um programa, o implementador escreve o código fonte do programa, onde são definidas todas as variáveis, funções, etc. Mas geralmente não se deseja que o usuário tenha contato com o programa a este nível. Gera-se então um executável, que irá esconder os detalhes de implementação do usuário, ou seja, irá permitir o acesso do usuário ao programa através de uma interface definida e controlada (desta forma podemos dizer que o arquivo executável é um encapsulamento do código fonte).

Algumas vantagens do encapsulamento são:

• protege as variáveis do objeto de serem corrompidas por outros objetos (proteção contra acesso não autorizado, valores inconsistentes, etc);
• esconde a estrutura interna do objeto de modo que a interação com este objeto seja relativamente simples e, à medida do possível, padrão.

É possível, dada a definição de um objeto gerenciado, que vários objetos satisfaçam as mesmas condições, até mesmo no mesmo sistema. Um exemplo disso é um log ou uma conexão. Vários logs de um sistema são gerenciados da mesma maneira, formando assim uma classe de objetos gerenciados, onde cada log em particular é uma instância desta classe.

Para se definir completamente uma classe, devemos caracterizar:

• as propriedades ou características visíveis na fronteira do objeto gerenciado, ou seja, os atributos e seus valores;
• as operações de gerenciamento aplicáveis à classe, sendo que algumas destas operações afetam apenas os atributos enquanto outras afetam o objeto como um todo;
• as regras de filtragem aplicáveis a filtros CMIS;
• o comportamento que exibe em resposta às operações de gerenciamento;
• as notificações que emite e as circunstâncias nas quais são emitidas;
• os pacotes que pode incluir;
• sua posição na árvore de herança;
• as name bindings, que definem o relacionamento entre as classes na árvore de contenção.

6.4.1. Hierarquia de Herança

Um conceito muito importante para o modelo de informação é o de Hierarquia de Herança, ou Hierarquia de Classes. Na hierarquia de herança, o conjunto de classes formam uma estrutura na qual existe o conceito de superclasses e subclasses. Uma subclasse herda todas as propriedades de sua superclasse, de maneira irrestrita, independentemente da necessidade ou não destas propriedades. Note que este conceito de superclasse e subclasse é relativo, pois uma classe pode ser subclasse de uma e superclasse de outra ao mesmo tempo.

A top é uma classe genérica definida na X.721, posicionada no topo da hierarquia.

A hierarquia de herança lida com especialização de classes e herança de atributos.

Para enxergar melhor o conceito de hierarquia de herança, tomemos um exemplo prático. Uma central telefônica CPA possui, para realizar a comutação, uma placa de comutação que possui um software baseado em tabelas. Vejamos a árvore de herança deste caso e depois a compararemos com a árvore de contenção.

Vamos supor, então, que as classes que estão nos quadrinhos cinzas foram as classes criadas por nós para atender ao modelo de informação desta central, derivadas das classes que estão nos quadrinhos brancos (que hipoteticamente já existem nos modelos genéricos). Supondo então, que as classes possuem como atributos:

Classe Software

• identificação
• linguagem

Classe Software de Comutação

• n. de tabelas de comutação
• versão

Classe Equipamento

• localidade

Classe Placas da Central

• tipo de barramento
• nível de tensão placa de comutação
• localização da placa
• estado operacional da placa

Classe Elemento gerenciado

• identificação

Classe Central

• prefixo
• localização

Classe Bastidor

• endereço

Tendo-se o conceito de que uma subclasse herda as características de sua superclasse, temos que os atributos da classe placa de comutação, por exemplo, passam a ser, além dos seus atributos originais (localização e estado operacional), os atributos herdados da classe placas da central (tipo de barramento e nível de tensão). Ou seja, se o gerente enviar ao agente um GET do valor do atributo tipo de barramento da placa de comutação, o agente vai consultar a classe placa de comutação, não vai achar o atributo, vai para a superclasse da placa de comutação (classe placas da central). Na classe placas da central o agente achou o atributo tipo de barramento da placa, lê o seu valor e manda a resposta ao gerente, como se o valor do atributo tivesse sido lido da classe placa de comutação. Portanto temos que a classe placa de comutação é uma especialização da classe placas da central.

A especialização de uma classe é conseguida através da:

• adição de novos atributos;
• extensão ou restrição da faixa de valores para um atributo existente;
• adição de novas operações e notificações às operações e notificações existentes;
• extensão ou restrição da faixa de valores de argumentos de operações e notificações existentes.

A hierarquia de herança se torna importante à medida em que facilita a reutilização dos atributos já definidos para as classes superiores. Desta forma, se ocorre a necessidade de se criar uma classe nova (que não existe nos modelos genéricos padronizados), deve-se sempre tentar criá-las especializando as classes padrões já existentes.

6.4.2. Hierarquia de Contenção

A Hierarquia de Contenção (ou Inclusão) refere-se, como o próprio nome diz, a uma relação onde um objeto (chamado objeto superior) contém outro objeto (denominado subordinado). Nota-se aqui a primeira e mais importante diferença entre as hierarquias de herança e contenção. Enquanto a hierarquia de herança diz respeito a classes de objetos, a hierarquia de contenção lida com instâncias das classes.

Esta relação de contenção pode ser utilizada para modelar as hierarquias existentes no mundo real, como por exemplo módulos, sub-módulos e componentes eletrônicos, ou no nosso exemplo da central telefônica, central, bastidor, placa de comutação, software de comutação. Isto significa que a central contém um bastidor que contém uma placa de comutação que contém um software de comutação (figura 6.6).

É importante distinguir bem o fato de que as duas hierarquias são, na realidade, duas formas diferentes de se enxergar a mesma coisa: o modelo de informação (na realidade, a relação entre as classes está definida em campos específicos do documento GDMO - detalhes nos ítens seguintes). Podemos até dizer, de uma maneira um pouco grosseira, que a árvore de inclusão se aproxima da realidade. Ela é dinâmica, ou seja, na medida em que os objetos vão sendo criados e deletados, eles aparecem e somem da árvore de inclusão.

Já a árvore de herança não tem esta característica dinâmica. Ela é criada para definir as características das classes e a estrutura de especialização delas e não muda, não importando quantas instâncias de cada classe existam no elemento gerenciado, e até mesmo não importando se existe alguma instância da classe. Por exemplo, pode não existir nenhuma instância da classe Placa de Comutação na minha central; por conseqüência, não existirá nenhuma Placa de Comutação na minha árvore de contenção (e também por conseqüência, não haverá nenhum Software de Comutação, pois uma placa de comutação contém um software de comutação, e se não existe a placa, não existirá o software). Mas na minha árvore de herança as classes Placa de Comutação e Software de Comutação existirão sempre.

A árvore de contenção também vai ser responsável pela formação do nome da instância do objeto gerenciado. O nome da instância é um DN (Distinguished Name), formado pela concatenação do RDN's (Relative Distinguished Name). Cada instância, quando criada, recebe um nome (id) para que possa ser identificada pelo protocolo e essa identificação se chama RDN. Para formar o nome completo da instância na árvore de contenção, ou seja, o DN, o processo é simplesmente concatenar os RDN's das classes superiores, começando pela mais alta.

Por exemplo, o DN do objeto Software de Comutação 2 é formado pelos RDN's de suas classes superiores, ou seja: Placa de Comutação 2, Bastidor e Central. Portanto, o DN do Software de Comutação 2 fica {1 2 3 4}. O Software de Comutação 1 ficaria com o DN={1 2 5 6}.

6.5. Guia para Definição de Objetos Gerenciados (GDMO)

6.5.1. Classes

O gabarito das classes é formado por:

<class-label> MANAGED OBJECT CLASS

DERIVED FROM <class-label>, <class-label>;

CHARACTERIZED BY <package-label>, <package-label>;

CONDITIONAL PACKAGES <package-label> PRESENT IF condition-definition, <package-label> PRESENT IF condition-definition ;

REGISTERED AS object-identifier ;

Obs:

• [xxxxxxx] - pode ou não aparecer;
• [xxxxxxx]* - pode aparecer zero ou mais vezes;
• <xxxxxx> - string que deve ser substituída em cada instância;
• Letras maiúsculas representam palavras chaves que devem estar presentes em cada instância da template, a menos que esteja dentro de [];

onde:

• DERIVED FROM indica a superclasse ou superclasses da qual esta classe é herdada;
• CHARACTERIZED BY permite que um ou mais "packages" sejam incluídos na definição da Classe de Objeto;
• CONDITIONAL PACKAGES permite que um ou mais "packages" condicionais sejam incluídos;

Exemplo de gabarito de classe:

classeExemplo MANAGED OBJECT CLASS

DERIVED FROM "CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992":top;

CHARACTERIZED BY pacoteExemplo1;

CONDITIONAL PACKAGES pacoteExemplo2 PRESENT IF "o recurso real suportar estes dados";

REGISTERED AS {joint-iso-ccitt ms(9) smi(3) part4(4) managedObjectClass(3) exampleClass(0)};

6.5.2. Pacote

O pacote é a coleção de atributos, notificações, operações e comportamento presentes no objeto. O pacote pode ser de dois tipos:

• condicionais: podem ou não estar presentes, de acordo com certas regras a serem seguidas pela instância;
• mandatórios: obrigatoriamente devem estar presentes em todas as instâncias da classe.

O gabarito de pacote é:

<pakage-label> PACKAGE

BEHAVIOR <behavior-definition-label>;

ATTRIBUTES <attribute-label> propertylist [,<parameter-label>*];

ATTRIBUTE GROUPS <group-label> <attribute-label>,

ACTIONS <action-label> <parameter-label>;

NOTIFICATIONS <notification-label> <parameter-label>;

REGISTERED AS object-identifier;

supporting productions

propertylist -> [REPLACE-WITH-DEFAULT] [DEFAULT VALUE value-specifier] [INITIAL VALUE value-specifier] [PERMITTED VALUES type-reference] [REQUIRED VALUES type-reference] [GET| REPLACE| GET-REPLACE] [ ADD| REMOVE| ADD-REMOVE]

onde:

• BEHAVIOUR permite mostrar a semântica do "package" através de texto não processável;
• ATTRIBUTES lista todos os atributos que fazem parte do "package" (associado a cada atributo existem zero ou mais parâmetros);
• ACTIONS e NOTIFICATIONS incluem, por referência, ações e notificações que são parte do "package";

As propriedades que podem ser especificadas são:

• REPLACE-WITH-DEFAULT: o atributo tem um valor default que pode ser atribuído por operação de gerência;
• DEFAULT VALUE: especifica que o valor default deve ser usado na criação do "package", caso nenhum outro valor seja fornecido;
• INITIAL VALUE: valor obrigatório inicial;
• PERMITTED VALUES: restrições nos valores de atributos, expressos em ASN.1;
• REQUIRED VALUES: especifica os valores que o atributo deve ser capaz de tomar;
• GET/REPLACE/GET-REPLACE: operações permissíveis nos atributos de valor simples;
• ADD/REMOVE/ADD-REMOVE: operações permissíveis nos atributos de conjunto de valores.

Exemplo de gabarito de pacote:

pacoteExemplo2 PACKAGE

BEHAVIOUR exemploBehaviourClasse;

ATTRIBUTES objectName GET, qOS-Error-Cause GET, qOS-Error-Counter PERMITTED VALUES AttributeModule.QOSCounterRange REQUIRED VALUES AttributeModule.QOSCounterRange GET;

ATTRIBUTE GROUPS qOS-Group;

NOTIFICATIONS erroProtocolo;

REGISTERED AS { joint-iso-ccitt ms(9) smi(3) part4(4) package(4) examplePack2(1) };

6.5.3. Atributos

Os atributos são as características reais do recurso contidas no objeto. Cada atributo representa uma propriedade do recurso que o objeto representa, como a identificação, as características operacionais, os estados correntes, o endereço, etc.

Os atributos possuem regras de acesso (leitura, escrita, leitura-escrita) e regras com as quais ele pode ser localizado através de filtro de pesquisa.

O gabarito do atributo é o seguinte:

<attribute-label> ATTRIBUTE

DERIVED FROM <attribute-label> /WITH ATTRIBUTE SYNTAX type-reference;

[MATCHES FOR qualifer [, qualifer]*;]

[BEHAVIOR <behavior-definition-label>[,<behavior-definition-label>]*;]

[PARAMETER <parameter-label> [,<parameter-label>]*;]

REGISTERED AS object-identifier;

supporting productions

qualifier: EQUALITY / ORDERING / SUBSTRINGS / SET - COMPARISON / SET - INTERSECTION

onde:

• DERIVED FROM indica que a definição do atributo deriva de outra definição existente;
• WITH ATTRIBUTE SYNTAX especifica o tipo de dado ASN.1;
• MATCHES FOR define os tipos de testes que podem ser aplicados para um valor de atributo (filtragem para operações de gerência);
• BEHAVIOUR descreve, em texto, o comportamento do atributo e não inclui semântica processável por computador;
• PARAMETER permite que a definição do parâmetro de erro seja associada com o comportamento do atributo

Os qualificadores são:

• EQUALITY: um valor de atributo pode ser comparado por igualdade a um dado valor;
• ORDERING: um valor de atributo pode ser comparado a um dado valor para determinar qual é o maior valor;
• SUBSTRINGS: um valor de atributo pode ser testado pela presença de um "substring";
• SET-COMPARISION: um atributo de conjunto de valores pode ser comparado a um dado conjunto de valores para determinar a relação de superconjunto e subconjunto;
• SET-INTERSECTION: um atributo de conjunto de valores pode ser comparado a um dado conjunto de valores para determinar se existe uma intersecção não nula.

Exemplo de gabarito de atributo:

objetcName ATTRIBUTE

WITH ATTRIBUTE SYNTAX AttributeModule.ObjectName;

MATCHES FOR EQUALITY;

REGISTERED AS {joint-iso-ccitt ms(9) smi(3) part4(4) attribute(7) objectName(0) };

6.5.4. Notificações

As notificações são os eventos enviados espontaneamente do objeto gerenciado para o gerente para relatar a ocorrência de alguma coisa. Devido ao fato da notificação ocorrer sem que haja a solicitação do gerente, ela é considerada uma mensagem assíncrona. As notificações podem ser transmitidas ao gerente ou armazenadas em logs.

O gabarito de notificação é o seguinte:

<notification-label> NOTIFICATION

[BEHAVIOR <behavior-definition-label>[,<behavior-definition-label>]*

[PARAMETERS <parameter-label> [,<parameter-label> ]*;]

[WITH INFORMATION SYNTAX type-reference [AND ATTRIBUTE IDS <field-name> <attribute-label> [,<field-name> <attribute-label> ]* ] ; ]

[WITH REPLY SYNTAX type-reference ; ]

REGISTERED AS object-identifier ;

onde:

• BEHAVIOUR define o comportamento da notificação, os dados que devem ser especificados com a notificação, os resultados que a notificação pode gerar e seus significados;
• PARAMETERS identifica a informação do evento ou parâmetros de resposta do evento ou falhas de processamento associados com o tipo de notificação;
• WITH INFORMATION SYNTAX identifica o tipo de dados ASN.1 que descreve a estrutura de informação da notificação que é transportada no protocolo de gerência;
• WITH REPLY SYNTAX identifica o tipo de dados ASN.1 que descreve a estrutura da informação de resposta da notificação que é transportada pelo protocolo de gerência;

6.5.5. Comportamento

Os objetos gerenciados exibem certas características comportamentais, incluindo como o objeto reage a operações desenvolvidas nele e as restrições a seu comportamento, sendo que todas as instâncias da mesma classe exibem o mesmo comportamento.

O comportamento define:

• a semântica dos atributos, operações e notificações;
• a resposta a operações de gerência invocadas sobre os objetos gerenciados;
• as circunstâncias sobre as quais as notificações serão emitidas;
• as dependências entre os valores de atributos particulares;
• os efeitos de relacionamento nos objetos gerenciados participantes.

exemploBehaviourClasse BEHAVIOUR

DEFINED AS

" Descrição do comportamento da classe de objetos gerenciados, incluindo como os atributos adquirem certos valores e o que estes significam, quais as circunstâncias ocasionam a geração de notificações, etc. ";

6.5.6. Name Bindings

A template de Name Binding nos permite definir diversas relações de nomeção para as classes de objetos gerenciados para que possamos localizá-los na árvore de inclusão. Esta template indica qual atributo será utilizado como nomeador, para compor o DN da instância.

<name-binding-label> NAME BINDING

SUBORDINATE OBJECT CLASS <class-label> [AND SUBCLASSES];

NAMED BY SUPERIOR OBJECT CLASS <class-label> [AND SUBCLASSES];

WITH ATTRIBUTE <attribute-label>;

[BEHAVIOUR <behaviour-definition-label> [, <behaviour-definition-label>*];]

[CREATE [<create-modifier> [, <create-modifier], [parameter-label>]*;]]

[DELETE [<delete-modifier>], [<parameter-label>]*;]

REGISTERED AS object-identifier

Onde:

Create-modifier: WITH-REFERENCE-OBJECT | WITH-AUTOMATIC-INSTANCE-NAMING

Delete-modifier: WITH-REFERENCE-OBJECT | WITH-AUTOMATIC-INSTANCE-NAMING

Exemplo de template de Name Binding:

ExemploNameBinding NAME BINDING

SUBORDINATE OBJECT CLASS classeExemplo;

NAMED BY SUPERIOR OBJECT CLASS "CCITT Rec. X.721 (1992) | ISSO/IEC 10165-2 : 1992":system;

WITH ATTRIBUTE objectName;

BEHAVIOUR behaviourInclusao;

CREATE WITH-AUTOMATIC-INSTANCE-NAMING parmErroCreate;

DELETE DELETES-CONTAINED-OBJECTS;

REGISTERED AS {joint-isso-ccitt ms(9) smi(3) part4(4) nameBinding(6) exemploNB(0)};

6.5.7. Ações

A template de ação nos permite definir o comportamento e a sintaxe associada com um tipo de ação em particular. O comportamento especificará a funcionalidade da ação em termos de seu efeito sobre a classe de objeto gerenciado.

<action-label> ACTION

[BEHAVIOUR <Behaviour-definition-label> [, Behaviour-definition-label>*];

[MODE CONFIRMED;]

[PARAMETERS <parameter-label> [, <parameter-label>*];]

[WITH INFORMATION SYNTAX type-reference;]

[WITH REPLY SYNTAX type-reference;]

REGISTERED AS object-identifier;

Exemplo:

Activate ACTION

BEHAVIOUR behaviourActivate

MODE CONFIRMED;

WITH REPLY SYNTAX ActionModule.RespostaActivate;

REGISTERED AS {joint-isso-ccitt ms(9) smi(3) part4(4) action(9) activate(1) };

6.5.8. Operações de Gerência

As operações de gerenciamento podem ser de dois tipos:

• operações orientadas a atributos;
• operações sobre objetos gerenciados como um todo.

6.5.8.1. Operações Orientadas a Atributos

As operações orientadas a atributos são:

• GET ATTRIBUTE VALUE: operação de leitura de valor de atributos, onde os atributos a serem lidos são especificados na operação;
• REPLACE ATTRIBUTE VALUE: esta operação altera os valores dos atributos especificados com os novos valores conhecidos;
• SET WITH DEFAULT VALUE: operação para substituir o valor de alguns dos atributos do objeto gerenciado pelo seu valor default, definido como parte da especificação da classe de objeto em questão;
• ADD MEMBER: aplicável a atributos cujos valores são conjuntos acessíveis para escrita. Para cada conjunto especificado de valores de atributo, esta operação substitui os valores de atributos existentes pelo conjunto união do conjunto existente com o conjunto especificado nesta operação;
• REMOVE MEMBER: aplica-se a atributos cujos valores são conjuntos acessíveis para escrita. Para cada conjunto especificado de valores de atributo, esta operação substitui o conjunto existente de valores de atributo pelo conjunto diferença entre o conjunto já existente e o conjunto especificado nesta operação.

6.5.8.2. Operações Orientadas a Objetos

Estas operações aplicam-se a objetos gerenciados como um todo e seus efeitos geralmente não se limitam a modificar os valores dos seus atributos. As operações são:

• CREATE: requisita a criação e iniciação de um objeto gerenciado. Designa valores a todos os atributos do objeto criado, baseado na definição da classe do objeto e nas informações fornecidas na própria operação;
• DELETE: requisita que o objeto gerenciado remova a si mesmo. Caso este objeto possua outros objetos contidos nele ou possua relação com outros objetos, o seu comportamento depende da definição da classe à qual pertence;
• ACTION: requer que o objeto gerenciado execute a ação especificada e indique o seu resultado. A ação e a informação opcional associada são parte da definição da classe do objeto gerenciado.

6.6. Notação de Sintaxe Abstrata (ASN.1)

Devido à complexidade dos dados a serem manipulados e a diferença de representação destes nas diversas máquinas existentes levaram a criação de uma forma de representação de dados mais eficiente. Desta forma, criou-se duas formas de representação:

• Representação Abstrata: refere-se aos tipos dos dados e é descrito como uma "linguagem", independente da plataforma utilizada
• Representação Concreta: refere-se ao preenchimento dos dados com os seus valores devidos, através da utilização de octetos ou bits.

A ASN.1, portanto, é uma notação para sintaxe abstrata de dados, utilizada para definir os tipos de dados manipulados. Ela é uma notação bem completa, permitindo se representar tipos de dados bastante complexos de uma forma relativamente simples. Para a representação concreta, utiliza-se a sintaxe BER (Basic Encoding Rules).

6.6.1. Tipos ASN.1

Os tipos ASN.1 podem ser divididos em dois tipos: primitivos e construtores.

Os tipos primitivos, como o próprio nome sugere, representa diretamente os tipos simples que se quer manipular, como por exemplo um inteiro, um boolean, etc.

Tipos primitivos ANS.1:

• Integer - números inteiros
• Boolean - falso ou verdadeiro
• Real - números reais
• Bit string - strings binários
• Octet string - string de octetos
• Enumerated - inteiros enumerados
• Null - nulo

6.6.1.1. Integer

O INTEGER é um tipo de dado que pode assumir como valor os inteiros utilizados para contagem.

Numero ::= INTEGER

tipo num Numero ::= 100 -- valor atribuído a uma variável num do tipo Numero

6.6.1.2. Enumerated

O tipo ENUMERATED é uma lista de valores numerados, onde se pode assumir um destes valores.

Cor ::= ENUMERATED { azul (0), amarelo (1), vermelho (2) }

carro Cor::= azul -- ou 0

6.6.1.3. Real

Uma variável do tipo REAL pode assumir qualquer valor real, especificado através de um conjunto de três valores inteiros: mantissa, base e expoente. A mantissa e o expoente podem assumir qualquer valor, enquanto a base está limitada aos valores 2 ou 10.

TranscendentalNumbers ::= REAL

number TranscendentalNumbers::={27182818, 10, -7} --{mantissa, base, expoente}

6.6.1.4. Bit String

O tipo BIT STRING define uma seqüência de zero ou mais bits, sem restrição de tamanho.

BitNumber ::= BIT STRING

bitValue BitNumber ::= '10010'B

O BIT STRING também pode ser utilizado para listas de bits nomeados:

Services ::= BIT STRING { bina (0), sigame (1), conferencia (2), despertador (3) }

meuServico Services::={bina, conferencia, despertador} -- ou '1011'B

6.6.1.5. Octet String

Define uma seqüência de zero ou mais octetos, sem delimitação de tamanho. Pode ser usado para representar caracteres ou dados orientados a byte (os tipos string estão relacionados com este tipo, e serão vistos mais à frente).

UserName ::= OCTET STRING

initial UserName ::= "anon" -- ou '616E6F6E'H

6.6.1.6. Null

O tipo NULL representa uma situação de ausência de informação. Sua aplicação fica evidente quando se fala dos tipos construtores.

Tipos Contrutores

Baseados nos tipos primitivos podemos construir novos tipos mais complexos (chamados construtores), de forma que a abrangência da sintaxe se torne mais flexível e poderosa.:

• SET - coleção de ítens
• SEQUENCE - grupo ordenado de valores
• SET OF - coleção de ítens do mesmo tipo
• SEQUENCE OF - vetor de ítens do mesmo tipo
• CHOICE - permite a escolha de um tipo entre vários possíveis

Exemplo de um módulo ANS.1:

AttributeModule {joint-isso-ccitt ms(9) smi(3) part4(4) asn1Module(2) attributes(0)}

DEFINITIONS ::= BEGIN

ObjectName ::= GraphicString

QOSErrorCause ::= ENUMERATED { tempoRespostaExcessivo (0), tamanhoFilaExcedido (1), larguraFaixaReduzida(2), taxaRetransmissaoExcessiva (3) }

QOSErrorCounter ::= INTEGER

QOSCounterRange ::= QOSErrorCounter {0 .. 4294967296} -- 32 bits

END