Viviane Cristina Dias
Proposta de um Framework Conceitual de Dados e Padrões de Análise para a
Definição de um Banco de Dados em Qualidade da Energia Elétrica
Dissertação apresentada ao Programa de Pós-Graduação
em Engenharia Elétrica, da Pontifícia Universidade
Católica de Minas Gerais, como requisito parcial para
obtenção do Grau de Mestre em Engenharia Elétrica.
Linha de Pesquisa: Inteligência Computacional e
Sistemas Distribuídos – ICSD
Orientador: Prof. Dr. Carlos Alberto Marques Pietrobon
Co-Orientador: Prof. Dr. Mário Fabiano Alves
Belo Horizonte
Pontifícia Universidade Católica de Minas Gerais
2004
II
“Feliz aquele que transfere o que sabe
e aprende o que ensina”
(Cora Coralina)
III
Agradecimentos
À Fundação Capes;
Ao Coordenador do Programa de Pós-Graduação em Engenharia Elétrica, Prof. Dr. Carlos
A . P. S. Martins .
Aos professores Dr. Carlos A. M. Pietrobon e Dr. Mário F. Alves, pelos sábios conselhos,
disponibilidade e dedicada orientação;
Ao Grupo de pesquisa Gerquali pela disponibilização dos dados, em especial ao Délio;
Aos professores do PPGEE, pela partilha do conhecimento;
Às amigas Juliana, Claudete e Viviane F. pelo companheirismo e incentivo nesta jornada;
À Isabel Sirqueira e Isabel Novais pelo atendimento cordial;
Ao Geraldo por seu amor, incentivo, paciência e compreensão;
Aos meus pais, Antonio e Geralda, pelo carinho, compreensão nos momentos de ausência e
pela formação que recebi;
Aos meus irmãos Nilton, Antonio e Elaine pela amizade;
A Deus, fonte de toda a vida e guia do melhor caminho.
IV
Resumo
A monitorização da Qualidade da Energia Elétrica associada a correta organização
e utilização da informação resultante, fornece meios para auxiliar no planejamento, na
operação e no projeto de sistemas de transmissão e distribuição de energia elétrica. A
grande quantidade de dados aquisitados em monitorizações de sistemas elétricos deve ser
armazenada em um banco de dados que possibilite uma diversidade de formas de
recuperação destes dados, a fim de inferir padrões de ocorrência de problemas de
Qualidade da Energia Elétrica. Este banco de dados deve ser bem estruturado e fácil de ser
projetado por engenheiros eletricistas. Este trabalho apresenta uma proposta do uso de um
Framework Conceitual e padrões de análise para QEE, aplicáveis as etapas de requisitos e
modelagem conceitual de um banco de dados para QEE visando facilitar o uso de técnicas
de orientação a objetos através do reuso de padrões.
V
Abstract
Power Quality monitoring associated with the correct storing an use of the resulting
information, provides a powerful way for planning, operating and designing transmission
and distribution power systems. The enormous quantity of data resulting from monitoring
should be stored in database designed for flexibility of data retrieval, such as to allow
inference into power quality problems occurrence patterns. This database should be well
structured and easy to be designed by power system engineer This work presents a
proposal of the use of a Framework Conceptual and analysis patterns for PQ, applicable to
the early stages of the database development (requirements and conceptual model). The
maim purpose is to facilitate the use of objects orientation techniques through the reuse of
patterns.
VI
Sumário
1
INTRODUÇÃO.................................................................................................................................... 13
1.1
1.2
1.3
1.4
2
MOTIVAÇÃO .................................................................................................................................. 13
OBJETIVOS .................................................................................................................................... 16
METODOLOGIA.............................................................................................................................. 17
ORGANIZAÇÃO DA DISSERTAÇÃO ................................................................................................. 18
REVISÃO DA LITERATURA ........................................................................................................... 20
2.1
A QUALIDADE DA ENERGIA ELÉTRICA.......................................................................................... 20
2.1.1
Distúrbios Eletromagnéticos ................................................................................................... 21
2.1.1.1
2.1.1.2
2.1.1.3
Transientes .................................................................................................................................... 23
Variações de Tensão ..................................................................................................................... 24
Harmônicos ................................................................................................................................... 25
2.1.2
Parâmetros de Referência para Análise da Qualidade da Energia Elétrica........................... 26
2.1.3
Sistema de Informação para Qualidade da Energia Elétrica.................................................. 27
2.2
INSTRUMENTOS DE REUTILIZAÇÃO ............................................................................................... 28
2.2.1
Reutilização de Especificações de Requisitos.......................................................................... 30
2.2.2
Padrões.................................................................................................................................... 31
2.2.3
Padrões de Projeto .................................................................................................................. 34
2.2.4
Padrões de Análise .................................................................................................................. 38
2.2.5
Framework .............................................................................................................................. 41
2.2.5.1
2.3
2.4
2.5
2.5.1
2.5.2
2.6
2.6.1
Framework x Padrões de Projeto................................................................................................... 47
QUALIDADE DE ENERGIA ELÉTRICA E APOIO COMPUTACIONAL ................................................... 49
UML - LINGUAGEM DE MODELAGEM UNIFICADA ........................................................................ 54
LINGUAGENS DE MARCAÇÃO ........................................................................................................ 60
Características da XML........................................................................................................... 61
XML como intercâmbio de Informações.................................................................................. 63
MODELO DE DADOS ...................................................................................................................... 64
Modelagem Conceitual de Banco de Dados............................................................................ 66
3
MODELAGEM CONCEITUAL DE DADOS PARA SISTEMAS DE INFORMAÇÃO DA
QUALIDADE DA ENERGIA ELÉTRICA................................................................................................. 68
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.3
3.4
4
REQUISITOS DE MODELAGEM CONCEITUAL PARA SIQEE............................................................. 69
PADRÕES DE ANÁLISE DE QEE ..................................................................................................... 71
Padrão Local de Monitorização.............................................................................................. 73
Padrão Equipamento de QEE ................................................................................................. 75
Padrão Ajuste dos Equipamentos de QEE .............................................................................. 76
Padrão Eventos em um Sistema Elétrico................................................................................. 77
Padrão Normas e Organizações.............................................................................................. 78
Padrão Ocorrências de Campo ............................................................................................... 79
METODOLOGIA DE DESENVOLVIMENTO DE FRAMEWORKS ........................................................... 80
FRAMEWORK QEE_FRAME ........................................................................................................... 84
AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE (ADS) ............................................... 89
4.1
4.2
4.3
4.4
TEORIA DO DOMÍNIO ..................................................................................................................... 89
ONTOLOGIA .................................................................................................................................. 91
ONTOLOGIA E BASE DE CONHECIMENTO....................................................................................... 93
AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE ORIENTADO A DOMÍNIO (ADSOD) .............. 94
5
AMBIENTE DE DEFINIÇÃO DE UM BANCO DE DADOS PARA QUALIDADE DE
ENERGIA ELÉTRICA................................................................................................................................. 96
5.1
5.2
5.3
6
MÓDULO GRÁFICO ........................................................................................................................ 98
MÓDULO DICIONÁRIO DE DADOS ............................................................................................... 105
MÓDULO GERAÇÃO AUTOMÁTICA .............................................................................................. 106
APLICAÇÃO: CASOS EXEMPLO................................................................................................. 108
6.1
A TEORIA DO DOMÍNIO ............................................................................................................... 108
6.1.1
Identificação do Propósito .................................................................................................... 108
VII
6.1.2
Definição ............................................................................................................................... 109
6.2
CASO 1- SISTEMA DE GERENCIAMENTO DA QUALIDADE DA ENERGIA ELÉTRICA. ...................... 110
6.2.1
Edição da Teoria do Domínio ............................................................................................... 110
6.2.2
Edição da Sub-teoria ............................................................................................................. 110
6.2.3
Edição de Conceitos .............................................................................................................. 111
6.2.4
Integração do Framework Conceitual com os Padrões de Análise....................................... 112
6.2.5
Conversão do Diagrama de Classes em DTD ....................................................................... 113
Temos então o arquivo .DTD gerado como pode ser visto no Apêndice C.......................................... 114
6.2.6
Mapeamento da DTD para um SGBD relacional.................................................................. 114
6.3
CASO 2- CARACTERIZAÇÃO DA SENSIBILIDADE DE PROCESSOS INDUSTRIAIS FRENTE A
AFUNDAMENTOS DE TENSÃO .................................................................................................................... 119
6.3.1
Edição da Teoria do Domínio ............................................................................................... 119
6.3.2
Edição da Sub-teoria ............................................................................................................. 120
6.3.3
Edição de Conceitos .............................................................................................................. 120
6.3.4
Integração do Framework Conceitual com os Padrões de Análise....................................... 121
6.3.5
Conversão do Diagrama de Classes em DTD ....................................................................... 122
6.3.6
Mapeamento da DTD para um SGBD relacional.................................................................. 122
7
CONCLUSÕES.................................................................................................................................. 123
7.1
7.2
CONTRIBUIÇÕES DA DISSERTAÇÃO .............................................................................................. 124
TRABALHOS FUTUROS ................................................................................................................ 125
8
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................. 127
9
APÊNDICES ...................................................................................................................................... 133
VIII
Lista de Figuras
Figura 2.1: Distúrbios de tensão típicos, idealizados [FER99]. .......................................... 22
Figura 2.2: Ilustra o diagrama de classes do padrão de projeto Composite [GAM95]........ 35
Figura 2.3: Diagrama de Classes do Padrão Local de Monitorização................................. 41
Figura 2.4: Aplicação desenvolvida totalmente [SIL00]..................................................... 44
Figura 2.5: Aplicação desenvolvida reutilizando classes de biblioteca [SIL00]................. 44
Figura 2.6: Aplicação desenvolvida reutilizando um Framework [SIL00]......................... 44
Figura 2.7: Framework Caixa Branca. ................................................................................ 47
Figura 2.8: Framework Caixa Preta..................................................................................... 47
Figura 2.9: Notação gráfica do diagrama de classes UML. ................................................ 58
Figura 2.10: Código de uma página em HTML. ................................................................. 60
Figura 2.11: Código de uma página em XML..................................................................... 61
Figura 2.12: Estrutura de disponibilização de dados na Web.............................................. 64
Figura 3.1: Arquitetura de um Sistema de Informação para Qualidade da Energia Elétrica.
..................................................................................................................................... 70
Figura 3.2: Processo de captura e aplicação de padrões...................................................... 72
Figura 3.3: Processo de captura e aplicação de padrões de QEE. ....................................... 73
Figura 3.4: Diagrama de Classes do Padrão Local de Monitorização................................. 74
Figura 3.5: Diagrama de Classes do Padrão Equipamentos de QEE .................................. 75
Figura 3.6: Diagrama de Classes do Equipamento de QEE. ............................................... 76
Figura 3.7: Diagrama de Classes do Padrão Eventos em um Sistema Elétrico................... 77
Figura 3.8: Diagrama de Classes do Padrão Normas e Organizações................................. 79
Figura 3.9: Diagrama de Classes do Padrão Ocorrências de Campo. ................................. 80
Figura 3.10: As Etapas do Projeto Dirigido por Exemplo para o Desenvolvimento de um
Framework................................................................................................................... 81
Figura 3.11: Etapas do Projeto Dirigido por Hot Spot para o desenvolvimento de um
Framework. ................................................................................................................. 82
Figura 3.12: Ciclo de vida de Framewoks [SIL00]. ............................................................ 85
IX
Figura 3.13: Ciclo de vida do Framework QEE-Frame. ..................................................... 86
Figura 3.14: Diagrama de classes do QEE_Frame. ............................................................. 86
Figura 5.1: Arquitetura do Ambiente de Definição de um Banco de Dados para Qualidade
de Energia Elétrica. ..................................................................................................... 98
Figura 5.2: Modelo para edição da Teoria do Domínio. ................................................... 100
Figura 5.3: Inclusão da Teoria do Domínio....................................................................... 100
Figura 5.4: Inclusão da subteoria....................................................................................... 101
Figura 5.5: Inserir Padrão de Análise. ............................................................................... 101
Figura 5.6: Inserir Referências Bibliográficas................................................................... 102
Figura 5.7: Inserir Conceito............................................................................................... 102
Figura 5.8: Inserir Associação entre Teoria do Domínio e Sub-teoria.............................. 103
Figura 5.9: Inserir Associação entre Sub-teoria e Conceito. ............................................. 103
Figura 5.10: Inserir Associação entre Subteoria e Padrões de Análise. ............................ 104
Figura 5.11:Inserir O Framework Conceitual de acordo com a Teoria do Domínio......... 104
Figura 5.12: Visualização das Subteorias e a relação com os Padrões de Análise............ 105
Figura 5.13: Demonstrativo do uso da ferramenta Rational Rose para Conversão de Dados.
................................................................................................................................... 106
Figura 6.1: Integração do Framework Conceitual – QEE_Frame e Padrões de Análise para
o Caso 1. .................................................................................................................... 113
Figura 6.2: Interface para definição da Linguagem de conversão do diagrama................ 114
Figura 6.3:Interface para geração do arquivo de dados no formato DTD......................... 114
Figura 6.4: Visualização da ferramenta XMLSPY............................................................ 115
Figura 6.5:Inclusão dos arquivos gerados. ........................................................................ 115
Figura 6.6:Conversão DTD/Shema. .................................................................................. 116
Figura 6.7:Demonstrativo das classes mapeadas............................................................... 116
Figura 6.8:Interface para alterações de tipos de dados...................................................... 117
Figura 6.9:Demonstrativo das tabelas que serão criadas no Microsoft Access................. 117
Figura 6.10: Demonstrativo do Script em SQL................................................................. 118
Figura 6.11:Seleção o SGBD que será utilizado. .............................................................. 118
X
Figura 6.12:Tabelas criadas no Microsoft Access............................................................. 119
Figura 6.13 : Integração do Framework Conceitual – QEE_Frame e Padrões de Análise
para o Caso 2. ............................................................................................................ 122
Figura 9.1: Seleção da Teoria do Domínio........................................................................ 145
Figura 9.2: Seleção da Subteoria. ...................................................................................... 145
Figura 9.3: Interface para definição da Linguagem XML - DTD ..................................... 147
Figura 9.4: Geração do documento .DTD ......................................................................... 147
Figura 9.5: Demonstrativo da Criação do Projeto e Inclusão do Arquivo .DTD .............. 151
Figura 9.6: Demonstrativo do resultado da conversão para DTD/Shema. ........................ 152
Figura 9.7: Demonstrativo do ajuste nos tipos dos dados. ................................................ 152
Figura 9.8: Interface para a escolha do SGBD utilizado. .................................................. 153
Figura 9.9: Definição das Chaves Primárias. .................................................................... 153
Figura 9.10: Visualização das Tabelas que serão Criadas................................................. 153
Figura 9.11: Banco de Dados Criado com suas respectivas Tabelas................................. 154
XI
Siglas
ADSOD
- Ambientes de Desenvolvimento de Software Orientados a Domínio
ADS
- Ambientes de Desenvolvimento de Software
ANEEL
- Agência Nacional de Energia Elétrica
ANSI
- American National Standars Institure
CASE
- Computer-aided Software Engineering
CBEMA
- Computer and Business Equipment Manufacturers Association
CICRE
- Conference Internatioanledes Gands Réseux Eletriques à Haute Tesion
HTML
- Hypertext Markup Language
IEC
- International Eletrotechnical Commission
IEEE
- Institute of Electrical and Electronics Engineers
ITI
- Information Technology Industry Council
ONS
- Operador Nacional do Sistema Elétrico
OOAD
- Object Oriented Analysis and Design
QEE
- Qualidade da Energia Elétrica
SGBD
- Sistema Gerenciador de Banco de Dados
SGML
- Standard Generalized Markup Language
SGQEE
- Sistema de Gerenciamento da Qualidade da Energia Elétrica
SIQEE
- Sistema de Informação da Qualidade da Energia Elétrica
UML
- Unified Modeling Language
XML
- Extensible Markup Language
XII
1
Introdução
Este capítulo introduz o trabalho proposto, apresentado a motivação, os objetivos, e
a metodologia utilizada, bem como uma descrição da forma como essa dissertação está
organizada.
1.1
Motivação
Sistemas de Informação para Qualidade da Energia Elétrica (SIQEE) são sistemas
computacionais que permitem a captura, armazenamento, manipulação, recuperação,
análise e apresentação dos dados relativos a Qualidade da Energia Elétrica (QEE). Esses
dados são constituídos por informações sobre os locais de monitorização, os fenômenos
eletromagnéticos monitorados, valores de referência (curvas, limites de norma, etc),
parâmetros de ajuste dos equipamentos de medição, dentre outros.
Os SIQEE manipulam uma grande quantidade de Informações, exigindo que se
trabalhe com banco de dados bem estruturados, moldados para atender as especificidades
impostas pelas características dos fenômenos envolvidos, e pelos objetivos dos resultados a
serem alcançados, de forma a possibilitar uma análise eficiente sobre a qualidade da
energia elétrica.
Em [ALV00] podemos verificar alguns objetivos que motivam pesquisas de
qualidade da energia elétrica:
•
Observância de limites impostos por legislação específica;
•
Obtenção de informações estatísticas para fins diversos;
•
Monitorização do sistema elétrico, objetivando a garantia da qualidade da
energia elétrica e o diagnóstico de falhas;
•
Monitorização dos sistemas elétricos industriais, objetivando diagnósticos e a
garantia de operação de equipamentos dentro de limite especificados pelos seus
fabricantes.
13
O gerenciamento da informação sobre a QEE exige a utilização de ferramentas
computacionais apropriadas como por exemplo o uso de um SGBD [AGO00], [DIA01],
[ALV00], [NET01], [FER01], [MED03], entre outros. Dependendo do número de locais de
monitorização, do período de monitoramento e do tipo de fenômeno eletromagnético
monitorado, a monitorização da qualidade da energia elétrica pode gerar gigabytes de
dados [DAB95]. Considerando estas características e as necessidades de tratamento da
informação, a adoção de um SGBD1 em muitos casos se faz necessário, como pode ser
visto em [DAB95], [FER99], [VIV01], [SAN02], [CRU03], [MED03], [ROM03].
No entanto, técnicas de projeto de banco de dados que são usados com sucesso em
aplicações de outros domínios, não têm sido adequadamente empregadas pela comunidade
de projetistas de aplicações de Qualidade da Energia Elétrica. Isso é decorrente de alguns
fatores, os quais podemos citar:
•
as aplicações de SIQEE são projetadas e desenvolvidas, muitas vezes, pelos
próprios usuários, os quais, normalmente, não possuem formação em
computação. Em geral esses profissionais não se preocupam com a modelagem
conceitual do banco de dados a ser utilizado pela sua aplicação, ou utilizam
alguma ferramenta que já disponibiliza um modelo para o armazenamento de
dados, que muitas vezes é ineficiente ao objetivo projetado pelo usuário;
•
Inexperiência por parte desses projetistas que lidam com QEE, em relação ao
uso de metodologias de desenvolvimento de sistemas.
•
Essa inexperiência tem resultado em alguns casos na construção de sistemas
com limitações de uso como: redundância de dados, inconsistência de dados,
etc.
Atualmente, as aplicações de SIQEE estão sendo desenvolvidas, em sua grande
maioria, pelas concessionárias, que têm grande interesse comercial neste tipo de sistema, e
pelas comunidades acadêmicas, sendo em alguns casos através de parceria entre essas
instituições.
Apesar da relevância do assunto, constata-se que existem poucos trabalhos
relacionados a projeto de banco de dados para QEE. Atualmente, quem deseja projetar um
1
Sistema Gerenciador de Banco de Dados
14
SIQEE que use um SGBD começará do zero, tendo que passar por todas as fases do
projeto de sistemas, o que demanda tempo do projetista e um alto conhecimento relativo
aos fenômenos que caracterizam a QEE e, conseqüentemente, aos dados envolvidos.
Neste sentido, os especialistas têm procurado na Engenharia de Software novos
paradigmas e ferramentas de desenvolvimento de software. O incremento nos custos de
desenvolvimento e manutenção, o aumento da demanda por informatização na sociedade e
a maior complexidade das novas aplicações têm gerado desafios no processo de
desenvolvimento de sistemas de informação. Os métodos clássicos para o desenvolvimento
de software não têm sido bem sucedidos em apoiar esse novo paradigma de
desenvolvimento. Portanto a orientação a objetos tem surgido como um poderoso
instrumento para o desenvolvimento de sistemas, principalmente em relação ao conceito de
reutilização.
Existem algumas propostas para possibilitar a reutilização aceitas na área de
orientação a objetos, dentre elas podemos citar o uso de padrões e Frameworks para
domínios específicos que poderiam ser instanciados para produzir novos produtos de
domínio. A reutilização de software tem sido considerada para diminuir os custos de
desenvolvimento e manutenção bem como gerar produtos de melhor qualidade, por estar
fazendo uso de um software já desenvolvido, testado e validado.
Em Engenharia Elétrica no que diz respeito a SIQEE, são pouco explorados os
benefícios da orientação objeto, bem como o reuso. Por outro lado essa técnica mostra-se
interessante visto que estaremos reutilizando a experiência adquirida por outros projetistas,
possibilitando desta forma iniciar um SIQEE baseado em projetos anteriores. Usando as
técnicas propostas pela Engenharia de Software durante a fase de análise, poderemos
definir requisitos para um SIQEE bem como a modelagem conceitual dos dados para este
sistema.
Uma forma de prover o reuso de análise e projeto para banco de dados para QEE é
definir um meio de disponibilização dos dados. Como os usuários que lidam com QEE
estão dispersos em lugares geograficamente distantes a disponibilização destes dados na
Web é um meio interessante, uma vez que eles poderão tratar os dados e adequá-los a seus
projetos específicos de banco de dados para QEE. Para facilitar essa troca de informações
15
na Web pode-se fazer o uso da XML (Extensible Markup Language), que atualmente está
sendo considerada como um padrão de transferência de dados via Web.
1.2
Objetivos
O objetivo principal desta dissertação é propor um Framework Conceitual de
Dados para Sistemas de Informação para Qualidade da Energia Elétrica (SIQEE).
Dentre os objetivos específicos podemos citar:
•
definir padrões de análise, que permitam aos projetistas de um determinado
domínio de aplicação modelar fenômenos de Qualidade de Energia Elétrica e
seus relacionamentos.
•
Disponibilização de dados de projeto de banco de dados na Web em um
formato padrão(XML) de forma que possam ser mapeados para diversos
fornecedores de banco de dados;
•
Definir uma arquitetura para um ambiente de definição de um banco de dados
para QEE que facilite o trabalho de pessoas experientes e não experientes no
desenvolvimento de banco de dados.
Uma das características desta pesquisa é a busca por uma solução que possa ser
utilizada, não só por especialistas em projetos computacionais mas, pelos próprios usuários
de SIQEE. Este é o papel do ambiente ADEBDQEE, onde faremos o uso de técnicas de
engenharia de software, associada ao conhecimento e correta conceituação das questões
envolvendo a qualidade da energia elétrica, a fim de atender a requisitos de eficiência e
qualidade em ambas as áreas.
Como o objetivo principal deste trabalho é propor um Framework Conceitual de
Dados para SIQEE, não iremos tratar da fase de pós-processamento de dados, uma vez que
essa fase pode ser implementada de acordo com as necessidades específicas de cada
sistema para QEE.
16
1.3
Metodologia
A metodologia desse trabalho consistiu em um estudo bibliográfico, seguido da
elaboração de uma proposta de um Framework Conceitual de Dados e Padrões de Análise
para a definição de um banco de dados para QEE descritos em UML.
Inicialmente, o trabalho envolveu um levantamento bibliográfico em artigos de
instituições,
publicações
especializadas,
documentações
técnicas
e
normas
ou
recomendações relativas ao gerenciamento da qualidade da energia elétrica, bem como a
utilização de banco de dados.
A seguir, foi necessário o levantamento bibliográfico sobre Frameworks, Padrões
de Projeto e Análise na literatura existente sobre Engenharia de Software. Esse
levantamento foi importante para caracterizar os Frameworks e Padrões de Análise como
instrumentos apropriados à reutilização.
A terceira etapa consistiu em um levantamento bibliográfico indicando os aspectos
relacionados a Engenharia Elétrica, mais especificamente a QEE e a Ciência de
Computação, considerando a Engenharia de Software. Esse levantamento foi importante
para caracterizar a existência a computação, apoiando as atividades ligadas a QEE, dentre
esses aspectos foi observado a utilização de técnicas de reuso.
A seguir, a pesquisa bibliográfica se concentrou no estudo da linguagem UML.
Para tanto, utilizou-se principalmente o material da OMG (Object Management Group) e a
literatura produzida pelos três criadores da UML (Booch, Jacobson e Rumbaugh). Como a
primeira etapa destacou-se o uso de uma técnica de orientação a objetos (Framework e
Padrões de Análise), essa etapa enfatizou uma linguagem de modelagem orientada a
objetos (UML) que serviu como apoio a essas técnicas.
A próxima etapa, preocupou-se em integrar o Framework Conceitual e os Padrões
de Análise identificados. Como resultado produziu-se um diagrama de classes segundo a
UML que representa o Sistema em questão.
17
A próxima etapa consistiu na preocupação da disponibilização dos dados na Web, a
fim de prover o intercâmbio de informações entre usuários interessados em projeto de
banco de dados para QEE. Neste caso foi necessária a escolha de uma linguagem que
melhor representasse o projeto de um banco de dados, o qual escolhemos XML.
Após a definição da linguagem para intercâmbio de dados foi feito o mapeamento
do diagrama de classes gerado do sistema para DTD. Estando o diagrama representado
desta forma, acontece a conversão do DTD para um SGBD específico de acordo com as
necessidades do usuário.
Finalmente para fins de verificação experimental, é proposto o estudo de dois
sistemas relacionados a QEE. A parte da inclusão da Teoria do Domínio foi programado
considerando os requisitos necessários para um sistema de QEE, o mapeamento do
diagrama de classes para DTD foi utilizada a própria ferramenta de modelagem ( Rational
Rose), e a conversão da DTD para um banco de dados relacional foi usada a ferramenta
XMLSPY 2004.
A última etapa consistiu na compilação do material produzido, na confecção final e
revisão da dissertação.
1.4
Organização da Dissertação
Essa dissertação está organizada em sete capítulos. O segundo capítulo abrange a
revisão da literatura, destacando-se a conceituação de Frameworks, Pradrões de Projeto e
Análise. Também é feita a apresentação das linguagens de marcação, destacando-se a
XML com intercâmbio de informações na Web.
No capítulo 3 é apresentado a modelagem conceitual de dados para sistemas de
informação para qualidade da energia elétrica. São definidos os requisitos de modelagem, e
a definição dos padrões de análise específicos para QEE. Também é apresentada a
metodologia de desenvolvimento de Frameworks, sendo ainda neste capítulo apresentada a
proposta do Framework específica para QEE (QEE_Frame).
18
No capítulo 4 é apresentada a idéia dos Ambientes de Desenvolvimento de
Software, que são amplamente utilizados para edição da Teoria do Domínio. Esses
ambientes possuem características semelhantes ao ambiente (ADEBDQEE) proposto pelo
trabalho.
No capítulo 5, utilizando as definições anteriores, é proposto um ambiente de apoio
a definição de um banco de dados para QEE, utilizando os conceitos de reuso através de
Frameworks e padrões de análise, e a definição da Teoria do Domínio.
No capítulo 6 é proposto à verificação experimental através de dois casos exemplo
relacionados a qualidade da energia elétrica, utilizando os conceitos de Teoria do Domínio,
Frameworks e Padrões de Análise.
No capítulo 7 são apresentas as conclusões dessa dissertação, suas contribuições e
propostas de trabalhos futuros.
No Apêndice – A é apresentado a documentação do projeto do banco de dados usado
no Ambiente de Definição de um Banco de Dados para QEE.
No Apêndice – B é apresentado as interfaces adicionais que compõe o Ambiente de
Definição de um Banco de Dados para QEE.
No Apêndice – C é apresentado o arquivo .DTD para o Caso exemplo: Sistema de
Gerenciamento da Qualidade da Energia Elétrica.
No Apêndice – D é apresentado a conversão do diagrama de classes para DTD para o
Caso exemplo : Caracterização da Sensibilidade de Processos Industriais frente a
Afundamentos de Tensão.
No Apêndice – E é apresentado o mapeamento da DTD para um SGBD relacional
para o Caso exemplo : Caracterização da Sensibilidade de Processos Industriais frente a
Afundamentos de Tensão.
19
2
2.1
Revisão da Literatura
A Qualidade da Energia Elétrica
A energia elétrica é considerada como um bem básico para a integração do ser
humano ao desenvolvimento. A economia de qualquer região não pode se desenvolver
completamente se não possuir fonte de energia garantida e de custo aceitável. O acesso à
energia elétrica é a porta de acesso aos serviços essenciais e ao aumento da qualidade de
vida [ALD01].
Analisando-se o sistema de energia elétrica como um todo, desde a geração até ao
consumidor, verifica-se o processo está sujeito a diversos fatores que podem afetar sua
qualidade. Dentre estes fatores, destacam-se as falhas provocadas por condições climáticas
(descarga atmosférica, vento, inundações, etc.). A própria operação normal do sistema gera
interferências de natureza elétrica como um subproduto capaz de degradar a energia
elétrica.
Conceituar Qualidade da Energia Elétrica é uma tarefa abrangente, pois o termo
engloba aspectos bem diversos, como a tecnologia usada, a satisfação dos clientes, custo
do produto, etc. Podemos dizer que o conceito de qualidade de energia elétrica está
relacionado a um conjunto de alterações que podem ocorrer no sistema elétrico.
A Qualidade da Energia Elétrica pode ser definida como a ausência relativa de
variações de tenção provocadas pelo sistema da concessionária, particularmente a ausência
de desligamentos, flutuações de tensão, transientes e harmônicos, medidos no ponto de
entrega de energia. Esta é uma definição vista sob o enfoque da identificação de qual é o
nível de qualidade de energia fornecida pela concessionária [FERN99].
Do ponto de vista do consumidor, a qualidade da energia elétrica pode ser definida
como sendo a ausência de variações manifestadas na tensão, corrente ou freqüência que
resultem em falhas ou má operação de seus equipamentos [DUG96].
20
Segundo [ALD01] o conceito de qualidade na energia elétrica significa a busca por
desenvolvimento de meios para erradicar ou minimizar problemas em dispositivos
alimentados por fontes de energia.
Distúrbios de energia ocorrem no sistema elétrico de potência desde o início de seu
funcionamento. Porém, ao longo dos anos, as cargas passaram a ser mais sensíveis a estes
distúrbios e, conseqüentemente a exigir uma energia elétrica de maior qualidade.
Logo, diante de um mercado globalizado crescentemente competitivo, a qualidade
da energia elétrica passa a ser de interesse tanto para as concessionárias quanto para os
consumidores. Uma boa base de informação sobre qualidade da energia elétrica permite às
concessionárias prover aos consumidores um atendimento pré-ativo, proporcionando uma
nova oportunidade de negócio, além de subsidiar a discussão das questões contratuais de
natureza técnica, as quais tendem a ganhar especial atenção nessa nova estruturação do
setor elétrico.
O IEEE ( Institute of Electrical and Electronics Engineers), vem através do comitê
(IEE SCC22), juntamente com outras entidades internacionais (IEC – International
Eletrotechnical Commission, CICRE – Conference Internatioanledes Gands Réseux
Eletriques à Haute Tesion), coordenando normalizações junto à chamada comunidade de
qualidade de energia elétrica [DUG96]. A terminologia, bem como a classificação,
basicamente definida pela amplitude e duração dos fenômenos eletromagnéticos são
apresentadas em [IEEE95]. A seguir serão apresentados os distúrbios eletromagnéticos que
serão considerados neste trabalho.
2.1.1
Distúrbios Eletromagnéticos
Existem diversas categorias de fenômenos eletromagnéticos descritos segundo a
recomendação do IEEE, que pode ser visto em [IEEE95]. Neste trabalho estaremos
tratando três categorias: transientes, variações de tensão e os harmônicos. Segundo
[FER99] o estudo dessas categorias abrange uma grande parte dos problemas de qualidade
da energia elétrica (Figura 2.1).
21
Figura 2.1: Distúrbios de tensão típicos, idealizados [FER99].
Segundo a classificação do IEEE [IEEE95], as variações de tensão e os
componentes harmônicos são fenômenos conduzidos de baixa freqüência, os transientes
impulsivos são fenômenos irradiados de alta freqüência e os transientes oscilatórios são
fenômenos conduzidos de alta freqüência.
A ocorrência de distúrbios eletromagnéticos está relacionada a uma série de fatores
identificados da operação normal de determinadas cargas ou dispositivos em um sistema
elétrico ou da ocorrência de fenômenos naturais que afetam o sistema elétrico, como
demonstrado na tabela a seguir.
22
Tabela - Principais Causas dos Fenômenos Eletromagnéticos Conforme Recomendação IEE
1159 - 1995
Categorias
Principais Causas
Transientes
Impulsivos
Descargas atmosféricas.
Oscilatórios
Energização de banco de capacitores.
Variações de Curta Duração
Afundamentos de Tensão
Faltas, chaveamento de cargas pesadas, partida de grandes motores.
Salto de Tensão
Faltas - Curto circuito fase-terra provocando elevação na fase sem
falta.
Interrupção
Faltas, falhas em equipamentos, disfunção de controle.
Variação de Longa Duração
Interrupção Sustentada
Falhas de natureza permanente e que necessitam de intervenção
manual para sua restauração.
Subtensões
Ligação de cargas, desligamento de banco de capacitores.
Sobretensões
Desligamento de cargas, anomalias em banco de capacitores.
Distorção de Forma de Onda
Nível de CC
Distúrbios geomagnéticos, retificação de meia onda.
Harmônicas
Características não lineares de cargas e dispositivos.
Interharmônicas
Conversores estáticos de freqüência, ciclo conversores, motores de
indução e dispositivos a arco.
Cortes
Operação normal de dispositivos de eletrônica de potência.
Ruído
Dispositivos eletrônicos, circuitos de controle, equipamentos a arco,
retificadores de estado sólido, fontes chaveadas.
Flutuações de Tensão
Fornos a arco.
Variações de Freqüência
Saída de grande bloco de cargas ou perda de um grande gerador.
2.1.1.1 Transientes
Os transientes são classificados como impulsivos ou oscilatórios. Transientes
impulsivos são repentinas variações, unidirecionais em polaridade, nas condições de
regime permanente de tensão, corrente, ou ambas. Eles são caracterizados por seus tempos
de subida e decaimento, pelo conteúdo espectral e pela máxima amplitude alcançada, e são
classificadas em três categorias de acordo com seu tempo de subida. Transientes
23
impulsivos podem excitar circuitos ressonantes do sistema elétrico produzindo os
transientes oscilatórios, que consistem em tensões ou correntes que têm polaridade de seus
valores instantâneos mudada rapidamente. Estes são caracterizados pelo conteúdo espectral
de sua freqüência predominante, e pela duração da oscilação. Os transientes oscilatórios
ocorrem, também, devido a operações de comutação e chaveamento de circuitos elétricos
[FER99].
2.1.1.2 Variações de Tensão
Variações de tensão são alterações no valor médio quadrático de uma tensão. Estas
variações são classificadas conforme sua duração e amplitude. Elas são divididas em
variações de curta duração e variações de longa duração [IEEE95] [ONS00].
a)Variações de Tensão de Curta Duração
Entende-se por Variação de Tensão de Curta Duração um desvio significativo da
amplitude da tensão por curto intervalo de tempo. A amplitude da Variação de Tensão de
Curta Duração é definida pelo valor extremo do valor eficaz (média quadrática) da tensão
em relação à tensão de referência do sistema no ponto considerado, enquanto perdurar o
evento[ONS00].
A duração da Variação de Tensão de Curta Duração é definida pelo intervalo de
tempo decorrido entre o instante em que o valor eficaz da tensão em relação à tensão de
referência do sistema no ponto considerado ultrapassa determinado limite e o instante em
que a mesma variável volta a cruzar este limite [ONS00]. A partir da duração e amplitude,
as Variações de Tensão de Curta Duração são classificadas como descrito na tabela a
seguir:
24
Tabela – Denominação das Variações de Tensão de Curta Duração
Classificação
Variação
Momentânea de
Tensão
Denominação
Duração da Variação
Interrupção
Momentânea de
Tensão
Afundamento
Momentâneo de
Tensão
Inferior ou igual a
três segundos
Elevação
Momentânea de
Tensão
Interrupção de
Tensão
Variação
Temporária de
Tensão
Afundamento
Temporário de
Tensão
Elevação
Temporária de
Tensão
Superior ou igual a
um ciclo e inferior
ou igual a três
segundos
Superior ou igual a
um ciclo e inferior
ou igual a três
segundos
Superior a três
segundos e inferior
ou igual a um
minuto
Superior a três
segundos e inferior
ou igual a um
minuto
Superior a três
segundos e inferior
ou igual a um
minuto
Amplitude da tensão
(Valor Eficaz) em
relação à tensão
nominal
Inferior a 0,1 pu
Superior ou igual a
0,1 e inferior a 0,9
pu
Superior a 1,1 pu
Inferior a 0,1 pu
Superior ou igual a
0,1 e inferior a 0,9
pu
Superior a 1,1 pu
2.1.1.3 Harmônicos
Harmônicos são correntes ou tensões senoidais de freqüências múltiplas da
freqüência que o sistema é designado a operar. Os componentes harmônicos, combinados
com a tensão ou correntes fundamentais, produzem alterações na forma de onda. A
distorção harmônica existe devido a características não lineares de dispositivos e cargas do
sistema elétrico. A distorção de tensão resulta da queda de tensão provocada pela passagem
de corrente pela impedância do sistema [FER99].
O indicador para avaliar o desempenho global quanto a harmônicos nos
barramentos da Rede Básica corresponde à distorção de tensão harmônica. Entende-se por
Distorção de Tensão Harmônica Total (DTHT) a raiz quadrada do somatório quadrático
25
das tensões harmônicas de ordens 2 a 50. Esse conceito procura quantificar o conteúdo
harmônico total existente em um determinado barramento [ONS00].
2.1.2
Parâmetros de Referência para Análise da Qualidade da Energia Elétrica
A análise da informação da qualidade da energia elétrica, monitorada durante um
determinado período de tempo, deve ser feita por comparações, seja com valores
normalizados, valores contratuais, ou mesmo com informações auferidas em outras
monitorizações.
Entidades nacionais e internacionais como ANEEL/ONS, IEEE, ANSI e IEC estão
envolvidas na emissão de normas aplicáveis à qualidade de energia elétrica, produzindo
documentos que são mundialmente utilizados como referência [RIB98]. A seguir é
apresentado uma lista de normas e entidades:
•
EN50160:
é
uma
nova
norma
que
cobre
flicker,
interharmônicas,
desvios/variações de tensão e muito mais.
•
ONS - Padrões de Desempenho da Rede Básica – Submódulo 2.2,
documento aprovado pela resolução da ANEEL n° 79/02, de 24/12/2002: tem
como objetivo definir os padrões de desempenho da Rede Básica do sistema
elétrico brasileiro.
•
IEC 61000-4-15: é uma norma de medição de flicker que inclui especificações
para medidores.
•
IEC 61000-4-7: descreve uma técnica de medição padrão para harmônicas.
•
IEEE 519 (1992): é uma prática recomendada pela IEEE, utilizada
principalmente por concessionárias de energia nos EUA. Descreve níveis
aceitáveis de harmônicas para o ponto de entrega de energia pela
concessionária.
•
IEEE 1159 (1995): é uma prática recomendada pela IEE para monitoração e
interpretação apropriada dos fenômenos que causam problemas de qualidade de
energia.
•
CBEMA: Computer and Business Equipament Manufacturers Association. A
CBEMA virou ITI em 1994. A curva CBEMA define os níveis de
26
suportabilidade
de
equipamentos
(originalmente
desenvolvida
para
copmputadores tipo “main-frame”), em função da magnitude da tensão e da
duração do distúrbio.
•
ITI: Information Technology Industry Council. Grupo que trabalha para
defender os interesses da indústria de informática. A curva ITIC de
suportabilidade para equipamentos da área coberta pela tecnologia da
informação, substituiu a curva CBEMA.
2.1.3
Sistema de Informação para Qualidade da Energia Elétrica
Segundo [TON03] os sistemas de informação podem ser considerados como um
conjunto de elementos interdependentes, ou um todo organizado, ou partes que interagem
formando um todo unitário e complexo. Ainda pode-se dizer que sistemas de informação
são subsistemas das organizações e são agentes de otimização dos processos da empresa.
Logo sistemas de informação na sua grande maioria provê informações no sentido de
servir como apoio a tomada de decisões ou até mesmo tomar decisões. Para [REZ02] um
sistema de informação pode ser definido como o processo de transformação de dados em
informações que são utilizadas na estrutura decisória da empresa e que proporcionam a
sustentação administrativa visando à otimização dos resultados esperados.
Dessa forma, os sistemas de informação devem ser analisados e/ou desenvolvidos
dentro da perspectiva sociotécnica, em que tecnologia e organização devem ser ajustadas
entre si até que se obtenha uma harmonização perfeita entre os dois domínios, gerando um
terceiro estado organizacional conjunto [REZ02].
Em [PPGEE00] é apresentado um projeto que propõe um Sistema de
Gerenciamento da Qualidade da Energia Elétrica (SGQEE), que consiste basicamente, de
um sistema de monitoramento e transmissão remota de informações relativas a QEE,
associado a um banco de dados relacional, apoiado por um conjunto de programas
complementares, que permite o pré e pós-processamento de dados, bem como o cálculo
estocástico de afundamentos de tensão e a análise da informação com base em técnicas de
Inteligência Artificial (IA).
27
O sistema apresentado em [PPGEE00] propõe um sistema considerando objetivos
específicos. Por outro lado, podemos definir um SGQEE de forma mais abrangente como
um Sistema Informação para Qualidade da Energia Elétrica (SIQEE).
Um SIQEE é um conjunto de algoritmos, equipamentos, metodologias, dados e
pessoas (usuário), perfeitamente integrados, de forma a tornar possível a coleta, o
armazenamento, o processamento e a análise de dados relativos a QEE, bem como a
produção de informação derivada de sua aplicação.
2.2
Instrumentos de Reutilização
A proposta de reutilização é inerente ao desenvolvimento de sistemas
computacionais. Durante as décadas de 60 e 70, a idéia de reutilização centrava-se na idéia
de reutilização de códigos de programas. Bibliotecas de funções, escritas em diversas
linguagens de programação, foram criadas e disponibilizadas para que pudessem ser
reutilizadas. A busca por mecanismos voltados a facilitar a reutilização de software teve
como resultado uma série de eventos científicos dedicados ao tema. Em 1983 ocorreu o
primeiro grande congresso na área, o Workshop on Reusability in Programming (Perlis,
1983 Apud [NEI94]).
Com o objetivo de aumentar a produtividade dos programadores e a qualidade nos
sistemas desenvolvidos, a idéia de reutilização sempre esteve associada à criação de
mecanismos que possibilitem a administração da complexidade dos sistemas.
Com a evolução da engenharia de software, surgem normas que tratam da
qualidade dos produtos de software, essas normas de modo geral é composta por um
conjunto de características e subcaracterísticas que devem ser avaliadas e previstas no
projeto do software. Dentre elas podemos citar manutenibilidade, modificabilidade,
escalabilidade. A manutenibilidade trata da facilidade de manutenção, modificabilidade
trata da facilidade de modificação e adaptação, e escalabilidade trata do risco quando se faz
alterações.
28
Diante desta nova realidade a reutilização de software é um fator que pode levar ao
aumento da qualidade e da produtividade na atividade de desenvolvimento de software.
Isso é possível graças a essa nova perspectiva que esse conceito oferece, uma vez que
estamos reutilizando o que já foi desenvolvido e testado, conseqüentemente teremos um
produto de maior qualidade entregue em tempo menor e com um custo de manutenção
reduzido.
Considerando os benefícios que a reutilização proporciona, os projetistas avançados
sabem que não devem resolver cada problema a partir de princípios elementares ou zero.
Ao invés disso, eles reutilizam soluções que funcionaram no passado. Logo quando
encontram uma boa solução, eles a utilizam repetidamente.
O conceito de Tipo Abstrato de Dados (TAD) foi desenvolvido para possibilitar que
estruturas de dados pudessem ser reutilizadas [EMB87]. Para usar um TAD, o
desenvolvedor necessita conhecer apenas a interface e a funcionalidade de cada um dos
subprogramas disponíveis. Outro instrumento que utiliza os conceitos de reutilização é o
paradigma de orientação a objetos que tem, como um de seus princípios fundamentais,
possibilitar a reutilização de classes existentes através de mecanismos como especialização
e polimorfismo. Atualmente na área de Engenharia de Software, pesquisas sobre
reutilização exploram conceitos como Framework e Padrões [GAM95].
Os benefícios do reuso em projetos de banco de dados, está relacionado a projeto de
sistema orientado a objeto onde o usuário do sistema é capaz de modificar o uso que faz de
seu banco de dados [MUL99]. Para ele o projeto de banco de dados deve formulado
visando sempre a reutilização, pois talvez novas estruturas de banco de dados, conexões
com outros bancos de dados ou novos sistemas precisem utilizar seu banco de dados.
Potencial de reutilização pode ser compreendido como o grau em que um usuário
de sistema é capaz de reutilizar o banco de dados numa determinada situação. O potencial
de reutilização mede a capacidade de reutilização inerente ao sistema, a capacidade de
reutilização em um domínio específico e a capacidade de reutilização do sistema em uma
organização [MUL99]
29
Este trabalho trata o uso de Frameworks e Padrões como instrumentos de
reutilização para projeto de banco de dados de QEE.
2.2.1
Reutilização de Especificações de Requisitos
Segundo [NEI94], no processo de desenvolvimento de software quanto mais cedo
forem identificados e criados recursos reutilizáveis, maior será o impacto da reutilização
nas fases posteriores. Portanto, a reutilização de modelos durante a especificação de
requisitos é o primeiro momento em que o projetista pode empregar algum tipo de recurso
reutilizável, isto é, qualquer recurso existente que possa ser útil na construção de um
sistema computacional.
Para [EDE94], o uso de abordagens de reutilização durante a fase de especificação
de requisitos apresenta as seguintes vantagens:
•
redução do custo do desenvolvimento da especificação;
•
redução do custo de verificação e validação da especificação;
•
aumento da produtividade no desenvolvimento de especificações;
•
aumento da qualidade das especificações;
•
padronização das especificações;
•
facilidade de comunicação entre equipes que utilizam a mesma biblioteca.
Como descrito anteriormente a reutilização é apresentada considerando o ciclo de
vida de um projeto de sistemas. A reutilização proposta neste trabalho está centrada na
reutilização de projeto para banco de dados o que apresenta as mesmas vantagens,
pesquisas sobre reutilização em Engenharia de software apresentam resultados satisfatórios
com relação ao uso de reutilização na fase de projeto.
30
2.2.2
Padrões
A abordagem de Padrões2 cada vez mais se torna um assunto disseminado no
campo da Ciência da Computação. Mas ainda existem várias definições para o termo
Padrão.
Segundo [GAM95], o uso de padrões esta diretamente relacionado com a idéia de
reuso em Engenharia de Software e teve origem no trabalho do arquiteto Chistopher
Alexander que afirma:
“cada padrão descreve um problema no nosso ambiente e o núcleo da solução, de
tal forma que você possa usar esta solução mais de um milhão de vezes, sem nunca fazê-lo
da mesma maneira”. Apesar desta definição está descrita considerando os padrões em
construções e cidades, ela é aplicada a padrões de projeto orientados a objeto.
Segundo [GAM95] padrões de projeto tornam mais fácil reutilizar projeto e
arquiteturas bem sucedidas. Os padrões de projeto ajudam a escolher alternativas de
projeto que tornam um sistema reutilizável e evitar alternativas que comprometam a
reutilização, um padrão identifica um problema e apresenta uma solução para ele.
Segundo [DAN02] um padrão pode ser pensado como a reutilização da essência de
uma solução para determinados problemas similares, pode-se dizer ainda que um padrão
resolve um problema recorrente, em um determinado contexto, fornecendo uma solução
que comprovadamente funcione, além de informar resultados e compromissos da sua
aplicação, e subsídios para que seja possível adaptar esta solução a uma variante do
problema.
Em [GER99] os padrões são considerados como resultado da abstração de
problemas semelhantes das soluções utilizadas. Já [ALU01] define os padrões como uma
referência à comunicação de problemas e soluções. Em outras palavras, os padrões
permitem documentar um problema conhecido recorrente e sua solução em um contexto
específico e comunicar esse conhecimento para outras pessoas. [LAR99] considera padrões
2
Do inglês Patterns
31
como fórmulas nomeadas de soluções de problemas que codificam princípios de projetos
exemplares
Como mostrado na Figure 2.1 temos o processo de identificação de um padrão que
pode ocorrer considerando diferentes contextos, essa identificação pode ocorrer nas
diversas etapas do desenvolvimento de software.
Projeto 1
Projeto 2
Projeto 3
Figure 2.1: Identificação de um padrão.
Existem muitas definições para um padrão, mas todas elas têm um comum a
informação relacionada à recorrência de um par problemas-soluções em um contexto
específico.
Em [ALU01] é apresentado um conjunto de características comuns dos padrões:
•
Os padrões são observados através da experiência.
•
Os padrões normalmente são escritos em um formato estruturado.
•
Os padrões evitam a reinvenção da roda.
•
Existem padrões em diferentes níveis de abstração.
•
Os padrões suportam melhorias contínuas.
•
Os padrões são artefatos reutilizáveis.
•
Os padrões comunicam designs e melhores práticas.
•
Os padrões podem ser utilizados em conjunto para solucionar problemas
maiores.
Padrões de software abrangem diferentes níveis de abstração, podendo portanto ser
classificado em diversas categorias de modo a facilitar sua recuperação e uso, é importante
salientar que é possível haver um padrão que se encaixe em mais do que uma categoria.
Várias categorias já foram sugeridas para classificar padrões de software e algumas mais
comuns são:
•
padrões de projeto: definem soluções para problemas de projeto de software;
32
•
padrões arquiteturais: expressam o esquema ou organização estrutural
fundamental de sistemas de software e hardware;
•
padrões de análise: descrevem soluções para problemas de análise de sistemas,
embutindo conhecimento sobre o domínio de aplicação específico;
Um padrão é uma combinação recorrente de elementos de modelagem que ocorrem
em algum contexto [LIS02]. Considerando que padrões podem ser aplicados nas diversas
etapas de desenvolvimento de software. Em [LIS00] é apresentado três categorias de
padrões: padrões de arquitetura, padrões de projeto, e idiomas. As duas primeiras
categorias incluem os padrões relacionados com a fase de projeto do sistema, mas são
aplicadas em problemas de diferentes escalas. Os padrões de projeto são mais abstratos do
que os padrões de arquitetura, enquanto que idiomas são padrões escritos em alguma
linguagem de programação, esse tipo de padrão é também conhecido como padrões de
implementação.
Uma outra categoria de padrões foi introduzida por [FOW97] inclui os padrões de
análise. Este tipo de padrão é utilizado para descrever soluções empregadas durante as
fases de análise de requisitos e modelagem conceitual dos dados. Os padrões de análise
refletem estruturas conceituais representativas do domínio da aplicação e não soluções
computacionais. Fowler em [FOW97] define um padrão de análise como:
“uma idéia que se provou útil em um contexto prático e que, provavelmente, será
útil em outras situações similares”.
A maioria dos padrões de análise publicados foram projetados, com o intuito de
resolver problemas de aplicações comerciais [FOW97]. No entanto, a idéia de padrões de
análise pode ser usada para aumentar a qualidade e a produtividade no desenvolvimento de
aplicações não-convencionais. Em [LIS00] é apresentado o uso de padrões de análise para
aplicações de Sistemas de Informação Geográfica (SIG). Em [LIS00] é apresentado o uso
de padrões de análise, de projeto e idiomas.
Em [LIS00] padrões de análise podem ser usados para documentar como os
projetistas de um determinado domínio de aplicação modelam fenômenos geográficos e
seus relacionamentos. Padrões de projeto são utilizados para documentar como os dados
33
sobre o relevo de uma região são representados através de modelo numérico de terreno, e
idiomas podem definir como um modelo numérico de terreno deve ser implementado em
cada software de Sistema de Informação Geográfica.
2.2.3
Padrões de Projeto
Em Engenharia de software o ciclo de desenvolvimento de software é acontece em
espiral, portanto temos atividades que são desenvolvidas durante as fases de análise e de
projeto do processo, podemos associar essa dificuldade em definir em qual instante
acontece as atividades, a dificuldade em estabelecer a diferença exata entre padrões de
projeto e de análise.
Em [LIS00] é apresentado as principais diferenças entre um padrão de projeto e um
padrão de análise. São elas:
•
Em um padrão de análise sua forma é descrita através de termos e conceitos
pertencentes ao domínio da aplicação. Já, a forma de um padrão de projeto é
descrita através de construtores genéricos de projeto de software;
•
Padrões de análise não são escritos para servirem a um propósito geral. É
importante encontrar o equilíbrio entre obter um padrão muito abstrato e um
padrão muito especializado.
•
Ao contrário dos padrões de análise, os padrões de projeto existentes são
apresentados de forma bem estruturada e organizados separadamente em
catálogos.
[GAM95] e outros propõem padrões de projeto como um novo mecanismo para
expressar experiências na elaboração de projetos orientados a objetos. Ensinam os novos
projetistas a trabalharem bem e padronizarem a maneira de desenvolvimento. Esses
padrões fornecem um vocabulário comum, reduzem a complexidade do sistema usando
abstrações, constituem uma base de experiência para o desenvolvimento de software
reusáveis e comportam-se como blocos de construção para serem empregados em sistemas
mais complexos.
34
Os padrões de projeto apresentados por [GAM95] são organizados considerando
quatro elementos essenciais: Nome do padrão, o problema, a solução e as conseqüências.
No entanto outros itens de descrição podem ser adicionados como motivação,
participantes, sinônimos e outros padrões relacionados. A seguir é apresentado os quatro
elementos essenciais de um padrão segundo [GAM95]:
•
O nome do padrão: é uma referência que podemos usar para descrever um
problema de projeto, suas soluções e conseqüências em uma ou duas palavras.
•
O problema: descreve quando aplicar o padrão. Ele explica o problema e seu
contexto. Pode descrever problemas de projetos específicos, tais como
representar algoritmos como objetos.
•
A solução: descreve os elementos que compõem o projeto, seus
relacionamentos, suas responsabilidades e colaborações.
•
As conseqüências: são os resultados e análises das vantagens e desvantagens
da aplicação do padrão. Embora as conseqüências sejam raramente
mencionadas quando descrevemos decisões de projeto, elas são críticas para a
avaliação de alternativas de projetos e para a compreensão dos custos e
benefícios da aplicação do padrão.
Um exemplo de padrão de projeto é descrito na Figura 2.2 (Padrão Composite). A
intenção do Padrão Composite é compor objetos em estruturas de árvore para
representarem hierarquias partes-todo. Esse padrão permite aos clientes tratarem de
maneira uniforme objetos individuais e composição de objetos.
Figura 2.2: Ilustra o diagrama de classes do padrão de projeto Composite [GAM95]
35
O padrão Composite pode ser usado em várias aplicações tais como: aplicações
gráficas, como editores de desenhos e sistemas de captura esquemática, que permitem aos
usuários construir diagramas complexos a partir de componentes simples. O usuário pode
agrupar componentes para formar componentes maiores, os quais, por sua vez, podem ser
agrupados para formar componentes ainda maiores. Uma implementação simples poderia
definir classes que funcionam como recipientes (containers) para estas primitivas.
O padrão Composite deve ser usado quando:
•
Você quiser apresentar hierarquias partes-todo de objetos;
•
Você quiser que os clientes sejam capazes de ignorar a diferença entre
composições de objetos e objetos individuais. Os clientes tratarão todos os
objetos na estrutura composta de maneira uniforme.
Logo o padrão Composite define hierarquias de classe que consistem de objetos
primitivos e objetos compostos. Os objetos primitivos podem compor objetos mais
complexos, os quais, por sua vez, também podem compor outros objetos, e assim por
diante, recursivamente. Sempre que o código do cliente espera um objeto primitivo ele
também pode aceitar um objeto composto [GAM95].
O padrão Composite também torna o cliente simples, uma vez que, podem tratar
estruturas compostas e objetos individuais de maneira uniforme, facilidade na inserção de
novas espécies de componentes, novas subclasses. Portanto os clientes não precisam ser
mudados para tratar novas classes. Sistemas orientados a objetos geralmente usam o
padrão Composite como por exemplo o Framework Compilador RTL Smaltalk.
Outro padrão de projeto também citado em [GAM95] é o padrão Strategy cuja
intenção é definir uma família de algoritmos, encapsular cada uma delas e torna-las
intercambiáveis. Strategy permite que o algoritmo varie independentemente dos clientes
que utilizam [GAM95].
Existem muitos algoritmos para quebrar um stream de texto em linhas. Codificar de
maneira fixa e rígida tais algoritmos nas classes que os necessitam não é desejável, por
várias razões tais como [GAM95]:
36
•
Quando os clientes necessitam quebras de linhas se tornam mais complexos se
incluírem o código de quebra de linhas. Isso os torna maiores e mais difíceis de
manter, especialmente se suportam múltiplos algoritmos de quebra de linhas.
•
Quando diferentes algoritmos serão apropriados em diferentes situações. Não
queremos suportar múltiplos algoritmos de quebra de linhas se não usamos
todos eles.
•
Quando é difícil novos algoritmos e variar os existentes quando a quebra de
linha é parte integrante de um cliente.
Em várias situações o uso do padrão Strategy será interessante, dentre eles podemos
citar:
•
Quando muitas classes relacionadas diferem somente no seu comportamento.
As estratégias fornecem uma maneira de configurar uma classe com um, dentre
muitos componentes;
•
Quando você necessita de variantes de um algoritmo. Por exemplo, pode definir
algoritmos
que
refletem
diferentes
soluções
de
compromisso
entre
espaço/tempo.
•
Quando um algoritmo usa dados de que os clientes não deveriam ter
conhecimento. O padrão Strategy deve ser usado para evitar exposição das
estruturas de dados complexas, específicas do algoritmo;
•
Quando uma classe define muitos comportamentos, e estes aparecem em suas
operações como múltiplos comandos condicionais da linguagem. Em vez de
usar muitos comandos condicionais, mova os ramos condicionais relacionados
para a sua própria classe Strategy.
Podemos citar como exemplo o ET++ como InterViews que usam estratégias para
encapsular diferentes algoritmos de quebras de linhas.
37
2.2.4
Padrões de Análise
Devido à abordagem de padrões ter sido introduzida na área de Engenharia de
Software, por projetistas de sistemas orientados a objetos, a categoria de padrões mais
conhecida atualmente é a dos padrões de projeto [LIS00]. Em [CUN03], [UCH], [DAN02],
[GER99], [MON02] são usados padrões de projeto.
Diversas pesquisas vem sendo realizadas com relação a padrões que auxiliem
projetistas de banco de dados a reutilizar soluções para problemas de modelagem de dados
[LIS00], [FOW97]. Os padrões que mais se adaptam a esse tipo de problemas são dos
padrões de análise visto que eles descrevem soluções para problemas de análise de
sistemas, embutindo conhecimento sobre o domínio de aplicação específico.
Um padrão de análise descreve um conjunto de classes, possivelmente pertencentes
a diferentes hierarquias de classes, e as associações existentes entre elas. Padrões de
análise podem ser vistos, como uma forma de descrever subesquemas de projetos mais
complexos, os quais ocorrem com freqüência durante o processo de modelagem de muitas
aplicações [LIS00].
Um padrão de análise descreve, em um nível arbitrário de abstração, um conjunto
de objetos do mundo real, seus relacionamentos e as regras que definem seu
comportamento e estado [LIS00].
[FOW97] define um padrão de análise como uma idéia que se provou útil em um
contexto prático e que, provavelmente, será útil em outras situações similares.
Padrões de Análise têm sido desenvolvidos para possibilitar a reutilização de
soluções de análise em diferentes sistemas. Quando identificamos os padrões, eles podem
ser mais genéricos, ou menos genéricos. Quando estes padrões são mais genéricos eles
podem ser reutilizados em aplicações de domínios diferentes, mas quando estes padrões
são menos genéricos, estes podem ser reutilizados considerando aplicações de um mesmo
domínio.
38
Mesmo evidenciando que a reutilização contribui para o aumento da produtividade
entre dos projetistas, para que seja possível o uso de padrões, é necessário o cumprimento
de algumas etapas, uma delas é a documentação dos padrões.
Percebe-se que em [FOW97] e [HAY95] os padrões de análise eram descritos de
forma narrativa, sem nenhum comprometimento com uma estrutura padronizada.
Atualmente existe uma tendência a descrever padrões de análise de forma semelhante aos
padrões de projeto como está descrito em [GAM95], essa tendência pode ser explicada
visto ao grau de organização, padronização e ao crescente uso de padrões pelos projetistas.
Em [FOW00] observa-se alto valor de um padrões de análise, visto que eles
fornecem um começo melhor quando trabalha-se em um domínio novo. [FOW00] relata
que começou a coletar padrões de análise porque estava frustrado com domínios novos,
uma vez que tinha certeza que não era a primeira pessoa que os modelava.
[FOW00] viveu uma experiência interessante, pois percebeu que os padrões de
análise surgem em lugares pouco comuns, por exemplo quando começou a trabalhar em
um projeto para fazer análise financeira corporativa, foi ajudado por um conjunto de
padrões que ele havia descoberto na área de saúde.
Um padrão é muito mais que um modelo. Um padrão deve incluir a razão pela qual
ele é do modo que é. Freqüentemente se diz que um padrão é uma solução para um
problema. Um padrão deve esclarecer o problema, explicar por que ele resolve o problema
e também explicar em que circunstâncias ele funciona ou não [FOW00].
Padrões são importantes porque são o próximo estágio além da compreensão do
básico de uma linguagem ou uma técnica de modelagem. Padrões lhe dão uma série de
soluções e também lhe mostram o que faz um bom modelo e como você deve proceder
para construir um modelo. Eles ensinam através de exemplos [FOW00].
[MES98] apresenta uma estrutura de documentação de padrões semelhante a
[GAM95] porém mais simplificada, essa estrutura pode ser definida por quatro elementos:
39
•
Problema: fornece uma declaração sucinta do problema que necessita ser
resolvido. Normalmente colocado na forma de pergunta;
•
Contexto: descreve o contexto no qual o problema foi identificado e para o qual
a solução foi proposta;
•
Forças: conjunto de restrições que foram consideradas quando da elaboração da
solução do problema;
•
Solução: fornece um diagrama de classes com a solução proposta.
A seguir é apresentado um exemplo de um padrão de análise considerando o
domínio de QEE:
Padrão: Local de Monitorização
Problema: Como modelar dados referentes aos locais de monitorização a fim de
obter informações de qualidade da energia elétrica?
Contexto: A monitoração da qualidade da energia elétrica pode ser executada
objetivando vários fins, uma vez determinado o escopo de um projeto de monitoração. Em
função de um objetivo de monitoração, regiões ou zonas de um sistema elétrico, definidas
pela seleção dos locais de monitoração, podem ser monitorizados a fim de obter
informações necessárias ao gerenciamento da qualidade da energia elétrica.
Forças:
•
Todo consumidor tem pelo menos um local de monitorização;
•
Um consumidor pode ter vários locais de monitorização;
•
Necessidade de obter dados do local de monitorização para QEE.
Solução: A Figura 2.3 mostra o diagrama de classes que compõe o padrão. Em
cada local de monitorização podemos ter um ou vários contatos associados, e o consumidor
pode ter vários locais monitorados.
40
Padrão Local de Monitorização
Local_Monitoracao
Cod_Local
Dat_Inicio_Monitoracao
Nom_Local
Des_Local
Num_Frequencia_alimentacao_local
Dat_Fim_Monitoracao
Val_Tensao_Nominal_Local
1
0..n
Local_Monit_Contato
Cod_Contato
Nom_Local_Contato
Car_Contato
Tel_Fax
Tel_Voz
Tel_Dados
Obs_Contato
1..n
1
Monitoracao_Consumidor
Cod_Consumidor
Nom_Consumidor
End_Consumidor
Ufe_Consumidor
Cep_Consumidor
Pais_Consumidor
Tel1_Consumidor
Tel2_Consumidor
Obs_Consumidor
Nom_Cont_Consumidor
Figura 2.3: Diagrama de Classes do Padrão Local de Monitorização
Padrões de análise têm sido propostos como instrumentos para a reutilização de
soluções durante as fases de análise de requisitos e modelagem conceitual do banco de
dados [FER98], [FOW97], [HAY95], [ROB93], [LIS00], [LIS01] e [LIS02].
2.2.5
Framework
A orientação a objeto cada vez mais tem sido um instrumento interessante para o
desenvolvimento de sistemas considerando os princípios propostos pela engenharia de
software. Podemos dizer fundamentalmente que se deseja com a orientação a objeto é
basicamente: reutilização e modularidade. No que tange a reutilização uma das propostas é
a de usar Frameworks para domínios específicos. Segundo [PRE94], Framework constitui
um avanço em termos de reutilização de software, uma vez que a reutilização ocorre não
41
apenas a partir de pequenos blocos de programas, mas sim de todo ou parte de um sistema,
incluindo a reutilização de projeto.
Segundo [FAY99], um Framework é uma técnica da orientação a objeto voltada
para a reutilização que se beneficia de três características das linguagens de programação
orientada a objeto: abstração de dados, polimorfismo e herança.
Já [TAL97] considera um Framework como um conjunto de classes de software
semi-prontas e relacionadas. Visa atender a solução de um determinado domínio de
problema, de forma que as classes possam ser usadas, estendidas ou customizadas por
desenvolvedores para soluções específicas.
Como mostrado em [GAM95] um Framework é um conjunto de classes
cooperantes que constroem um projeto reutilizável para uma específica classe de software.
Por exemplo, um Framework pode ser orientado para a construção de editores gráficos
para diferentes domínios, tais como: desenho artístico, composição musical e sistemas
CAD para mecânica.
[LAR99] diz que um Framework é um subsistema extensível para um conjunto de
serviços relacionados, ou seja, um conjunto coeso de classes que colaboram para fornecer
serviços para o núcleo invariante de um subsistema lógico. Já [SIL00] define um
Framework como uma estrutura de classes inter-relacionadas, que corresponde a uma
implementação incompleta para um conjunto de aplicações de um domínio.
Enfim um framework é uma abstração de um domínio de aplicações, adequada a ser
especializada em aplicações deste domínio. A principal característica buscada ao
desenvolver um Framework, é a generalidade em relação a conceitos e funcionalidades do
domínio tratado. Além disso, é fundamental que a estrutura produzida seja flexível, isto é,
apresentar as características alterabilidade e extensibilidade [SIL00]:
•
alterabilidade a capacidade de alterar a funcionalidade presente, sem
conseqüências imprevistas sobre o conjunto da estrutura, considerando os
Frameworks essa característica reflete na capacidade de alterar suas
responsabilidades em função da necessidade de uma aplicação específica, o que
42
é operacionalizado através de uma identificação adequada das partes da
estrutura que diferem em aplicações distintas de um mesmo domínio.
•
Extensibilidade se refere a capacidade de ampliar a funcionalidade presente,
sem conseqüências imprevistas sobre o conjunto da estrutura, essa característica
em relação ao Framework se refere a manutenibilidade do Framewok. Um
framework possui uma estrutura de classes mais complexa que a estrutura de
uma aplicação do seu domínio, essa estrutura é construída iterativamente uma
vez que a evolução de uma estrutura de um framework se estende por toda a sua
vida útil, pois a medida em que é utilizado, novos recursos podem ser
agregados.
Existem diversas definições pra o termo Framework, em contrapartida podemos
citar dois aspectos que caracterizam um Framework segundo [TAL97]:
•
Os Frameworks fornecem infraestrutura e projeto: Frameworks portam
infraestrutura de projeto disponibilizada ao desenvolvedor da aplicação, que
reduz a quantidade de código a ser desenvolvida, testada e depurada.
•
Os Frameworks “chamam”, não são “chamados”: um papel do framework é
fornecer o fluxo de controle da aplicação. Assim em tempo de execução, as
instâncias das classes desenvolvidas esperam ser chamadas pelas instâncias das
classes do Framework.
Para [SIL00] um Framework se destina a gerar diferentes aplicações para um
domínio. Precisa, portanto, conter uma descrição dos conceitos deste domínio.
Alguns usuários confundem Frameworks e a reutilização de classes de uma
biblioteca. Segundo [SIL00] existe uma diferença fundamental, e que no caso de
reutilização de classes de uma bilbioteca são usados artefatos de software isolados,
cabendo ao desenvolvedor estabelecer sua interligação, e no caso do Framework, é
procedia a reutilização de um conjunto de classes inter-relacionadas, esse interrelacionamento é estabelecido no projeto do framework. As Figuras Figura 2.4, Figura 2.5
e Figura 2.6 ilustram essa diferença, onde a parte sombreada representa classes e
associações que são reutilizadas.
43
Figura 2.4: Aplicação desenvolvida totalmente [SIL00].
Figura 2.5: Aplicação desenvolvida reutilizando classes de biblioteca [SIL00].
Figura 2.6: Aplicação desenvolvida reutilizando um Framework [SIL00].
Em relação a reutilização, segundo [LIS00] um Framework não necessita estar
implementado em uma linguagem de programação para fornecer a solução parcial a uma
família de problemas. Logo é possível concluir que é uma vantagem o Framework estar
parcialmente implementado, visto que a solução para uma nova implementação está mais
próxima de ser alcançada.
Segundo [LIS00] uma das principais características de um framework é que o fluxo
de controle entre o Framework e a aplicação cliente, uma vez que no Framework os
métodos desenvolvidos para a aplicação é que são chamados pelos métodos de framework.
Isto evidencia que, além de reutilizar todo um conjunto de classes, o conhecimento sobre o
projeto do software também é reutilizado.
44
Um dos primeiros Frameworks que pode ser encontrado na literatura é o ModelView-Controller (MVC), disponível em ambiente de desenvolvimento Smalltalk, para o
desenvolvimento de interfaces para o usuário (GUI), podemos citar outros Frameworks
relacionados a esta área: MacApp, para aplicações gráficas no ambiente Macintosh, ET++,
Iterviews, Microsoft foundation Classes, Java AWT. Apesar dos Frameworks pioneiros
estarem relacionados a criação de interfaces gráficas, atualmente existem Frameworks para
diversos domínios.
Algumas literaturas tentam classificar Frameworks em diferentes dimensões,
caracterizando de acordo com seus propósitos. [FAY97] divide Frameworks em:
•
Frameworks de Infra-estrutura: são usados para dar suporte a diversos
tipos de aplicação independente dos domínios endereçados por estas
aplicações. Exemplos seriam Frameworks para sistemas operacionais,
comunicação, redes e construção de interfaces.
•
Frameworks de Integração: normalmente são usados para integrar
aplicações e componentes distribbuídos, como Frameworks CORBA ORB,
DCOM, implementações do padrão ODMG.
•
Frameworks de Domínio de Aplicação: representam esqueletos de
aplicações para domínios específicos, como telecomunicações, manufatura e
engenharia financeira. Frameworks deste tipo capturam elementos
invariantes de domínio, e deixam em abertos aspectos específicos de cada
aplicação.
Desta forma podemos destacar que os Frameworks de Infra-estrutura e Integração
estão basicamente relacionados a problemas internos de desenvolvimento de software e são
independente de domínio, já os Frameworks de Domínio de Aplicação têm o objetivo de
apoiar o desenvolvimento de aplicações dirigidas ao usuário e produtos em domínios
específicos.
Outra forma de classificar os Frameworks é de acordo com a aplicabilidade, em
horizontais ou verticais [FAY99] [TAL97]. Frameworks horizontais são voltados à
implementações de aplicações relacionadas a infra-estruturas de comunicação de dados, de
interface de usuários e de gerenciamento de dados.
45
Já os Frameworks verticais são voltados ao desenvolvimento com orientação para
um domínio de aplicação específico. Procuram atender a características comuns do
domínio e deixar as específicas para serem implementadas em aplicações construídas a
partir deles.
Os Frameworks de Domínio de Aplicação, ou verticais, são de maior interesse neste
trabalho. Procura-se trabalhar com um determinado domínio de uma aplicação (engenharia
elétrica – QEE) para, a partir dele facilitar desenvolvimento de novas aplicações .
Além da aplicabilidade os Frameworks, podem ainda classificar-se, de acordo com
sua visibilidade [BOS97]:
•
Frameworks do tipo caixa-branca: permitem ao usuário visualizar como
foram implementados e a partir de classes já existentes, através de herança,
criar novas classes adicionando funcionalidades particulares de sua
aplicação.
•
Frameworks do tipo caixa-preta: apenas especificam, através de
interfaces, os serviços que são por eles disponibilizados e requisitados.
Facilitam ao usuário o seu uso, mas reduzem a flexibilidade.
Um aspecto variável de um domínio de aplicação é chamado de “ponto de
especialização”3. Diferentes aplicações dentro de um mesmo domínio são distinguidas por
um ou mais Hot Spots, que representam as partes do framework de aplicação. Já os pontos
fixos4 definem a arquitetura geral de um sistema de software (componentes básicos e os
relacionamentos entre eles). Os frozen-spots ficam fixos em todas as instanciações do
Framework de aplicação [SCH97].
A Figura 2.7 apresenta um Framework caixa branca com um único hot spot
[SCH97]. Logo para a utilização do Framework é necessário fornecer a implementação
referente a esse hot spot.
3
4
Em inglês “Hot Spot”.
Em inglês “Frozen-spots”.
46
Hot
Spot
Figura 2.7: Framework Caixa Branca.
A Figura 2.8 ilustra um Framework caixa preta, também com um único hot-spot.
Nesse Framework existem duas alternativas de implementação. O usuário deve escolher
uma delas ara obter sua aplicação específica. Note que na Figura 2.8 as implementações
fazem parte do Framework, e são as únicas alternativas possíveis de implementação no
hot-spot, já na Figura 2.7 a implementação não fazia parte do Framework, o que permite
qualquer implementação para o hot-spot.
Hot
Spot
Figura 2.8: Framework Caixa Preta
Geralmente os Frameworks são desenvolvidos segundo as características de um
Framework caixa-branca, isso acontece pois a medida que são utilizados, são sugeridas
várias especializações. Logo, conforme vão alcançando um grau de maturidade, tornam-se
cada vez mais parecidos com Frameworks do tipo caixa preta [PRE97].
Portanto a decisão em usar uma abordagem ou outra de um Framework para o
desenvolvimento de uma aplicação, é uma característica de cada Framework, e que será
definida na fase de projeto. De forma geral o projeto de um Framework é desenvolvido
com uma generalização de um domínio de problema. Este, estabelece a flexibilidade
necessária impondo restrições a serem consideradas pelos usuários [SIL00].
2.2.5.1 Framework x Padrões de Projeto
Os conceitos de padrões e Frameworks são às vezes confundidos, apesar de existir
algumas diferenças fundamentais. É importante ressaltar que ambos são elementos de
47
projeto que contém microarquitetura de classes e objetos cooperante para resolver um
problema recorrente de projeto orientado a objetos. Em [GAM95], são apresentados três
diferenças entre padrões e Frameworks:
•
padrões de projeto são mais abstratos que Framewoks. Os Framewoks
podem ser implementados, mas somente exemplos de padrões podem ser
implementados. Um ponto forte dos Frameworks é que podem ser
implementados em uma linguagem de programação, e não apenas
estudados, mas executados e reutilizados diretamente. Já os padrões de
projeto têm que ser implementados cada vez que forem reutilizados, eles
explicam também as intenções, custos e benefícios e conseqüências de um
projeto.
•
padrões de projeto são elementos de arquitetura menores que os
Frameworks. Um Framework típico contém vários padrões de projeto, mas
a recíproca não é verdadeira.
•
padrões de projeto são menos especializados que os Frameworks. Os
Frameworks sempre têm um particular domínio de aplicação. Um
Framework para um editor gráfico poderia ser usado na simulação de uma
fábrica, mas ele não seria confundido com um Framework para simulação.
Por outro lado, os padrões de projeto podem ser usados em praticamente
qualquer tipo de aplicação. Apesar da existência de padrões de projeto mais
específicos de um domínio, mesmo assim eles não ditam a arquitetura de
uma aplicação da maneira como um Framework faz.
Os Frameworks estão se tornando cada vez mais comuns e importantes. Eles são a
maneira pela qual os sistemas orientados a objetos conseguem a maior reutilização. A
tendência é que as aplicações orientadas a objetos terminarão por consistir-se em camadas
de Frameworks que cooperam uns com os outros.
A maioria dos trabalhos relacionados ao uso de Frameworks, estão ligados a
aplicações, neste trabalho propõe uma abordagem relacionada ao uso de Frameworks em
um projeto de banco de dados. Neste caso estamos propondo um Framework conceitual,
segundo [LIS00] o objetivo de um Framework conceitual é o de fornecer um diagrama de
classes que pode ser usado como base para a modelagem das classes do domínio da
48
aplicação. O termo Framework conceitual significa que o produto gerado a partir do uso do
framework não é um software executável, mas sim, um esquema conceitual de dados que,
posteriormente, deverá ser traduzido para um esquema de dados específico do domínio no
qual será desenvolvida a aplicação. No caso deste trabalho o Framework está relacionado
ao domínio de qualidade na energia elétrica.
2.3
Qualidade de Energia Elétrica e Apoio Computacional
Os processos industriais modernos cada vez mais utilizam dispositivos de controle
baseados em tecnologia microprocessada com o objetivo de atingir as metas gerenciais de
produtividade e qualidade. Em conseqüência, suas cargas têm se tornado muito sensíveis
aos fenômenos associados à qualidade da energia, trazendo grandes prejuízos devido às
interrupções de seus processos, perdas de produção, perdas de insumos e custos associados
à mão-de-obra e a reparos de equipamentos [MED03].
As concessionárias de energia elétrica por sua vez, estão sofrendo desgastes na sua
imagem empresarial, além dos custos com pedidos de ressarcimento de prejuízos sofridos
por consumidores, decorrentes da má qualidade da energia [MED03].
Várias pesquisas estão sendo desenvolvidas no que diz respeito a dados relativos a
QEE, essas pesquisas em sua maioria são apoiadas por ferramentas computacionais.
Portanto dispor de apoio computacional para tratar sistemas que visam QEE apresenta-se
como uma alternativa crescentemente utilizada, como veremos a seguir.
Para [MED03], [NET01] os recursos computacionais estão sendo usados pelas
empresas de energia elétrica no sentido de implementar programas de diagnósticos e
controle da qualidade da energia elétrica, já que a mesma está se transformando num fator
de competitividade no mercado de energia elétrica. [MED03] apresenta um programa de
monitoração com o objetivo de determinar indicadores que expressem a QEE nos pontos
de conexão com a transmissora e em alguns pontos de entrega, de forma qualitativa e
quantitativa, permitindo estabelecer relações de causa-efeito que venham subsidiar ações
49
de caráter preventivo ou corretivo para operações do sistema elétrico ou mesmo no
planejamento da operação de expansão do sistema elétrico.
Já [NET01] apresenta um algoritmo Neuro-DEA que através da medida da
eficiência relativa identifica os valores das tensões que não causam prejuízos ao sistema
bem como os pontos onde estas tensões prejudicariam o bom funcionamento dos
equipamentos.
[AGO00] mostra que as transformações ocorridas nos últimos anos na organização
dos Sistemas de Energia Elétrica, com o estabelecimento de um ambiente competitivo,
principalmente na geração e na comercialização, têm sinalizado para o aproveitamento
máximo das capacidades das instalações. Ao mesmo tempo, novas metodologias e novos
equipamentos (FACTS, por exemplo) são constantemente desenvolvidos, e precisam ser
incorporados nas ferramentas de apoio ao setor elétrico de forma rápida e eficiente. Assim,
um bom suporte computacional ao desenvolvimento dessas ferramentas torna-se
imprescindível.
Para [KAG03] as ferramentas computacionais destinadas a análises e diagnósticos
de sistemas de distribuição integrados são muito procuradas atualmente, pois as
regulamentações do setor têm exigido das concessionárias um melhor desempenho de seus
sistemas elétricos com enfoque direto em qualidade de fornecimento. O trabalho proposto
por [KAG03] apresenta uma metodologia de cálculo de índices técnicos descritivos,
capazes de diagnosticar as redes de distribuição, além de descrever um modelo
computacional para estimação de índices técnicos de qualidade de fornecimentos de
energia das redes de média e baixa tensão.
[ROM03] mostra o uso de programas computacionais que permitem ao usuário
simular algumas situações no sistema elétrico, como por exemplo simular faltas deslizantes
aplicadas ao longo das linhas e barramentos existentes dentro de uma área de influência
pré-definida, e na monitoração das tensões na barra de interesse onde se deseja obter
índices de qualidade. O trabalho proposto por [ROM03] apresenta uma ferramenta para
essa simulação denominada “ANAQUALI”.
50
[PEL03] usa recursos computacionais para implementar um modelo de
planejamento que estabelece as providências e obras prioritárias, em uma dada área
geográfica da empresa que maximizem a relação benefício/custo. [PEL03] apresenta uma
ferramenta denominada “SISQUALI” que permite tal funcionalidade.
[CRU03] apresenta as características principais do sistema de monitoramento da
qualidade da energia elétrica da Chesf e sua experiência na operação e manutenção de uma
rede de instrumentos digitais de medição para fins da análise da qualidade da energia
elétrica fornecida pela empresa, na administração de um sistema de coleta, armazenamento
e distribuição de dados e nas atividades desenvolvidas em uma plataforma para teste e
simulações. Neste trabalho é descrito a rede de monitoração de QEE da Chesf, bem como a
administração do banco de dados e o sistema de distribuição de dados disponibilizados na
Intranet da empresa.
Para [DIA01], [ALV00], [FER99], [FER01] as informações relativas a QEE
proporciona as concessionárias prover aos consumidores um atendimento pré-ativo,
configurando uma nova oportunidade de negócio, e as ferramentas computacionais dão
apoio no que diz respeito a monitoração, a aquisição, tratamento e disponibilização de
dados relativos a QEE.
[DIA01] discute o resultado adquirido no desenvolvimento do projeto [PPGEE00]
onde foi implantado uma rede piloto de monitoração da QEE, essa discussão apresenta
critérios utilizados no desenvolvimento de um sistema de aquisição de dados para
gerenciamento da Qualidade da Energia Elétrica, baseado na instalação de uma rede de
equipamentos de monitoramento da QEE em pontos chave do sistema, que permite avaliar
uma série de fatores como: fenômenos eletromagnéticos a serem observados, metodologias
e protocolos de medição, tratamento e disponibilização dos dados medidos. Com isso é
possível definir requisitos de hardware, software, topologia da rede de monitoramento,
arquitetura do sistema, transmissão dos dados e especificação de um equipamento monitor
de QEE.
[ALV00] fundamenta-se em um sistema de gerenciamento da QEE, desenvolvido a
fim de permitir um eficiente tratamento da informação, tratando a grande quantidade de
dados aquisitados, permitindo a extração de informações específicas, disponibilizando-as
51
na forma de relatórios formatados para atender aos objetivos estabelecidos em [FER99]. A
partir da recuperação da informação contida no banco de dados uma série de outras
informações pode ser levantada a fim de responder, à necessidade, ou o objetivo, da
avaliação.
Já [FER01] apresenta que uma rede de monitores instalada em pontos específicos
do sistema elétrico, pode gerar uma grande quantidade de informações, sob diferentes
formas de registro de variações na tensão ou corrente do sistema monitorado. Isto indica a
necessidade de um sistema de gerenciamento que minimize a quantidade de dados
armazenados e maximize a eficiência de sua análise, para isso foi desenvolvido um banco
de dados relacional cujo objetivo global é a produção automatizada de relatórios que
auxiliem no gerenciamento da qualidade da energia elétrica em um sistema elétrico.
[VIV01] teve por objetivos especificar e desenvolver para a Companhia de
Eletricidade do Rio de Janeiro – CERJ, um sistema que tivesse a característica de aquisitar
anomalias relacionadas a sub-tensão, sobre tensão e harmônicos de tensão, transmitir esses
dados até um Servidor de Comunicação e disponibiliza-los em um Servidor de Dados com
programas visualizadores adequados para permitir a um especialista da área analisá-los e
tomar decisões pertinentes. O sistema prevê também, a disponibilização do banco de dados
para um Servidor Web para que as informações possam ser acessadas mediante uma
autenticação, por consumidores ou agências reguladoras.
Em [SAN02] tendo em vista a necessidade de competição neste novo mercado e
vislumbrando as informações necessárias para o real conhecimento de seus clientes, a AES
Eletropaulo está construindo uma base de dados de medição que permite o
acompanhamento diário via Web do comportamento de seus clientes de Alta e Média
Tensão, de suas subestações de transmissão e distribuição, o tratamento de clientes com
várias plantas como uma mesma companhia, além do estudo e a análise de dados
históricos.
[FAV02] apresenta um projeto que trata a obtenção das informações com qualidade
e prazos determinados, para a aquisição de dados das medições de fronteira, optou-se pela
instalação de medidores de retaguarda, aproveitando-se os transformadores de
instrumentos existentes. As informações são registradas em memória local dos medidores,
52
essas informações são coletadas pelo sistema de aquisição e armazenadas em um SGBD
(Oracle), aplicativos acessam a base de dados para o cálculo da curva de carga e para a
apresentação dos dados sob forma de tabelas e gráficos. Este trabalho apresenta a
experiência da ELEKTRO na implantação de um sistema de aquisição e tratamento de
dados das medições de fronteira.
[OLI99] trata questões relativas a QEE e sua relação com a conservação de energia.
Determina as principais medidas de conservação adotadas pelo PROCEL (Programa
Nacional de Conservação de Energia Elétrica) dentro dos programas de GLD,
quantificando física e economicamente os efeitos destas sobre a Qualidade. Objetivando
por fim levantar argumentos para que os programas de conservação incluam em suas
análises de viabilidade econômica as medidas de mitigação dos distúrbios gerados.
[DAB95] apresenta um software para um sistema de gerenciamento da qualidade da
energia elétrica. Os dados são adquiridos pelos monitores de QEE, tratados e inseridos no
banco de dados, este trabalho usou o SGBD Microsoft Access, arquitetura Cliente/servidor
e a Structures Query Language (SQL) para consulta aos dados.
Analisando estas propostas, percebe-se que:
•
Existem propostas relativas a Qualidade da Energia Elétrica que usam
algoritmos sem especificar uma base de dados, e outras que necessitam guardar
informações, quando isso ocorre, geralmente usam um SGBD (relacional) para
armazenamento.
•
Nas propostas que usam banco de dados, não é apresentado o projeto do banco
de dados, vê-se que a definição dos requisitos para a definição do banco de
dados está associada a experiência adquirida pelos profissionais que lidam com
QEE.
•
Quando se deseja projetar um banco de dados, não existe o reuso das
informações adquiridas por outros projetos/pesquisadores.
•
Os recursos de orientação a objetos são pouco utilizados.
53
2.4
UML - Linguagem de Modelagem Unificada
A partir da década de 70, métodos orientados a objetos começaram a surgir,
vislumbrando a mudança de paradigma. A programação orientada a objetos já estava
amadurecendo, bastava portanto criar para ela uma metodologia, e começamos a conhecer
a análise orientada a objetos.
Tem-se comprovado que a orientação a objetos vem propiciar aos desenvolvedores
aumento de produtividade, diminuição do custo de desenvolvimento e principalmente de
manutenção, maior portabilidade e reutilização de código. A orientação a objetos baseia-se
em vários conceitos como objetos, classes, encapsulamento, herança, polimorfismo e
outros.
Desde os primeiros conceitos de orientação a objetos, diversos métodos foram
apresentados à comunidade, mas a maioria procuravam estender os métodos estruturados,
logo tínhamos uma insatisfação por parte dos usuários que não conseguiam encontrar uma
satisfação no que havia disponível.
A partir de meados da década de 90 começava a surgir novas abordagens que
procuravam trabalhar o novo paradigma. Vários pesquisadores através de suas publicações
deram grandes contribuições à orientação a objetos: Ward Cunningham e Kent Beck, Sally
Shlaer e Steve Mellor, Jim Odell e James Martin, Peter Coad e Ed Yourdon, James
Rumbaugh (OMT – Object Modeling Technique), Grady Booch (Método Booch), Ivar
Jacobson (OOSE – Object-Oriented Software Engineering).
Os métodos que mais que mais cresciam no mercado eram: Booch’93, OMT-2 e
OOSE, cada método apresentava pontos significativos. Resumidamente, o OOSE possuía
seu foco em casos de uso (use case), provendo suporte à engenharia de negócios e análise
de requisitos. O OMT-2 era expressivo na fase de análise dos sistemas de informação, já
Booch’93 destacava-se na fase de projeto.
Os esforços para a unificação desses métodos tiveram início com James Rumbaugh
e Grady Booch na Rational Software, mais tarde juntou-se a essa equipe Jacobson com o
54
intuito de incorporar o método OOSE. O método unificado passou a se chamar UML –
Unified Modeling Language.
Durante o ano de 1996 a UML já era vista pelas organizações como uma estratégia
de negócios. Um requerimento de proposta de padronização emitido pela OMG5 gerou
uma união de forças a fim de produzir uma resposta a esse requerimento. Houve
participação ativa da comunidade de engenharia de software, além de várias empresas de
software que passaram a contribuir no intuito de fortalecer a UML. Assim consegui-se uma
linguagem bem definida, expressiva, poderosa e genericamente aplicável.
Para [BOO99] a UML é uma linguagem-padrão para a elaboração da estrutura de
projetos de software, que poderá ser empregada para a visualização, especificação,
construção e a documentação de artefatos que façam uso de sistemas complexos de
software.
Segundo [FOW00] a UML é chamada de linguagem de modelagem, não é um
método. A maioria dos métodos consiste, pelo menos em princípio, de uma linguagem de
modelagem e de um processo. A linguagem de modelagem é a notação utilizada por
métodos para expressar projetos. O processo é a sugestão de quais passos a serem seguidos
na elaboração de um projeto.
Para o [OMG99], a UML consiste na especificação semi-formal de um metamodelo
para representar a semântica de modelos de análise e projeto orientado a objeto, incluindo
modelos estáticos, comportamentais, de uso e arquiteturais.
Para [MEL02] a UML é uma linguagem para especificação, visualização,
construção e documentação de artefatos6 de sistemas de software.
Um fator importante no uso da UML é que ela é independente de linguagens de
programação quanto de processos de desenvolvimento, logo ela pode ser utilizada para a
5
É uma organização internacional, que promove a teoria de prática da tecnologia orientada a objeto em
desenvolvimento de sistemas. A patente da organização inclui o estabelecimento de normas industriais e
especificações de gerenciamento de objetos para prover um padrão comum para desenvolvimento de aplicações.
6
Exemplos de artefatos: requisitos, arquitetura, projeto, código fonte, planos de projeto, testes, protótipos, versões,
e etc.
55
modelagem de sistemas, não importa qual a linguagem de programação que será utilizada
na implementação do sistema, ou qual a forma de desenvolvimento adotada.
A UML é uma linguagem visual pra modelar sistemas orientados a objetos. Isso
quer dizer que a UML é uma linguagem construída de elementos gráficos (visuais)
utilizados na modelagem que permite representar os conceitos do paradigma de orientação
a objetos. Através de elementos gráficos definidos nesta linguagem pode-se construir
diagramas que representam diversas perspectivas de um sistema [ BEZ02].
O desenvolvimento de um sistema de software demanda múltiplas visões dos
desenvolvedores, ou seja, eles devem ter a possibilidade de estudar esse sistema a partir de
várias perspectivas. Segundo [BOO99] um sistema pode ser descrito por cinco visões
interdependentes do sistema, as visões propostas são:
•
Visão de Casos de Uso: descreve o sistema de um ponto de vista externo como
um conjunto de interações entre o sistema e os agentes externos ao sistema.
•
Visão de Projeto: enfatiza as características do sistema que dão suporte, tanto
estrutural quanto comportamental, às funcionalidades externamente visíveis do
sistema.
•
Visão de Implementação: corresponde à distribuição física dos sistemas em
seus subsistemas e à conexão entre esses partes.
•
Visão de Processo: esta visão enfatiza as características de concorrência
(paralelismo), sincronização e desempenho do sistema.
É importante lembrar que dependendo das características e complexidades do
sistema, nem todas as visões precisam ser construídas.
Na terminologia da UML os documentos que são criados na modelagem são
denominados artefatos de software ou artefatos, esses artefatos compõem as visões do
sistema. Os artefatos gráficos produzidos durante o desenvolvimento de um sistema de
software são definidos através dos diagramas da UML:
56
•
Diagrama de classe: utilizado na construção do modelo de classes desde o nível
de análise até o nível de especificação.
•
Diagrama de objetos: podem ser vistos como instâncias de diagramas de
classes, da mesma forma que objetos são instâncias de classes7.
•
Diagrama de componentes: mostra os vários componentes de software de um
sistema e suas dependências.
•
Diagrama de implantação: representa a topologia física do sistema e,
opcionalmente, os componentes que são executados nessa topologia.
•
Diagrama de caso de uso: corresponde a uma visão externa do sistema e
representa graficamente os atores, casos de uso e relacionamentos entre esses
elementos, onde o objetivo é ilustrar em um nível alto de abstração quais
elementos externos interagem com que funcionalidades do sistema.
•
Diagrama de seqüência: a ênfase está na ordem temporal das mensagens
trocadas entre os objetos.
•
Diagrama de colaboração: enfatiza os relacionamentos que há entre os objetos
que participam da realização de um cenário.
•
Diagrama de transição de estados: utilizado para realizar a análise das
transições entre estados dos objetos de um sistema de software, podem prever
todas as possíveis alterações realizadas, em função de um evento que pode
ocorrer.
•
Diagrama de atividades: é um tipo especial de diagrama de estados, em que são
representados os estados de uma atividade, em vez dos estados de um objeto,
esse diagrama é orientado a fluxo de controle.
Essa dissertação se concentra no diagrama de classes, pois esse é o diagrama central
para descrever a estrutura dos Frameworks, e na descrição dos padrões de análise. Apenas
alguns recursos da UML serão utilizados, os quais fazem parte do modelo de classes, cujos
principais construtores são mostrados na Figura 2.9. Em relação ao SIQEE este apresenta
características que indicam a viabilidade de disponibilização deste sistema na Web, logo o
uso de linguagem padrão torna-se fator importante.
7
Diagramas de objetos também são chamados de diagramas de instâncias.
57
Pacote
Multiplicidade
Classe
Classe Agregada
atributo : domínio
1
Método()
Generalização/
Especialização
atributo : domínio
0..*
Associação
Método()
Agregação
Subclasse
ClasseComponente
atributo : domínio
Suclasse
atributo : domínio
atribributo : domínio
Método()
Método()
Instanciação
Composição
Método()
objeto: classe
Figura 2.9: Notação gráfica do diagrama de classes UML.
Segundo [CON03] na Web Application Extension for UML (WAE), a notação
UML é estendida com semântica e restrições adicionais para permitir a modelagem de
elementos da arquitetura específica da Web como parte do modelo de sistema. Para
aplicações Web significa que os modelos UML, precisam capturar a execução da lógica de
negócios nas páginas Web, nos scripts do cliente e nos componentes Web. Tendo um único
modelo central de toda a lógica de negócio em um sistema, conseguimos compreendê-lo
melhor e, eventualmente, aperfeiçoá-lo em futuras versões.
Segundo [JON01], os objetivos principais definidos pelos criadores da UML são os
seguintes:
•
Prover aos usuários uma linguagem de modelagem visual expressiva e pronta
para uso, de forma que eles possam desenvolver e compartilhar modelos
significativos;
•
Prover mecanismos de extensibilidade e especialização para ampliar os
conceitos centrais;
•
Ser
independente
de
linguagens
de
programação
e
processos
de
desenvolvimento particulares;
58
•
Prover uma base formal para entendimento da linguagem de modelagem;
•
Estimular o crescimento do mercado de ferramentas orientadas a objetos;
•
Suportar conceitos de desenvolvimento de nível mais alto, tais como
colaborações, estruturas, modelos e componentes;
•
Integrar as melhores práticas.
De acordo com [FUR98], a UML pode ser usada para as seguintes atividades ao
longo de um processo de desenvolvimento de software:
•
Mostrar as fronteiras de um sistema e suas funções principais utilizando atores
e casos de uso;
•
Ilustrar a realização de casos de uso com diagramas de interação;
•
Representar uma estrutura estática de um sistema utilizando diagramas de
classe;
•
Modelar o comportamento de objetos com diagramas de transição de estado;
•
Revelar a arquitetura de implementação física com diagramas de componente e
de implantação;
•
Estender sua funcionalidade através de estereótipos.
Segundo [TON03] a UML tem como objetivo prover as necessidades de
desenvolvedores de software com uma linguagem de modelagem visual completa,
buscando atingir os seguintes aspectos:
•
disponibilizar de mecanismos de especificações que possam expressar os níveis
conceituais;
•
independência de processos de desenvolvimento e linguagens de programação;
•
incentivo do crescimento das aplicações desenvolvidas no conceito da
orientação a objetos;
•
Permissão de suporte a conceitos de desenvolvimento de alto nível, tais como
Frameworks, padrões e componentes;
Considerando os objetivos definidos por [JON01] essa dissertação está relacionada
ao segundo e ao terceiro objetivo, em relação as atividades descritas por [FUR98] está
relacionada a terceira e sexta, e em relação a [TON03] está relacionada a todos os itens.
59
2.5
Linguagens de Marcação
As linguagens de marcação já existem a algum tempo de várias formas, cuja
característica fundamental é a capacidade de descrever símbolos ou marcadores inseridos
em um documento de texto para definir o significado que aqueles símbolos dão ao texto
associado [CAR01]. Já [HOL01] define uma linguagem de marcação como uma referência
à descrição do documento, ou seja, do modo como o conteúdo do documento deve ser
interpretado.
O objetivo principal de uma linguagem de marcação é fornecer uma descrição
detalhada de como o documento dever ser estruturado independente de qual processador
possa estar processando os dados, e a tarefa de formatação é deixada para as folhas de
estilo que o desenvolvedor cria [PIT99].
A HTML(Hypertext Markup Language), linguagem de marcação de
hipertexto popularizou o uso de linguagens de marcação, foi criada em 1990 como uma
técnica para a criação e vinculação de documentos, e execução de links. Com o
crescimento do uso da Web para disseminação das informações novas necessidades foram
surgindo excedendo as capacidades da HTML. A XML (Extensible Markup Language),
linguagem de marcação extensível, foi criada para superar essas limitações e capacitar uma
nova geração de intercâmbio de informações. As figuras Figura 2.10 e Figura 2.11
apresentam um exemplo de uma página HTML e XML respectivamente.
<HTML>
<HEAD>
<TITLE> Livro </TITLE>
</HEAD>
<BODY>
<CENTER>
<H1>
Qualidade na Energia Elétrica Autor
Ricardo Aldabó Editora Artliber
</H1>
</CENTER>
Engenharia Elétrica
</BODY>
</HTML>
Figura 2.10: Código de uma página em HTML.
60
<?xml version=”1.0” encoding=”utf-8”?>
<LIVRO>
<AREA>
Engenharia Elétrica
</AREA>
<TITULO>
Qualidade na Energia Elétrica
</TITULO>
<AUTOR>
Ricardo Aldabó
</AUTOR>
<EDITORA>
Artliber
</EDITORA>
</LIVRO>
Figura 2.11: Código de uma página em XML.
2.5.1
Características da XML
A XML, [W3C98] é um padrão aprovado pela W3C8 (Worls Wide Web
Consortium) que deve se tornar um formato universal para a troca de informações na Web.
A SGML (Standard Generalized Markup Language), linguagem de marcação
generalizada padrão, é predecessora da XML, mas também devido a sua generalidade
tornou-se complexa demais para o seu uso amplamente na Web. Contudo segundo
[CAR01] como a XML é definida como um subconjunto de SGML, qualquer documento
XML válido também é um documento SGML válido, mas o inverso não é verdadeiro.
Em [PIM00], apresenta a XML como uma meta-linguagem, o que significa que
XML provê recursos para a definição de gramáticas que caracterizam linguagens para
classes de documentos específicos, com conjunto de elementos, atributos e regras de
composição bem determinados.
8
Órgão que define os padrões para a Web.
61
Já [GRA02], diz que a XML é uma linguagem usada para representar dados como
uma string que inclui uma “marcação” intercalada a fim de descrever as propriedades dos
dados. O uso de marcação permite que o texto seja intercalado por informações
relacionadas a seu conteúdo ou forma.
Nas figuras Figura 2.10 e Figura 2.11 podemos observar as diferenças entre XML e
HTML, segundo [ABT99] podemos citar os seguintes aspectos:
•
novas tags9 podem ser definidas à vontade;
•
estruturas podem ser aninhadas a profundidades arbitrárias;
•
um documento XML pode conter uma descrição opcional de sua gramática.
Visto que as tags podem ser definidas de acordo com a necessidade do sistema, isso
faz com que as tags deixam de ser fixas e se tornam mais auto-descritivas. Logo pode-se
ainda atribuir nomes mais significativos ao conteúdo referenciado. Já a gramática descrita
no terceiro aspecto pode ser usada pelas aplicações que usam XML e que necessitam
validar a estrutura do documento. Esta descrição da gramática é chamada esquema, no qual
existem as seguintes propostas: DTD e XML Schema.
Diferente da HTML, XML exige que a todo elemento de abertura seja associado
um elemento de fechamento, mesmo que nenhum dados esteja delimitado por tais
elementos.
De acordo do [PIT99] a XML é uma linguagem de marcação mais avançada do que
o HTML, afirma ainda que a HTML é usado basicamente para apresentação de conteúdo e
o XML para estruturar os dados, mesmo assim a XML não é uma substituta da HTML, e
também não é uma HTML com marcas extras.
Na Web a HTML é muito utilizada muito embora ela trate as informações de forma
superficial, visto que descreve a disposição de textos, imagens e controles em uma página
e não o seu conteúdo. Essa característica é o inverso da XML, uma que vez que ela
descreve o conteúdo em vez da apresentação.
9
São marcas combinantes que são balanceadas devendo ser fechadas em ordem inversa à aquelas que foram
abertas. O texto entre as marcas é o conteúdo.[ABT99]
62
Esta diferença agrega uma vantagem para XML em relação a HTML. Segundo
[SUC98], a XML permite que a troca eletrônica de dados na Web seja legível para o
computador, o que não acontece na HTML, uma vez que a troca de documentos é legivel
apenas para o homem. Com a XML há um ganho semântico pois os programas passam a
entender a estrutura dos documentos disponíveis na Web, possibilitando assim pesquisas
inteligentes das informações armazenadas.
Para [PIT99] a XML é na realidade uma maneira de solucionas determinados
problemas que são encontrados ao usarmos a HTML. Com a XML temos:
•
Melhor controle em relação ao layout;
•
Menos esforço no servidor Web devida à capacidade de acessar informações do
lado do cliente;
•
O uso de vários tipos de links;
•
A capacidade de publicar qualquer tipo de informação tanto na Internet quanto
em Intranets.
•
2.5.2
Um número menor de problemas para exibir páginas longas.
XML como intercâmbio de Informações
Com a evolução da Internet, a World Wide Web (Web) se tornou um vasto
repositório de dados dos mais variados domínios. A XML vem sendo usada para a
representação e intercâmbio de dados na Web.
Segundo [CH98], um software precisaria ser apenas capaz de exportar e importar os
dados utilizados no formato XML para que conseguisse operar com outras ferramentas
compatíveis com XML. A [OMG99b] especifica os quatros seguintes cenários onde o
XML pode ser útil:
•
Combinação de ferramentas em um ambiente heterogêneo;
•
Cooperação através de definições comuns de metamodelos;
•
Troca de experiências em um ambiente distribuído com facilidade de
publicação e captura de informações;
•
Promoção de padrões de projeto e reutilização.
63
Neste trabalho estaremos utilizando XML para disponibilização de um esquema
para um banco de dados independente do SGBD. A Figura 2.12 representa a estrutura de
disponibilização de dados na Web utilizando XML, o que facilitaria da troca de
informações entre grupos de pesquisas de QEE, pois os dados estariam em formato padrão,
fazendo com que cada grupo tenha apenas uma ferramenta para capturar dados em formato
XML e armazenar em seu banco de dados de acordo com a tecnologia usada.
Em [MAG01] é apresentado uma possível solução para o problema de dados semiestruturados é extraí-los de páginas Web e armazená-los em banco de dados relacional para
posterior manipulação. Neste sentido, diversas abordagens têm sido propostas para a
extração e estruturação de dados na Web.
Banco de
Dados QEE
Disponibilização de dados
Web em formato XML
Ferramenta de Extração de
Dados na Web
Oracle
DB2
Outros
Figura 2.12: Estrutura de disponibilização de dados na Web
2.6
Modelo de Dados
A modelagem de dados teve seu início sob o enfoque da abordagem Entidade-
Relacionamento proposto por Peter P. Chen na década de 70, mas tem evoluído com o
passar dos anos, para enfoques que a tornam mais próxima ao conceito de orientação a
objeto o qual é foco deste trabalho.
64
Para [COU97] é importante entender o conceito de modelo antes de entender a
modelagem de dados, para ele o modelo é representação abstrata e simplificada de um
sistema real, com a qual se pode explicar ou testar o seu comportamento, em seu todo ou
em partes.
Um modelo de Dados é uma coleção de conceitos que podem ser usados para
descrever um conjunto de dados e operações para manipular esses dados [BAT92], já
[NAV00] diz que um modelo de dados é uma coletânea de conceitos que podem ser
utilizados para descrever a estrutura de um banco de dados, fornecendo meios necessários
para alcançar essa abstração.
Segundo [KOR99] um modelo de dados é um conjunto de ferramentas conceituais
usadas para a descrição de dados, relacionamentos entre dados, semântica de dados e
regras de consistência.
A modelagem de dados ajuda a organizar sua forma de pensar sobre os dados,
esclarecendo o significado e a aplicação prática deles. Ajuda não somente a comunicar as
necessidades, mas também a comunicar de que forma pretende atendê-las. Provê uma
plataforma a partir da qual pode utilizar para projetar e construir com um certo grau de
segurança quanto ao sucesso [MUL99].
A modelagem de dados é a primeira etapa em um projeto de banco de dados. Ela
estabelece o vínculo entre as necessidades dos usuários e a solução de software que as
atende, é a abstração inicial que encobre a complexidade do sistema [MUL99].
Com relação a dimensão dos modelos de dados segundo [NAV00], eles podem ser
classificados em duas dimensões: em função da etapa de desenvolvimento do projeto de
banco de dados em que o modelo é utilizado, um exemplo seria o projeto conceitual, lógico
e físico, a outra dimensão seria em função da flexibilidade e poder de expressão.
A etapa de projetar um banco de dados está relacionada com o ciclo de vida de
desenvolvimento de software, onde a cada etapa, novas informações e detalhes são
acrescidos ao projeto de software [PRE01]. Durante o projeto de banco de dados, as
65
informações que compõe o banco de dados são especificadas utilizando-se modelos de
dados em diferentes níveis de abstração, iniciando por modelos de alto nível de abstração.
Com relação a dimensão de flexibilidade e expressividade, o termo flexibilidade
está relacionado, neste contexto à facilidade com a qual o modelo pode tratar com
aplicações complexas, enquanto que a expressividade refere-se à habilidade de gerar
diferentes abstrações em uma aplicação [NAV00]. Segundo este aspecto os modelos são
classificados como: primitivos (ou de arquivos), modelos de dados clássicos (relacional,
hierárquico, redes), modelos semânticos de propósito especial (CAD/CAM e SIG) e
modelos orientado a objetos.
Considerando essas duas classificações este trabalho estará considerando o nível de
abstração empregados nos modelos conceituais e modelos orientado a objetos.
2.6.1
Modelagem Conceitual de Banco de Dados
Segundo [NAV00], o projeto de banco de dados envolve três fases: projeto
conceitual, projeto lógico e projeto físico. Este trabalho tem enfoque no projeto conceitual.
Uma das etapas de um processo de desenvolvimento de um projeto de banco de
dados é criar um esquema conceitual para o banco de dados, utilizando um modelo
conceitual de alto nível, essa etapa é chamada de projeto conceitual.
Segundo [NAV00] o esquema conceitual é uma descrição concisa dos requisitos de
dados feitos pelos usuários, devido a esses conceitos não incluírem detalhes sobre
implementação, são geralmente mais fáceis de serem compreendidos e podem ser
utilizados para a comunicação de usuários não-técnicos.
[MUL99] diz que um modelo conceitual representa as informações no banco de
dados. Esse esquema representa as estruturas, operações e as restrições do modelo de
dados que você está utilizando. Já [COU97] define um modelo conceitual como aquele em
que os objetos, suas características e relacionamentos têm representação fiel ao ambiente
66
observado, independente das limitações quaisquer impostas por tecnologias, técnicas de
implementação ou dispositivos físicos.
Em [HEU01] define-se um modelo conceitual como uma descrição do banco de
dados de forma independente de implementação em um SGBD. O modelo conceitual
registra que dados podem aparecer no banco de dados, mas não registra como estes dados
estão armazenados considerando o SGBD.
A modelagem conceitual é feita com base em algum formalismo conceitual, como
por exemplo Entidade-Relacionamento ou Orientação a Objetos. Esse formalismo provê
um conjunto de conceitos, elementos e regras que são usados no processo de modelagem
da realidade, enquanto que a linguagem de descrição fornece uma gramática para a
apresentação do esquema conceitual resultante da modelagem.
Logo esse diferencial é o mais importante para o contexto deste trabalho, uma vez
que podemos derivar diferentes estruturas de implementação a partir de um mesmo modelo
conceitual. Assim, a partir deste modelo conceitual poderemos a qualquer instante, derivar
um modelo para implementação de um SGDB relacional. Se futuramente a necessidade
não for mais um modelo relacional, descartamos o modelo derivado, voltaremos ao modelo
conceitual, aplicaremos as regras de derivação e poderemos ter um outro tipo de modelo.
67
3
Modelagem Conceitual de Dados para Sistemas de Informação da
Qualidade da Energia Elétrica
Esse capítulo apresenta os modelos conceituais de banco de dados para aplicações
para SIQEE, bem como a proposta de um modelo conceitual para um banco de dados para
QEE considerando o paradigma de orientação a objetos.
Pesquisas vêm sendo desenvolvidas com o objetivo de se encontrar um projeto
ideal para um banco de dados de QEE que atenda as necessidades dos usuários.
Geralmente os projetos desses bancos de dados têm como base a experiência dos seus
projetistas em conjunto com os usuários ligados a área de engenharia elétrica.
Em geral, as publicações que apresentam resultados de trabalhos que usam um
SGBD não apresentam um projeto conceitual adequado para o banco de dados para QEE,
como pode ser visto em [DAB95], [FERN99], [VIV001], [FAV02], [SAN02],
[CRU03],[ROM03], [MED03]. Apesar de não apresentar um modelo conceitual é possível
notar que tais trabalhos usam um SGBD relacional. Os trabalhos [DIA01], [FER01] e
[PPGEE00] também não apresentam um modelo conceitual, mas foi desenvolvido um
modelo lógico considerando um SGBD relacional específico.
Podemos observar que tais bancos de dados para QEE não aproveitam as
experiências adquiridas em outros projetos, ou seja, eles sempre começam do zero. Isto
acontece devido a falta de maturidade no desenvolvimento destes tipos de aplicações e de
ferramental e métodos adequados de trabalho. Isto normalmente leva a ineficiência, a
geração de erros e perda de tempo. Por outro lado a engenharia de software tem proposto
metodologias e técnicas de reuso baseadas em orientação a objetos, que, utilizadas de
forma apropriada, podem levar a grandes ganhos de eficiência e qualidade no
gerenciamento da informação sobre a QEE. Como foi apresentado no item 2.2 existem
vários instrumentos de reutilização que apóiam um projeto de sistemas, e que podem ser
usados no projeto de um banco de dados, a fim de garantir qualidade, rapidez e sucesso no
processo de desenvolvimento.
Neste trabalho estaremos utilizando Padrões de Análise e um Framework
Conceitual (QEE_Frame), aplicáveis as etapas de requisitos e modelagem conceitual de
68
banco de dados para QEE visando facilitar o desenvolvimento de novos bancos de dados.
O objetivo é apresentar um modelo conceitual de um banco de dados (framework de
dados), que através de uma ferramenta de software permitirá a qualquer usuário não
especialista editar o modelo e montar o seu banco de dados para QEE.
O Framework Conceitual chamado QEE_Frame, utiliza a linguagem de modelagem
unificada UML acrescida de alguns esteriótipos (um mecanismo de extensão fornecido
pela UML ) para identificar pontos de variabilidade.
3.1
Requisitos de Modelagem Conceitual para SIQEE
A Figura 3.1 apresenta uma arquitetura de um Sistema de Informação para a
Qualidade da Energia Elétrica. A definição desta arquitetura foi possível considerando
vários aspectos: a definição de sistemas de informação, o conceito de QEE, e da análise
dos trabalhos relacionados [DAB95], [FERN99], [VIV001], [FAV02], [SAN02],
[CRU03],[ROM03], [MED03].
Analisando essa arquitetura para um SIQEE percebe-se que esse tipo de sistema
provê um conjunto de atividades, incluindo:
•
Medição de diversos fenômenos eletromagnéticos através de equipamentos
específicos (medidores) localizados nos locais onde se quer monitorar;
•
Armazenamento destas medidas, normalmente através de um banco de dados
digital;
•
Pesquisas sobre estas representações para produzir novas medidas e descobrir
novos relacionamentos através da integração de fontes diversas;
69
Local de Monitoração
Rede Local
Usuários
Medidor
Servidor
Usuários
Medidor
Meio de
Comunicação
Disponibilização
da Informação
Usuários
Medidor
Dados de
QEE
Figura 3.1: Arquitetura de um Sistema de Informação para Qualidade da Energia Elétrica.
Na Figura 3.1 observamos que em geral temos equipamentos monitores de QEE
localizados nos locais os quais desejamos monitorar, esses locais podendo estar
relacionados a um mesmo consumidor, ou a consumidores diferentes. Dados
correspondentes aos fenômenos eletromagnéticos em investigação são localmente
detectados, transmitidos e processados. Pode-se optar por várias formas de transmissão de
dados, as mais usadas são através de redes locais ou remotamente para consumidores
localizados em pontos geograficamente distantes. Os dados são transmitidos para um
servidor de dados que será responsável em armazenar toda a informação do sistema.
Esse servidor de dados geralmente utiliza um SGBD onde os dados podem ser
processados e armazenados. Para a disponibilização da informação há uma comunicação
entre o servidor de dados e os clientes, essa comunicação podendo ser via rede local ou
remotamente.
Os clientes têm acesso a base de dados com consultas pré-definidas que servem
para análise de dados relativos a QEE.
Com base nessas atividades é possível definir os requisitos para modelagem
conceitual de um SIQEE:
70
•
Requisitos de dados convencionais cadastrais para os locais de monitorização e
consumidores;
•
Tipos de equipamentos e ajustes necessários;
•
Os parâmetros que caracterizam os fenômenos eletromagnéticos medidos ou
simulados;
3.2
•
Valores de referência para QEE, tais como limites, curvas estabelecidas e etc;
•
Características de ocorrências de Campo;
Padrões de Análise de QEE
Uma das técnicas que vem crescendo em termos de utilização pelos projetistas de
sistemas orientados a objetos é o emprego de instrumentos que possibilitem a reutilização
de componentes de software através da definição de padrões. Estes padrões podem ser de
análise, projeto, implementação entre outros. Consideraremos aqui os padrões de análise.
Um padrão de análise é um mecanismo de reutilização que permite aos projetistas
menos experientes reutilizarem o conhecimento de outros especialistas durante a fase de
análise. Para [FOW97] a contribuição mais significativa não é o modelo fornecido como
solução, mas sim, o raciocínio que está por trás desta solução.
O processo de reconhecimento ou captura de um novo padrão de análise requer do
projetista, habilidade e experiência suficientes para perceber analogias existentes entre
partes de um projeto, de um sistema em estudo, que possam ser recorrentes em outros
sistemas.
Segundo [FER98], o processo de criação de padrões é feito através da identificação
de partes de um projeto que são possíveis candidatas à reutilização. Em seguida, esse
diagrama deve ser abstraído, suas especificidades devem ser eliminadas e o padrão deve
ser documentado de acordo com uma linguagem de descrição de padrões.
Para [ROB93] para que um analista consiga identificar um novo padrão de análise é
necessário que ele possua a habilidade de abstração. O processo de descoberta de padrões
71
reutilizáveis é uma tarefa mais difícil que utilizá-los, isso justifica-se pois esses padrões
devem desconsiderar aspectos característicos do sistema ou da organização ao qual o
sistema está sendo desenvolvido.
Em [LIS00] é apresentado um processo de captura de padrões, como está
apresentado na Figura 3.2, onde é apresentado o processo de criação e uso de padrões onde
a aplicação de padrões requer a percepção de uma analogia entre um problema atual e os
padrões disponíveis, com a conseqüente adaptação no projeto, do padrão identificado.
Padrão
Abstrato
Sistema A
Sistema B
Abstração
P1
Especialização
Analogia
P2
Figura 3.2: Processo de captura e aplicação de padrões.
O uso do processo apresentado na Figura 3.2 apresentou um resultado satisfatório
em [LIS00], porém para a definição de padrões de análise para QEE, foi necessário propor
uma extensão a esse processo, uma vez que tais padrões apresentam especificidades que
não foram consideradas por [LIS00].
Para gerar padrões para QEE, ou seja, aspectos comuns entre diversas aplicações,
propomos um novo processo baseado em comparação de aplicações desenvolvidas, com
análise de domínio do problema e com abordagem de padrões conhecidos. Comparação de
diversas aplicações foi feita por meio de revisão de literatura. Análise de domínio foi
conseguida através da experiência de especialistas, verificando-se as normas e relatórios
técnicos especializados. Por fim tinha-se a experiência de construir um sistema de
qualidade em energia elétrica.
A proposta sugerida na Figura 3.3 pode ser adaptada para qualquer domínio desde
que apresente um conjunto consistente de informações como os relatórios técnicos
72
especializados, normas relativas ao domínio (se existirem), e experiência de
projetistas/usuários de um determinado domínio.
Relatórios
Técnicos
Especializados
Normas
Experiência no
domínio
Padrão
Abstrato
Sistema A
Sistema B
Abstração
P1
Especialização
Analogia
P2
Figura 3.3: Processo de captura e aplicação de padrões de QEE.
A próxima etapa após o reconhecimento dos padrões é definir a linguagem que irá
descrever o padrão de análise. É importante que seja uma linguagem de amplo
conhecimento e fácil de ser entendida pelos usuários, que seja extensível a fim de atender
as especificidades que possam a vir a existir para aplicação.
De acordo com as características apresentadas no item 2.4, a UML atende a todos
esses requisitos. Assim para apresentar os padrões de análises propostos será utilizado a
notação gráfica do diagrama de classes da linguagem UML.
A seguir serão apresentados exemplos dos padrões de análise para QEE, baseado na
estrutura de definição de padrões apresentado no item 2.2.4.
3.2.1
Padrão Local de Monitorização
Problema: Como modelar dados referentes aos locais de monitorização a fim de
obter informações de qualidade da energia elétrica?
73
Contexto: A monitoração da qualidade da energia elétrica pode ser executada
objetivando vários fins, uma vez determinado o escopo de um projeto de monitoração. Em
função de um objetivo de monitoração, regiões ou zonas de um sistema elétrico, definidas
pelas seleções dos locais de monitorização, podem ser monitorados a fim de se obter
informações necessárias ao gerenciamento da qualidade da energia elétrica.
Forças:
•
Todo consumidor tem pelo menos um local de monitorização;
•
Um consumidor pode ter vários locais de monitorização;
•
Necessidade de obter dados do local de monitorização para QEE.
Solução: A Figura 3.4 mostra o diagrama de classes que compõe o padrão. Em
cada local de monitorização podemos ter um ou vários contatos associados, e o consumidor
que está sendo pesquisado pode ter vários locais monitorados.
Padrão Local de Monitorização
Local_Monitoracao
Cod_Local
Dat_Inicio_Monitoracao
Nom_Local
Des_Local
Num_Frequencia_alimentacao_local
Dat_Fim_Monitoracao
Val_Tensao_Nominal_Local
1
0..n
Local_Monit_Contato
Cod_Contato
Nom_Local_Contato
Car_Contato
Tel_Fax
Tel_Voz
Tel_Dados
Obs_Contato
1..n
1
Monitoracao_Consumidor
Cod_Consumidor
Nom_Consumidor
End_Consumidor
Ufe_Consumidor
Cep_Consumidor
Pais_Consumidor
Tel1_Consumidor
Tel2_Consumidor
Obs_Consumidor
Nom_Cont_Consumidor
Figura 3.4: Diagrama de Classes do Padrão Local de Monitorização
74
3.2.2
Padrão Equipamento de QEE
Problema: Como modelar dados referentes aos equipamentos (medidores) de
QEE?
Contexto: Os monitores de qualidade da energia elétrica são equipamentos com
capacidade para identificar informações de fenômenos eletromagnéticos diversos, em
diversas faixas de freqüências. Eles também possuem memória de dados, e são dotados de
dispositivos de transmissão de dados, tratamento de dados, entre outras características.
Forças:
•
Existem diversos equipamentos para medição/monitoração da QEE disponíveis
no mercado, cada qual com seus critérios de aquisição e pré-tratamento de
dados, e diferentes formatos de registro de dados.
•
Necessidade de se atender a diferentes formas de caracterização dos fenômenos
eletromagnéticos relativos a QEE, em decorrência do fato de ser ainda
incipiente a normatização relativa ao assunto .
Solução: A Figura 3.5 mostra o diagrama de classes que compõe o padrão. Um
equipamento de QEE pode ter vários canais. Cada canal pode ter uma grandeza associada a
um rótulo. Ao longo do tempo, esse equipamento pode estar monitorando locais diferentes.
Padrão Equipamento de QEE
Canal_Equipamento
Cod_Canal_Equipamento
Num_Canal
Raz_Transf_De
Raz_Transf_Para
*
Uni_Grandeza
Canal
1
Cod_Canal
Nom_Grandeza
Ind_Grandeza
Rot_Grandeza
*
Equipamento
Cod_Equipamento
Num_Serie
Nom_Fabricante
Nom_Modelo
Ver_Software
Str_Inic_Pc
Str-Inic_Equipamento
Obs_Equipamento
Figura 3.5: Diagrama de Classes do Padrão Equipamentos de QEE
75
3.2.3
Padrão Ajuste dos Equipamentos de QEE
Problema: Como modelar parâmetros de ajustes para os equipamentos de
monitoração de QEE?
Contexto: Os dados coletados pelos equipamentos monitores de QEE são entregues
sob a forma de pacotes de dados com uma formatação sugerida pelo fabricante. Este
formato de dados carrega toda a informação de identificação dos dados, de ajuste do
equipamento e dos eventos propriamente ditos.
Forças:
•
Para um equipamento podemos ter vários ajustes a fim de monitorar a QEE.
•
Necessidade de armazenar as informações dos ajustes para apoiar a análise
relativa aos dados coletados.
•
Os ajustes influenciam nos dados referentes aos distúrbios elétricos.
Solução: A Figura 3.6 mostra o diagrama de classes que compõe o padrão. Um
equipamento de QEE pode ter vários ajustes. Cada parâmetro de ajuste tem um tipo
associado. Em função do ajuste feito no equipamento teremos diferentes quantidades de
dados.
Padrão Ajuste Equipamentos QEE
Parametro_Aguste
Cod_Param_ajustavel
Dat_Ajuste
Val_Ajuste
*
Tipos_Ajustes
Cod_Ajuste
Des_Ajuste
Uni_Ajuste
1
Idc_Ajuste
Figura 3.6: Diagrama de Classes do Equipamento de QEE.
76
3.2.4
Padrão Eventos em um Sistema Elétrico
Problema: Como caracterizar distúrbios em um sistema elétrico?
Contexto: Os eventos são rótulos de identificação dos fenômenos eletromagnéticos
monitorados ou simulados. Eles estão relacionados com um conjunto de dados referentes
aos distúrbios. Distúrbios são informações que, após um tratamento formam pacotes de
informações que são identificados por um evento. Cada evento está relacionado a um local
de monitorização.
Forças:
•
Os distúrbios têm a característica de possuírem um tamanho e formato que
variam em função dos ajustes do equipamento monitor de QEE.
•
Necessidade de caracterização de diferentes fenômenos eletromagnéticos
(afundamentos, harmônicos,etc.).
Solução: A Figura 3.7 mostra o diagrama de classes que compõe o padrão. Eventos
são informações sobre distúrbios eletromagnéticos que são medidos pelos monitores de
QEE. Essa solução permite através do esteriótipo <<incomplete>>, mostrar que podem
existir outros distúrbios monitorados de acordo com a necessidade do projeto de banco de
dados .
Padrão Eventos em um Sistema Elétrico
Tratamento_Eventos
Cod_Tratamento_Eventos
Tam_Janela_Eventos
Tip_Janela_Eventos
*
Des_Janela_Eventos
<<Incomplete>>
Eventos_Tendencia_Vef
Cod_Tend_Rms
Val_Maximo
Val_Medio
Val_Minimo
Eventos_Estampa
1
Cod_Evento
Idc_Tipo_Evento
Dat_Inicio_Evento
<<Incomplete>>
Eventos_Harmonicos
Ord_Harmonico
Mod_harmonico
Ang_Harmonico
<<Incomplete>>
Eventos_Vtcd
Cod_Vtcd
Des_Max_Amp
Media_Amp
Dur_Vtcd
Des_Padrao_Amp
Med_Amp
Per_Tensao
Per_Energia
Idc_Tipo_Vtcd
Figura 3.7: Diagrama de Classes do Padrão Eventos em um Sistema Elétrico.
77
3.2.5
Padrão Normas e Organizações
Problema: Como modelar alguns valores de referência de QEE, considerando a
legislação atual ou futura, considerando os padrões brasileiros ou internacionais?
Contexto: Os valores de referência para a análise dos dados coletados, são aqueles
valores utilizados como referência para a comparação com os dados de distúrbios. A
Europa é a região mais avançada em relação a normas de QEE, uma vez que a norma
EN50160 foi oficialmente adotada por vários países. Nos EUA, muitas concessionárias têm
usado normas como a IEEE 519 apenas como referência. No Brasil, a ANEEL adotou para
a rede básica do sistema interligado brasileiro os critérios e limites para QEE definidos no
documento Padrões de Desempenho da Rede Básica. Com o crescimento de mercados
competitivos a possibilidade da inclusão de cláusulas referentes a QEE pode ser tornar
comum no futuro.
Forças:
•
Necessidade de ter vários valores comparativos a fim de diagnóstico de QEE.
•
Possibilidade de surgimento de novas normas ou ampliação das existentes.
Solução: A Figura 3.8 mostra o diagrama de classes que compõe o padrão. São
valores de referência para a análise dos dados coletados, são aqueles valores utilizados
como referência para a comparação com os objetos de dados de eventos. Esses valores são
limites normalizados ou não, tais como: EM 50160, IEC 61000-4-15, IEC 519, IEC 1159,
CBEMA, ITIC, valores propostos de curvas de suportabilidade de equipamentos, limites
estabelecidos por normas (IEE/ANSI, IEC, ABNT), e sumários de outras pesquisas.
78
Padrão Normas e Organizações
Norma_Instituto
Cod_Norma
Nom_Norma
Nom_Intituto
Dat_Norma
<<Incomplete>>
Harm_Ind_Tensao
Cod_Cit
Ref_Cit
Num_Cit
Lim_Perc_Cit
Niv_Tensao_Inf_Cit
Niv_Tensao_Sup_Cit
<<Incomplete>>
Tipo_Curva
Cod_Curva
Nom_Curva
Tip_Interpolacao
Des_Curva
<<Incomplete>>
Harm_ind_Corrente
Cod_Cic
Ref_Cic
Num_Cic
Iscil
Lim_Perc_Cic
Comp_Harm_Dht
Cod_Dht
Ref_Dht
Val_Dht
Tip_Dht
Niv_Tensao_Inf_Dht
Niv_Tensao_Sup_Dht
Dado_Curva
*
Cod_Par_Ordenado
Num_Tensao
Num_Amplitude
Figura 3.8: Diagrama de Classes do Padrão Normas e Organizações.
3.2.6
Padrão Ocorrências de Campo
Problema: Como modelar as ocorrências de campo considerando as várias
possibilidades observadas?
Contexto: As ocorrências de campo são informações diversas de registro de falhas
ocorridas junto ao local de monitoração, ou seja, fatos ocorridos no ambiente monitorado.
Os seus registros contêm informações de ocorrências de falhas em equipamentos instalados
no sistema elétrico monitorizado.
Forças:
•
As informações de ocorrências de campo auxiliam no diagnóstico na relação
entre as falhas ocorridas e os eventos registrados pelo equipamento de
monitoração de QEE.
•
Um local pode ter várias ocorrências e com uma certa freqüência.
•
Um local pode ter várias ocorrências aleatoriamente.
79
Solução: A Figura 3.9 mostra o diagrama de classes que compõe o padrão.
Ocorrências de campo são informações diversas de registros de falhas ocorridas junto a um
local de monitoração. Os registros devem conter informações de ocorrências de falhas em
equipamentos instalados no sistema elétrico monitorizado, para que se encontrem
associações entre estas falhas e os eventos registrados pelo instrumento monitor de
qualidade de energia. Estes registros são provenientes de informações dos usuários do
sistema elétrico.
Padrão Ocorrências de Campo
Ocorrencia
Cod_Ocorrencia
Dat_Ocorrencia
Hor_Ocorrencia
Dur_Ocorrencia
Obs_Ocorrencia
Falhas
*
Cod_Falhas
Des_Falhas
1
*
*
Tipo_Falha
1
Periodicidade
Cod_Idc_Falha
Des_IdcTipo_Falha
Cod_Periodicidade
Des_Periodicidade
Figura 3.9: Diagrama de Classes do Padrão Ocorrências de Campo.
3.3
Metodologia de Desenvolvimento de Frameworks
Existem algumas propostas de metodologias de desenvolvimento de Frameworks.
Essas metodologias consistem na captura de informações do domínio, a construção e o
teste da estrutura de Frameworks. Podemos citar três metodologias de desenvolvimento de
Frameworks: Projeto Dirigido por Exemplo (Example-Driven Design) [JOH93], Projeto
Dirigido por Hot Spot (Hot Spot Driven Design) [PRE95] e a metodologia de projeto da
empresa Taligent [TAL95]. Estas metodologias se caracterizam por estabelecer linhas
gerais, sem se ater à definição de técnicas de modelagem ou detalhar o processo.
Resumidamente
no
Projeto
Dirigido
por
Exemplo
estabelece
que
o
desenvolvimento de um Framework para um domínio de aplicação é decorrente de um
processo de aprendizado a respeito deste domínio, que se processa concretamente a partir
de desenvolvimento de aplicações ou do estudo de aplicações desenvolvidas
80
O processo de generalização ocorre a partir da busca de elementos que recebem
nomes diferentes, mas representam a mesma coisa, recorrendo a parametrização para
eliminar diferenças, particionando elementos para tentar obter elementos similares,
agrupando elementos similares em classes.
Analisar o domínio de
aplicações
(aplicações existentes)
Projetar estrutura de
classes
(o framework)
Testar sobre exemplos
Figura 3.10: As Etapas do Projeto Dirigido por Exemplo para o Desenvolvimento de um Framework.
Segundo [JOH93] o processo de desenvolvimento do Projeto Dirigido por Exemplo
(Figura 3.10), atravessa as etapas de análise, projeto e teste. A forma para desenvolver um
Framework é:
a) Análise do domínio:
•
assinalar as abstrações já conhecidas;
•
coletar exemplos de programas que poderiam ser desenvolvidos a partir do
Framework;
•
avaliar a adequação de cada exemplo;
b) Projetar uma hierarquia de classes que possam ser especializada para abranger
os exemplos (um Framework) – nesta etapa o autor recomenda a utilização de design
patterns.
c) Testar o framework usando-o para desenvolver os exemplos (implementar, testar
e avaliar cada exemplo usado na primeira etapa, utilizando para isto o Framework
desenvolvido).
O Projeto Dirigido por Exemplo carece de um conjunto de técnicas de modelagem
e de um processo de desenvolvimento detalhado. Isto sugere que a metodologia poderia ser
81
complementada por subsídios de metodologia OOAD - Object Oriented Analysis and
Design (Análise e Projeto Orientados a Objetos).
Já o Projeto Dirigido por Hot Spot [PRE95] a essência desta metodologia é
identificar os Hot Spots na estrutura de classes de um domínio, e, a partir disto, construir o
Framework. Um Framework possui partes propositalmente indefinidas – o que lhe dá a
capacidade de ser flexível e se moldar a diferentes aplicações. Podem ser definidas as
seguintes etapas (Figura 3.11):
•
Na primeira etapa o desenvolvedor do Framework, a partir de informações de
especialistas do domínio, define uma estrutura de classes.
•
Na segunda etapa, também com o auxílio de especialistas do domínio , são
identificados os Hot Spots. Deve-se definir o grau de flexibilidade que deve ser
mantido em cada caso.
•
Na terceira etapa, faz-se o projeto do Framework (ou reelaboração do projeto).
Consiste em modificar a estrutura de classes inicialmente definida, de modo a
comportar a flexibilidade requerida
•
A quarta etapa, consiste num refinamento da estrutura do Framework a partir de
novas intervenções de especialistas do domínio. Se após isto o Framework
avaliado como satisfatório, está concluída uma versão do Framework.
Identificação de classes
(Metodologia OOAD)
Identificação de Hot Spots
(Re)projeto do Framework
Design Patterns
Adaptação do Framework
Não
Hot Spots
Satisfazem?
Sim: Framework concluído
Figura 3.11: Etapas do Projeto Dirigido por Hot Spot para o desenvolvimento de um Framework.
82
Segundo [PRE95] a etapa de projeto do desenvolvimento do Framework é centrado
em design patterns, cuja aplicação é fundamental para garantir flexibilidade ao Framework
Por outro lado a metodologia proposta pela empresa Taligent [TAL95] difere das
anteriores pelo conjunto de princípios que norteia o desenvolvimento de Frameworks. A
visão de desenvolver um Framework cubra as características e necessidades de um
domínio é substituída pela visão de produzir um conjunto de Frameworks estruturalmente
menores e mais simples, que usados conjuntamente, darão origem às aplicações. Isso
justifica-se porque pequenos Frameworks são mais flexíveis e podem ser reutilizados mais
frenquentemente. Assim, a ênfase passa a ser o desenvolvimento de Frameworks pequenos
e direcionados a aspectos específicos do domínio. Essa metodologia apresenta os passos a
seguir:
•
identificar e caracterizar o domínio do problema;
•
definir a arquitetura e o projeto;
•
implementar o Framework;
•
desdobrar o Framework.
Em [SIL00] é apresentado uma análise comparativa dessas metodologias,
ressaltando que nenhuma das metodologias estabelece técnicas de modelagem capazes de
conter a descrição de projeto de Frameworks ou detalha o processo de desenvolvimento.
Sugerindo a necessidade de buscar subsídios em outras áreas, como as metodologias
OOAD, para a definição de um procedimento concreto de desenvolvimento.
Essas metodologias não atendem completamente ao desenvolvimento de um
Framework Conceitual para projeto de banco de dados que estamos visualizando, devido
às características destes ambientes de energia elétrica e ao conhecimento e experiência que
dispúnhamos para montar este framework. Isto levou esse trabalho a definir os passos que
inclui características da metodologia do Projeto Dirigido por Exemplo e do Projeto
Dirigido por Hot Spot, como pode ser visto a seguir:
•
Na primeira etapa, com o auxílio de especialistas do domínio (engenheiros,
projetistas, etc), normas técnicas, relatórios especializados, aplicações
83
consultadas na literatura, e aplicação desenvolvida foram analisados e
identificadas as classes comuns que irão compor os Framework.
•
A segunda etapa consiste em modificar a estrutura de classes inicialmente
definida, de modo a comportar a flexibilidade requerida. Nesta fase são usados
os padrões de análise que irão garantir a flexibilidade requerida, ou seja,
genérico o suficiente para ser utilizado em qualquer banco de dados para QEE.
•
Na terceira etapa, são feitas as modificações no Framework procurando
otimizar o projeto final do Framework.
3.4
Framework QEE_Frame
O QEE_Frame é um Framework conceitual que fornece um diagrama de classes
básico para auxiliar o projetista nos primeiros passos na modelagem conceitual de dados de
QEE, a partir do qual serão incluídos os padrões de análise necessários ao banco de dados
para QEE, que o projetista deseja construir.
O QEE_Frame é definido de acordo com as regras do formalismo da orientação a
objetos, utilizando a notação gráfica do diagrama de classes da linguagem UML (Figura
3.14).
O processo de desenvolvimento de um Framework pode seguir a linha do processo
unificado interativo e incremental, apesar desta linha está associada a uma aplicação
convencional, ela pode ser adaptada a fim de atender o desenvolvimento de um
Framework.
O ciclo de vida de um Framework pode ser associado em parte ao ciclo de vida de
uma aplicação convencional. Eles se diferem porque o Framework nunca é um artefato de
software isolado mas sua existência está sempre relacionada a existência de outros
artefatos, originados do Framework, a partir dele ou que exercem alguma influência na
definição da estrutura de classes do Framework.
84
Em [SIL00] ( Figura 3.12 ) é apresentado um demonstrativo do ciclo de vida de um
Framework, onde é apresentado várias fontes de informação que influem na definição da
estrutura de um Framework: artefatos de software existentes, artefatos de software
produzidos a partir do Framework e o conhecimento do desenvolvedor do Framework ( ou
da equipe de desenvolvimento). As setas representam o fluxo de informações que levam à
produção da estrutura de classes do Framework, bem como de aplicações sob o
Framework.
Figura 3.12: Ciclo de vida de Framewoks [SIL00].
É importante ressaltar a importância do papel do desenvolvedor. Ele responsável
por decidir que classes comporão a estrutura do Framework, suas responsabilidades e a
flexibilidade provida aos usuários do Framework. O desenvolvedor atua na construção e
manutenção do Framework.
No caso do QEE_Frame esse ciclo de vida sofre algumas alterações devido as
especificidades que esse framework requer, na Figura 3.13 é apresentado o ciclo de vida
para um Framework Conceitual para QEE.
Na Figura 3.13 é possível observar que as fontes de informação que influem na
estrutura da Framework aumentaram, uma vez que além das aplicações analisadas, é
necessário a interação com o usuário de QEE (engenheiro, projetista, etc), deve-se avaliar
os relatório técnicos especializados apresentados em vários trabalhos referentes a QEE, e
85
principalmente as normas existentes em relação a transmissão e distribuição da energia
elétrica referentes a índices de qualidade de QEE.
Geração do
framework
Usuário
Normas
Geração/
Alteração do
framework
Relatórios
Aplicações
framework
Aplicação
Alteração do
framework
Alteração do
framework
Geração
Esquema
Lógico
Modelo Lógico da
nova aplicação
Figura 3.13: Ciclo de vida do Framework QEE-Frame.
O QEE_Frame será definido de acordo com as regras do formalismo da orientação
a objetos, utilizando a notação gráfica do diagrama de classes da linguagem UML. A
Figura 3.14 mostra o diagrama de classes do QEE_Frame.
Pesquisa
Consumidor
1
*
Local Monitoração
1
*
Des_pesquisa
*
*
Objeto Convencional
*
Evento
Objeto QEE/Distúrbio
Figura 3.14: Diagrama de classes do QEE_Frame.
86
Pesquisa e Consumidor
As classes Pesquisa e Consumidor formam a base de qualquer aplicação de QEE.
Toda aplicação que trata QEE tem como objetivo o gerenciamento e a manipulação de um
conjunto de dados para um determinado consumidor que estará associado a uma pesquisa,
estando ainda relacionado a um sistema de distribuição/transmissão específico.
A idéia de Pesquisa visa agregar todas as informações referentes a um estudo de
QEE, sejam estas informações dos consumidores ou mesmo de pontos do sistema da
concessionária. Caso a pesquisa de QEE seja feita em um consumidor, informações como
o segmento de atuação, tipo de processo, entre outras são aqui reunidas. A vantagem que se
percebeu em usar essa definição no esquema conceitual é que esse mecanismo funciona de
forma a reduzir a complexidade dos sistemas que venham a se tornar grandes.
Sempre teremos um consumidor, ou seja quem faz o uso da energia elétrica que
está relacionado a um ou mais locais de monitorização, esses apresentam características
físicas, localização geográfica e características elétricas. O registro de locais de
monitorização deve ser composto por informações que descrevam ou caracterizem o local
de monitorização. Desta forma, permite-se o relacionamento dos locais com variáveis do
sistema elétrico (níveis de tensão, tamanho de alimentadores, existência de bancos de
capacitores e etc.)
Objeto Convencional
Normalmente num banco de dados relacionado a QEE, além dos dados referentes a
eventos/distúrbios elétricos (harmônicos, afundamentos de tensão e etc), existem também
objetos convencionais presentes em qualquer sistema de informação, como por exemplo
dados cadastrais do local onde aconteceram os distúrbios.
Evento e ObjetoQEE/Distúrbio
Eventos são rótulos de identificação dos eventos monitorados ou simulados. Estes
eventos possuem um aspecto temporal uma vez que estarão associados a uma data e hora.
Embora tenha sido adotado o nome “eventos”, essa classe representa a todos os dados
registrados pelo equipamento monitor de QEE, inclusive o dados de registro contínuo,
independente de sua ocorrência ser ou não eventual.
87
ObjetoQEE/Distúrbio é uma generalização de todas as classes do domínio. Neste
caso são incluídas aquelas classes que representam fenômenos relativos a QEE (Exemplo:
harmônicos, VTCD, valor eficaz, etc).
Através do Framework QEE_Frame é possível gerar um esquema conceitual
elaborado a partir da especialização das suas classes com a inclusão dos padrões de
análise. Nada impede o uso de padrões de projeto em conjunto com os padrões de análise.
88
4
Ambiente de Desenvolvimento de Software (ADS)
Este
capítulo
apresenta
as
principais
características
de
Ambiente
de
Desenvolvimento de Software no que se refere a conceituação, bem como a utilização de
um Ambiente de Desenvolvimento de Software Orientado a Domínio, o qual será proposto
um ambiente de definição para um banco de dados para QEE.
A qualidade e produtividade de software podem ser melhoradas pelo uso de
Ambientes de Desenvolvimento de Software (ADS). Um ADS é um sistema
computacional que provê suporte para o desenvolvimento, reparo e melhorias em software
e para o gerenciamento e controle destas atividades; contendo uma base de dados central e
um conjunto de ferramentas de apoio [OLI99a]. A base central atua como um repositório
para todas as informações relacionadas ao projeto ao longo do seu ciclo de vida e as
ferramentas oferecem apoio para as várias atividades técnicas e gerenciais passíveis de
automação que devem ser realizadas no projeto [MOU92].
4.1
Teoria do Domínio
A análise de domínio é definida para procurar organizar informações de domínio de
forma a torná-las reutilizáveis. Existem várias pesquisas dedicadas a engenharia de
software [OLI99a],[MIL95],[SIL00a]. Em [MIL95] foram identificados cinco níveis de
reutilização de informações de desenvolvimento de software:
•
conhecimento ambiental: refere-se ao conhecimento sobre transferência de
tecnologias e sobre os sistemas em uso;
•
conhecimento
externo:
refere-se
ao
conhecimento
do
processo
de
desenvolvimento utilizado e sobre o domínio ou área de aplicação para o qual
os sistemas são desenvolvidos;
•
arquiteturas funcionais: referem-se à especificação de funções e objetos de
dados;
•
estruturas lógicas: consistem de processos e arquiteturas de dados e os
fragmentos de código.
89
•
Essa classificação serviu de guia para a definição e estruturação de informações
nos diferentes trabalhos de orientação a domínio, que procuram organizar as
informações do domínio em um conjunto de itens que pudessem ser reutilizados
ao se descrever e construir um software.
Para [OLI99a] o trabalho de análise de domínio baseia-se nas seguintes crenças:
•
a necessidade de uma especificação para um domínio de informações
reutilizáveis, que refere-se à identificação, aquisição e representação das
informações dentro de um domínio;
•
o nível de coesão dos problemas do domínio, que torna possível a captura do
conhecimento necessário para a solução de diversos problemas, sob a forma de
um conjunto finito e pequeno de descrições reutilizáveis;
•
a estabilidade dos problemas de domínio, que torna possível diminuir o custo da
captura e representação da informação através da reutilização durante longos
períodos e em diversas situações e lugares.
O ambiente ADEBDQEE considera as especificações apresentadas anteriormente
por [OLI99a]. Este ambiente considera o uso de Frameworks e padrões de análise, neste
sentido [FAV97] afirma que a engenharia do domínio foi dificultada durante alguns anos
pela falta de tecnologias adequadas para registrar os resultados da análise de domínio, o
que foi conseguido com o surgimento e uso dos Frameworks orientados a objetos e os
padrões de modelagem.
A Teoria do Domínio é o modelo é o modelo de conhecimento do domínio a ser
utilizado para assistir o desenvolvimento ao longo do desenvolvimento de software[OLI].
A definição da teoria do domínio consiste em definir uma ontologia do domínio. Ontologia
é uma especificação explícita de uma conceituação, ou seja, uma especificação explicita
dos objetos, conceitos e outras entidades que assumimos existir em um área de interesse,
além das relações entre estes conceitos e restrições expressas através de axioma [GRU95].
Para [VAN97] uma ontologia do domínio expressa uma conceituação para um domínio
particular, definindo restrições na estrutura e conteúdo do conhecimento desse domínio.
90
Devido a grande quantidade de informações de um domínio a definição de uma
ontologia de domínio pode se tornar um processo muito longo. Portanto em [OLI] é definese que a teoria do domínio deve ser dividida em subteorias. Cada subteoria considera os
conceitos do domínio e relação entre esses conceitos que estão semanticamente mais
relacionados e em um mesmo nível de abstração. Para compor a teoria do domínio como
um todo são criadas também relações entre as subteorias. Cada subteoria pode se vista
como uma ontologia sobre uma parte do domínio específica.
4.2
Ontologia
O termo ontologia vem da filosofia significando uma explicação sistemática da
existência, ou seja, o que significa “existir”. O termo vem sendo amplamente utilizado em
diversas áreas, o que proporciona diferentes propostas para definir para o termo ontologia:
•
Ontologia é uma especificação explícita de uma conceituação [GRU95].
•
Ontologia é uma descrição parcial e explicita de uma conceituação [GUA95].
•
Ontologia é uma teoria sobre o domínio que especifica um vocabulário de
entidades, classes, propriedades, predicados e funções e um conjunto de
relações que necessariamente amarram esses vocabulários [FIK99].
Portanto percebe-se que existem várias visões e definições de ontologia na
literatura, mas qualquer definição resultará em um vocabulário, que representará o
entendimento consensual de um grupo de pessoas que atuam sobre um mesmo domínio. A
conceituação apresentada por [FIK99] é a que será usada neste trabalho.
Segundo [FOU02] as ontologias de aplicação descrevem conceitos dependentes do
domínio e da tarefa particulares e são especializações de ambas as ontologias, de domínio e
de tarefa. Estes conceitos freqüentemente correspondem a papéis desempenhados por
entidades do domínio quando da realização de uma certa atividade.
Uma ontologia pode ser utilizada com muitos objetivos que podem proporcionar
muitos benefícios [FOU02], um deles é tornar viável o entendimento comum, bem como
possibilitar a interoperabilidade de sistemas.
91
A utilização de ontologias tem um forte impacto na aquisição do conhecimento,
pois o conhecimento geral do domínio é capturado, organizado e especificado na forma de
um modelo de conhecimento [FAL98]. Além disso, ontologias possibilitam o
compartilhamento e o reuso do conhecimento por diferentes aplicações [FOU02].
Para representar um domínio é necessário focar em um número limitado de
conceitos que são suficientes e pertinentes para se criar uma abstração dele. Assim, um
aspecto central de qualquer atividade de modelagem consiste em desenvolver uma
conceituação: um conjunto de regras informais que restringem a estrutura de um pedaço de
realidade que um agente usa para isolar e organizar conceitos e relações pertinentes
[MIA02].
Portanto ontologias têm sido usadas para construir um ADSOD, isso deve-se a
necessidade de definir um modelo que torne explícita a conceituação básica do domínio em
questão, logo ontologias podem ser muito úteis para apoiar a orientação a domínio em um
ADS.
Segundo [MIA02] a idéia básica do uso de ontologias como especificações é
conduzir ao reuso de software em níveis de abstração mais altos. Se um ADSOD incorpora
uma ontologia de domínio, aplicações neste domínio podem ser desenvolvidas com base
em uma especificação compartilhada. Também, componentes de domínio, tais como
Frameworks e padrões de análise, que foram desenvolvidos com base em ontologias
podem ser usados em outras atividades do processo de software.
Um dos benefícios do uso de ontologias no desenvolvimento de software é a
reutilização de especificações de domínio na fase de especificações de requisitos. Portanto
para cada nova aplicação ao invés de definir uma conceituação nova, usa-se uma
abordagem baseada em ontologias, e elicitação e a modelagem de requisitos podem ser
realizadas em duas fases. Primeiro, o conhecimento de domínio geral deve ser extraído e
especificado na forma de ontologias. Estas ontologias são usadas para guiar a segunda fase
da análise de requisitos, quando são consideradas as particularidades de uma aplicação
especificações, diminuindo os custos da primeira fase e permitindo o compartilhamento e
reuso do conhecimento [MIA02].
92
Neste sentido este trabalho apresenta no ambiente ADEBDQEE que uso ontologias
para conduzir o reuso no que diz respeito a especificações do domínio na fase de
especificações de requisitos utilizando Frameworks e padrões de análise.
4.3
Ontologia e Base de Conhecimento
Na literatura percebe-se uma certa confusão quando define-se a ontologia e base de
conhecimento uma vez que às vezes são referenciadas como tendo o mesmo significando,
isso pode ser justificado uma vez que ambos capturam conceitos e suas relações dentro de
um domínio.
Para [GOM95] A generalidade da informação é a diferença mais importante entre
ontologias e base de conhecimento. As definições de ontologias são mais gerais do que o
conhecimento de uma base de conhecimento, de forma que estas podem ser compartilhadas
entre diferentes sistemas devendo ser independentes do sistema que irá compartilhar ou
reutilizar.
Segundo [GUA97] a diferença entre ontologia e base de conhecimento está
relacionada ao propósito de uma ontologia que é uma base de conhecimento particular
descrevendo fatos assumidos sempre como verdade por uma comunidade de usuários em
virtude de um significado em comum acordo sobre o vocabulário utilizado.
Portanto, uma ontologia provê um conjunto de conceitos e termos para descrever
algum domínio enquanto a base de conhecimento usa estes termos para representar o que
verdadeiro sobre o mundo real ou hipotético [SWA99]. Segundo [MUS98] uma base de
conhecimento pode ser vista como uma instanciação de uma ontologia, que significa
preencher as decisões dos conceitos da ontologia detalhado a aplicação que estiver sendo
construída.
Um dos objetivos deste trabalho é apoiar o entendimento do domínio
disponibilizando conhecimento do domínio. Esse conhecimento dever representar as
características do domínio, suas restrições e organização. Além disso esse conhecimento
93
deve ser útil na construção de ferramentas de desenvolvimento de software. Dessa forma,
optamos por utilizar ontologias para modelagem do domínio.
Essa escolha se deve a várias razões: o não comprometimento da modelagem do
conhecimento do domínio com qualquer aspecto que não seja as características do próprio
domínio, a possibilidade de trabalhar com o conhecimento que seja processável e que
possa ser utilizado em assistentes para apoio ao desenvolvimento no domínio, a boa e clara
definição de como esse conhecimento deve ser explicitado, estruturado e representado
[OLI99a].
4.4
Ambientes de Desenvolvimento de Software Orientado a Domínio (ADSOD)
Existem várias propostas para Ambiente de Desenvolvimento de Software Orientado
a Domínio. Estes ambientes tornam disponível o conhecimento sobre o domínio numa
representação simbólica utilizando ontologias do domínio e a identificação de possíveis
tarefas realizadas no domínio em questão.
Segundo [OLI99a] um Ambiente de Desenvolvimento de Software Orientado a
Domínio (ADSOD) são ADS que apóiam o desenvolvimento de software em domínios
específicos através do uso do conhecimento deste domínio durante todo o processo de
desenvolvimento para auxiliar o desenvolvedor no entendimento do problema. O domínio
é uma área de aplicação, no que se refere a essa dissertação o domínio é QEE.
A concepção desses ambientes está baseada na premissa de que uma das principais
dificuldades no desenvolvimento de sistemas é o fato dos desenvolvedores de software não
conhecem, ou não estarem familiarizados com o domínio para o qual devem desenvolver
um determinado sistema.
A idéia principal dos ADSOD é o uso do conhecimento do domínio no ADS.
Segundo [OLI99a] as principais questões para a definição de um ADSOD referem-se a:
•
Qual o conhecimento que deve estar disponível no ambiente.
•
Como este conhecimento deve estar organizado e representado.
•
Quando e como utilizar este conhecimento definido durante o desenvolvimento.
94
Para definir o conhecimento que deve estar disponível no ambiente e como este
conhecimento deve estar armazenado foi definida a Teoria do Domínio, que deve conter o
conhecimento do domínio a ser utilizado no ambiente. A Teoria do Domínio considera
descrições de tarefas relacionadas aos conceitos para facilitar o entendimento do
domínio[OLI99a].
Com relação a quando e como utilizar o conhecimento definido durante o
desenvolvimento, deve-se considerar o estudo e investigação do domínio nas diferentes
atividades do processo de software apoiando suas realizações [SIL00a].
Os elementos teoria do domínio, descrição de processo e processo de software são
incorporados ao ADSOD através de ferramentas de definição e são utilizados ao longo do
desenvolvimento de um sistema específico através de ferramentas de desenvolvimento.
A Teoria do Domínio é um modelo de conhecimento do domínio a ser utilizado
para assistir o desenvolvedor ao longo do desenvolvimento de software.
95
5
Ambiente de Definição de um Banco de Dados para Qualidade de
Energia Elétrica
A existência do Framework Conceitual bem como a definição dos padrões de análise
não é suficiente para proporcionar os engenheiros eletricistas, projetistas, profissionais
ligados a QEE o uso apropriado destes conceitos a fim de apoiar o desenvolvimento de um
banco de dados para QEE. Isso justifica-se pelos seguintes fatores:
•
Existência de pessoas ligadas a área de QEE mas que não dominam os
conceitos relacionados a engenharia de software;
•
Existência de pessoas ligadas a área de engenharia de software, mas que não
conhecem plenamente o domínio pesquisado (QEE);
•
A possibilidade da rotatividade de pessoas trabalhando em um projeto, o que
implica em explicar os conceitos básicos relacionado as duas áreas (QEE,
engenharia de software)a este novo membro .
Portanto, é necessária a existência de um Ambiente de Definição de um Banco de
Dados para Qualidade de Energia Elétrica (ADEBDQEE) com recursos que auxiliem nas
diversas atividades de desenvolvimento de um banco de dados. Este é um ambiente que
apresenta características de um Ambiente de Desenvolvimento de Software Orientado a
Domínio, justamente por propor um conjunto de ferramentas para o desenvolvimento
(análise, projeto e implementação), mas também a representação do conhecimento do
domínio, encurtando o tempo de aprendizado como um todo, tanto para a equipe no início
do projeto, quanto para novos integrantes que chegam à equipe durante o desenvolvimento.
A Figura 5.1 apresenta uma arquitetura para o Ambiente de Definição de um Banco
de Dados para Qualidade de Energia Elétrica, a qual é composta por três módulos. O
módulo gráfico fornece ao projetista uma interface que permite ao mesmo definir as
informações do domínio, e permite a recuperação e definição das informações de um
Framework conceitual, bem como dos padrões de análise.
O modulo dicionário de dados gera o esquema conceitual de um banco de dados
para QEE considerando o Framework conceitual, os padrões de análise e as extensões
96
necessárias definidas utilizando o módulo gráfico. Esse esquema conceitual estará em
formato XML a fim de proporcionar intercâmbio de informações na Web.
O módulo geração automática ficará responsável em ler o arquivo XML com o
esquema desejado e mapear para o SGBD específico para a aplicação em questão. Por
exemplo se estivermos tratando de um banco de dados relacional, este módulo será
responsável em ler o arquivo XML e mapear para tabelas.
97
Módulo Gráfico
Framework
Conceitual
Ferramenta
Case
Informações
Domínio
Editor de
Domínio
Repositório
Padrões
Análise
Editor de
Padrões
Linguagem
Programação
Módulo Dicionário de Dados
Esquema
Conceitual
QEE
XML
Módulo Geração Automática
Regras de
Transformação
Oracle
Ms.
Access
Interbase
Outros
Formatos
Figura 5.1: Arquitetura do Ambiente de Definição de um Banco de Dados para Qualidade de Energia
Elétrica.
5.1
Módulo Gráfico
Ambiente de Definição de um Banco de Dados para Qualidade de Energia Elétrica
(ADEBDQEE) apresenta um módulo gráfico que faz uso de uma ferramenta CASE10 como
apoio a modelagem de dados. Foram analisadas duas ferramentas o Rational Rose e o
Microsoft Visio Professional. Inicialmente optou-se pelo uso da ferramenta Rational Rose
10
Computer-aided software engineering (engenharia de software com o auxílio do computador. Ele se refere
a uma gama de diferentes tipos de programas utilizados para apoiar as atividades de processo de software,
como a análise de requisitos, modelagem de sistemas, a depuração e os testes [PRE01].
98
por apresentar uma facilidade em apoiar o processo de desenvolvimento de software e por
apresentar uma facilidade de exportação de diagramas para várias ferramentas disponíveis
no mercado.
O módulo gráfico apresenta também um editor de domínio que permite fazer a
edição da Teoria do Domínio, a linguagem usada para desse editor foi o Microsoft Visual
Basic, foram analisadas algumas linguagens tais como Pascal e Java. A escolha foi
definida devido a plataforma de apoio apresentada no projeto [PPGEE00], que será o
projeto instanciado e que poderia ser adicionado ao Sistema de Gerenciamento da
Qualidade da Energia Elétrica (SGQEE) como um módulo adicional. Mas nada impede o
desenvolvimento deste módulo utilizando outras linguagens.
Desta forma, esse módulo apresenta como saída um esquema conceitual para um
banco de dados definido em um formato de diagrama de classes da UML. Nesse módulo
também teremos armazenado toda a teoria do domínio, o que facilitará a evolução ou
criação de um Framework proporcionando o reuso de análise e projeto, e a recuperação do
conhecimento para novos membros que venham a participar do projeto.
No módulo gráfico temos a primeira etapa que é a edição da teoria do domínio.
Esse módulo foi construído considerando as características da Teoria do Domínio
apresentado no item 4.1, ou seja, um modelo que utiliza ontologias do domínio e relaciona
conceitos do domínio com tarefas pertinentes aquele domínio. Neste caso teremos
subteorias, conceitos, características desses conceitos e suas relações, o que implicou na
definição de um modelo que considerasse essas características. Na Figura 5.2 apresenta o
modelo que representa a definição do domínio e a descrição dos conceitos. No Apêndice A,
é apresentado a descrição do modelo, definição das entidades, atributos e relacionamentos.
99
Teoria_Dominio
CodTeoria
NomTeoria
DesTeoria
I
A80
A255
Framework_Conceitual
T eoria_Framework
CodFramework
NomArqFramework
I
A80
T eoria_Subteoria
Padrao_Analise
Sub_TeoriaDominio
Bibliografia
CodBibliografia
AutorBibliografia
DescBibliografia
EditEveBibliografia
InfoBibliografia
I
A80
A200
A100
A255
CodSubTeoria
NomSubTeoria
DesSubTeoria
I
A80
A255
Subt eoria_PadraoAnali se
CodPadrao
NomPadrao
DesProblema
ContextoPadrao
ForcasPadrao
ArquivoPadrao
SolucaoPadrao
I
A80
A100
A255
A255
A100
OLE
SubT eoriaConceito
Subteoria_Conceito
Subt eoria_Concei to_Bi bl io
CodConceito
SinConceito
DesConceito
NomConceito
I
A80
A255
A100
Figura 5.2: Modelo para edição da Teoria do Domínio.
As principais funções do módulo gráfico são:
- Permitir a entrada de informações de domínio: a partir de uma interface
amigável, o ambiente permite a inserção de todas as informações sobre o domínio
desejado;
- Permitir o acesso ao framework conceitual para QEE: a partir da interface
gráfica, o ambiente permite a visualização do Framework conceitual que irá ajudar os
usuários na definição do seu banco de dados para QEE.
- Permitir o acesso aos padrões de análise para QEE: a partir da interface
gráfica, o ambiente permite a visualização dos padrões de análise para QEE.
Na Figura 5.3 é a fase onde é permitida a edição da Teoria do Domínio (ApêndiceB é apresentado um demonstrativo da possibilidade de seleção das teorias existentes),
cada uma das subteorias (Figura 5.4), seus conceitos (Figura 5.7).
Figura 5.3: Inclusão da Teoria do Domínio.
100
Figura 5.4: Inclusão da subteoria
No Apêndice-B é apresentada a possibilidade de seleção das subteorias.
No ambiente ADEBDQEE podemos inserir padrões de análise como é mostrado na
Figura 5.5, a edição é feita através da ferramenta Rational Rose.
Figura 5.5: Inserir Padrão de Análise.
Para o Domínio de QEE foi necessário incluir a idéia de referências bibliográficas,
para que o usuário quiser ter mais informações sobre determinado conceito, tenha esses
dados no ambiente como é mostrado na Figura 5.6.
101
Figura 5.6: Inserir Referências Bibliográficas.
Outra funcionalidade do ambiente ADEBDQEE é a possibilidade do desenvolvedor
ao longo do projeto identificar e relacionar quais conceitos da Teoria do Domínio serão
utilizados em um determinado projeto, neste momento teremos a informação das
referências estão associadas a cada conceito, como é possível verificar na Figura 5.7.
Figura 5.7: Inserir Conceito.
102
Uma Teoria do Domínio pode ter várias sub-teorias associadas, que por sua vez
pode ter vários conceitos, essas determinações podem ser vistas nas Figuras Figura 5.8 e
Figura 5.9.
Figura 5.8: Inserir Associação entre Teoria do Domínio e Sub-teoria.
Figura 5.9: Inserir Associação entre Sub-teoria e Conceito.
103
Cada Subteoria pode ter padrões associados que ajudaram no processo de definição
do banco de dados para QEE, essa associação pode ser vista na Figura 5.10.
Figura 5.10: Inserir Associação entre Subteoria e Padrões de Análise.
A inserção do Framework Conceitual pode ser feita como pode ser visto na Figura
5.11, sua edição é feita pela ferramenta Rational Rose.
Figura 5.11:Inserir O Framework Conceitual de acordo com a Teoria do Domínio.
104
O usuário pode visualizar cada padrão de análise associado a cada subteoria, isso
facilita o reuso dos padrões (Figura 5.12).
Figura 5.12: Visualização das Subteorias e a relação com os Padrões de Análise.
Durante a construção da ontologia para dados de QEE, foi possível notar que essa
Teoria do Domínio apresentava detalhes que não se adequavam ao modelo proposto por
[OLI99a] e [SIL00], portanto foi necessário apresentar mudanças no modelo para edição
da Teoria do Domínio. Desta forma essas modificações acarretaram mudanças também na
interface.
Após a definição da Teoria do Domínio, o usuário será capaz de apresentar um
Framework Conceitual para um banco de dados para QEE, através de uma interface gráfica
que permite incluir o Framework, e editá-lo através da ferramenta Rational Rose. Também
é possível fazer uma associação das subteorias identificadas com os padrões de análise,
esses são editáveis através da ferramenta Rational Rose.
5.2
Módulo Dicionário de Dados
105
Nesta etapa teremos um diagrama de classes que representará um banco de dados
para QEE de acordo com a Teoria do Domínio, o Framework e os padrões de análise
selecionados. A ferramenta utilizada para modelagem (Rational Rose) do banco de dados
oferece a funcionalidade de conversão do diagramas de classes para o formato XML
(Figura 5.13), porém essa ferramenta faz o mapeamento do diagrama de classes para a
DTD e os coloca em arquivos separados, essa característica nos levou a usar uma
ferramenta intermediária que gerasse a DTD em um só arquivo. Essa forma de geração é
importante visto que podemos ter desenvolvedores interessados em desenvolver suas
próprias ferramentas de extração de dados, facilitando desta forma a leitura dos dados.
Existem várias ferramentas de modelagem que podem ser utilizadas para o mesmo
propósito tais como: Together, PowerDesigner entre outras. Neste trabalho estaremos
utilizando as ferramentas Rational Rose e a PowerDesigner, para modelagem dos dados e
mapeamento para XML.
Figura 5.13: Demonstrativo do uso da ferramenta Rational Rose para Conversão de Dados.
5.3
Módulo Geração Automática
106
Este módulo é mais específico, ou seja, dependente do SGBD o qual deseja-se
utilizar. O módulo dicionário de dados faz a leitura dos dados no formato XML, e converte
para o modelo lógico do SGBD considerado. No caso, os dados são convertidos para um
SGBD relacional.
Como a XML é um formato padrão, basta que o usuário conheça tal formato e faça
a conversão para o SGBD que deseja utilizar. Todo processo é auxiliado por ferramentas
específicas de mapeamento. Neste caso estaremos utilizando a ferramenta XMLSPY-2004
que será utilizada para a conversão dos dados em formato XML para tabelas para um
banco de dados específico.
A ferramenta XMLSPY foi desenvolvida pela empresa Altova, a escolha desta
ferramenta foi por dispor de um ambiente integrado que pode facilitar a troca de
informações entre várias ferramentas, e por apresentar um pacote de desenvolvimento de
documentos XML e de todos os documentos relacionados ( folhas de estilo, schemas, etc)
[ALT04].
107
6
Aplicação: Casos Exemplo
O estudo de caso tem o objetivo de avaliar o desempenho da metodologia de uso de
Frameworks e padrões de análise para projeto de banco de dados, verificando a
possibilidade de intercâmbio de informações na Web. Conforme mencionado na
introdução desta dissertação, foge ao escopo do trabalho a fase de pós-tratamento de dados.
Os casos estudados a seguir têm diferentes objetivos de monitorização, ou seja, são
diferentes situações em que o foco de interesse na qualidade da energia elétrica varia. O
primeiro caso é o Sistema de Gerenciamento da Qualidade da Energia Elétrica [PPGEE00],
já o segundo caso é a Caracterização da Sensibilidade de Processos Industriais Frente a
Afundamentos de Tensão [LEB03].
6.1
A Teoria do Domínio
A Teoria do Domínio para QEE foi definida segundo as normas relativas a QEE, a
partir de especialistas em QEE do grupo de pesquisa GERQUALI [PPGEE00] além de
consulta a trabalhos tais como: [PPGEE00], [FER99], [FERN99], [FER01], [ALV00],
[DIA01], [SAN02], entre outros.
É importante salientar que não é o objetivo desse trabalho explorar em todas os
detalhes o domínio de QEE. A Teoria do Domínio, apresentada a seguir, foi particularizada
para atender as necessidades do domínio em QEE, o que não impede a sua evolução
considerando as especificidades de novas teorias de domínio. Nosso objetivo foi utilizar
essa teoria para mostrar a sua aplicabilidades no ADEBDQEE.
A seguir serão apresentados cada um dos passos realizados para a definição da
Teoria do Domínio.
6.1.1
Identificação do Propósito
108
A definição de uma Teoria do Domínio para QEE, tem como objetivo apoiar o
desenvolvimento de um banco de dados para QEE. Dessa forma, é estabelecido um
vocabulário comum que possa facilitar a comunicação entre os diferentes participantes no
desenvolvimento de projeto de banco de dados, ou seja, desenvolvedores, engenheiros de
conhecimento, especialistas (engenheiros eletricistas) e usuários em geral.
A Teoria do Domínio para QEE, visa definir, hierarquizar e organizar conceitos no
que se refere a informações relativas a QEE.
6.1.2
Definição
Para definição da Teoria do Domínio vários ciclos de captura e especificação foram
realizados. Inicialmente foram analisados o conhecimento de especialistas em QEE,
procurando registrar os conceitos a medida em que iam surgindo. Com isso foi identificado
um conjunto de conceitos importantes da área de QEE que englobam informações de
diferentes níveis de abstração. Também foi necessário a análise de normas relativas a QEE,
e os trabalhos relacionados na área. Com a junção desses conceitos, foi possível perceber
que desenvolver sistemas nesta área pode requerer qualquer uma dessas informações o que
leva a necessidade de definição de diferentes conjuntos de conceitos que irão compor
diferentes sub-teorias para o domínio. A partir desses aspectos, identificaram-se as
seguintes questões de competência gerais:
a) Como estão organizados os dados relativos a locais de monitorização?
b) Que informações de equipamentos de monitorização são necessárias?
c) Como caracterizar os diferentes distúrbios eletromagnéticos monitorados?
d) Quais informações de ocorrência de campo devem ser armazenadas?
e) Como podemos analisar dados de QEE, utilizando valores de referência?
Para a identificação das sub-teorias foram definidas, inicialmente, questões de
competência gerais com base no objetivo definido para a Teoria do Domínio, ou seja, o
que seria importante e útil para o desenvolvimento de um banco de dados para QEE, e que,
portanto a Teoria do Domínio deveria contemplar. Foram identificados Grupos Principais.
109
6.2
Caso 1- Sistema de Gerenciamento da Qualidade da Energia Elétrica.
O primeiro caso estudado é o Sistema de Gerenciamento da Qualidade da Energia
Elétrica – SGQEE [PPGEE00], projeto cujo objetivo, consiste de um sistema de
monitoramento e transmissão remota de informações sobre QEE, associado a um banco de
dados relacional, apoiado por m conjunto de programas complementares, que permitem o
pré e pós-processamento de dados, bem como o cálculo estocástico de afundamentos de
tensão e análise da informação com base em técnicas de Inteligência Artificial. O sistema é
estruturado com base em objetivos específicos, capazes de fornecer de forma simples e
automatizada, relatórios que atendam a estes objetivos.
Considerando a arquitetura definida de acordo com a Figura 5.1 foi definido o
ambiente para o SGQEE.
6.2.1
Edição da Teoria do Domínio
A Teoria do Domínio, trata do sistema que desejamos pesquisar, descrevendo as
informações sobre o domínio em questão, neste caso estaremos pesquisando o domínio do
sistema SGQEE, como pode ser visto na Figura 5.3, onde temos:
•
Teoria: Sistema de Gerenciamento da Qualidade da Energia Elétrica.
•
Descrição da Teoria: O Sistema de Gerenciamento da Qualidade da Energia
Elétrica gerencia informações sobre QEE, sejam estas provenientes de
monitoração ou de simulações computacionais, bem como o pós-processamento
de dados para análise.
6.2.2
Edição da Sub-teoria
Para identificação das Sub-teorias foram definidas, inicialmente, questões de
competência gerais com base no objetivo definido para a Teoria do Domínio, como foi
visto no item 6.1.2 . A partir dessas questões gerais foi possível chegar às sub-teorias a
seguir:
110
•
Local de Monitorização: para responder a questão a), essa sub-teoria
caracteriza os dados cadastrais dos locais que desejamos monitorar.
•
Informações de Equipamentos: para responder a questão b), essa sub-teoria
caracteriza as informações cadastrais dos equipamentos, bem como dos ajustes.
•
Informações de Medição: para responder a questão c), essa sub-teoria
caracteriza os fenômenos relacionados a QEE que estão sujeitos a
monitorização de locais específicos.
•
Ocorrências de Campo: para responder a questão d), as ocorrências de campo
são informações diversas de registro de falhas ocorridas junto a um local de
monitoração. Os registros devem conter informações de ocorrências de falhas
em equipamentos instalados no sistema elétrico monitorizado, para que
encontrem relacionamentos entre estas falhas e os eventos registrados pelo
instrumento monitor de qualidade de energia. Esses registros são provenientes
de informações dos usuários do sistema elétrico e são , inicialmente, coletadas a
partir de um formulário que, contendo informações também sobre o sistema
elétrico, pode vir a fornecer informações para diagnóstico da ocorrência.
•
Valores Comparativos: para responder a questão e), os valores de referência
para a análise dos dados coletados, são aqueles valores utilizados como
referência para a comparação com os objetos de dados de eventos. Neste caso
estaremos considerando as normas relativas a afundamentos de tensão.
6.2.3
Edição de Conceitos
A partir das informações coletadas como descrito no item 6.1.2, é necessário definir
os conceitos relacionados a cada sub-teoria. A inclusão pode ser feita como pode ser vista
na Figura 5.7, os conceitos identificados são listados a seguir:
•
Sub-teoria Local de Monitorização
o Informações
do
Consumidor:
Informações
gerais
do
consumidor
monitorado;
o Informações do Contato do Local de Monitorização: Informações do
responsável pelo local de monitorização.
•
Sub-teoria Informações de Equipamentos
111
o Informações gerais do equipamento;
o Informações dos canais do equipamento;
o Informações relativas aos ajustes do equipamento.
•
Sub-teoria Informações de Medição
o Informações de Harmônicos;
o Informações de Variação de Tensão de Curta Duração;
o Informações de Valor Eficaz.
•
Ocorrências de Campo
o Tipo de Falha do Sistema: Identificação de falhas que podem ocorrer como
software e hardware, evidências físicas;
o Periodicidade: Freqüência que o ocorre a falha.
•
Valores Comparativos
o Curvas: Curvas usadas como referência, por exemplo CBEMA;
o Valores propostos de curvas de suportabilidade de equipamentos;
o Limites específicos estabelecidos por normas (IEEE/ANSI. IEC, ABNT);
o Sumários de outras pesquisas.
6.2.4
Integração do Framework Conceitual com os Padrões de Análise
Para gerar um esquema para um banco de dados para QEE, considerando o SGQEE,
utilizamos o Framework Conceitual e os padrões de análise identificados no item 3.2. Na
Figura 6.1 é apresentada uma instância do QEE_Frame onde podemos verificar o uso dos
padrões de análise. Após fazer a integração do Framework Conceitual com os padrões de
análise identificados, teremos um diagrama de classes que irá representar o banco de dados
para QEE, que então poderá ser mapeado para qualquer SGBD específico. Na Figura 6.1
foram omitidos os atributos das classes com o objetivo de simplificação do diagrama.
112
Pesquisa
n
Padrão Ajuste Equipamentos QEE
1
Padrão Ocorrências de Campo
Tipo_Falha
1
Padrão Local de Monitoração
*
Local_Monit_Contato
Local_Monitoracao
n
1 0..n
1..n
Ocorrencia
Periodicidade
1
1
n
*
Falhas
n
Tipos_Ajustes
Parametro_Aguste
*
*
1
Monitoracao_Consumidor
1
n
1
Padrão Equipamento de QEE
1
Equipamento
Canal
Padrão Eventos em um Sistema Elétrico
Tratamento_Eventos
Eventos_Estampa
n
n
n
Canal_Equipamento
1
*
1
Padrão Normas e Organizações
<<Incomplete>>
Eventos_Tendencia_Vef
1
<<Incomplete>>
Eventos_Harmonicos
<<Incomplete>>
Norma_Instituto
Eventos_Vtcd
<<Incomplete>>
Harm_Ind_Tensao
<<Incomplete>>
<<Incomplete>>
Harm_ind_Corrente
Tipo_Curva
Comp_Harm_Dht
Dado_Curva
n
Figura 6.1: Integração do Framework Conceitual – QEE_Frame e Padrões de Análise para o Caso 1.
6.2.5
Conversão do Diagrama de Classes em DTD
A etapa de conversão está relacionada com a Figura 5.1, ou seja, com o módulo
dicionário de dados, devido as especificidades das ferramentas foi feita a importação do
diagrama de classes da ferramenta Rational Rose para a PowerDesigner como pode ser
visto da figura . Para fins de visualização consideramos parte do diagrama de classes
apresentado na Figura 6.1. Consideramos a parte do diagrama reverente aos locais de
monitorização.
Na ferramenta PowerDesigner define-se a linguagem para conversão (XML-DTD)
que será utilizada como pode ser visto na Figura 6.2
113
Figura 6.2: Interface para definição da Linguagem de conversão do diagrama.
Após a definição da linguagem é feita a geração do arquivo como pode ser visto na
Figura 6.3.
Figura 6.3:Interface para geração do arquivo de dados no formato DTD
Temos então o arquivo .DTD gerado como pode ser visto no Apêndice C.
6.2.6
Mapeamento da DTD para um SGBD relacional
A etapa de mapeamento está relacionada ao módulo de geração automática, neste
caso utilizaremos a ferramenta XMLSPY, como pode ser visto na Figura 6.4.
114
Figura 6.4: Visualização da ferramenta XMLSPY.
Com essa ferramenta é possível fazer o mapeamento da DTD gerado para um SGBD
relacional, para tal, temos que criar um projeto e incluir os arquivos .DTD. Como pode ser
visto na Figura 6.5.
Figura 6.5:Inclusão dos arquivos gerados.
O próximo passo é a conversão para DTD/ Shema, formato W3C Shema.(Figura 6.6)
115
Figura 6.6:Conversão DTD/Shema.
Na figura a seguir podemos verificar o mapeamento de cada classe.
Figura 6.7:Demonstrativo das classes mapeadas.
Após o mapeamento é necessário fazer algumas alterações manuais para os atributos em
relação aos tipos, e definições de chave primária(Figura 6.8)
116
Figura 6.8:Interface para alterações de tipos de dados.
Como a conversão será feita para o Microsoft Access a Figura 6.9 mostra o
resultado alcançado. O script também pode ser armazenado em arquivo .sql (Figura 6.10).
Figura 6.9:Demonstrativo das tabelas que serão criadas no Microsoft Access.
117
Figura 6.10: Demonstrativo do Script em SQL.
Finalmente na fase final é feita a conversão do Shema para um banco de dados
relacional (Microsoft Access) como pode ser visto na Figura 6.11, define-se o banco para o
qual deseja realizar a conversão, e automaticamente as tabelas são criadas( Figura 6.12).
Figura 6.11:Seleção o SGBD que será utilizado.
118
Figura 6.12:Tabelas criadas no Microsoft Access.
6.3
Caso 2- Caracterização da Sensibilidade de Processos Industriais Frente a
Afundamentos de Tensão
O segundo caso estudado é o trabalho de Caracterização da Sensibilidade de
Processos Industriais Frente a Afundamentos de Tensão [LEB03], onde o objetivo deste
projeto propor uma metodologia para caracterização da sensibilidade das cargas e
processos incorporados a assimetria, o desequilíbrio, e outras características dos
afundamentos de tensão, tais como salto de ângulo de fase, ponto de início, e métodos de
caracterização a um parâmetro. Os estudos envolvendo afundamentos de tensão são
conduzidos a partir da monitoração das tensões do sistema elétrico ou através da utilização
de metodologias de predição [LEB03].
6.3.1
Edição da Teoria do Domínio
A seguir é apresentada a definição da Teoria do Domínio:
119
•
Teoria: Caracterização da Sensibilidade de Processos Industriais Frente a
Afundamentos de Tensão.
•
Descrição da Teoria: Caracterização da sensibilidade das cargas e processos
incorporando a assimetria, o desequilíbrio, e outras características dos
afundamentos de tensão, tais como salto de ângulo de fase, ponto início, e
métodos de caracterização de um parâmetro. Apresentando formas alternativas
para caracterizar o distúrbio, levando em conta a assimetria e o desequilíbrio
dos fasores de tensão, além de classificação dos eventos e os indicadores
utilizados para avaliar uma determinada barra do sistema.
6.3.2
Edição da Sub-teoria
Para identificação das Sub-teorias também foram definidas, inicialmente, questões
de competência gerais com base no objetivo definido para a Teoria do Domínio como foi
visto no item 6.1.2 . A partir dessas questões gerais foi possível chegar a sub-teorias a
seguir, que são editadas no ambiente de acordo com a Figura 5.3:
•
Local de Monitorização: para responder a questão a), essa sub-teoria
caracteriza os dados cadastrais dos locais de desejamos monitorar.
•
Informações de Equipamentos: para responder a questão b), essa sub-teoria
caracteriza as informações cadastrais dos equipamentos, bem como dos ajustes.
•
Informações de Medição: para responder a questão c), essa sub-teoria
caracteriza os fenômenos relacionados a QEE que estão sujeitos a
monitorização de locais específicos.
Destacamos que para esse estudo de caso aconteceu o reuso de conhecimento
definido pelo estudo de caso do item 6.2.
6.3.3
Edição de Conceitos
A partir das informações coletadas como descrito no item 6.1.2, também foi
definido os conceitos relacionados a cada sub-teoria. A inclusão pode ser feita como pode
120
ser vista na Figura 5.7. Essa interface permite a associação entre os conceitos e as
bibliografias existentes. Caso a bibliografia desejada não exista é possível incluir uma nova
como é mostrado na Figura 5.6. Os conceitos identificados são listados a seguir:
•
Sub-teoria Local de Monitorização
o Informações
do
Consumidor:
Informações
gerais
do
consumidor
monitorado;
o Informações do Contato do Local de Monitorização: Informações do
responsável pelo local de monitorização.
•
Sub-teoria Informações de Equipamentos
o Informações gerais do equipamento;
o Informações dos canais do equipamento;
o Informações relativas aos ajustes do equipamento.
•
Sub-teoria Informações de Medição
o Informações de Variação de Tensão de Curta Duração;
Nesta definição aconteceu o reuso total dos conceitos ligados as sub-teorias: Local
de Monitorização e Informações de Equipamentos, já o conceito relacionado a Informações
de Medição sofreu alterações de forma a atender este novo caso. Por outro lado alguns
conceitos não foram utilizados.
6.3.4
Integração do Framework Conceitual com os Padrões de Análise
Para gerar um esquema para um banco de dados para QEE, considerando
Caracterização da Sensibilidade de Processos Industriais Frente a Afundamentos de
Tensão, utilizamos o Framework Conceitual e os padrões de análise identificados no item
3.2, alguns serão reusados sem requerer mudanças, outros sofreram adaptações antes de
integração, e outros não serão utilizados. Os padrões de análise que não forem utilizados
podem ser facilmente incorporados quanto necessários.
Na Figura 6.13 é apresentada uma instância do QEE_Frame onde podemos verificar
o uso dos padrões de análise. Após fazer a integração do Framework Conceitual com os
padrões de análise identificados, teremos um diagrama de classes que irá representar o
banco de dados para QEE, que então poderá ser mapeado para qualquer SGBD específico.
121
Na Figura 6.13 foram omitidos os atributos das classes com o objetivo de simplificação do
diagrama.
n
Pesquisa
Padrão Ajuste Equipamentos QEE
n
Padrão Local de Monitoração
Local_Monitoracao
1..n
*
1
Tipos_Ajustes
Parametro_Aguste
1
1
*
Local_Monit_Contato
0..n
*
1
1
Padrão Equipamento de QEE
Monitoracao_Consumidor
1
Equipamento
Canal
Padrão Eventos em um Sistema Elétrico
Tratamento_Eventos
Eventos_Estampa
n
n
n
Canal_Equipamento
1
1
*
1
<<Incomplete>>
Eventos_Vtcd
Figura 6.13 : Integração do Framework Conceitual – QEE_Frame e Padrões de Análise para o Caso 2.
6.3.5
Conversão do Diagrama de Classes em DTD
Nesta etapa foram utilizados os mesmos critérios que no estudo de caso anterior
onde os resultados podem ser verificados no Apêndice D.
6.3.6
Mapeamento da DTD para um SGBD relacional
Nesta etapa também foram adotados os mesmos critérios dos itens anteriores os
quais podem ser verificados no Apêndice E.
122
7
Conclusões
Esta dissertação apresentou instrumentos que podem ser utilizados a fim de apoiar a
modelagem conceitual de um banco de dados para QEE. Esses instrumentos utilizam o
paradigma de orientação a objetos, empregando conceitos de reutilização baseada em
padrões de análise.
A partir da constatação que a maioria das aplicações de SIQEE são projetadas e
desenvolvidas pelos próprios usuários, houve uma preocupação em possibilitar uma
solução que possa ser utilizada na prática tanto por especialistas em computação quanto
por usuários sem experiência nesta área.
Inicialmente foram identificados e descritos alguns padrões de análise em
aplicações para QEE, com base em várias de informação como foi descrito no item 3.2 .
Padrões de análise são fáceis de serem utilizados porém difíceis de serem identificados,
requer do projetista uma habilidade de perceber sub-esquemas recorrentes, abstrair os
elementos essenciais de forma a torná-lo independente da aplicação, e depois documentar
esses padrões usando alguma linguagem de descrição de padrões. Foi então implementado
um ambiente de apoio a definição de um banco de dados para QEE, considerando a teoria
do domínio, padrões de análise e o Framework Conceitual.
Uma das grades vantagens do uso da UML foi a possibilidade de adotar uma
solução simples, utilizando os próprios recursos da linguagem. Assim alcançou-se uma
notação gráfica compacta de fácil aprendizado e entendimento por parte de usuários e
projetistas não especialistas em modelagem conceitual.
A solução UML/ QEE_Frame é independente de plataforma, essa característica é
uma vantagem proposta pela solução uma vez que habilita o usuário a utilizar qualquer
ferramenta CASE para UML existente no mercado.
Com os estudos de caso, foi possível fazer a verificação da arquitetura proposta
(arquitetura para definição de um banco de dados para QEE). Uma vez que no primeiro
estudo de caso o resultado alcançado foi coerente ao projeto [PPGEE00], e com o segundo
123
estudo de caso criou-se um novo banco de dados de acordo com a suas especificidades de
forma satisfatória.
7.1
Contribuições da dissertação
Utilização do paradigma de orientação a objetos para banco de dados para QEE, o
que não foi encontrado na literatura consultada. A definição de requisitos para modelagem
conceitual de um SIQEE.
O instrumento principal da abordagem de reutilização proposta na dissertação é o
Framework Conceitual QEE_Frame, ele fornece um entendimento básico dos elementos
presentes em qualquer banco de dados para QEE, servindo como ponto de partida para a
modelagem conceitual de banco de dados para QEE. Também foi possível definir uma
metodologia para a definição deste Framework. Não foi identificado na literatura
consultada nenhum padrão de análise para aplicações relacionadas a QEE, bem como a
utilização de um Framework Conceitual para apoiar o projeto de um banco de dados para
QEE.
Outra contribuição é a descrição de um conjunto de padrões de análise para QEE,
bem como uma proposta que representa a captura e a aplicação de padrões de QEE. Esses
padrões estão documentados utilizando uma linguagem universal que é a UML, o que
facilita a troca de informações entre grupos de pesquisa.
Com a definição do Framework QEE-Frame e um conjunto de padrões de análise,
foi possível estabelecer a possibilidade integração com aplicações SIG (Sistema de
Informação Geográfica). Essa nova possibilidade ser torna interessante uma vez que os
projetos orientados a objetos utilizando o conceito de reutilização, Frameworks e padrões
de análise, apresentados para SIG estão evoluídos e apresentam resultados satisfatórios.
Essa integração é uma oportunidade interessante visto que aplicações relativas a QEE
apresentam dados com características geográficas, o que apresentaria apoio a análise dos
dados relativos a QEE.
124
Uma contribuição importante é a definição de um ambiente para apoiar os
projetistas de banco de dados para QEE, que proporciona trabalhar com reutilização em um
nível mais alto de abstração que é a reutilização do conhecimento. Além de possibilitar a
integração das áreas de Engenharia Elétrica e Engenharia de Software, a fim de prover uma
melhor utilização dos dados para QEE.
7.2
Trabalhos Futuros
O resultado de processo de modelagem conceitual é um esquema conceitual de
dados. Após validado e aprovado, o esquema conceitual tem de ser transformado em um
esquema lógico, o qual é dependente do software a ser utilizado. Como não existe um
modelo lógico de SIQEE único não existe uma regra única para a transformação de um
esquema conceitual para um esquema lógico. Portanto pode-se desenvolver ferramentas
para a transformação de um esquema conceitual em um esquema lógico de SIQEE.
Essa primeira versão do ambiente ADEBDQEE não está na Web, mas foi projetado
de forma a facilitar a migração para a Web, isso seria uma vantagem para o ambiente uma
vez que teríamos a possibilidade de usuários localizados no consumidor pudessem interagir
diretamente com a adição de Teorias de Domínio. Com relação ao módulo geração
automática também teríamos uma vantagem, visto que o módulo dicionário de dados
disponibiliza os dados em formato XML, esse formato é compatível com a Web como foi
visto no item 2.5, o que facilita os grupos de pesquisas em QEE a criarem um módulo de
geração automática a fim de atender a necessidades de suas aplicações específicas para
QEE.
O desenvolvimento de uma ferramenta CASE específica para o ambiente
ADEBDQEE a fim de integrar a edição dos padrões de análise e do Framework
Conceitual.
Um dos pontos importantes e críticos de um SIQEE é o armazenamento de dados e
sua disponibilização. Com relação ao armazenamento, observa-se que teremos dados
referenciados ao longo do tempo, portanto temos uma grade massa de dados que serão
analisados após um certo período. Neste caso temos um alto custo para armazenamento e
125
uma grande quantidade de informações, o que torna interessante a troca de dados entre as
diversas instituições que se preocupam com a QEE, hoje na maioria dos casos a troca de
informação acontece através de instituições que trabalham em parceria, ou através de
grupos de pesquisas.
Com relação a disponibilização dos dados, as informações relativas a QEE são de
interesse das concessionárias, consumidores e grupos de pesquisa em QEE, mas hoje
somente os grupos de pesquisas e as concessionárias têm acesso a esse tipo de informação
de modo limitado, através de consultas pré-definidas.
Atualmente o processo de disponibilização de dados de QEE na Web é pouco
utilizado, uma forma interessante seria a disponibilização de dados utilizando o padrão
XML descrito nesta dissertação de forma a prover dados padronizados facilitando a troca
de informações na Web.
A disponibilização de consultas na Web apresenta grandes benefícios uma vez que
teremos medições distribuídas ao longo de áreas geográficas extensas. Desta forma
teremos usuários espalhados geograficamente tendo acesso aos dados. Esses dados além de
serem visualizados podem ser tratados e inseridos em um novo banco de dados, uma forma
de permitir essa funcionalidade, é fazendo o uso de XML (Extensible Markup Language).
A XML [W3C98] é um padrão aprovado pela W3C (World Wide Web Consortium) que
deve se tornar um formato universal para a troca de informações na Web.
126
8
Referências Bibliográficas
[ABT99] ABTEBOUL, S. et al. Data on the Web: From Relations to Semistructured Data and XML.
Morgan Kaufmann, 1999.
[AGO00] AGOSTINI, M.. N. et al. Desenvolvimento e Implementação de uma Base Computacional
Orientada a Objetos para Aplicações em Sistemas de Energia Elétrica. Anais do XIII Congresso
Brasileiro de Automática – CBA2000. Setembro, 2000. Florianópolis.
[ALD01] ALDABO, R. Qualidade na Energia Elétrica. São Paulo, Artliber, 2001.
[ALU01] ALUR, D. et al. Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall, 1ª.
Edição, 2001.
[ALT04] XML SPY 4.0 . Tutoriais Altova Inc. & Altova GmbH, 2003. Disponível com o software shareware
em http://www.xmlspy.com
[ALV00] ALVES, M. F. et al. Um Sistema para o Gerenciamento da Qualidade da Energia Elétrica.
XIII Congresso Brasileiro de Automática - CBA 2000, Setembro 2000, Florianópolis.
[BEZ02] BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. Editora Campus, Rio de
Janeiro, 2002.
[BAT92] BATINI, C. et al. Conceptual Database Design: Na Entity-Relationship Approach. Redwood:
Benjamin/Cummings, 1992.
[BOO99] BOCH, G., et al. The Unified Modeling Language User Guide. Addison-Wesley, 1999.
[BOS97] BOSCH, J. Adapting Object-oriented Components. In: Workshop Component-oriented
programming WCOP ´97, Jyvaskylä; Finland, 1997. Disponível em:
http://www5.bth.se/cgibin/MsmGo.exe?grab_id=60675328&EXTRA_ARG=&CFGNAME=MssFind%2Ecfg&host_id=4&page_id
=5409&query=Adapting+objectoriented+componentes&hiword=ADAPTING+OBJECTORIENTED+COM
PONENTES+COMPONENT+COMPONENTS+ADAPTATION+ADAPT+ADAPTED+ADAPTERS+ADA
PTER+ADAPTS+OBJECTORIENTATION+ADAPTION+ADAPTOR+ADAPTORS+COMPONENTY+A
DAPTIONS+COMPONENTI+
Acesso em (13/01/2004)
[CAR01] CARLSON, D. Modeling XML Applications with UML Practical e-Business Applications.
Addison Wesley, 2001.
[CHE02] CHEN, S.; F.Y.Lu. Web-Based Simulation of Power Systems. IEEE Computer Applications in
Power, Vol. 15, n° 1, janeiro/2002.
[CUN03] CUNHA, G. E., et al. Proposta de Padrões de Software para Reutilização Sistemática em
Sistemas de Software Orientados a Objetos. 2003
[CON03] CONALLEN, J. Building Web Applications with UML. Addison Wesley 2003.
[COU97] COUGO, P. S. Modelagem Conceitual e Projeto de Banco de Dados. Campus, Rio de Janeiro,
1997
[CRU03] CRUZ, J. C. A. O. et al. Administração de uma Rede de Aquisição e Distribuição de Dados
para Avaliação da Qualidade da Energia Elétrica. V SBQEE-Seminário Brasileiro sobre Qualidade da
Energia Elétrica, Agosto 2003, Aracaju.
127
[DAB95] DABBS, B. et al. The Power Quality Database: A Software Toll for Utility Engineers to Solve
Problems. IEEE Computer Applications in Power, p 72-79.
[DAN02] DANTAS, A., et al. Suporte a Padrões no Projeto de Software. XVI SBES – Simpósio
Brasileiro de Engenharia de Software, Outubro 2002, Gramado.
[DIA01] DIAS V. C. et al. Um Sistema de Aquisição de Dados para o Gerenciamento da Qualidade da
Energia Elétrica. IV SBQEE –Seminário Brasileiro sobre Qualidade da Energia Elétrica, Agosto 2001,
Porto Alegre.
[DUG96] DUGAN, R. C.; Mcgranahan, M. F., et al. Eletrical Power Systems Quality. McGraw-Hill, 1996.
[ECL04] Plataforma Eclipse. Disponível em http://www.eclipse.org. Acesso (15/01/2004)
[EDE94] EDELWEISS, N., Sistemas de Informação de Escritórios: um Modelo para Especificações
Temporais. Porto Alegre: CPGCC da UFRGS, 1994. Tese Doutorado.
[EMB87] EMBLEY, D. W., WOODFIELD, S. N., A knowledge structure for reusing abstracr data
types. In: International Conference on Software Engineering, 1987, Monterey. New York: IEEE Computer
Socity Press, 1987.
[FAL98] FALBO, R., Integração de Conhecimento em um Ambiente de Desenvolvimento de Software.
COPPE/UFRJ, Rio de Janeiro, RJ, 1998. Tese de Doutorado.
[FAV97] FAVARO, J. Standardizing Production of Domain Components. Standard View, vol 5, no. 2,
1997.
[FAV02] FAVARIN, S. et al. Sistema de Telemedição e Supervisão de Qualidade de Energia Elétrica.
Seminário Internacional sobre Automação e Redes de Distribuição de Energia Elétrica e Centros de Controle,
Setembro 2002, São Paulo.
[FAY97]FAYAD,M.,
et
al.
Object-Oriented
Communications of the ACM, New Yok, v. 40, n. 10, 1997.
Application
Frameworks.
[FAY99] FAYAD, M. et al. Building Applications Frameworks. Editora John Willey e Songs, 1999.
[FER98] FERNANDEZ, E. B. Building Systems Using Analysis Patterns. Procs. of Int. software
Architecture Workshop – ISAW3, 1998.
[FER99] FERNANDES, D. E. B., et al. Development of na Automated Power Quality Management
System. IEEE – Transmission and Distribution Conference, 1999, New Orleans.
[FERN99] FERNANDES, D. E. B., Uma Metodologia de Gerenciamento da Qualidade da Energia
Elétrica. PUC-Minas, Belo Horizonte, PPGEE, 1999. Dissertação de Mestrado.
[FER01] FERNANDES, D. E. B., et al. Um Banco de Dados Relacional para o Gerenciamento da
Qualidade da Energia Elétrica. IV SBQEE –Seminário Brasileiro sobre Qualidade da Energia Elétrica,
Agosto 2001, Porto Alegre.
[FIK99] FIKES, R. et al. Distributed Repositories of Highly Expressive Reusable Ontologies”. IEEE
Intelligent Systems & Their Applications, vol 14, no. 2, 1999.
[FOU02] FOURO, A. M. M. Apoio à Construção de Base de Dados de Pesquisa em Ambientes de
Desenvolvimento de Software Orientados a Domínio. COPPE/UFRJ, Rio de Janeiro, 2002. Dissertação de
Mestrado.
[FON99] FONSECA, V. R. C. Cálculo Estocástico do Afundamento de Tensão. PUC-Minas, Belo Horizonte,
PPGEE, 1999. Dissertação de Mestrado.
[FOW97] FOWLER, M., Analysis Patterns: Reusable Object Models, Addison Wesley, 1997.
128
[FOW00] FOWLER, M., et al. UML Distilled – A Brief Guide to the Standard Object Modeling
Language. Addison Wesley, 2000.
[FRA02] FRANCO, C. S. et al. Sistema de Geração de Base de Dados. Seminário Internacional sobre
Automação e Redes de Distribuição de Energia Elétrica e Centros de Controle, Setembro 2002, São Paulo.
[FUR98] FURLAN, J. D. Modelagem de Objetos através da UML. Makron Books, São Paulo, 1998.
[GAM95] GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison
Wesley, 1995.
[GER99] GERBER, L. D. Uma Linguagem de Padrões para o Desenvolvimento de Sistemas de Apoio à
Decisão Baseado em Frameworks. Porto Alegre, PUCRS, 1999. Dissertação Mestrado.
[GOM95] GÓMEZ-PÉREZ, A. Some Ideas and Examples to Evaluate Ontologies. In Proceedings of 11th
Coference in Artificial Intelligence for Applications, Los Angeles, 1995.
[GRA02] GRAVES, M. Designing XML Databases. Prenctice Hall, 2002.
[GRU95] GRUBER, T. R. Towards Principles for the Design of Ontologies used for Knowledge
Sharing. International Journal Human-Computer Studies, no. 43, 1995
[GUA95] GUARINO, N., et al. “Ontologies and Knowledge Bases – Towards a Terminological
Clarification”. In: Mars, N. J., Towards Very Large Knowledge Bases: Knowledge Building and Knowledge
Sharing, IOS Press, Amsterdan, 1995.
[GUA97] GUARINO, N. Semantic Matching: Formal Ontological Distinctions for Information
Organization, Extraction and Integration. In: Information Extraction: a Multidisciplinary Approach to na
Emerging Information Tecnhology, 1997.
[HAY95] HAY, D. C. Data Model Patterns: Conventions of Thought. Dorset House Publishing, 1995.
[HEU01] HEUSER, C. A. Projeto de Banco de Dados. Sagra Luzzatto, edição 4, número 4, 2001.
[HOL01] HOLZNER, S. Inside XML. New Riders Press, 2001.
[IEEE95] IEEE STANDARS BOARD, IEE Std 1159 – 1995 – Recommended pratice for Monitoring
Electric Power Quality, USA, 1995.
[JOH93] JOHNSON, R. E. How to Design Frameworks, OOPSLA, 1993. Disponível para ftp em:
st.cs.uiuc.edu. Conectar como anonymous. Pasta: /pub/papers/framework
[JON01] JONES, M. P. Fundamentos de Desenho Orientado a Objeto com UML. São Paulo, Makron
Books, 2001
[KAG03] KAGAN, N., et al. Desenvolvimento de Ferramenta Automatizada para Estimação da
Qualidade de Fornecimento das Redes de Distribuição. V SBQEE-Seminário Brasileiro sobre Qualidade
da Energia Elétrica, Agosto 2003, Aracaju.
[KOR99] KORTH, H. F. et al. Sistemas de Banco de Dados. Makron Books, edição 3, 1999.
[LAR99] LARMAN, C. Applying UML and Patterns – An Introduction to Object-Oriented Analysis
and Design. Prentice-Hall, 1999.
[LEB03] LEBORGHE R. C. Uma Contribuição à Caracterização da Sensibilidade de Processos
Industriais Frente a Afundamentos de Tensão. Itajubá, Universidade Federal de Itajubá, 2003. Dissertação
de Mestrado
129
[LIS00] LISBOA, J. F., Projeto Conceitual de Banco de Dados Geográficos através da Reutilização de
Esquemas, utilizando Padrões de Análise e um Framework Conceitual, Porto Alegre, UFRGS, PPGC,
2000. Tese de Doutorado.
[LIS01] LISBOA J. F. et al. Padrões de Análise para Aplicações de Gestão Urbana em Sistemas de
Informação Geográfica. In: Latin American conference on Pattern Languages of Programming, 2001.
[LIS02] LISBOA J. F., et al. Reutilização de Esquemas de Banco de Dados em Aplicações de Gestão
Urbana. Revista IP-Informática Pública, Belo Horizonte, V.4, n1, 2002.
[MAG01] MAGALHÃES, K. V. et al. Uma Abordagem de Dados Semi-Estruturados em Banco de Dados
Relacionais. XVI Simpósio Brasileiro de Banco de Dados, Rio de Janeiro, 2001.
[MED03] MEDEIROS, M. O. M. et al. Monitoração da Qualidade de Energia de um Sistema de
Distribuição. V SBQEE- Seminário Brasileiro sobre Qualidade da Energia Elétrica, Agosto 2003, Aracaju.
[MEL02] MELO, A . C. Desenvolvendo Aplicações com UML. Brasport, Rio de Janeiro, 2002.
[MES98] MESZAROS, G., et al. A Pattern Language for Pattern Writing. Disponível em:
http://webclass.cqu.edu.au/Patterns/Resources/writers/language/patterns.html#1.0 ou
http://hillside.net/patterns/writing/patterns.htm#1.0
[MIA02] MIAN, P. G. et al. Orientação a Domínio em ODE. Universidade Federal do Espírito Santo. In:
InfoUYClei, Montevideo, Uruguay, 2002.
[MIL95] MILI, H., et al. Reusing Software: Issues and Research Directions. IEEE Transactions on
Software Engineering, Vol. 21,no. 26, 1995.
[MON02] MONTEIRO, O. L. D. Aplicações de Padrões de Projeto no Desenvolvimento de Frameworks
– Um estudo de Caso. Florianópolis, UFSC, PPGCC, 2002. Dissertação Mestrado.
[MOU92] MOURA, L. M. et al. Ambientes de Desenvolvimento de Software, COPPE/UFRJ, Rio de
Janeiro, 1992. Documento Técnico.
[MUL99] MULLER, R. J. Database Designer for Smarties using UML for Data Modeling. Academic
Press, 1999.
[MUS98] MUSEN, M. A . Modern Architectures for Intelligent Systems: Reusable Ontologies and
Problem Solving Methods. JAMIA, Journal of the American Medical Informatics Association, 1998.
[NAV00] NAVATHE, S. B., et al. Fundamentals of Database Systems. Addison Wesley, 3rd Edition, 2000.
[NEI94] NEIGHBORS, J. M. An assessment of reuse technology after ten years. In: International
Conference on Software Reuse, 3., 1994, Rio de Janeiro. Proceedings... Los Alamitos, Califórnia: IEEE
Computer Socity Press, 1994.
[NET01] NETO, L. B., et al. DEA: Uma Aplicação no Controle da Qualidade da Energia Elétrica.
Simpósio Brasileiro de Pesquisa Operacional, Novembro 2001, Campos do Jordão.
[OLI99] OLIVEIRA, A. et al. Conservação de Energia e sua Relação com a Qualidade da Energia
Elétrica. XV SNPTEE –Seminário Nacional de Produção e Transmissão de Energia Elétrica, Outubro 1999,
Foz do Iguaçu.
[OLI99a] OLIVEIRA, K. M. Modelo para a Construção de Desenvolvimento de Software Orientados a
Domínio. Universidade Federal do Rio de Janeiro,COPPE, 1999. Tese de Doutorado.
[OLI] OLIVEIRA, K. M. et al. O Uso da Teoria do Domínio no Processo de Desenvolvimento de
Software.
130
[OMG99] OMG, Unified Modeling Language Specification. Versão 1.3, 1999. Disponível em:
http://www.rational.com.br/uml
Acesso em: (13/01/2004)
[ONS00] Operador Nacional do Sistema Elétrico-NOS/ANEEL. Padrões de Desempenho da Rede Básica.
2000. Disponível em : http:://www.ons.org.br.
[PEL03] PELEGRINI, M. A.et al.SISQUALI: Uma Ferramenta de Planejamento de Redes de
Distribuição Utilizando Parâmetros de Qualidade. V SBQEE- Seminário Brasileiro sobre Qualidade da
Energia Elétrica, Agosto 2003, Aracaju.
[PIM00] PIMENTEL, M. G. C., et al. XML: Explorando suas Aplicações na Web. XX Congresso
Nacional da Sociedade Brasileira de Computação , XIX Jornada de Atualização em Informática, Julho 2000,
Curitiba.
[PIT99] PITTS-MOULTIS, N. XML Black Book. Coriolis Groups, 1999.
[PPGEE00] PUC-MG/No. PPGEE-65/2000. Projeto de Pesquisa: Gerenciamento da Qualidade da
Energia Elétrica; financiamento CEMIG/PUC-FIP, abril 2000.
[PRE94] PREE, W. Meta Patterns – a means for capturing essencial of reusable object-oriented design.
In European Conference on Object-Oriented Programming.
[PRE95] PREE, W. Design Patterns of Object-Oriented software Development. Addison Wesley, 1995.
[PRE97] PREE, W., Essencial Framework Design Patterns. New York, 1997. Disponível em:
Acesso em:
[PRE01] PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. Edição 5, McGraw-Hill,
2001.
[REZ02] REZENDE, D. A . Engenharia de Software e Sistemas de Informação. Edição 2, Brasport, Rio
de Janeiro, 2002.
[RIB98] RIBEIRO, T. N. Uma Discussão dos Critérios e Normas Relativos à Qualidade da Energia
Elétrica. PUC-MG, Agosto, 1998. Dissertação de Mestrado.
[ROB93] ROBERTSON, S. et al. Reusing the Products of Analysis. Procs. of Int. Workshop on Software
Reusability. Lucca, Italy, 1993. Disponível em:
http://www.atlsysguild.com/GuildSite/SQR/reusingAnalysis.html
Acesso em (13/01/2004)
[ROM03] ROMERO, S. P., et al. Um Programa para Simulação de Afundamentos Momentâneos de
Tensão. Seminário Brasileiro sobre Qualidade da Energia Elétrica, Agosto 2003, Aracaju.
[SAN02] SANTOS, N. A . M. et al. Construção de Base de Dados de Medição Utilizando de
Ferramentas de Telemetria, Agregação e Análise via Web. Seminário Internacional sobre Automação e
Redes de Distribuição de Energia Elétrica e Centros de Controle, Setembro 2002, São Paulo.
[SIL00] SILVA, R. P. Suporte ao Desenvolvimento e uso de Frameworks e Componentes. Porto Alegre,
UFRGS, PPGC, 2000. Tese de Doutorado.
[SIL00a] SILVA C. G. M. Neturno: Um Ambiente de Desenvolvimento de Software Orientados ao Domínio
de Acústica Submarina. COPPE/UFRJ, 2000. Dissertação de Mestrado.
[SCH97] SCHMIDT, H. A .Systematic Framework Design by Generalization. Communications of the
ACM, vol 40, no.10, 1997.
[SUC98] SUCIU, D. Semistructured Data and XML. The 5th Internacional Conference of Foundations of
Data Organization - FODO’98, Kobe, Japan, Novembro, 1998.
131
[SWA99] SWARTOUT, W., et al. Ontologies – Guest Editors Introduction. IEEE Intelligent Systems &
Their Applications, vol 14, no. 1, 1999.
[TAL97] TALIGENT, Inc. Building Object-Oriented Frameworks. 1997. Disponível em: http://lhcbcomp.web.cern.ch/lhcb-comp/Components/postscript/buildingoo.pdf
Acesso em: (09/01/2004)
[TON03] TONSING,S. L. Engenharia de Software. Futura, São Paulo, 2003
[UCH] UCHÔA, E. M. A ., et al. Integração de Sistemas de Dados Heterogêneos usando Frameworks.
[VAN97] VAN, H. G. et al. Using Explicit Ontologies in KBS Development. International Journal of
Human-Computer Studies, val. 45, no. 2/3, 1997.
[VIV01] VIVEKANANDA, R. et al. Monitoração e Apresentação dos Indicadores de Qualidade da
Rede de Distribuição da CERJ, via Site dedicado na Internet, baseado em Medições de Harmônicos e
Afundamentos de Tensão. Seminário Internacional sobre Automação e Redes de Distribuição de Energia
Elétrica e Centros de Controle, Outubro 2001, Puerto Iguazu, Argentina.
[W3C98] The World Wide Web Consortium. Extensible Markup Language (XML) 1.0, February 1998.
http://www.w3.org/TR/REC-xml
132
9
Apêndices
No Apêndice – A é apresentado o projeto do banco de dados usado no Ambiente de
Definição de um Banco de Dados para QEE.
No Apêndice – B é apresentado as interfaces adicionais que compõe o Ambiente de
Definição de um Banco de Dados para QEE.
No Apêndice – C é apresentado o arquivo .DTD para o Caso exemplo: Sistema de
Gerenciamento da Qualidade da Energia Elétrica.
No Apêndice – D é apresentado a conversão do diagrama de classes para DTD para o
Caso exemplo : Caracterização da Sensibilidade de Processos Industriais frente a
Afundamentos de Tensão.
No Apêndice – E é apresentado o mapeamento da DTD para um SGBD relacional
para o Caso exemplo : Caracterização da Sensibilidade de Processos Industriais frente a
Afundamentos de Tensão.
133
Conceptual Data Model
Proj_ADEBDQEE
Apêndice - A
Standard CDM report
PowerDesigner
28/9/2005
Page
134
Conceptual Data Model
Proj_ADEBDQEE
Table of Contents
The 'Table of contents' field needs to be updated!
CDM GraphsCDM GraphsCDM Graphs
Global model GraphGlobal model GraphGlobal model Graph
Teoria_Dominio
CodTeoria
I
NomTeoria
A80
DesTeoria
A255
Teoria_Framework
Framework_Conceitual
CodFramework
I
NomArqFramework
A80
Teoria_Subteoria
Padrao_Analise
Sub_TeoriaDominio
Bibliografia
CodBibliografia
AutorBibliografia
DescBibliografia
EditEveBibliografia
InfoBibliografia
I
A80
A200
A100
A255
CodSubTeoria
NomSubTeoria
DesSubTeoria
I
A80
A255
Subteoria_PadraoAnalise
CodPadrao
NomPadrao
DesProblema
ContextoPadrao
ForcasPadrao
ArquivoPadrao
SolucaoPadrao
I
A80
A100
A255
A255
A100
OLE
SubTeoriaConceito
Subteoria_Conceito
CodConceito
I
SinConceito
A80
DesConceito
A255
NomConceito
A100
Subteoria_Conceito_Biblio
Lists of objectsLists of objectsLists of objects
Data Item ListData Item ListData Item List
Name
ArquivoPadrao
AutorBibliografia
CodBibliografia
CodConceito
CodFramework
CodPadrao
CodSubTeoria
CodTeoria
ContextoPadrao
DescBibliografia
DesConceito
DesProblema
DesSubTeoria
DesTeoria
EditEveBibliografia
FigFramework
ForcasPadrao
InfoBibliografia
NomArqFramework
NomConceito
NomPadrao
NomSubTeoria
NomTeoria
SinConceito
Code
ARQUIVOPADRAO
AUTORBIBLIOGRAFIA
CODBIBLIOGRAFIA
CODCONCEITO
CODFRAMEWORK
CODPADRAO
CODSUBTEORIA
CODTEORIA
CONTEXTOPADRAO
PERIODICOBIBLIOGRAFIA
DESCONCEITO
DESPROBLEMA
DESSUBTEORIA
DESTEORIA
EDITEVEBIBLIOGRAFIA
FIGFRAMEWORK
FORCASPADRAO
INFOBIBLIOGRAFIA
NOMARQFRAMEWORK
NOMCONCEITO
NOMPADRAO
NOMSUBTEORIA
NOMTEORIA
SINCONCEITO
PowerDesigner
28/9/2005
Type
A100
A80
I
I
I
I
I
I
A255
A200
A255
A100
A255
A255
A100
PIC
A255
A255
A80
A100
A80
A80
A80
A80
Page
135
Conceptual Data Model
Proj_ADEBDQEE
Name
Code
SOLUCAOPADRAO
SolucaoPadrao
Type
OLE
Entity ListEntity ListEntity List
Name
Bibliografia
Framework_Conceitual
Padrao_Analise
Sub_TeoriaDominio
Subteoria_Conceito
Teoria_Dominio
Code
BIBLIOGRAFIA
FRAMEWORK_CONCEITUAL
PADRAO_ANALISE
SUB_TEORIADOMINIO
SUBTEORIA_CONCEITO
TEORIA_DOMINIO
Relationship ListRelationship ListRelationship List
Name
Subteoria_Conceito_Biblio
Subteoria_PadraoAnalise
SubTeoriaConceito
Teoria_Framework
Teoria_Subteoria
Code
SUBTEORIA_CONCEITO_BIBLIO
SUBTEORIA_PADRAOANALISE
SUBTEORIACONCEITO
TEORIA_FRAMEWORK
TEORIA_SUBTEORIA
Entity InformationEntity InformationEntity Information
Entity BibliografiaEntity BibliografiaEntity Bibliografia
Name:
Code:
Label:
Number:
Bibliografia
BIBLIOGRAFIA
Generate Table:
Yes
Description
Informações sobre referencias bilbiográficas onde possa ser encontrado informações adicionais a respeito do
Conceito.
Attribute List
Name
CodBibliografia
AutorBibliografia
DescBibliografia
EditEveBibliografia
InfoBibliografia
Code
CODBIBLIOGRAFIA
AUTORBIBLIOGRAFIA
PERIODICOBIBLIOGRAFIA
EDITEVEBIBLIOGRAFIA
INFOBIBLIOGRAFIA
Type
I
A80
A200
A100
A255
I
Yes
No
No
No
No
M
Yes
No
No
No
No
Data Item CodBibliografia
Description
Código identificador da Bibliografia
Data Item AutorBibliografia
Description
PowerDesigner
28/9/2005
Page
136
Conceptual Data Model
Proj_ADEBDQEE
Autor da Bibliografia relacionada.
Data Item DescBibliografia
Description
Nome do livro, artigo, etc. da Bibliografia relacionada.
Data Item EditEveBibliografia
Description
Editora / Evento: Congresso Bibliografia relacionada.
Data Item InfoBibliografia
Description
Informações adicionais.
Reference List
Entity
Card
Subteoria_Conceito(SUBTEORIA_CONC 1,n
EITO)
Dep.
Relationship
No
Subteoria_Conceito_Biblio(SUBTEORIA
_CONCEITO_BIBLIO)
Entity Framework_ConceitualEntity Framework_ConceitualEntity
Framework_Conceitual
Name:
Code:
Label:
Number:
Framework_Conceitual
FRAMEWORK_CONCEITUAL
Generate Table:
Yes
Description
Informações sobre os frameworks existentes. Que pertecem a alguma Teoria de Domínio
Attribute List
Name
CodFramework
NomArqFramework
Code
CODFRAMEWORK
NOMARQFRAMEWORK
Type
I
A80
I
Yes
No
M
Yes
Yes
Data Item CodFramework
Description
Código idenficador do Framework Conceitual.
Data Item NomArqFramework
Description
Nome do Arquivo que idenfica o Framework.
PowerDesigner
28/9/2005
Page
137
Conceptual Data Model
Proj_ADEBDQEE
Annotation
Arquivos de idenficação: .mdl
Reference List
Entity
Teoria_Dominio(TEORIA_DOMINIO)
Card
1,1
Dep.
Relationship
No
Teoria_Framework(TEORIA_FRAMEW
ORK)
Entity Padrao_AnaliseEntity Padrao_AnaliseEntity Padrao_Analise
Name:
Code:
Label:
Number:
Padrao_Analise
PADRAO_ANALISE
Generate Table:
Yes
Description
Infomações de Padrões de Análise para QEE, de acordo com a Teoria do Domínio.
Attribute List
Name
CodPadrao
NomPadrao
DesProblema
ContextoPadrao
ForcasPadrao
ArquivoPadrao
SolucaoPadrao
Code
CODPADRAO
NOMPADRAO
DESPROBLEMA
CONTEXTOPADRAO
FORCASPADRAO
ARQUIVOPADRAO
SOLUCAOPADRAO
Type
I
A80
A100
A255
A255
A100
OLE
I
Yes
No
No
No
No
No
No
M
Yes
Yes
Yes
Yes
Yes
Yes
No
Data Item CodPadrao
Description
Identifica o padrão de análise.
Data Item NomPadrao
Description
Nome do Padrão de Análise.
Data Item DesProblema
Description
Fornece uma declaração sucinta do problema que necessita ser resolvido.
Annotation
Normalmente colocado na forma de pergunta.
Data Item ContextoPadrao
PowerDesigner
28/9/2005
Page
138
Conceptual Data Model
Proj_ADEBDQEE
Description
Contexto: descreve o contexto no qual o problema foi identificado e para o qual a solução foi proposta.
Data Item ForcasPadrao
Description
Forças: Conjunto de restrições que foram consideradas quando da elaboração da solução do problema.
Data Item ArquivoPadrao
Description
Arquivo .mdl que identifica o padrão.
Data Item SolucaoPadrao
Description
Solução: Fornece um diagrama de classes com a solução proposta.
Reference List
Entity
Sub_TeoriaDominio(SUB_TEORIADOMI
NIO)
Card
1,n
Dep.
Relationship
No
Subteoria_PadraoAnalise(SUBTEORIA_
PADRAOANALISE)
Entity Sub_TeoriaDominioEntity Sub_TeoriaDominioEntity Sub_TeoriaDominio
Name:
Code:
Label:
Number:
Sub_TeoriaDominio
SUB_TEORIADOMINIO
Generate Table:
Yes
Attribute List
Name
CodSubTeoria
NomSubTeoria
DesSubTeoria
Code
CODSUBTEORIA
NOMSUBTEORIA
DESSUBTEORIA
Type
I
A80
A255
I
Yes
No
No
M
Yes
Yes
Yes
Data Item CodSubTeoria
Description
Código idenficador da subteoria do domínio.
Data Item NomSubTeoria
Description
Nome da subteoria do domínio.
Data Item DesSubTeoria
PowerDesigner
28/9/2005
Page
139
Conceptual Data Model
Proj_ADEBDQEE
Description
Descrição da Subteoria do Domínio.
Reference List
Entity
Padrao_Analise(PADRAO_ANALISE)
Card
1,n
Subteoria_Conceito(SUBTEORIA_CONC 1,n
EITO)
Teoria_Dominio(TEORIA_DOMINIO)
1,n
Dep.
Relationship
No
Subteoria_PadraoAnalise(SUBTEORIA_
PADRAOANALISE)
No
SubTeoriaConceito(SUBTEORIACONC
EITO)
No
Teoria_Subteoria(TEORIA_SUBTEORIA
)
Entity Subteoria_ConceitoEntity Subteoria_ConceitoEntity Subteoria_Conceito
Name:
Code:
Label:
Number:
Subteoria_Conceito
SUBTEORIA_CONCEITO
Generate Table:
Yes
Description
Definição dos Conceitos para as Subteorias.
Attribute List
Name
CodConceito
SinConceito
DesConceito
NomConceito
Code
CODCONCEITO
SINCONCEITO
DESCONCEITO
NOMCONCEITO
Type
I
A80
A255
A100
I
Yes
No
No
No
M
Yes
No
No
No
Data Item CodConceito
Description
Código identificador do Conceito.
Data Item SinConceito
Description
Sinônimo do Conceito.
Data Item DesConceito
Description
Descrição do Conceito.
Data Item NomConceito
Description
Nome que identifica o conceito.
PowerDesigner
28/9/2005
Page
140
Conceptual Data Model
Proj_ADEBDQEE
Reference List
Entity
Bibliografia(BIBLIOGRAFIA)
Card
1,n
Sub_TeoriaDominio(SUB_TEORIADOMI
NIO)
1,n
Dep.
Relationship
No
Subteoria_Conceito_Biblio(SUBTEORIA
_CONCEITO_BIBLIO)
No
SubTeoriaConceito(SUBTEORIACONC
EITO)
Entity Teoria_DominioEntity Teoria_DominioEntity Teoria_Dominio
Name:
Code:
Label:
Number:
Teoria_Dominio
TEORIA_DOMINIO
Generate Table:
Yes
Description
Responsável pela Definição da Teoria do Domínio
Annotation
Exemplo: Domínio Sistema Gerenciador para Qualidade da Energia Elétrico, Sistema de Monitoração da
Qualidade da Energia Elétrica.
Attribute List
Name
CodTeoria
NomTeoria
DesTeoria
Code
CODTEORIA
NOMTEORIA
DESTEORIA
Type
I
A80
A255
I
Yes
No
No
M
Yes
Yes
Yes
Data Item CodTeoria
Description
Código que idenfica a Teoria do Domínio.
Data Item NomTeoria
Description
Nome da Teoria da Domínio
Data Item DesTeoria
Description
Descrição da Teoria do Domínio
Reference List
Entity
Framework_Conceitual(FRAMEWORK_
CONCEITUAL)
Sub_TeoriaDominio(SUB_TEORIADOMI
NIO)
PowerDesigner
Card
1,n
1,n
28/9/2005
Dep.
Relationship
No
Teoria_Framework(TEORIA_FRAMEW
ORK)
No
Teoria_Subteoria(TEORIA_SUBTEORIA
)
Page
141
Conceptual Data Model
Proj_ADEBDQEE
Relationships InformationRelationships InformationRelationships Information
Relationship Subteoria_Conceito_BiblioRelationship
Subteoria_Conceito_BiblioRelationship Subteoria_Conceito_Biblio
Name:
Subteoria_Conceito_Biblio
Code:
SUBTEORIA_CONCEITO_BIBLIO
Label:
Entity 1:
Bibliografia
Entity 2:
Subteoria_Conceito
Cardinality:
Many to Many
Entity 2 dependent of Entity 1:
No
Entity 1 --> Entity 2:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
Entity 2 --> Entity 1:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
Relationship Subteoria_PadraoAnaliseRelationship
Subteoria_PadraoAnaliseRelationship Subteoria_PadraoAnalise
Name:
Subteoria_PadraoAnalise
Code:
SUBTEORIA_PADRAOANALISE
Label:
Entity 1:
Sub_TeoriaDominio
Entity 2:
Padrao_Analise
Cardinality:
Many to Many
Entity 2 dependent of Entity 1:
No
Entity 1 --> Entity 2:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
Entity 2 --> Entity 1:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
Relationship SubTeoriaConceitoRelationship SubTeoriaConceitoRelationship
SubTeoriaConceito
Name:
Code:
Label:
PowerDesigner
SubTeoriaConceito
SUBTEORIACONCEITO
28/9/2005
Page
142
Conceptual Data Model
Proj_ADEBDQEE
Entity 1:
Sub_TeoriaDominio
Entity 2:
Subteoria_Conceito
Cardinality:
Many to Many
Entity 2 dependent of Entity 1:
No
Entity 1 --> Entity 2:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
Entity 2 --> Entity 1:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
Relationship Teoria_FrameworkRelationship Teoria_FrameworkRelationship
Teoria_Framework
Name:
Teoria_Framework
Code:
TEORIA_FRAMEWORK
Label:
Entity 1:
Teoria_Dominio
Entity 2:
Framework_Conceitual
Cardinality:
One to Many
Entity 2 dependent of Entity 1:
No
Entity 1 --> Entity 2:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
Entity 2 --> Entity 1:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, 1
Relationship Teoria_SubteoriaRelationship Teoria_SubteoriaRelationship
Teoria_Subteoria
Name:
Teoria_Subteoria
Code:
TEORIA_SUBTEORIA
Label:
Entity 1:
Teoria_Dominio
Entity 2:
Sub_TeoriaDominio
Cardinality:
Many to Many
Entity 2 dependent of Entity 1:
No
Entity 1 --> Entity 2:
Role:
Mandatory:
Yes
Dominant:
No
PowerDesigner
28/9/2005
Page
143
Conceptual Data Model
Min, Max:
Proj_ADEBDQEE
1, n
Entity 2 --> Entity 1:
Role:
Mandatory:
Yes
Dominant:
No
Min, Max:
1, n
PowerDesigner
28/9/2005
Page
144
Apêndice – B
Esse apêndice apresenta a possibilidade de recuperação e alteração das Teorias do
Domínio e Subteorias, Figuras Figura 9.1e Figura 9.2.
Figura 9.1: Seleção da Teoria do Domínio.
Figura 9.2: Seleção da Subteoria.
145
Apêndice – C
Demonstrativo da geração do documento .DTD gerado para o Caso 1: Sistema de
Gerenciamento da Qualidade da Energia Elétrica. (Parte)
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT Local_Monitoracao
(Cod_Local,Dat_Inicio_Monitoracao,Nom_Local,Des_Local,Num_Fre
quencia_alimentacao_local,Dat_Fim_Monitoracao,Val_Tensao_Nomi
nal_Local)>
<!ELEMENT Local_Monit_Contato
(Cod_Contato,Nom_Local_Contato,Car_Contato,Tel_Fax,Tel_Voz,Te
l_Dados,Obs_Contato,Local_Monitoracao+)>
<!ELEMENT Monitoracao_Consumidor
(Cod_Consumidor,Nom_Consumidor,End_Consumidor,Ufe_Consumidor,
Cep_Consumidor,Pais_Consumidor,Tel1_Consumidor,Tel2_Consumido
r,Obs_Consumidor,Nom_Cont_Consumidor,Local_Monitoracao)>
<!ELEMENT Cod_Local (#PCDATA)>
<!ELEMENT Dat_Inicio_Monitoracao (#PCDATA)>
<!ELEMENT Nom_Local (#PCDATA)>
<!ELEMENT Des_Local (#PCDATA)>
<!ELEMENT Num_Frequencia_alimentacao_local (#PCDATA)>
<!ELEMENT Dat_Fim_Monitoracao (#PCDATA)>
<!ELEMENT Val_Tensao_Nominal_Local (#PCDATA)>
<!ELEMENT Cod_Contato (#PCDATA)>
<!ELEMENT Nom_Local_Contato (#PCDATA)>
<!ELEMENT Car_Contato (#PCDATA)>
<!ELEMENT Tel_Fax (#PCDATA)>
<!ELEMENT Tel_Voz (#PCDATA)>
<!ELEMENT Tel_Dados (#PCDATA)>
<!ELEMENT Obs_Contato (#PCDATA)>
<!ELEMENT Cod_Consumidor (#PCDATA)>
<!ELEMENT Nom_Consumidor (#PCDATA)>
<!ELEMENT End_Consumidor (#PCDATA)>
<!ELEMENT Ufe_Consumidor (#PCDATA)>
<!ELEMENT Cep_Consumidor (#PCDATA)>
<!ELEMENT Pais_Consumidor (#PCDATA)>
<!ELEMENT Tel1_Consumidor (#PCDATA)>
<!ELEMENT Tel2_Consumidor (#PCDATA)>
<!ELEMENT Obs_Consumidor (#PCDATA)>
<!ELEMENT Nom_Cont_Consumidor (#PCDATA)>
146
Apêndice – D
Conversão do Diagrama de Classes do Caso 2: Caracterização da Sensibilidade de
Processos Industriais frente a Afundamentos de Tensão para DTD.
A seguir são descritas as etapas para a conversão do diagrama de classes:
1- Definição da linguagem:
Figura 9.3: Interface para definição da Linguagem XML - DTD
2- Interface para geração do documento:
Figura 9.4: Geração do documento .DTD
147
3- Documento gerado
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT Pesquisa (Cod_pesquisa,Des_pesquisa)>
<!ELEMENT Local_Monit_Contato
(Cod_Contato,Nom_Local_Contato,Car_Contato,Tel_Fax,Tel_Voz,Te
l_Dados,Obs_Contato,Local_Monitoracao+)>
<!ELEMENT Local_Monitoracao
(Cod_Local,Dat_Inicio_Monitoracao,Nom_Local,Des_Local,Num_Fre
quencia_alimentacao_local,Dat_Fim_Monitoracao,Val_Tensao_Nomi
nal_Local,Monitoracao_Consumidor+,Equipamento+,Pesquisa+)>
<!ELEMENT Monitoracao_Consumidor
(Cod_Consumidor,Nom_Consumidor,End_Consumidor,Ufe_Consumidor,
Cep_Consumidor,Pais_Consumidor,Tel1_Consumidor,Tel2_Consumido
r,Obs_Consumidor,Nom_Cont_Consumidor)>
<!ELEMENT Canal
(Cod_Canal,Nom_Grandeza,Ind_Grandeza,Rot_Grandeza,Canal_Equip
amento*)>
<!ELEMENT Canal_Equipamento
(Cod_Canal_Equipamento,Name,Num_Canal,Raz_Transf_De,Raz_Trans
f_Para,Uni_Grandeza,Equipamento+)>
<!ELEMENT Equipamento
(Cod_Equipamento,Num_Serie,Nom_Fabricante,Nom_Modelo,Ver_Soft
ware,Str_Inic_Pc,StrInic_Equipamento,Obs_Equipamento,Parametro_Aguste*)>
<!ELEMENT Tipos_Ajustes
(Cod_Ajuste,Des_Ajuste,Uni_Ajuste,Idc_Ajuste,Parametro_Aguste
*)>
<!ELEMENT Parametro_Aguste
(Cod_Param_ajustavel,Dat_Ajuste,Val_Ajuste)>
<!ELEMENT Eventos_Vtcd
(Cod_Vtcd,Des_Max_Amp,Media_Amp,Dur_Vtcd,Des_Padrao_Amp,Med_A
mp,Per_Tensao,Per_Energia,Idc_Tipo_Vtcd)>
<!ELEMENT Eventos_Estampa
(Cod_Evento,Idc_Tipo_Evento,Dat_Inicio_Evento,Tratamento_Even
tos*,Canal_Equipamento*)>
<!ELEMENT Tratamento_Eventos
(Cod_Tratamento_Eventos,Tam_Janela_Eventos,Tip_Janela_Eventos
,Des_Janela_Eventos)>
<!ELEMENT Cod_pesquisa (#PCDATA)>
<!ELEMENT Des_pesquisa (#PCDATA)>
<!ELEMENT Cod_Contato (#PCDATA)>
<!ELEMENT Nom_Local_Contato (#PCDATA)>
<!ELEMENT Car_Contato (#PCDATA)>
<!ELEMENT Tel_Fax (#PCDATA)>
<!ELEMENT Tel_Voz (#PCDATA)>
<!ELEMENT Tel_Dados (#PCDATA)>
<!ELEMENT Obs_Contato (#PCDATA)>
<!ELEMENT Cod_Local (#PCDATA)>
<!ELEMENT Dat_Inicio_Monitoracao (#PCDATA)>
<!ELEMENT Nom_Local (#PCDATA)>
148
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Des_Local (#PCDATA)>
Num_Frequencia_alimentacao_local (#PCDATA)>
Dat_Fim_Monitoracao (#PCDATA)>
Val_Tensao_Nominal_Local (#PCDATA)>
Cod_Consumidor (#PCDATA)>
Nom_Consumidor (#PCDATA)>
End_Consumidor (#PCDATA)>
Ufe_Consumidor (#PCDATA)>
Cep_Consumidor (#PCDATA)>
Pais_Consumidor (#PCDATA)>
Tel1_Consumidor (#PCDATA)>
Tel2_Consumidor (#PCDATA)>
Obs_Consumidor (#PCDATA)>
Nom_Cont_Consumidor (#PCDATA)>
Cod_Canal (#PCDATA)>
Nom_Grandeza (#PCDATA)>
Ind_Grandeza (#PCDATA)>
Rot_Grandeza (#PCDATA)>
Cod_Canal_Equipamento (#PCDATA)>
Name (#PCDATA)>
Num_Canal (#PCDATA)>
Raz_Transf_De (#PCDATA)>
Raz_Transf_Para (#PCDATA)>
Uni_Grandeza (#PCDATA)>
Cod_Equipamento (#PCDATA)>
Num_Serie (#PCDATA)>
Nom_Fabricante (#PCDATA)>
Nom_Modelo (#PCDATA)>
Ver_Software (#PCDATA)>
Str_Inic_Pc (#PCDATA)>
Str-Inic_Equipamento (#PCDATA)>
Obs_Equipamento (#PCDATA)>
Cod_Ajuste (#PCDATA)>
Des_Ajuste (#PCDATA)>
Uni_Ajuste (#PCDATA)>
Idc_Ajuste (#PCDATA)>
Cod_Param_ajustavel (#PCDATA)>
Dat_Ajuste (#PCDATA)>
Val_Ajuste (#PCDATA)>
Cod_Vtcd (#PCDATA)>
Des_Max_Amp (#PCDATA)>
Media_Amp (#PCDATA)>
Dur_Vtcd (#PCDATA)>
Des_Padrao_Amp (#PCDATA)>
Med_Amp (#PCDATA)>
Per_Tensao (#PCDATA)>
Per_Energia (#PCDATA)>
Idc_Tipo_Vtcd (#PCDATA)>
Cod_Evento (#PCDATA)>
Idc_Tipo_Evento (#PCDATA)>
Dat_Inicio_Evento (#PCDATA)>
149
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
Cod_Tratamento_Eventos (#PCDATA)>
Tam_Janela_Eventos (#PCDATA)>
Tip_Janela_Eventos (#PCDATA)>
Des_Janela_Eventos (#PCDATA)>
150
Apêndice – E
Mapeamento do documento .DTD gerado para um SGBD relacional (ferramenta
XMLSPY ). Para tal estamos considerando o Caso 2: Caracterização da Sensibilidade de
Processos Industriais frente a Afundamentos de Tensão.
A seguir são descritas as etapas para chegar ao objetivo final:
1- Criação projeto na ferramenta XMLSPY, e importação do arquivo .DTD gerado
na fase anterior (Figura 9.5):
Figura 9.5: Demonstrativo da Criação do Projeto e Inclusão do Arquivo .DTD
151
2- Conversão do DTD/Shema no formato W3C Shema (Figura 9.6), e ajuste dos tipos de
dados (Figura 9.7):
Figura 9.6: Demonstrativo do resultado da conversão para DTD/Shema.
Figura 9.7: Demonstrativo do ajuste nos tipos dos dados.
152
3- Criar o Banco de Dados (considerando o SGBD a ser utilizado – Figura 9.8) de
acordo com o Shema gerado:
Figura 9.8: Interface para a escolha do SGBD utilizado.
4- Definição dos atributos que são chave primária (Figura 9.9):
Figura 9.9: Definição das Chaves Primárias.
5- Visualização das tabelas que serão geradas (Figura 9.10):
Figura 9.10: Visualização das Tabelas que serão Criadas.
153
6- Resultado das tabelas criadas no Microsoft Access.
Figura 9.11: Banco de Dados Criado com suas respectivas Tabelas.
154