MARCELA DO PRADO
PROTÓTIPO DE UM SISTEMA DE MANUTENÇÃO
PREVENTIVA DE EQUIPAMENTOS, APLICADA À
UNOCHAPECÓ USANDO O PARADIGMA DE
ORIENTAÇÃO A OBJETOS COM SOFTWARE LIVRE
Monografia apresentada à UNOCHAPECÓ como
parte dos requisitos para obtenção do grau de
Bacharel em Ciência da Computação.
Orientador (a): Monica Pereira
Chapecó - SC, jun. 2006.
PROTÓTIPO DE UM SISTEMA DE MANUTENÇÃO
PREVENTIVA DE EQUIPAMENTOS, APLICADA À
UNOCHAPECÓ USANDO O PARADIGMA DE
ORIENTAÇÃO A OBJETOS COM SOFTWARE LIVRE
MARCELA DO PRADO
Esta Monografia foi julgada para obtenção do título de Bacharel em Ciência da Computação,
na área de concentração e aprovada pelo curso de Ciência da Computação
ORIENTADORA: Profª. Monica Pereira
COORDENADORA DO CURSO: Profª. Monica Pereira
BANCA EXAMINADORA
PRESIDENTE:
Profª. Monica Pereira
Prof. Cristiano Agosti
Prof. Jorge Antonio Di Domenico
DEDICATÓRIA
Dedico à minha mãe e irmã que fazem parte de minha vida, sempre
apoiando, e, mesmo nas horas mais conturbadas me incentivaram a
continuar e lutar pelo que queria.
AGRADECIMENTOS
A Deus, por permitir ter pessoas maravilhosas ao meu redor, de onde recebo energia
para transpor obstáculos.
A família, minha mãe, Zilá Rosa Santini, e irmã, Fernanda do Prado, que estiveram
presente nos momentos mais importantes da minha vida, compartilhando das alegrias e
dando total apoio e conforto nas horas difíceis e por não me deixarem desistir. Obrigada por
existirem e estarem comigo.
Os meus tios, Carlos Alberto Carniel e Maria Edhit Carniel, nunca mediram esforço
para auxiliar-me, ao longo da minha vida. Muito obrigada por estarem comigo.
A professora e orientadora Monica Pereira, agradeço por ter disponibilizado seu tempo,
sem o qual este trabalho não seria possível. Pela sua dedicação e colaboração para concluir
este trabalho. E ao professor Radamés Pereira, sempre orientando e auxiliando quando
solicitado.
Aos colegas de trabalho, Marcos Antonio Moretto, coordenador dos Laboratórios de
Informática, Sergio Tscha Wanderley, Analista de Suporte da Coordenadoria de Informática,
que com muita paciência me ajudaram e sempre me socorreram nos momentos de angustias
com o Linux.
A Marcia Surdi e Roberta Pasqualli, colegas de trabalho da UNOCHAPECÓVirtual,
que sempre me escutaram e ajudaram. Em fim, a todos os colegas de trabalho que me
ajudaram.
A todos os meus verdadeiros amigos, que me apoiaram e encorajaram nas horas de
dificuldades, e que não foram poucas. Pela compreensão e esforços desmedidos que
dedicaram a mim.
Aos mestres, agradeço pela aprendizagem que me foi passada, amizade formada e
também a todos os meus colegas de classe indistintamente, vocês foram importantíssimos, de
coração meu fraterno abraço sucesso a todos.
Em fim, todas as pessoas que me ajudaram a passar e conquistar mais uma etapa da
minha vida, muito obrigada!
SUMÁRIO
RESUMO .................................................................................................................................. XI
ABSTRACT ............................................................................................................................. XII
1 INTRODUÇÃO.........................................................................................................................1
1.1 ORGANIZAÇÃO DO TRABALHO....................................................................................3
2 PARADIGMA DA ORIENTAÇÃO A OBJETOS......................................................................4
2.1 OBJETO...........................................................................................................................4
2.2 CLASSE...........................................................................................................................5
2.3 MENSAGENS E MÉTODOS ...........................................................................................6
2.4 ABSTRAÇÃO...................................................................................................................7
2.5 ENCAPSULAMENTO ......................................................................................................7
2.6 POLIMORFISMO .............................................................................................................8
2.7 HERANÇA........................................................................................................................8
3 BANCO DE DADOS ORIENTADO A OBJETOS E BANCO DE DADOS OBJETORELACIONAL...........................................................................................................................10
3.1 BANCO DE DADOS ORIENTADO A OBJETOS...........................................................10
3.2 BANCO DE DADOS OBJETO-RELACIONAL...............................................................11
3.3 MODELOS DE DADOS ORIENTADOS A OBJETOS OU BANCO DE DADOS
OBJETO-RELACIONAL.......................................................................................................12
3.4 MODELAGEM E PROJETO PARA BANCO DE DADOS ORIENTADOS A OBJETOS13
3.4.1 Análise Orientada a Objeto.....................................................................................14
3.4.2 Projeto de Sistema Orientado a Objeto ..................................................................14
4 LINGUAGEM DE MODELAGEM – UML ..............................................................................16
4.1 BREVE HISTÓRICO DA UML .......................................................................................16
4.2 TERMOS E CONCEITOS..............................................................................................17
4.2.1 Classes ...................................................................................................................17
4.2.2 Atributos..................................................................................................................18
4.2.3 Operações ..............................................................................................................18
4.2.4 Relacionamentos ....................................................................................................18
4.2.5 Estereótipos............................................................................................................20
vi
4.3 MODELAGEM NA UML .................................................................................................20
4.3.1 Diagrama de Classes .............................................................................................21
4.3.2 Diagrama de Objetos..............................................................................................23
4.3.3 Diagrama de Caso de Uso .....................................................................................23
4.3.4 Diagrama de Seqüência .........................................................................................24
4.3.5 Diagrama de Gráfico de Estados............................................................................25
4.3.6 Diagrama de Atividades..........................................................................................26
4.3.7 Diagrama de Componentes....................................................................................27
4.3.8 Diagrama de Implantação.......................................................................................28
5 SOFTWARE LIVRE...............................................................................................................29
5.1 CONCEITUAÇÃO ..........................................................................................................29
5.2 HISTÓRICO ...................................................................................................................30
5.3 CONTEXTUALIZAÇÃO .................................................................................................30
5.4 FUTURO DO SOFTWARE LIVRE.................................................................................31
6 DESCRIÇÃO DAS FERRAMENTAS UTILIZADAS..............................................................32
6.1 UMBRELLO UML MODELLER......................................................................................32
6.2 POSTGRESQL ..............................................................................................................32
6.2.1 Declaração de Classes-Objetos .............................................................................33
6.2.2 Identificação de Objetos .........................................................................................34
6.2.3 Manipulação de dados............................................................................................35
6.2.4 Regras, Métodos e Funções...................................................................................35
6.3 PHP: HYPERTEXT PREPROCESSOR.........................................................................36
7 DESCRIÇÃO DO PROBLEMA .............................................................................................37
8 DESCRIÇÃO DA RESOLUÇÃO DO PROBLEMA ...............................................................38
9CONSIDERAÇÕES FINAIS ...................................................................................................54
9.1 TRABALHOS FUTUROS...............................................................................................55
10 REFERÊNCIAS ...................................................................................................................56
11 APÊNDICES ........................................................................................................................58
LISTA DE FIGURAS
Figura 1. Representação de objeto.............................................................................................5
Figura 2. Representação da estrutura de uma classe ...............................................................5
Figura 3. Representação de herança entre classes ...................................................................6
Figura 4. Representação de polimorfismo ..................................................................................8
Figura 5. Representação de Herança .........................................................................................9
Figura 6. Representação do objeto Equipamento.....................................................................15
Figura 7. Representação de Classe, Atributo e Operação .......................................................18
Figura 8. Representação dos Relacionamentos .......................................................................19
Figura 9. Representação de um estereótipo.............................................................................20
Figura 10. Diagrama de Classes do SMPC ..............................................................................22
Figura 11. Diagrama de Caso de Uso do SMPC ......................................................................24
Figura 12. Diagrama de Seqüência do SMPC - solicitação de orçamento ...............................25
Figura 13. Diagrama de Gráfico de Estados do SMPC ............................................................26
Figura 14. Diagrama de Atividade do SMPC ............................................................................27
Figura 15. Diagrama de Caso de Uso do SMPC ......................................................................39
Figura 16. Diagrama de Classes do SMPC ..............................................................................40
Figura 17. Tela de login ............................................................................................................42
Figura 18. Interface do usuário(nível 1) ...................................................................................43
Figura 19. Tela para inserir manutenção ..................................................................................44
Figura 20. Tela para consultar manutenções por palavra.........................................................45
Figura 21. Interface do usuário(nível 2) ....................................................................................46
Figura 22. Interface do usuário(nível 3) ....................................................................................46
Figura 23. Interface dos relatórios ............................................................................................48
Figura 24. Interface dos relatórios manutenções pendentes, manutenções concluídas e custos
das manutenções......................................................................................................................49
viii
Figura 25. Interface do resultado do relatório dos equipamentos que devem receber
manutenção preventiva.............................................................................................................50
Figura 26. Interface do resultado do relatório de manutenções pendentes..............................51
Figura 27. Interface do resultado do relatório de manutenções concluídas..............................51
LISTA DE QUADROS E TABELAS
Quadro 1. Declaração de classes-objetos ................................................................................34
Quadro 2. Adicionar dados na tabela........................................................................................35
Quadro 3. Consultando dados da tabela ..................................................................................35
Quadro 4. Função para espelhamento das tabelas equipamento, arcond e microscopio ........36
Quadro 5. Arquivo usuario.php .................................................................................................43
Quadro 6. Inserindo dados........................................................................................................44
Quadro 7. Criação da classe-objeto EQUIPA e da tabela EQUIPAMENTO ............................52
Quadro 8. Arquivo gerado para importação de dados ..............................................................52
Quadro 9. Comando para importação das tabelas ...................................................................53
Tabela 1. Vantagens e desvantagens do SGBDOO.................................................................11
Tabela 2. Links dos Níveis ........................................................................................................41
LISTA DE SIGLAS E ABREVIATURAS
BDOR
Banco de Dados Objeto-relacional
QUEL
Query Language
SELinux
Security Enhanced Linux
SGDBOO
Sistema de Gerenciamento de Banco de Dados Orientado a Objetos
SGDBOR
Sistema de Gerenciador de Banco de Dados Objeto-relacionais
SMPC
Sistema de Manutenção Preventiva e Corretiva
SQL
Structured Query Language
UML
Unified Modeling Language
UNOCHAPECÓ
Universidade Comunitária Regional de Chapecó
RESUMO
O presente projeto tem como objetivo desenvolver um protótipo de um sistema computacional,
através da utilização do paradigma de orientação a objetos e a filosofia de software livre,
tendo como estudo de caso a manutenção preventiva de equipamentos para Universidade
Comunitária Regional de Chapecó – UNOCHAPECÓ. O objetivo principal é a utilização do
paradigma orientação a objetos, tanto para programação quanto para a análise do sistema,
utilizando-se ferramentas livres. A definição deste projeto orientou-se por entrevista realizada
com um funcionário do Setor de Infra-estrutura e Manutenção da UNOCHAPECÓ,
constatando-se a demanda por serviços de manutenção preventiva, ferramenta indispensável
no processo de controle de custos, adequação do tempo e planejamento das atividades. Para
isto é necessário que se adotem padrões e metodologias adequadas pata tal, buscando no
paradigma de orientação a objetos as metodologias e técnicas para o análise e
implementação do sistema. A descrição do sistema revela que este paradigma torna o
processo mais rígido, melhorando o desenvolvimento do software. Relativamente ao protótipo,
este deve possibilitar o atendimento de necessidades como o controle sobre as garantias dos
equipamentos que retornam do conserto, tornar a solicitação de manutenção de
equipamentos mais ágil, criando um cronograma das atividades, e aumentando a vida útil de
equipamentos e estruturas, através da manutenção preventiva. A solicitação do serviço será
feita de maneira on-line, informando usuário e senha, que serão código funcional e senha,
respectivamente. Também é preciso ratificar que, em função de que os equipamentos tem
muitas características comuns, bem como os processos pelos quais devem passar, o
paradigma orientado a objetos já se mostra fortemente indicado para tal propósito. Assim, se
pretende obter um controle mais eficiente das manutenções, do tempo e dos custos.
Relativamente as ferramentas que deverão ser utilizadas, deverão ser ferramentas livres,
podendo gerar também uma nova ferramenta livre para manutenção de equipamentos,
podendo ser utilizada por outras instituições ou empresas.
Palavras-chave: orientação a objetos, software livre, manutenção.
ABSTRACT
The current project has as its objective to develop a prototype of a computational system via
application of the paradigm supervising over objects and the philosophy of free software. It has
as its study case, the preventive maintenance of equipment at Universidade Comunitária
Regional de Chapecó – UNOCHAPECO. The main objective is the application of the paradigm
supervising over objects for programming as well as the system analysis, making use of free
software. The definition of this project was oriented by interview involving an employee in the
infrastructure and maintenance department at UNOCHAPECÓ, and the need for services of
preventive maintenance was verified, the latter being important in cost control, time adequacy
and planning of activities. In order to do so, it is necessary to adopt appropriate patterns and
methodologies searching in the paradigm of supervising over objects the techniques and
methods for the analysis and implementation of the system. The description of the system
reveals that this paradigm makes the process more efficient, improving the development of the
software. In relation to the prototype, it should open possibilities for serving needs such as the
control over the guarantees of the equipment that returns from fixing, asking for quicker
maintenance and stretching the life of equipment and structures via preventive maintenance.
Asking for services should be done online via user and access code. It is necessary to pinpoint
that the paradigm oriented towards objects exists already because equipment shares many
common characteristics. In this way, it is expected that we have a more efficient control over
maintenance, time and costs. At the same time tools applied in the process are free and can
generate a new free tool for equipment maintenance and be used by institutions and
companies.
Keywords: orientation to objects, free software, maintenance.
1
INTRODUÇÃO
A história nos apresenta diversos tipos de bens que serviram de base para o
desenvolvimento da economia: propriedade, mão-de-obra, máquinas e capital. Atualmente, a
informação, aparece como um novo tipo de bem econômico e, a empresa que dispõem de
maior informação sobre seu processo de negócio está em vantagem em relação as suas
competidoras. Um ditado popular nos diz que, a necessidade é a mãe das invenções. Em
função da necessidade de gerenciar informações de uma forma adequada e eficiente e, como
conseqüência do crescimento da importância da informação, surgiram os denominados
sistemas de informações (BEZERRA, 2000).
Essa necessidade gerou o crescimento da informática, o qual exerce grande impacto no
mundo de produção da sociedade. O mercado globalizado requer uma constante atualização
tecnológica, buscando a rapidez na tomada de decisões. Na tentativa de automatizar ainda
mais setores, novos paradigmas de programação surgem, com novos conceitos e aplicações,
gerando, também uma permanente atualização dos desenvolvedores de software, visando
proporcionar soluções informatizadas, ágeis, seguras, confiáveis e atualizadas.
Constatando que o Setor de Infra-estrutura e Manutenção da UNOCHAPECÓ são os
responsáveis diretos pela execução dos serviços de manutenção, a intenção desse projeto é
aplicar tecnologias de orientação a objetos e software livre, para ir de encontro com a
manutenção preventiva que é ferramenta indispensável no processo de controle de custos,
adequação do tempo e planejamento das atividades. Criar, desenvolver e adotar padrões
práticos de execução nos serviços surge com a automatização através de banco de dados1 e
ferramentas apropriadas, que visa uma maior disposição nos procedimentos técnicos e
práticos para o Setor de Infra-estrutura e Manutenção da instituição.
Junto com padrões definidos pelo setor de manutenção vem complementar o projeto já
existente e atuante na instituição visando um melhor controle sobre as manutenções
realizadas, em base no crescimento acelerado da instituição.
Esse crescimento gera a
ocorrência de dificuldades no controle de serviços e este necessita de um projeto que
1
Banco de Dados: uma coleção de dados armazenados e gerenciados eletronicamente (WINBLAD;
EDWARDS; KING, 1993, p. 280).
2
apresente maior rapidez, controle, redução de custos e agilidade na relação das atividades de
manutenção.
Assim, buscando automatizar procedimentos, a informática insere em nosso dia-a-dia
novas tecnologias capazes de resolver os mais diversos problemas. Como o volume de
informações vem crescendo, fez com que se criassem alternativas para armazenar essas
informações de forma segura e de fácil consulta. Conhecendo a realidade da instituição e sua
amplitude, percebe-se a necessidade de desenvolver um sistema para o controle de
manutenção de equipamentos, com isso, evita-se urgências e emergências, o que implica na
grande diminuição de custo e avarias nos equipamentos.
Assim o processo será mais rígido, melhorando o controle dos equipamentos,
proporcionando a redução de custos através de manutenção preventiva, evitando transtornos
com eventuais paradas dos equipamentos por falta de manutenção. Tendo controle sobre as
garantias dos equipamentos que retornam do conserto, a solicitação de manutenção de
equipamentos será mais ágil, criando um cronograma das atividades, e aumentando a vida útil
de equipamentos e estruturas através da manutenção preventiva.
O presente projeto visa automatizar processos de controle de manutenção de
equipamentos que atualmente são realizados manualmente na UNOCHAPECÓ. Para
resolução deste problema que consiste no controle dos equipamento que vão para o conserto,
propõe-se um sistema baseado em conceitos de orientação a objetos e banco de dados
orientados a objetos a partir de padrões definidos pelo Setor de Infra-estrutura e Manutenção,
visando diminuir custos, através da utilização de software livre, que com sua expansão e
consolidação é possível projetar e implementar softwares sem alterar a qualidade.
O controle de manutenção preventiva de equipamentos (ar-condicionado, microscópio,
estufa, tomadas, fluxo laminar, entre outros) é realidade na instituição. Porém, como o parque
de equipamentos é numeroso e torna-se difícil manter um programa de manutenção realista
sem o auxílio de computador, pois acredita-se que esse processo venha a garantir que este
esteja em dia, aumentando sua vida útil e melhorando o desempenho de toda organização e
também a relação custo x benefícios destes.
3
1.1
ORGANIZAÇÃO DO TRABALHO
Este estudo foi organizado em forma de capítulos. No próximo capítulo são
apresentados os conceitos de paradigma da orientação à objetos. O terceiro capítulo aborda
alguns dos conceitos do modelo, os quais complementam os demais apresentados no capítulo
anterior. Também banco de dados orientado a objetos e banco de dados objeto-relacional são
abordadas, demonstrando as vantagens e desvantagens do Sistemas Gerenciais de Banco de
Dados Orientados à Objetos (SGBDOO). Para construção e aplicação, no quarto capítulo, é
mostrado a linguagem de modelagem UML, que mostra alguns diagramas referente ao
protótipo. Já no capítulo quinto, um breve histórico sobre a contextualização e futuro do
software livre. No sexto capítulo, uma descrição dos softwares livres, visando a utilização de
software livre, como PHP, Umbrello e PostgreSQL, abordando as especificações de cada um.
Nos capítulos seguintes, a descrição do problema e como este foi resolvido. Nos apêndices
mostra a Descrição Contextual, Relatório da entrevista realizada com o Setor de Infraestrutura e Manutenção da UNOCHAPECÓ, Instalando e configurando APACHE + PHP +
POSTGRESQL+PhpPgAdmin e por fim o arquivo usuario.tle.
2
PARADIGMA DA ORIENTAÇÃO A OBJETOS
O paradigma de orientação a objetos foi criado com o intuito de modelar a realidade
representada por atributos e operações.
O paradigma da orientação a objetos visualiza um sistema de software como
uma coleção de agentes interconectados chamados objetos. Cada objeto é
responsável por realizar tarefas específicas. É através da interação entre
objetos que uma tarefa computacional é realizada. (BEZERRA, 2002, p.06)
A orientação a objetos minimiza a diferença da realidade sendo modelada e os modelos
construídos. Um software orientado a objetos é formado por objetos em colaboração com o
objetivo de fazer as funcionalidade do software. Através da cooperação entre objetos que se
desenvolve o sistema de software.
Antes de visualizar as técnicas de modelagem deste paradigma é importante conhecer
os conceitos de orientação à objeto para melhor compreensão de sua aplicação.
2.1
OBJETO
Segundo Winblad; Edwards; King (1993), são entidades que contêm dados (atributos) e
maneiras de comportamento (métodos) para operar sobre estes dados.
Um objeto é tudo o que pode ser identificado conforme a mundo real, sempre estarão
associadas a um objeto o estado, comportamento e identidade. Onde estado é definido pelas
propriedades, comportamento é definido pela forma como ele reage e a identidade é uma
particularidade que distingue dos demais, tornando-o único.
Um exemplo de objeto que poderíamos ilustrar é de um ar condicionado, conforme
figura 1. O objeto ar condicionado possui propriedades como, potência e voltagem. Possui
também estados como ligar, desligar, resfriar, ventilar e aquecer.
5
Figura 1. Representação de objeto
2.2
CLASSE
Segundo Booch; Rumbaugh; Jacobson (2000), uma classe é uma descrição de um
conjunto de objetos que compartilham os mesmos atributos, operações, relações e semântica.
Uma classe possui um nome, onde é definido o conjunto de atributos e de métodos. A
representação da estrutura de uma classe é ilustrada na Figura 2.
Figura 2. Representação da estrutura de uma classe
Uma superclasse (classe-pai), transfere suas características (atributos e métodos) para
uma subclasse (classe-filho), onde aplicamos o conceito de herança, que veremos na figura 3.
6
Figura 3. Representação de herança entre classes
Instância e objetos são sinônimos, falamos que um objeto é uma instância de uma
classe, onde cada uma delas possui alguns métodos e atributos, mas cada objeto atua
independentemente. Pode-se dizer que um dos principais elementos do paradigma é os
objetos.
2.3
MENSAGENS E MÉTODOS
Os objetos se comunicam apenas através de mensagens. Quando um objeto deseja
alguma tarefa de outro objeto, ele envia uma mensagem contendo nome do objeto-origem,
objeto-destino, nome do método a ser ativado no objeto-destino e se necessário, parâmetros
que permitem especificar alguma função especial a ser executada pelo método.
Por exemplo, um objeto solicita a impressão de um documento para o objeto imprimir
que solicita um lugar na fila. O objeto imprimir pode responder com outra mensagem,
solicitando mais informações, ou simplesmente imprimindo o documento. (WINBLAD;
EDWARDS; KING, 1993)
Segundo Winblad; Edwards; King (1993, p.30),
[...] métodos residem em objetos e determinam como o objeto agirá ao
receber uma mensagem. [...] trabalham em respostas às mensagens e
manipulam os valores das variáveis de instância.
7
2.4
ABSTRAÇÃO
Segundo Winblad; Edwards; King (1993), uma abstração é um modelo que insere os
aspectos mais importantes, ao mesmo tempo em que ignora os detalhes menos importantes.
Abstrações permitem gerenciar a complexidade e concentrar a atenção nas principais
características de um objeto.
Um mecanismo pelo qual restringimos a análise, variáveis e constantes, desprezando os
dados que não interessa. Por exemplo, se imaginarmos uma mesa, essa mesa provavelmente
vai ser diferente quando outra pessoa imaginá-la, mas o importante é que a tenha as
informações para cumprir sua função independente de se for redonda ou quadrada, de vidro
ou madeira ou mármore (WINBLAD; EDWARDS; KING, 1993).
A abstração consiste em manter a mesma funcionalidade para o comportamento de um
objeto, de tal forma que, alterando-se o valor dos seus atributos, ele possa interagir
adequadamente com outros objetos.
2.5
ENCAPSULAMENTO
O encapsulamento é uma forma de restringir o acesso ao comportamento interno do
objeto, contribuindo com a diminuição dos malefícios causados pela interferência externa
sobre os dados, assim uma transação só poderá ser realizada se o procedimento estiver no
objeto através do envio de mensagens. Isso também é válido para as rotinas, se forem
encapsuladas, suas operações internas não serão visíveis para outras rotinas (BEZERRA,
2002).
A vantagem no uso deste conceito está na manutenção do sistema, podem resolver
problemas e analisar soluções, além de facilitar a reutilização, bem como manter a integridade
dos valores dos atributos de cada objeto.
8
2.6
POLIMORFISMO
“Os objetos agem em resposta às mensagens que recebem. A mesma mensagem pode
resultar em ações completamente diferentes quando recebidas por objetos diferentes”
(WINBLAD; EDWARDS; KING, 1993, p. 37). Um objeto com comportamentos semelhantes,
mas que retornam informações distintas, isto é, a mesma mensagem é enviada a objetos de
classes distintas e eles poderão reagir de maneiras diferentes, conforme Figura 4.
“O polimorfismo indica a capacidade de abstrair várias implementações diferentes em
uma única interface” (BEZERRA, 2002, p.10). Por exemplo, uma classe herda um método de
uma superclasse, mas o método tem uma implementação diferente tanto na superclasse
quanto na classe.
Figura 4. Representação de polimorfismo
2.7
HERANÇA
“Cada classe em nível de hierarquia herda as características das classes nos níveis
acima” (BEZERRA, 2002, p. 10). As classes que herdam atributos e métodos são chamadas
de subclasses e sua classe antecessora é chamada de superclasse. Isso faz com que as
classes semelhantes compartilhem do mesmo comportamento e também os mesmos
atributos, conforme visto na Figura 5. Uma subclasse pode herdar atributos e métodos de
mais de uma superclasse. Uma das características mais fortes da orientação a objeto é a
herança.
A utilização do conceito herança vêem para otimizar o desempenho de um sistema
através da reusabilidade e para tornar mais fácil a atualização desse sistema, pois se os
9
módulos modificados estão no topo da hierarquia, esta atualização se propaga aos módulos
inferiores.
Figura 5. Representação de Herança
Os conceitos de banco de dados orientados a objetos e banco de dados objetorelacional incorporam os conceitos do paradigma da orientação a objetos, vistos neste
capítulo. A seguir será apresentado os conceitos de banco de dados orientado a objetos
(BDOO) e banco de dados objeto-relacional (BDOR).
3
BANCO DE DADOS ORIENTADO A OBJETOS E BANCO DE DADOS
OBJETO-RELACIONAL
3.1
BANCO DE DADOS ORIENTADO A OBJETOS
O modelo de banco de dados orientado a objetos surgiu na década de 80, projetado
como uma extensão das linguagens de programação orientadas a objetos como o Smalltalk
ou C++.
Nessa mesma época, eles iniciaram a caminhada rumo a comercialização e
atualmente são mais de 25 produtos no mercado (KHOSHAFIAN, 1994).
Os banco de dados orientados a objetos apresentam uma grande revolução para os
bancos de dados, incorporando conceitos de orientação à objeto permitindo aplicações
complexas sejam desenvolvidas com um custo de manutenção baixo e com desempenho de
máquina superior aos bancos de dados relacionais, bem como a análise orientada a objetos
seguindo uma tendência natural (KHOSHAFIAN, 1994).
No SGBDOO, a noção de objeto é usada no nível lógico e possui características não
encontradas nas linguagens de programação tradicionais, como operadores de manipulação
de estruturas, gerenciamento de armazenamento, tratamento de integridade e persistência
dos dados.
Os SGBDOO realizam automaticamente a transformação dos objetos em relações ou
estruturas de arquivos, devido ao compilador incluído, que interpreta o código-fonte e gera a
estrutura de dados no banco de dados dos objetos a fim de armazená-lo (KROENKE, 1999).
Segundo Kroenke (1999), o SGBDOO possui vantagens e desvantagens, conforme
mostra a tabela 1:
11
Tabela 1. Vantagens e desvantagens do SGBDOO
Vantagens
Desvantagens
Integrada com a linguagem de programação Exige programação orientada a objetos
Armazenamento automático de métodos Ferramentas
para
consulta
e
relatórios
(quando disponível)
inexistentes (ou primitivas)
Tipos de dados definidos pelo usuário
Poucos dados existentes na forma de objetos
Dados
complexos
processados Controle de concorrência e gerenciamento de
imediatamente
transações limitadas
Ids de objetos persistentes automaticamente Desempenho ainda não avaliado
Memória de um único nível
Exige mudança substancial e aprendizado
Fonte: KROENKE, 1999, p. 321
É importante ressaltar, que algumas desvantagens apresentadas na tabela acima,
podem ser vistas como vantagens, como por exemplo a exigência de programação orientada
a objetos. Para Kroenke (1999), a essa desvantagem esta relacionada com a transformação
da linguagem de programação tradicional para a orientada a objetos, pois não compensaria o
esforço e nem custos, tornando-se muito oneroso.
3.2
BANCO DE DADOS OBJETO-RELACIONAL
Os Bancos de Dados Objeto-Relacionais (BDOR) surgiram com o intuito de atender as
necessidades das aplicações atuais tais como manipular e modelar tipos de dados complexos
e suportar dados de grandes tamanhos. Esses bancos de dados estendem o modelo
relacional para suportar o modelo de objetos.
[...]surgiu uma tendência de combinar as melhores características do modelo
e da linguagem de dados de objetivos com o modelo de dados relacional, de
modo que o mesmo possa ser estendido para lidar com as desafiadoreas
aplicações[...] (ELMASRI; NAVATHE, 2002, p.361)
12
Um SGBDOR conhecido que incorpora as tecnologias de orientação a objeto e
relacional, é o PostgreSQL, onde as mesmas funcionalidades utilizadas pelos SGBDOO, mas
de maneira diferente, isso deve-se ao modelo de objeto utilizado pelo Structured Query
Language (SQL):19992 ter de se adaptar ao modelo relacional do SQL-92, tendo como
conseqüência, não corresponder as linguagens de programação orientada a objetos, sendo
assim usando o termo objeto-relacional.
3.3
MODELOS DE DADOS ORIENTADOS A OBJETOS OU BANCO DE DADOS
OBJETO-RELACIONAL
Orientação a objetos, como já vimos, é a organização de um sistema a analogia de uma
coleção de objetos que integram estruturas de dados e comportamento. A seguir, veja os
alguns dos conceitos do modelo, que complementam os demais já apresentados no capítulo
de paradigma da orientação a objetos:
•
Identidade de Objeto: faz as distinção entre os objetos, é independente do valor corrente
e do endereçamento de armazenamento físico. Elimina anomalias de atualizações e
integridade referencial. “É a notação mais forte de identidade do que a encontrada em
linguagem de programação ou em modelos de dados não baseados a orientação a
objetos” (KORTH; SILBERSCHATZ, 1995, p.476). Há formas de identidade como: o valor
de um dado; nome fornecido pelo usuário; embutida (Built-in), não requer identidade
fornecida pelo usuário.
•
Objeto Complexo: formados por construtores (conjunto, listas, tuplas, registros, array)
aplicados a objetos simples. O construtor pode ser aplicado em qualquer objeto. “Um
objeto complexo é um item que é visto como um único objeto no mundo real, mas que
contém outros objetos” (KORTH; SILBERSCHATZ, 1995, p.468).
•
Objeto Persistente: existe independente de um servidor, se o servidor termina, o estado
do objeto e código permanecem no disco, ou seja o objeto sobrevive depois do término da
execução de um processo (KROENKE, 1999).
2
padrão para manipulação da informação nos bancos de dados
13
•
Objeto Transiente: existe apenas em virtude de um servidor, se o servidor termina o
objeto também termina. O objeto sobrevive durante a execução do processo ou da linha
de controle que o criou (KROENKE, 1999).
•
Tipo de objetos: baseia-se na descrição e especificação do objeto. Possui duas partes:
interface (visível para o usuário) e implementação (visível para o usuário do construtor). A
vantagem de se ter um sistema de tipos é, segurança, modularidade, especificações do
comportamento. O Versant Object Database, um SGBDOO puramente orientado a
objetos, implementa estes tipos de objetos, inclusive a interface, mas este requer licença,
pois trata-se de software pago.
3.4
MODELAGEM E PROJETO PARA BANCO DE DADOS ORIENTADOS A OBJETOS
Quando pensamos em construir uma casa, o primeiro passo é fazer um planejamento
detalhado, criando um projeto onde serão visualizados divisórias da casa, parte elétrica e
encanamentos etc., assim evitando transtornos que poderiam surgir no decorrer da
construção. Com o projeto, poderemos prever o tempo necessário para a casa ficar pronta e
calcular a quantidade de material e o custo.
A modelagem e o projeto de um sistema tem importância por vários fatores, um que
ajudam
a
visualizar
o
sistema
como
desejamos;
permitem
especificar
a
estrutura/comportamento desse sistema; torna-se um guia para a construção; e documentam
as decisões tomadas. (BOOCH; RUMBAUGH; JACOBSON, 2000)
Percebe-se que o projeto é importante para o desenvolvimento de BDOO ser bem
sucedido, um elemento que contribui com isso é a modelagem, sem restrição quanto ao
tamanho do banco de dados.
Segundo Bezerra (2002, p.04):
A modelagem de sistema de software consiste na utilização de notações
gráficas e textuais com o objetivo de construir modelos que representam as
partes essenciais de um sistema, considerando-se diversas perspectivas
diferentes e complementares.
14
A análise e do projeto orientado a objeto, tem com principal objetivo considerar um
domínio de problema e uma solução lógica, através da perspectiva de objetos (LARMAN,
2000).
3.4.1
Análise Orientada a Objeto
Antes de resolver qualquer problema utilizando banco de dados orientados a objetos, é
necessário definir a funcionalidade, tipos de recursos oferecidos ao usuário; o ambiente,
plataformas suportadas; e a interface, quais paradigmas de interface do usuário, para
realização da análise. Então a análise nada mais é que, a investigação do problema e de
como a solução é definida.
A análise orientada a objeto fornece uma descrição detalhada do sistema
utilizando o simbolismo e a metodologia do projeto OO do sistema. A análise
OO será incorporada ao projeto OO do software. A fase do projeto OO
fornece detalhadas especificações das classes do domínio do
problema/produto e especifica classes de suporte adicionais para a
implementação. Portanto, as classes e as definições de classe serão usadas
como especificação funcional do código base. (KHOSHAFIAN, 1994, p. 111)
A análise OO não depende de uma linguagem, pois essa fase é conceitual onde são
definidas as classes. Essas classes podem ser implementadas diretamente ou mapeadas.
“Durante a análise orientada a objetos, há uma ênfase na descoberta e na descrição
dos objetos – ou conceitos – do domínio do problema” (LARMAN, 2000, p. 30). Por exemplo,
um sistema de informação para controle de manutenção, alguns dos conceitos são
Equipamentos, Setor e Usuário.
3.4.2
Projeto de Sistema Orientado a Objeto
O projeto do sistema possibilita ao desenvolvedor identificar os objetos que são
derivados de cada classe e como esses objetos se relacionam. Nesta fase decide-se como o
problema será resolvido, primeiro em alto nível e depois em níveis cada vez mais detalhados.
Da análise para um projeto há um refinamento, onde pode-se ou não novos detalhes.
O projeto enfatiza uma solução lógica, como o sistema atente os requisitos.
15
Algumas vantagens oferecidas (WINBLAD; EDWARDS; KING, 1993, p. 199) :
•
alto grau de reusabilidade das rotinas;
•
modularização do sistema facilita, pois os dados e processos estão localizados
dentro dos objetos;
•
pouca vulnerabilidade a mudanças na funcionalidade do sistema.
Durante o projeto orientado a objetos existe uma ênfase na definição de
elementos lógicos de software, os quais, em última instância, serão
implementados em uma linguagem de programação orientada a objetos.
Estes objetos têm atributos e métodos (LARMAN, 2000, p.30).
Por exemplo, utilizando o sistema para controle de manutenção, um objeto de software
Equipamento pode ter um atributos e métodos, conforme Figura 6.
Figura 6. Representação do objeto Equipamento
Com os conceitos de BDOO revisados neste capítulo, pode-se apresentar a Linguagem
de Modelagem – UML, vista no próximo capítulo, que auxilia na definição dos requisitos e
processos antes do desenvolvimento do software.
4
LINGUAGEM DE MODELAGEM – UML
Nos últimos anos, a Linguagem de Modelagem Unificada tornou-se um padrão utilizada
internacionalmente pela Engenharia de Software, que tem como objetivo auxiliar na definição
das características do software, como requisitos, processos entre outros, antes do software
ser desenvolvido. (GUEDES, 2005)
4.1
BREVE HISTÓRICO DA UML
Entre a metade da década de 1970 e o final da década de 1980 surgiram as linguagens
de modelagem orientadas a objetos, um novo gênero de linguagens de programação
orientadas a objetos e de aplicações. Entre 1989 à 1994 a quantidade de métodos orientados
a objetos aumentou, e muitos de seus usuários tiveram dificuldades para encontrar uma
linguagem de modelagem capaz de atender inteiramente as suas necessidades, alimentando
assim, a chamada guerra de métodos (BOOCH; RUMBAUGH; JACOBSON, 2000).
Com mais experiência, novas gerações desses métodos surgiram, destacando-se o
Booch, o OOSE (Object-Oriented Sofware Engineering) de Jacobson, e o OMT (Object
Modeling Technique) de Rumbaugh. Todos eram métodos completos, mas apresentavam
pontos fortes e pontos fracos (BOOCH; RUMBAUGH; JACOBSON, 2000).
Por volta da década de 1990 Grady Brooch (Rational Sofware Corporation), Ivar
Jacobson (Objectory) e James Rumbaugh (General Electrics) começaram a adotar idéias
provenientes de cada um dos métodos, que vinham sendo reconhecidos mundialmente como
os principais métodos orientados a objetos, surgindo assim uma unificação de linguagem de
modelagem (BOOCH; RUMBAUGH; JACOBSON, 2000).
A criação de UML (Linguagem Unificada de Modelagem) teve inicio oficial em outubro
de 1994, quando Rumbaugh se juntou a Booch na Rational, tendo como foco inicial um projeto
de unificar os métodos Booch e OMT. Dessa unificação surgiu a versão 0.8 do Método
Unificado em 1995. Nesta época, Jacobson se associou a Rational e o escopo do projeto da
UML foi expandido com a finalidade de incorporar o OOSE. Em junho de 1996 surgiu a
versão 0.9 da UML, que recebeu e solicitou retornos da comunidade de engenharia de
software em geral, bem como foi utilizado por muitas empresas de software como um recurso
estratégico para seus negócios, surgindo assim, um consorcio de UML com o propósito de
17
trabalhar a favor de uma definição mais forte e completa da UML. Com tantos parceiros que
colaboravam para a definição da UML 1.0, essa colaboração resultou em uma linguagem de
modelagem bem-definida, expressiva, poderosa e que poderia ser aplicada a uma grande
variedade de tipos de problemas (BOOCH; RUMBAUGH; JACOBSON, 2000).
Em 1997, a UML 1.0 foi oferecida para padronização ao OMG (Object Management
Group) em resposta a solicitação do próprio OMG de propostas para uma linguagem-padrao
de modelagem. No período de janeiro a julho do mesmo ano, houve uma expansão do grupo
original de parceiros e todos os participantes e colaboradores passaram a incluir virtualmente
a resposta inicial ao OMG. Em julho de 1997 ma versão revisada da UML (versão 1.1) foi
oferecida para padronização ao OMG e em setembro do mesmo ano, essa versão foi aceita
pela ADTF (Analysis and Design Task Force) e pelo Architecture Board do OMG e, a seguir,
submetida ao voto de todos os membros do OMG. Em novembro de 1997 a UML 1.1 foi
adotada pelo OMG (BOOCH; RUMBAUGH; JACOBSON, 2000).
A UML foi assumida pela RTF (Revisino Task Force) do OMG para a manutenção a qual
lançou uma revisão editorial em 1998, a UML 1.2. A RTF lançou no final do mesmo ano, a
UML 1.3 fornecendo alguns aprimoramentos técnicos (BOOCH; RUMBAUGH; JACOBSON,
2000).
4.2
TERMOS E CONCEITOS
Neste tópico repetiremos rapidamente alguns conceitos já apresentados, a fim de
descrever de forma completa a metodologia.
4.2.1
Classes
“Conjunto
de
objetos
que
compartilham
os
mesmos
atributos,
operações,
relacionamentos e semântica”( BOOCH; RUMBAUGH; JACOBSON, 2000, p.49). Sua
representação gráfica é um retângulo, conforme Figura 7.
18
4.2.2
Atributos
“É uma propriedade de uma classe que descreve um intervalo de valores que as
instâncias da propriedade podem apresentar” (BOOCH; RUMBAUGH; JACOBSON, 2000,
p.50). Veja Figura 7.
4.2.3
Operações
É a implementação de um serviço que pode ser solicitado pelo objeto da classe para
modificar o comportamento. Uma abstração de algo que pode ser feito pelo objeto que
compartilha com todos os objetos da classe (BOOCH; RUMBAUGH; JACOBSON, 2000,
p.51). Veja Figura 7.
Figura 7. Representação de Classe, Atributo e Operação
4.2.4
Um
Relacionamentos
relacionamento
é
a
interação
entre
itens.
Há
quatro
tipos
de
relacionamentos(BOOCH; RUMBAUGH; JACOBSON, 2000):
•
Dependência: indica dependência entre os itens, onde alterando-se o item
independente,
o
item
dependente
graficamente por linhas tracejadas.
é
afetado(modificado).
É
representada
19
•
Generalização: indica especialização/generalização entre os objetos, onde os
objetos-filhos são substituíveis pelos objetos-pai. Dessa maneira os filhos
compartilham a estrutura e comportamento dos pais. Sua representação é uma linha
sólida com uma seta apontando para o pai.
•
Associação: indica a associação entre os itens, cada associação tem duas pontas,
onde esta ligado ao item. É representado por linhas sólidas, podendo conter rótulos.
Na associação há a multiplicidade, onde é definido quantos objetos podem participar
do relacionamento.
•
Agregação: Representa uma associação, onde um todo é relacionado com suas
partes.
A figura 8, representa graficamente alguns do relacionamentos explicados acima, como
dependência, generalização e associação.
Figura 8. Representação dos Relacionamentos
Fonte: (BOOCH; RUMBAUGH; JACOBSON, 2000)
20
4.2.5
Estereótipos
“Permite a criação de novos tipos de blocos de construção, para atender necessidades
específicas de um modelo” (SILVA, 2001, p.87). São utilizados para classificar os elementos,
esses elementos podem conter no máximo um estereótipo.
São formados por palavras entre ângulos duplos “<<palavra>>”. Um estereótipo define
o papel do relacionamento das classe, por exemplo, a figura 9, a classe equipamento
demostra que o equipamento pertence ao setor.
Figura 9. Representação de um estereótipo
4.3
MODELAGEM NA UML
A modelagem do sistema fornece várias visões do sistema, procurando atingir a
perfeição, através da análise sob diversos aspectos. Para isso, faz-se uso dos diagramas, que
analisam o sistema num todo ou parte dele.
Cada diagrama tem sua finalidade, funções específicas, o uso de diversos diagramas
auxilia na visualização de possíveis falhas que podem vir ocorrer na fase de desenvolvimento
do software, mas para modelar um sistema não há necessidade de utilizar todos os diagramas
(GUEDES, 2005).
Segundo GUEDES (2005), a UML oferece treze diagramas:
•
diagrama de casos de uso;
•
diagrama de classes;
21
•
diagrama de objetos;
•
diagrama de estrutura composta;
•
diagrama de seqüência;
•
diagrama de colaboração(comunicação na UML 2);
•
diagrama de gráficos de estados (máquina de estados na UML 2);
•
diagrama de atividades;
•
diagrama de componentes;
•
diagrama de implantação;
•
diagrama de pacotes;
•
diagrama de interação geral;
•
diagrama de tempo.
A seguir será descrito sobre alguns destes diagramas e suas principais características.
Contudo, serão exemplificados conforme protótipo, somente os diagramas de classes, casos
de uso, de sequência, de atividades, de gráfico de estado.
4.3.1
Diagrama de Classes
Este diagrama é mais utilizado na modelagem orientada a objetos, pois permite
visualizar o modelo da estrutura do sistema, demonstrando as classes, os relacionamentos e
as colaborações. Dando uma visão estática do projeto de um sistema.
Um diagrama de classes de projeto ilustra as especificações para as classes
de software e de interfaces(por exemplo, interface java) de uma aplicação. As
informações típicas incluem as seguintes:
classes, associações e atributos;
interfaces, com suas operações e constantes;
22
métodos;
informações do tipo de atributos;
navegabilidade;
dependência (LARMAN, 2000, p. 254-255).
Os diagramas de classes são a base para um par de diagramas relacionados:
diagramas de componentes e de implantação (BOOCH; RUMBAUGH; JACOBSON, 2000).
A figura 10, Diagrama de Classes do Sistema de Manutenção Preventiva e Corretiva
(SMPC), apresenta as classes, os relacionamentos e as especializações identificadas para o
desenvolvimento do protótipo.
Figura 10. Diagrama de Classes do SMPC
23
4.3.2
Diagrama de Objetos
“Representa a modelagem de instâncias das classes de um sistema em determinado
ponto e momento de execução” (SILVA, 2001, p.86).
Os diagramas de objetos direcionam a visão estática do projeto de um
sistema ou a visão estática do processo de um sistema, tal qual os diagramas
de classes, mas considerando casos reais ou prototípicos (BOOCH;
RUMBAUGH; JACOBSON, 2000, p.94).
Esse diagrama é considerado um complemento do Diagrama de Classes, pois utiliza
quase todas notações, tornando-se dependente deste.
4.3.3
Diagrama de Caso de Uso
Um diagrama de caso de uso representa um conjunto de cenários identificados,
composto por seqüências de passos em que há interação entre usuário e o sistema. O
diagrama pode ser utilizado em todas as fases no desenvolvimento do sistema, sendo mais
utilizado nas fases de levantamento e análise de requisitos.
Um diagrama de caso de uso ilustra um conjunto de casos de uso para um
sistema, os atores e a relação entre os atores e os casos de uso. Os casos de
uso são ilustrados em ovais; os atores, como figuras de traço simples
(palitos). Existem linhas de comunicação entre esses casos e os atores; as
flechas podem indicar o fluxo de informação ou de estímulo. (LARMAN, 2000,
p.73)
Este diagrama possibilita compreender quais são os atores externos e captar o
comportamento desejado do sistema, analisando a abrangência dos requisitos, documentando
e organizando-os, permitindo identificar os riscos possíveis na fase de construção.
A figura 11, Diagrama de Caso de Uso do SMPC, apresenta os cenários identificados na
descrição textual, apêndice 1 e na entrevista com o funcionário do Setor de Infra-Estrutura e
Manutenção da UNOCHAPECÓ, apêndice 2.
24
Figura 11. Diagrama de Caso de Uso do SMPC
4.3.4
Diagrama de Seqüência
O diagrama de seqüência deve ser ilustrado para demonstrar as interações dos atores
com o sistema de software de eventos do caso de uso.
Um diagrama de seqüência do sistema é uma figura que mostra, para o
particular cenário de um caso de uso, os eventos que os atores externos
geram, sua ordem e os eventos entre sistemas. Todos os sistemas são
tratados como uma caixa-preta; a ênfase do diagrama está nos eventos que
atravessam a fronteira do sistema entre atores e outros sistemas. (LARMAN,
2000, p. 143)
25
A figura 12, Diagrama de Seqüência do SMPC - solicitação de orçamentos, mostra o
cenário solicitar orçamento da figura 11, Diagrama de Caso de Uso do SMPC.
Figura 12. Diagrama de Seqüência do SMPC - solicitação de orçamento
4.3.5
Diagrama de Gráfico de Estados
“Representa os estados possíveis de um objeto em particular. São demonstrados os
estados de um objeto, eventos, transições e atividades que devem ocorrer ao longo da vida do
objeto” (SILVA, 2001, p.86). Modelam comportamento de uma interface, classe ou
colaboração.
É formado por:
•
Estados: situação na vida de um objeto onde ele realiza uma atividade ou aguarda
um evento.
26
•
Transições: relacionamento entre dois estados.
•
Eventos: uma ocorrência significativa; um estímulo capaz de ativar uma transição
de estado.
•
Atividades: execução em uma máquina de estado
A figura 13, Diagrama de Gráfico de Estados do SMPC, apresenta os estados, eventos
e transições que há no envio do email das manutenções preventivas.
Figura 13. Diagrama de Gráfico de Estados do SMPC
4.3.6
Diagrama de Atividades
“Representa um fluxo de controle de atividades, que ocorrem no processo de um
sistema, oferecendo suporte para comportamentos condicionais e paralelos” (SILVA, 2001,
p.86). É possível também, fazer a modelagem do fluxo de atividade de um objeto específico.
Sua origem, ao contrário dos outro diagramas, foi na técnicas de Jim Odell, SDL e nas redes
de Petri.
Tipo especial de diagrama de gráfico de estado, exibindo o fluxo de uma atividade para
outra no sistema diagramas de atividades.
27
A figura 14, Diagrama de Atividade do SMPC, demostra o fluxo da atividade de solicitar
manutenção corretiva. Onde verifica-se o tipo da manutenção, interna ou externa, a
necessidade de pedir orçamento, até o encaminhamento da manutenção.
Figura 14. Diagrama de Atividade do SMPC
4.3.7
Diagrama de Componentes
“Representa os componentes que farão parte dos sistemas em construção,
demonstrando as dependência entre esses componentes” (SILVA, 2001, p.86). Esse
diagrama é utilizado na modelagem de fontes de sistemas e nas versões de sistemas.
Demonstra uma visão estática da implementação do sistema.
Os componentes que podem ser representados são: arquivo, documentos, tabelas,
bibliotecas, entre outros artefatos.
28
4.3.8
Diagrama de Implantação
Este diagrama esta mais direcionado aos engenheiros de sistemas ou analistas de
suporte. Demonstra uma visão estática de uma arquitetura de diagramas de implantação.
Representa a configuração e a arquitetura de um sistema a que estarão
ligados seus respectivos componente, podendo ser representada também a
arquitetura física de hardwares, processadores, etc (SILVA, 2001, p.86).
Existem várias ferramentas de modelagem que geram os diagramas apresentados
neste capítulo, como DIA, ArgoUML e UMBRELLO que são ferramentas livres, a definição de
software livre será exposta no próximo capítulo por ser um dos objetivos propostos deste
trabalho.
5
SOFTWARE LIVRE
5.1
CONCEITUAÇÃO
O conceito de software livre foi desenvolvido, inicialmente, por Richard Stallman no
início dos anos 80. A filosofia do software livre está baseada em quatro conceitos básicos
(GNU, 2000):
•
A liberdade de executar o programa, para qualquer propósito.
•
A liberdade de estudar como o programa funciona e, adaptá-lo para as suas
necessidades. O acesso ao código-fonte é um pré-requisito para esta liberdade.
•
A liberdade de redistribuir cópias de modo a ampliar as possibilidades de acesso de
pessoas e instituições a tais programas.
•
A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de modo
que toda a comunidade se beneficie, sem gastos adicionais.
Esses conceitos buscam garantir que o usuário possa executar, copiar, estudar,
modificar o software, visando sempre a liberdade de produção (ou aperfeiçoamento) e
utilização. Software livre pressupõe a liberdade de utilização, por isso é melhor evitar termos
como “de graça” ou “doado”, pois não se trata de uma questão de preço, mas sim de liberdade
de acesso ao código-fonte e de uso.
Um usuário pode redistribuir as cópias do software de maneira gratuita ou cobrando
uma taxa pela distribuição, as pessoas possuem livre escolha para decidir como distribuir um
programa, alterá-lo, etc., sem ter que pedir permissão a ninguém.
Os softwares livres mais conhecidos são: o sistema operacional LINUX, o pacote de
ferramentas para escritório OpenOffice, o editor de imagem GIMP, o navegador de Internet
Mozilla, etc.
30
5.2
HISTÓRICO
A história do software livre início em 1969, quando Ken Thompson, pesquisador do Bell
Labs, criou a primeira versão do Unix, um sistema operacional multi-tarefa. Este sistema era
utilizado pelos mainframes que existiam na década de 70 nas universidades e grandes
empresas. O Unix era distribuído gratuitamente para as universidades e centros de pesquisa,
com suas linhas de programação aberto. A sigla OSS (Open Source Software) é a que
designa esse tipo de programa, cuja estrutura pode ser modificada por qualquer usuário com
conhecimentos em informática. Com isso, foram surgindo novas versões do Unix, com essa
mesma filosofia (BUYS, 2000).
Em 1971, Richard Stallman, do Massachusetts Institute of Technology (MIT),
inaugurou o movimento Open Source. Ele produziu no Laboratório de
Inteligência Artificial do MIT diversos programas com código-fonte aberto. Em
1979, quando a empresa AT&T anunciou seu interesse em comercializar o
Unix, a Universidade de Berkley criou a sua versão do sistema, o BSD Unix. A
AT&T se juntou a empresas como IBM, DEC, HP e Sun para formar a Open
Source Foundation, que daria suporte ao BSD. (BUYS, 2000)
Stallman, em 1983, criou o Projeto GNU, o objetivo era de desenvolver uma versão do
Unix, acompanhada de aplicativos e ferramentas compatíveis, como editor de texto e planilhas
de cálculos, utilizando-se da mesma filosofia, com código-fonte livre. Dois anos depois, ele
publicou um tratado anti-copyright, General Public License, criando assim a Free Software
Foundation, explicando a filosofia do software livre (BUYS, 2000).
5.3
CONTEXTUALIZAÇÃO
O software livre tornou-se nos últimos anos uma alternativa financeiramente viável ao de
licenciamento de software e a sua política de renovação constante de licença e atualização de
hardware. O software livre passa a ser uma solução para os software piratas que estão
espalhados. Não há "um dono", não há uma grande empresa de software por trás. Todos que
decidem usar um software livre devem seguir suas regras na qual um software livre não pode
deixar de ser livre, pode ser copiado sem que isso seja pirataria e pode ser alterado já que o
código fonte é aberto para todos.
31
Tanto no Brasil como no exterior, o uso de software livre está dando os primeiros
passos. O Brasil é considerado um forte atuante quanto à sua aplicação, graças aos vários
movimentos neste sentido. Para o Brasil, o enfoque principal é o custo e a possibilidade de
inclusão digital. No exterior, o enfoque é em aspectos ligados à segurança e à autonomia
tecnológica.
O Brasil vem destacando-se, uma das provas é o Fórum Internacional de Software
Livre, onde John Maddog Hall afirmou que, “o Brasil é a maior estrela mundial do software
livre” (CIPSGA, 2005b). Além de elogio, reivindicou incentivos fiscais do governo para criação
de uma indústria de software.
5.4
FUTURO DO SOFTWARE LIVRE
No Brasil, a tendência é de implantar software livre em todos os setores públicos,
visando a redução de custos e aumento de investimentos.(SOFTWARE Livre, 2005)
A nível mundial, o projeto para criação da Organização Mundial de Software Livre
(OMSL), propõe viabilizar o modelo de negócios com software livre. A OMSL contará
inicialmente com a adesão de grandes empresas, que devem contribuir para mantê-la. A
organização vai criar normas de certificação, garantia de qualidade e suporte para os
aplicativos em software livre, e criar mecanismos de proteção aos desenvolvedores.
A pesquisa sobre os diferentes softwares livres disponíveis na Internet permitiu a escoha
de ferramentas para o desenvolvimento deste trabalho, estas ferramentas, suas
características e viabilidade de uso são descritos a seguir.
6
DESCRIÇÃO DAS FERRAMENTAS UTILIZADAS
Há vários softwares livres disponíveis na Internet que visam atender a demanda de
diversos setor, a seguir a descrição dos softwares escolhidos para o desenvolvimento deste
trabalho.
6.1
UMBRELLO UML MODELLER
O Umbrello UML Modeller é uma ferramenta de diagrama UML que auxilia nas fases de
análise e modelagem no desenvolvimento de software. É um software livre e disponível
gratuitamente, acompanha algumas versão do Sistema Operacional Linux, como RedHat 7x e
CentOS.
A interface dessa ferramenta é muito amigável, possiblitando sua utilização sem
necessitar grande conhecimento.
O Umbrello suporta os seguintes diagramas, que após desenhados podem ser
exportados como imagens:
•
•
•
•
•
•
•
•
Diagrama de Classe
Diagrama de Seqüência
Diagrama de Colaboração
Diagrama de Caso de Uso
Diagrama de Estado
Diagrama de Atividade
Diagrama de Componente
Diagrama de Distribuição (MANUAL, 2003).
Para fazer a interação entre os diagramas e a implementação, essa ferramenta
disponibiliza gerar código fonte numa linguagem de programação, que são: ActionScript, Ada,
C++, CORBA IDL, Java™, JavaScript, PHP, Perl, Python, SQL e Esquema XML.
6.2
POSTGRESQL
O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional
(SGBDOR), tem uma estrutura para armazenar dados sem tamanho fixo, trabalha com
33
diversos níveis de abstração de dados, e é muito confiável. É um descendente de código fonte
aberto deste código original de Berkeley (DOCUMENTAÇÃO, 2005).
Funcionalidades como:
•
•
•
•
•
•
comandos complexos
chaves estrangeiras
gatilhos
visões
integridade transacional
controle de simultaneidade multiversão
Também pode ser estendido pelo usuário, por exemplo, adicionando novos:
• tipos de dado
• funções
• operadores
• funções de agregação
• métodos de índice
• linguagens procedurais (DOCUMENTAÇÃO, 2005).
Essas funcionalidades são as utilizadas pelos SGBDOO, mas de maneira diferente.
Isso deve-se ao modelo de objetos usado pelo SQL:19993 ter de se adaptar ao modelo
relacional do SQL-92, tendo como conseqüência, não corresponder as linguagens de
programação orientada a objetos, sendo assim usando o termo objeto-relacional, uma
extensão da orientação a objetos do relacional.
Uma das características mais importante, é a armazenagem dos dados históricos,
devido à utilização de discos ópticos que armazenam o estado do banco de dados, depois de
cada alteração, permitindo assim saber sobre o estado do banco de dados em um
determinado período do passado, um exemplo é uma consulta sobre o valor da manutenção
realizada em um determinado equipamento há um ano atrás.
6.2.1
Declaração de Classes-Objetos
A definição de um tipo define uma classe, essa classe estabelece uma relação de
herança na geração das tabelas, assim fazendo a persistência dos objetos.
3
padrão para manipulação da informação nos bancos de dados
34
Por exemplo, no quadro 1 declaração de classes-objetos, demonstra a criação da
classe-objeto EQUIPA e também, criação da tabela EQUIPAMENTO que fez uso da classeobjeto EQUIPA. Para criar a tabela ARCOND, utilizou-se o conceito de herança.
Quadro 1. Declaração de classes-objetos
--Criando objeto equipa
create type equipa as (
e_nome
varchar(100),
e_descricao varchar(150),
e_marca varchar(60),
e_nmserie varchar(30),
e_aquisicao date,
e_garantia date,
e_valor numeric(20));
--Criando tabelas usando o objeto equipa
create table equipamento(
e_codpatr numeric(10) PRIMARY KEY,
e_equip equipa,
lo_gerencial numeric(6) REFERENCES localizacao(lo_gerencial));
--Criando tabelas usando herança
create table arcond(
a_capacidade numeric(6),
a_dimensao varchar(20),
a_ciclio varchar(40)
inherits (equipamento));
Principal característica, herança, que torna este BDOO é demostrado no exemplo
acima, com a utilização do comando inherits, pode ser utilizado em mais de uma relação.
A chave primária é definida pelo comando key, podendo ser definido uma ou mais
atributo, sendo que este atributo não poderá conter valor nulo.
6.2.2
Identificação de Objetos
Tem grande influência no gerenciamento de armazenamento. Em uma base de
objetos persistentes é necessário identificá-los unicamente. A identidade de um objeto é a
propriedade que o distingue dos demais, independentemente de seu valor, localização ou
endereço, sendo o valor indicado pelos atributos de referência. Este pode ser definido pelo
usuário ou pelo sistema, e constituir uma chave primária.
35
6.2.3
Manipulação de dados
O Postgres possui uma linguagem de consulta derivada do Query Language(QUEL) e
Structured Query Language(SQL). Nos exemplos abaixo, será mostrado algunas comandos,
utilizando as duas linguagem.
No quadro 2, manipulação de dados, uma linha é adicionada na tabela manutenção,
onde o append é comando do QUEL e insert do SQL.
Quadro 2. Adicionar dados na tabela
append to manutencao (
ma_codigo = 1,
ma_codpatr = 005481,
ma_codusu = 10640,
ma_defeito = “não liga”
)
insert into manutencao values (1,005481,10640, “não liga”)
No quadro 3, consultando dados da tabela, demonstra exemplo de uma consulta, onde
o retrieve é comando do QUEL e select do SQL.
Para obter os dados de uma manutenção:
Quadro 3. Consultando dados da tabela
retrieve (E.ma_codpatr, D.ma_defeito) where E.ma_codpatr = 1
select ma_defeito from manutencao where ma_codpatr=005481
6.2.4
Regras, Métodos e Funções
“Uma regra é uma ação executada no banco de dados, gerada por um determinado
evento”( NASSU; SETZER, 2002, p.55). Uma regra existente em todos bancos de dados é a
integridade referencial, mas em sua implementação o objetivo é de oferecer algumas
36
funcionalidades como: gerenciamento de visões, triggers, restrições de integridade,
integridade referencial, proteção e controle de versões.
No quadro 4, a função realiza uma seleção das tabelas equipamento, arcond e
microscopio
e
insere
nas
tabelas
equipamentoaux,
arcondaux
e
microscopioaux,
respectivamente.
Quadro 4. Função para espelhamento das tabelas equipamento, arcond e microscopio
create or replace function copy_table( )
returns void as
insert into equipamentoaux(select * from equipamento);
insert into arcondaux(select * from arcond);
insert into microscopioaux(select * from microscopio);
language SQL;
6.3
PHP: HYPERTEXT PREPROCESSOR
O PHP é uma linguagem de programação do tipo script, para ser usado em arquivos
HTML pré-processados pelo servidor Web de código aberto (WEB, 2003).
As aplicações em PHP são geradas com excelente performace e automaticamente pelo
servidor. O usuário não vê o código PHP, somente o HTML; isto é muito importante quando se
está lidando com senhas (WEB, 2003).
Disponível para diversas plataformas, incluindo Linux, Windows e outros Unix'es. O PHP
funciona muito bem com o servidor http Apache, com diversos bancos de dados (MySQL,
Postgres, Oracle, Sybase, mSQL, Solid, ODBC, Informix, dBase, Interbase, entre outros),
pode ser usado para soluções de comércio eletrônico, webmail, processamento de
formulários, cookies, entre outros recursos que necessitam de integração com o servidor Web
(WEB, 2003).
Após o estudo desse capítulo, verificou-se que um dos objetivos propostos, a utilização
de softwares livres, foi alcançado. A seguir a descrição do problema encontrado no Setor de
Infra-Estrutura e Manutenção da UNOCHAPECÓ.
37
7
DESCRIÇÃO DO PROBLEMA
Em fevereiro de 2005, verificou-se o problema do Setor de Infra-estrutura e Manutenção
da UNOCHAPECÓ, não é a execução da manutenção, e sim, o controle dos equipamentos
que vão para conserto. Por exemplo, um equipamento vai para manutenção, retorna e depois
de alguns dias volta a apresentar problemas. Como as informações não eram armazenadas
em um banco de dados, caso precisasse saber o último dia em que ocorreu manutenção em
determinado equipamento, como esse controle é feito manualmente, o processo é lento e com
muita probabilidade de enganos. Em muitos casos, quando não há um histórico das
manutenções realizadas em cada equipamento, impede a identificação do tipo de problema
que ocorre em determinado equipamento.
Outro problema encontrado é em relação ao tempo médio que um equipamento
necessita de manutenção preventiva, essa previsão não existe, causando parada dos
equipamentos.
Atualmente, a instituição possui um sistema de Controle de Manutenção Preventiva, que
foi implantado entre maio e junho de 2005, onde este faz a monitoração das manutenções,
informando a data da próxima manutenção ao funcionário do Setor de Infra-Estrutura e
Manutenção da UNOCHAPECÓ, quem é o responsável pelo equipamento e qual empresa
realizou a manutenção, armazenando assim um histórico dos equipamentos. Porém, ainda
são dados insuficientes para o controle adequado das informações do processo(sistema).
8
DESCRIÇÃO DA RESOLUÇÃO DO PROBLEMA
Para a análise dos dados necessários no desenvolvimento do protótipo, foi realizada
coleta de informações que serviram como suporte para o desenvolvimento do sistema de
forma consistente e íntegra. O levamentamento de requisitos foi realizado por meio de
entrevistas com um funcionário do Setor de Infra-Estrutura e Manutenção da UNOCHAPECÓ,
conforme Apêndice 1, no qual consta a Descrição Contextual do Sistema de
Manuntenção de Equipamentos e Apêndice 2, no qual consta o Relatório da entrevista
realizada
com
o
funcionário
Setor
de
Infra-Estrutura
e
Manutenção
da
UNOCHAPECÓ.
Após o término da análise dos dados e dos processos, foram definidos o banco de
dados e a ferramenta para modelagem do sistema. Enquanto banco de dados, optou-se pelo
PostgreSql. Já a ferramenta para modelagem foi a Umbrello. A interface gráfica para
manipulação do banco de dados foi o phpPgAdmin e o Sistema Operacional Linux – CentOS
versão 4.1. Todas as ferramentas utilizadas no desenvolvimento deste trabalho estão
inseridas na filosofia de código livre.
Ao instalar o pacote CentOS como servidor, este permitiu a utilização do servidor Web,
Apache e vários bancos de dados. No pacote de instalação, a versão disponível do
PostgreSql não oferecia algumas funcionalidades. Nesse sentido, foi necessário atualizá-la e
isso gerou alguns contratempos, uma vez que era impossível atualizá-la sem eliminar o
banco existente. A Umbrello também fazia parte do pacote de instalação do CentOS.
A instalação do phpPgAdmin deu-se de forma separada, conforme Apêndice 3.
Com os softwares instalados e funcionando de maneira correta, os diagramas foram
modelados na Umbrello, a representação da modelagem dos dados (diagramas) estão
exemplificados no capítulo 4, pois os mais relevantes para o desenvolvimento do protótipo são
demonstrados a seguir.
O diagrama de Caso de Uso representa um conjunto de cenários, onde há interação
entre o usuário e o sistema. A figura 15, Diagrama de Caso de Uso do Sistema de
Manutenção Preventiva e Corretiva (SMPC), demonstra os atores e cenários identificados na
análise dos dados do protótipo.
39
Figura 15. Diagrama de Caso de Uso do SMPC
Com base nos cenários do diagrama de Caso de Uso, pode-se desenvolver o diagrama
de classes, que propicia a visualização da estrutura do sistema. A figura 16, Diagrama de
Classes do SMPC, demonstra as classes e relacionamentos.
40
Figura 16. Diagrama de Classes do SMPC
Para mapear o diagrama de classes para o modelo físico, foram necessárias algumas
adaptações, pois existem limitações referentes ao banco, de forma que a persistência dos
objetos é feita em tabelas e a tabela equipamento possui os mesmos atributos das tabelas
arcond e microscopio.
A implementação do protótipo consiste em:
•
solicitação e consulta das manutenções corretivas;
•
emissão de relatórios;
41
•
importação de dados;
•
envio das manutenções preventivas por e-mail.
Como o sistema será utilizado por técnicos e professores, foi criada uma interface
diferenciada para cada nível, especificados na tabela usuário, sendo o nível 1 para técnicos e
professores, nível 2 para Diretores de Centro e nível 3 para o funcionário do Setor de InfraEstrutura e Manuntenção. É importante salientat que todos os níveis têm opções
diferenciadas.
Segue na tabela 2, os Links dos Níveis, quais links cada nível tem disponível e a
interface da página principal. No protótipo não foi implementado o Orçamento e Fechar
Manutenção.
Tabela 2. Links dos Níveis
Nível 1
Nível 2
Nível 3
Home
Home
Home
Inserir Manutenção
Inserir Manutenção
Inserir Manutenção
Consultar
Consultar
Consultar por palavra
Consultar por palavra
Consultar por palavra
Fechar Manutenção
Sair
Orçamento
Relatórios
Sair
Orçamento
Importação
Sair
O protótipo desenvolvido será para a Internet, de maneira on-line para o
desenvolvimento das interfaces em PHP. Utilizou-se de templates, que fornecem uma maneira
fácil de controlar a separação da aplicação lógica e o conteúdo de sua apresentação.
A seguir serão apresentadas as telas do protótipo e alguns códigos que demonstram a
separação proporcionada pela utilização de templates.
42
Primeira tela, a Figura 17, Tela de login, o usuário deverá informar o código funcional e
senha. O protótipo tem condições de identificar o nível de acesso, conforme demonstração na
tabela 2, Links dos Níveis.
Figura 17. Tela de login
A figura 18, da Interface do usuário(nível 1), demonstra que o usuário informado na tela
de login é funcionário da UNOCHAPECÓ, tendo como opções:
inserir solicitação de manutenção corretiva, Figura 19;
consultar todas as manutenções;
consultar as manutenções por palavra, Figura 20.
43
Figura 18. Interface do usuário(nível 1)
No quadro 5, Arquivo usuario.php, pode-se visualizar a utilização das templates, pois
nesse código só é vista a parte da aplicação lógica.
Quadro 5. Arquivo usuario.php
<?php
session_start();
include("classes/template.lib");
$CENTRO='<p><span class="text">Ola, voce e funcionario da UNOCHAPECO</span></p>';
ReadTLE("view/usuario.tle");
?>
Em relação ao o conteúdo da apresentação, este pode ser visto no apêndice 4, Arquivo
usuario.tle.
Em relação à inserção da solicitação de manutenção corretiva, na Figura 19, Tela para
inserir manutenção e no quadro 6, Inserindo dados, podem ser visualizadas a separação da
aplicação lógica do conteúdo da apresentação. Na última linha de código, o comando
44
ReadTLE("view/usuario.tle") faz a leitura do arquivo usuario.tle, o qual tem a parte do
conteúdo da apresentação.
Figura 19. Tela para inserir manutenção
Quadro 6. Inserindo dados
<?
session_start();
include("classes/template.lib");
include("classes/conf.php");
$d=date(d);
$m=date(m);
$y=date(Y);
$data="$d"."-"."$m"."-"."$y";
$sql="insert into tcc.manutencao values (nextval('tcc.manutencao_ma_codigo_seq'), '$codpatr',
'$usuario', '$problema', '$data', '11-11-1111','11-11-1111', '', NULL, '1', '$prioridade', NULL);";
$result=pg_query($link,$sql);
if ($result){
$CENTRO='<span class="text">Seu pedido foi inserido, em breve sera atendido</span>';
}
else{
$CENTRO='<span class="text">Nao foi possivel inserir seu pedido, por favor tente mais
tarde</span>';
}
ReadTLE("view/usuario.tle");
?>
45
A Figura 19, Tela para inserir manutenção e a Figura 20, Tela para consultar
manutenções por palavra são iguais para todos os níveis.
Figura 20. Tela para consultar manutenções por palavra
A figura 21, Interface do usuário(nível 2) e a Figura 22, Interface do usuário(nível 3),
diferem-se da Figura 18, Interface do usuário (nível 1), pelos links que têm a mais, conforme
tabela 2, Links dos Níveis.
46
Figura 21. Interface do usuário(nível 2)
Figura 22. Interface do usuário(nível 3)
47
A Figura 21, Interface do usuário(nível 2), demonstra que o usuário informado na tela de
login é Diretor de Centro da UNOCHAPECÓ, tendo como opções:
•
inserir solicitação de manutenção corretiva;
•
consultar todas as manutenções;
•
consultar as manutenções por palavra;
•
orçamento.
Já a Figura 22, Interface do usuário(nível 3), demonstra que o usuário informado na tela
de login é Funcionário do setor de Infra-Estrutura e Manutenção da UNOCHAPECÓ e
apresenta as opções:
•
inserir solicitação de manutenção corretiva;
•
consultar as manutenções por palavra;
•
fechar as manutenções realizadas;
•
relatórios das manutenções;
•
orçamento;
•
importação dos dados.
O protótipo proporcionará 4 tipos de relatórios, conforme a Figura 23, Interface dos
relatórios:
•
manutenções pendentes em um período, selecionando o tipo da manutenção
(Corretiva Interna, Corretiva Externa, Preventiva Interna ou Preventiva Externa),
Figura 24 ;
•
manutenções concluídas em um período, selecionando o tipo da manutenção,
Figura 24;
48
•
custos das manutenções em um período, selecionando o tipo da manutenção,
Figura 24;
•
relatório de quais equipamentos devem receber manutenção preventiva, Figura 25.
Figura 23. Interface dos relatórios
A figura 24, Interface dos relatórios manutenções pendentes, manutenções concluídas e
custos das manutenções, tem o mesmo layout para os três níveis(1, 2, 3).
49
Figura 24. Interface dos relatórios manutenções pendentes, manutenções concluídas e
custos das manutenções
A Figura 25, Interface do resultado do relatório dos equipamentos que devem receber
manutenção preventiva, como o próprio título informa, mostra o resultado da consulta dos
equipamentos que devem receber manutenção. Esse relatório também é enviado por e-mail
ao funcionário do Setor de Infra-Estrutura e Manutenção da UNOCHAPECÓ.
50
Figura 25. Interface do resultado do relatório dos equipamentos que devem receber
manutenção preventiva
A figura 26, Interface do resultado do relatório de manutenções pendentes, e a figura 27,
Interface do resultado do relatório de manutenções concluídas, apresentam o layout desses
relatórios.
51
Figura 26. Interface do resultado do relatório de manutenções pendentes
Figura 27. Interface do resultado do relatório de manutenções concluídas
52
Após apresentadas as interfaces do protótipo, agora será apresentada a criação do tipo
classe-objeto e a importação dos dados.
Na implementação foi definido um tipo de dado EQUIPA, para criação das tabelas
equipamento, arcond e microscópio, conforme descrito no quadro 7.
Quadro 7. Criação da classe-objeto EQUIPA e da tabela EQUIPAMENTO
--Criando objeto equipamento
create type equipa as (
e_nome
varchar(100),
e_descricao varchar(150),
e_marca varchar(60),
e_nmserie varchar(30),
e_aquisicao date,
e_garantia date,
e_valor numeric(20));
--Criando tabelas usando o objeto equipa
create table equipamento(
e_codpatr numeric(10) PRIMARY KEY,
e_equip equipa,
lo_gerencial numeric(6) REFERENCES localizacao(lo_gerencial));
No momento de importar os dados foram encontrados vários problemas.
Um dos problemas relevantes para este trabalho tem relação ao modo de gerar o
arquivo “txt”. Há um campo nas tabelas definido com o tipo de dados criado especificamente
para o protótipo. Este campo pode ser comparado a um vetor. Assim, o arquivo deverá ser
gerado como demonstra o quadro 8, Arquivo gerado para importação de dados, em função do
formato de entrada e armazenagem de dados.
Quadro 8. Arquivo gerado para importação de dados
1;(Ar condicionado,Frio,Consul,21457,25-07-1999,25-07-2001,700);1100;1800;100x300;3
5;(Ar condicionado,Climatizador Ar quente,Carier,5478963,20-03-2003,20-03-2005,5000);1100;2800;
300x700;6
6;(Ar condicionado,Frio,Consul,21457,25-07-1999,25-07-2001,700);2200;1800;100x300;3
53
A importação dos dados se deu da seguinte forma:
Eliminar as chaves primárias das tabelas equipamento, arcond e microscopio, pois o
banco não permite desabilitar;
•
Truncar as tabelas auxiliares, equipamentoaux, arcondaux e microscopioaux;
•
Fazer espelhamento das tabelas principais para as tabelas auxiliares;
•
Truncar as tabelas principais, equipamento, arcond e microscopio;
•
Importar dos dados para as tabelas principais;
•
Adicionar as chaves primárias das tabelas equipamento, arcond e microscopio.
No quadro 9. Comando para importar os dados para as tabelas principais, é
demonstrada a importação dos dados, sendo que não foi implementado em forma de gatilho.
Para ocorrer a importação, é preciso executar a função.
Quadro 9. Comando para importação das tabelas
CREATE FUNCTION copy_file() RETURNS void AS
COPY equipamento (e_codpatr, e_equip, lo_gerencial) FROM '/tmp/equipamento.txt' WITH DELIMITER
AS ';';
COPY
arcond
(a_codpatr,
a_equip,
lo_gerencial,a_capacidade,a_dimensao,a_ciclio)
FROM
'/tmp/arcond.txt' WITH DELIMITER AS ';';
COPY microscopio (mi_codpatr, mi_equip, lo_gerencial,mi_cabecote, mi_objetivas, mi_dimensao) FROM
'/tmp/microscopio.txt' WITH DELIMITER AS ';';
LANGUAGE 'sql';
9
CONSIDERAÇÕES FINAIS
No desenvolvimento do trabalho, nota-se a importância do entendimento dos conceitos
mais básicos e elementares da tecnologia utilizada na criação do sistema.
Porém, no momento em que se está realizando a entrevista e coleta de dados, o
trabalho torna-se lento, devido a dificuldade de comunicação entre as pessoas envolvidas no
processo.
Também, foram encontradas dificuldades nas instalações dos softwares, por não ter
conhecimento na manipulação do LINUX, sistema operacional utilizado. Após superadas as
dificuldades já mencionadas, começou-se atingir os objetivos.
Um dos objetivos atingidos é que o paradigma orientação a objetos vem de encontro às
necessidades levantadas, pois há várias classes que possuem as mesmas propriedades,
podendo assim ser criado tipo de dados para geração das tabelas.
Outro objetivo atingido, das ferramentas utilizadas, sob a filosofia de software livre,
demonstrou que o Umbrello atende as necessidades para a criação do diagrama de casos de
uso e diagrama de classes, que serviram de auxílio no desenvolvimento do sistema, porém,
essa ferramenta não gera um script orientado a objeto, então foi utilizada apenas para
modelagem do sistema.
Também, sob as ferramentas utilizadas, estudou-se o uso do PostgreSQL 8.0, onde
verificou-se que este é um banco de dados objeto-relacional, uma extensão do modelo
relacional para o modelo orientado a objetos, que tem muitas características presentes em
outros SGBDs comerciais como transações, subconsultas, gatilhos, visões, integridade
referencial de chave estrangeira, tipos definidos pelo usuário, herança, regras, funcionalidades
estas que se agregam as de sistemas orientados a objetos.
Como já mencionado o PostgreSQL é objeto-relacional e, assim, para mapear
o
diagrama de classes para o modelo físico foram necessárias algumas adaptações, pois
existem limitações referentes ao banco, de forma que a persistência dos objetos é feita em
tabelas e, uma tabela possui os mesmos atributos de duas outras, sendo assim utilizado o
conceito de herança, um dos mais relevantes deste paradigma. Já os métodos, foram
implementados através de funções ou procedimentos.
55
Relativo as interfaces, a utilização de templates criadas em PHP, fornecem uma
maneira fácil de controlar a separação da aplicação lógica e o conteúdo da apresentação,
assim, os elementos (tabelas HTML, cores de fundo, tamanhos de fontes, folhas de estilos,
etc) foram criados uma única vez, possibilitando fazer mudanças na lógica da aplicação sem
a necessidade de reestruturá-los.
Desta forma, o desenvolvimento dos aplicativos, utilizando tecnologias baseadas no
paradigma de Orientação a Objetos e na filosofia de software livre, comprova que é possível
encontrar nestas ferramentas a maioria das funcionalidades teoricamente propostas.
9.1
TRABALHOS FUTUROS
•
Testar SGBD totalmente OO e baseados em software livre.
•
Implementação utilizando-se ferramentas – SGBD free OO puros.
•
Estender o protótipo, complementando suas funcionalidades.
10 REFERÊNCIAS
BACIC, Nicolas. O software livre como alternativa ao aprisionamento tecnológico
imposto pelo software proprietário, 2003. Disponível em: http://www.rau-tu.unicamp.br/nourau/softwarelivre/document/?view=107. Acesso em 09 jun. 2005.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 3ª ed. Rio de
Janeiro: Elsevier, 2002.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, guia do usuário; Trad. Fábio
Freitas da Silva, 6ª. ed. Rio de Janeiro: Campus, 2000.
BUYS, Bruno et. al. O surgimento do Linux, 2000. Disponível
<http://www.comciencia.br/reportagens/softliv/softliv5.htm>. Acesso em: 10 jun. 2005.
em:
CIPSGA. Governo reafirma que programa SL é estratégico para o país, 2005. Disponível
em: <http://softwarelivre.org.br/article.php?sid=7106>. Acesso em: 10 jun. 2005.
CIPSGA. Maddog: O FISL é a melhor conferência do mundo sobre o tema, 2005. Disponível
em: <http://www.softwarelivre.org/news/4254>. Acesso 10 jun. 2005.
DOCUMENTAÇÂO do PostgreSQL 8.0.0. The PostgreSQL Global Development Group, 19962005. Disponível em: <http://pgdocptbr.sourceforge.net/pg80/preface.html>. Acesso em: 15
set. 2005.
EGAS, Frederico M. G. UML-Unified Modeling Language: Overview, 2001. Disponível em:
<www.inf.ucp.br/profs/tavares/ 2001_02/aula01/apresentacao_aula1.ppt>. Acesso em 01 de
jun. 2005.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados : fundamentos e
aplicações. 3ª ed. Rio de Janeiro: LTC, 2002.
FURLAN, José Davi. Modelagem de Objeto através da UML. São Paulo: Makron Books,
1998.
GNU. O que é software livre?, 2000. Disponível em: <http://www.gnu.org/philosophy/freesw.pt.html>. Acesso 09 jun. 2005.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. São Paulo: Novatec Editora Ltda,
2005.
HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4ª. ed. Porto Alegre: Instituto de
Informática da UFRGS: Sagra Luzzatto, 2001.
JAVAFREE. Disponível em: <http://www.javafree.org/news/view.jf?idNew=517>. Acesso em
17 jun. 2005.
KHOSHAFIAN, Strag. Banco de dados orientado a objeto; trad. Tryte Informática. Rio de
Janeiro: Infobook, 1994.
KORTH, Henry F.; SILBERSCHATZ, Abraham. Sistema de Banco de Dados. 2ª. ed. ver.
São Paulo: Makron Books, 1995.
57
KROENKE, David M. Banco de Dados: Fundamentos, Projeto e Implementação. 6 ed. Rio de
Janeiro: Livros Técnicos e Científicos Editora S.A., 1999.
LARMAN, Craig. Utilizando UML e Padrões: uma introdução à análise e ao projeto
orientados a objetos. Porto Alegre: Bookman, 2000.
MANUAL do Umbrello UML Modeller. Umbrello UML Modeller, 2003. Disponível em:
<http://docs.kde.org/development/pt_BR/kdesdk/umbrello/index.html>. Acesso em: 15 set.
2005.
MUASSAB, José R. Gerenciamento da Manutenção na Indústria Automobilística. 2002.
98f. Monografia – (Especialização MBA-Gerência de Produção). Disponível em:
<http://www.unitau.br/prppg/cursos/ppga/mba/2002/muassab_jose_roberto.pdf>. Acesso em:
25 mai. 2005.
NASSU, Eugénio A.; SETZER, Valdemar W. Bancos de Dados Orientados a Objetos. São
Paulo: Edgard Blucher, 2002
POSTGRESQL-Projeto Brasil. Disponível em: <http://www.postgresql.org.br/>. Acesso em 15
jun. 2005.
SILVA, Douglas Marcos da. UML, Guia de consulta rápida. São Paulo: Novatec Editora, 2001.
SOFTWARE Livre, Tendência do Governo Federal é implantar 'software livre' em
todos
os
setores
públicos,
2005.
Disponível
em:
<http://sl.geness.ufsc.br/ceae/index.php?option=com_content&task=view&id=31&Itemid=2>.
Acesso 10 jun. 2005.
UMBRELLO UML Modello. Disponível em: <http://uml.sourceforge.net/index.php>. Acesso
em 15 jun. 2005.
WEB Total.
Desenvolvimento
Orientado
ao
Bolso,
2003.
Disponível
em:
<http://webtotal.com.br/template.php?pagina=/comuns/artigos/artigos.php&id_artigo=46&pag=
1&area=php>. Acesso em: 15 dez. 2005.
WINBLAD, Ann L.; EDWARDS, Samuel D.; KING, David R. Software Orientado ao Objeto.
São Paulo: Makron Books, 1993.
11 APÊNDICES
59
Apendice 1. Descrição Textual do Sistema de Manuntenção de Equipamentos
Para acessar o sistema o usuário deverá entrar com o seu código de funcionário. As
solicitações de serviço devem ser feitas somente via rede.
Todos os usuários devem possuir um nível de senha (exemplo: 1)para acesso normal
em todos campos exceto no campo de autorização onde o usuário deve possuir uma senha
maior (exemplo:2) para coordenador, diretor de centro etc.
SMP deve possuir uma tela principal onde o Setor de Manutenção irá receber todas as
solicitações de conserto/manutenção das estruturas.
As solicitações devem possuir um campo chamado “tipo de conserto/manutenção”. Os
campos devem ser os seguintes (Bloco, piso, centro/setor/gerencial/ramal/nome da pessoa
que enviou a solicitação, e-mail, data da próxima manutenção preventiva, status informando
se foi executada “ok ou pendente”, espaço para descrever o problema. Obs: todos os campos
deverão ser preenchidos .
Na estrutura de equipamentos número do patrimônio será a base para todas as
informações, se possível resgatar algumas informações do NewAge4 exemplo(data da
aquisição, valor de aquisição, fornecedor, data da garantia quando novo, local físico, conta
gerencial, responsável direto pelo equipamento (exemplo diretor de centro).
Na estrutura de equipamentos o sistema deve possuir 02 formulários diferenciadas de
manutenção (01- preventiva e 02- corretiva):
•
01 Preventiva campos : Data da próxima manutenção e a freqüência que ela deve ser
executada, status informando se a manutenção foi executa ou não “ok ou pendente”,
manutenção interna e externa, valor da manutenção, campo para descrever MP interna e
MP externa, nome do técnico responsável pela descrição da MP, tempo de garantia da
manutenção, nome do fornecedor,
4
New Age - é um sistema de informação contábil, financeiro, patrimonial, fiscal da UNOCHAPECÓ
60
•
02 Corretiva campos : data da aquisição, valor de aquisição, fornecedor, data da garantia
quando novo, local físico , conta gerencial, responsável direto pelo equipamento (exemplo
diretor de centro),campo para descrição do serviço realizado e/ou peças que foram
substituídas.
Devem ter relatórios para:
•
das manutenções preventivas devem ser feitos mensalmente;
•
das solicitações de manutenção pendentes;
•
do status da manutenção preventiva;
•
das despesas por setor/gerencial;
•
dos equipamentos que retornaram da manutenção;
•
das manutenções preventivas executadas no campus;
•
das manutenções preventivas executadas por terceiros;
61
Apêndice 2. Relatório da entrevista realizada com o Setor de Infra-estrutura e
Manutenção da UNOCHAPECÓ
Nome: Douglas José Ramos do Prado
O sistema de manutenção preventiva deverá ser divido em 4 estruturas :
equipamentos;
hidráulica;
elétrica;
predial
Obs.: Sistema de manutenção preventiva será divido em 2 etapas de implantação, a 1º etapa
deverá ser implantada no decorrer do ano de 2005 e irá abranger somente a (Estrutura de
Equipamentos), a 2º etapa deverá ser implantada no decorrer do ano de 2006 e irá abranger
as Estruturas(elétrica, hidráulica e predial) .
1. Informações necessárias referentes ao equipamento :
Nome do equipamento;
Número do patrimônio;
Descrição/especificações do equipamento;
Marca do equipamento;
Número de série;
Localização atual do equipamento;
Pertencente ao centro/setor;
Data de aquisição;
Tempo de garantia do equipamento/peças
Valor de aquisição;
Manutenção Corretiva:
Data da manutenção
Histórico/comentários sobre a manutenção
Tempo de garantia da manutenção
Descrição das peças trocadas
Valor da manutenção
62
Manutenção Preventiva/preditiva :
Usar cronograma anual (férias)
Identificar se a MP será executada por técnicos internos ou externos
O sistema deverá informar através de e-mail a data que a manutenção deverá ser
executada.
2. Criar Ordem de Serviço ( OS) com os seguintes campos:
Numeração(0001 à 1.000/Ano);
Responsável direto pelo equipamento;
Ramal do responsável;
Conta Gerencial onde deverá ser lançado o custo da manutenção;
Data saída do equipamento para o conserto;
Prazo máximo de retorno;
Nome da empresa onde foi encaminhado o equipamento (telefone/fax/e-mail da empresa);
Provável defeito;
3. EMISSÃO DE RELATÓRIOS
Relatório dos equipamentos que foram enviados para fora do campus para manutenção
preventiva ou corretiva (mês/semestre/ano);
Relatório dos equipamentos que retornaram da manutenção;
Relatório dos equipamentos que não retornaram da manutenção(pendentes);
Relatório do custos com manutenção preventiva/corretiva;
Relatório por conta gerencial;
Relatório das manutenções preventivas executados no campus;
Relatório das manutenções preventivas pendentes referentes ao campus;
4. USUÁRIOS
Todos os professores/técnicos e estagiários que estiverem em rede, poderão solicitar a
manutenção/conserto de qualquer tipo de equipamento. Através da Ordem de Serviço
(OS), que obrigatoriamente
63
Apêndice 3. Instalação e configuração do Sistema Operacional LINUX – CentOs e
phpPgAdmin
•
Instalar o Sistema Operacional LINUX-CentOs, no tipo de instalação selecionar a
opção
Servidor,
fazendo
a
instalação
e
configuração
das
ferramentas
necessárias(HTTPD, PHP e Postgresql) .
•
Iniciar os serviços httpd e postgresql;
•
Para testar se as ferramentas estão funcionando, criar um aquivo em php com a
função phpinfo();
•
Instalar
o
phpPgAdmin,
que
é
só
descompactar
para
o
diretório
de
publicação(/var/www/html) e renomear o arquivo para phpPgAdmin;
•
No arquivo config.inc.php do postgresql(/var/www/html/phpPgAdmin/conf/), configure
as seguintes linhas:
•
•
$conf['servers'][0]['host'] = 'localhost';
•
$conf['extra_login_security'] = false;
No arquivo pg_hba.conf (/var/lib/pgsql/data/), altere as seguintes linhas:
•
local all
•
lost
all md5 (md5 – requer um senha para autenticação)
all
all
127.0.0.1 255.255.255.255 trust (trust – a conexão sempre é
permitida por qualquer usuário existente)
•
No arquivo postgresql.conf (/var/lib/pgsql/data/), altere a seguinte linha:
•
•
#tcpip_socket = false para tcpip_socket = true
Para alterar a senha do administrado do banco que é usuario postgres:
[root@LabRT1 ~]# su - postgres
-bash-3.00$ createdb tcc
CREATE DATABESE
-bash-3.00$ psql tcc
Senha:(dependendo do método utilizado)
Bem-vindo ao psql 7.4.8, o terminal iterativo do PostgreSQL.
Digite: \copyright para mostrar termos de distribuição
\h para ajuda com comandos SQL
\? para ajuda com comandos internos
\g ou terminar com ponto-e-vírgula para executar a consulta
64
\q para sair
tcc=# alter user postgres with encrypted password 'senha';
ALTER USER
tcc=# \q
•
O PostgreSql trabalha com formato de datas ano-mês-dia, por exemplo '2006-06-12',
assim, para resolver este problema foi necessário alterar o datestyle, no
postgresql.conf, como demonstrado abaixo:
#datestyle iso, mdy
alterar para
datestyle iso, dmy
Alguns comandos básicos necessários para instalação, no Sistema Operacional Linux,
para qualquer tipo de pacote:
•
make: compila arquivos
•
make install <pacote>: instala software, depois de compilar
•
yum install <pacote>: procura o software para instalação
•
rpm –ivh <arquivo.rpm>: instala pacote .rpm
•
tar –zxvf <arquivo.tar.gz>: descompacta arquivos .tar.gz
•
./<arquivo>: roda o script de configuração do programa
•
chmod +x <arquivo.rpm.bin> ou chmod u+x <arquivo.rpm.bin>: transforma o
arquivo.bin em um executável
65
Apêndice 4. Arquivo usuario.tle
<html>
<head>
<title>Sistema de Manutencao Preventiva e Corretiva de Equipamentos - SMPC </title>
<link rel="stylesheet" href="view/styles.css" type="text/css">
<meta http-equiv="Content-Type" content="text/html;">
<script language="JavaScript">
function makeArray() {
for (i = 0; i<makeArray.arguments.length; i++)
this[i] = makeArray.arguments[i];
}
function getFullYear(d) {
var y = d.getYear();
if (y < 1000) {y += 1900};
return y;
}
//var zone = "EDT";
var days = new makeArray("Domingo","Segunda","Terca","Quarta","Quinta","Sexta","Sabado");
var months = new
makeArray("Janeiro","Fevereiro","Março","Abril","Maio","Junho","Julho","Agosto","Setembro","Outubro","N
ovembro","Dezembro");
function format_time(t) {
var Day = t.getDay();
var Date = t.getDate();
var Month = t.getMonth();
var Year = t.getFullYear();
timeString = "";
timeString += days[Day];
timeString += ", ";
timeString += " ";
timeString += Date;
timeString += " de ";
timeString += months[Month];
timeString += " de";
timeString += " ";
timeString += Year;
timeString += ".";
return timeString;
}
</script>
</head>
<body bgcolor="#ffffff" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0" link="#FF9933"
vlink="#FF6600">
<table width="100%" border="0" cellspacing="0" cellpadding="0" height="100%">
<tr>
<td valign="top" height="85"><table width="100%" border="0" cellspacing="0" cellpadding="0"
height="85">
66
<tr>
<td valign="top" width="241" height="85"><img name="companyname" src="images/smpc.gif"
border="0" width="241" height="85"></td>
<td valign="top" height="85">
<table width="100%" border="0" cellspacing="0" cellpadding="0" height="85" bgcolor="#FFCB7D">
<tr>
<td height="41" valign="top" width="28" align="left" bgcolor="#FBDEB1"><img
src="spacer.gif" width="1" height="41"></td>
<td height="41" valign="middle" width="97%" align="right" bgcolor="#FBDEB1"><p align="center">
<font color="#004080"><span class="title">Sistema de Manutencao Preventiva e
Corretiva</span></font></td>
</tr>
<tr>
<td valign="top" height="24" width="28" align="left"><img name="menutriangle"
src="images/menutriangle.gif" width="28" height="24" border="0"></td>
<td height="24" background="images/menufill.gif" align="right" nowrap><a class="menutext"
href="usuario.php" target="_self">Home</a>&nbsp;&nbsp;&nbsp;<span
class="menutext">&nbsp;|</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a class="menutext"
href="u_inserir.php">Inserir</a> &nbsp;&nbsp;<span class="menutext">&nbsp;
|</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a class="menutext" href="u_consultar.php">Consultar
Todos</a>&nbsp;&nbsp; <span class="menutext">
&nbsp;&nbsp;|&nbsp;</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a class="menutext"
href="u_consultar_pl.php"> Consultar por palavra</a>&nbsp;&nbsp; <span
class="menutext">&nbsp;&nbsp;|&nbsp;</span>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;<a class="menutext"
href="logout.php" target="_self">Sair</a></td>
</tr>
<tr>
<td height="20" width="28" align="left" bgcolor="#FBDEB1"></td>
<td height="20" valign="middle" align="right" bgcolor="#FBDEB1"></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td valign="top" height="85%"><table width="100%" border="0" cellspacing="0"
cellpadding="0" height="100%">
<tr valign="top">
<td width="189" bgcolor="#FFCB7D" height="488"><table width="100%" border="0"
cellspacing="0" cellpadding="12" height="100%">
<tr>
<td align="center" valign="middle" height="55" bgcolor="#FBDEB1"><img name="logo"
src="images/logo.gif" width="169" height="60" border="0"></td>
</tr>
<tr>
<td valign="top" align="center" bgcolor="#FBDEB1"><table width="100%" border="0"
cellspacing="0" cellpadding="1" bgcolor="#F29200" height="100">
<tr>
<td valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"
height="100%">
<tr>
<td height="18" bgcolor="#FFB13E" valign="middle" align="center"
class="menutext">SMPC</td>
</tr>
<tr>
<td bgcolor="#FFCB7D" valign="top"><table width="100%" border="0" cellspacing="0"
67
cellpadding="3" height="100%">
<tr>
<td valign="middle" align="center" height="80" class="whitetext">Prototipo de um Sistema
de Manutencao Preventiva de Equipamentos, aplicada a UNOCHAPECO usando o
Paradigma de
Orientacao a Objetos com Software Livre<p><img src="images/imagem.gif" width="150"
height="147" alt="imagem.gif (66207 bytes)"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td bgcolor="#FFCB7D" valign="bottom" align="right" height="12"><img name="tabletriangle"
src="images/tabletriangle.gif" width="12" height="12" border="0"></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
<td width="80%"><table width="766" border="0" cellspacing="0" cellpadding="5"
height="100%">
<tr>
<td valign="middle" height="47" width="124"></td>
<td valign="middle" height="47" align="right" class="subtitle" width="622"><script
language="JavaScript">
<!-d = new Date();
document.write(format_time(d));
// -->
</script> </td></tr>
<tr>
<td valign="top" width="736" colspan="2">#CENTRO</td>
</tr>
</table></td>
<td width="33" align="right" valign="bottom">&nbsp;<p>&nbsp;</td>
</tr>
</table> </td>
</tr>
<tr>
<td height="20" bgcolor="#FFB13E" valign="middle" align="center" class="footer">Trabalho
de Conclusao de Curso - Ciencia da Computação - Marcela do Prado</td>
</tr>
</table>
</body>
</html>