UNIVERSIDADE PAULISTA - UNIP COORDENAÇÃO DE … · Monografia submetida à Coordenação de ......
Transcript of UNIVERSIDADE PAULISTA - UNIP COORDENAÇÃO DE … · Monografia submetida à Coordenação de ......
UNIVERSIDADE PAULISTA - UNIP COORDENAÇÃO DE GRADUAÇÃO EM
ENGENHARIA DA COMPUTAÇÃO ANTÔNIO DEYVYSON BEZERRA DUARTE
CONTRIBUIÇÃO AO DESENVOLVIMENTO DO SISTEMA DE GEREN CIAMENTO
DE MANUTENÇÃO INDUSTRIAL – CAMADA MODEL
MANAUS 2008
1
ANTÔNIO DEYVYSON BEZERRA DUARTE
CONTRIBUIÇÃO AO DESENVOLVIMENTO DO SISTEMA DE GEREN CIAMENTO DE MANUTENÇÃO INDUSTRIAL – CAMADA MODEL
Monografia submetida à Coordenação de Graduação da Universidade Paulista – UNIP, como requisito parcial para obtenção do Título de Bacharel em Engenharia da Computação. Orientador: Fábio Souza Cardoso MSc. Co-Orientador: Marcelo A. Oliveira MSc.
MANAUS 2008
2
ANTÔNIO DEYVYSON BEZERRA DUARTE
CONTRIBUIÇÃO AO DESENVOLVIMENTO DO SISTEMA DE GEREN CIAMENTO DE MANUTENÇÃO INDUSTRIAL – CAMADA MODEL
Monografia submetida à coordenação de graduação da Universidade Paulista - UNIP como requisito parcial à obtenção do Título de Bacharel em Engenharia da Computação.
Aprovada em: 15 de dezembro de 2008.
BANCA EXAMINADORA
____________________________________________ Profº. Fábio Souza Cardoso, MSc.
Orientador
____________________________________________ Profº. Marcelo A. Oliveira, MSc.
Co-orientador / Examinador
____________________________________________ Profº. Danielle Lima, Esp.
Examinador
MANAUS 2008
3
DEDICATÓRIA
Aos meus pais, pelas angústias e
preocupações que passaram por minha causa, por
terem dedicado suas vidas a mim, pelo amor, carinho
e apoio que me ofereceram, dedico-lhes essa
conquista como gratidão.
4
AGRADECIMENTOS
Agradeço a Deus por permitir mais esta realização
na minha vida;
Ao Orientador Profo Fábio Cardoso pelo apoio e
pela confiança em mim depositada;
Ao Coordenador Profo Marcelo A. Oliveira pela
oportunidade no desenvolvimento do Projeto MMS;
Aos Professores pelos ensinamentos, empenho e
pela dedicação no decorrer do curso de Engenharia;
Aos amigos e colegas da equipe de
desenvolvimento do Projeto MMS: Diego Nascimento,
Marcelo Pereira, Paôllo Maciel e Raphael Souza;
Aos amigos Roberlânio e Erivelson pelos incentivos
e apoio no decorrer do curso de Engenharia;
À minha família, por compreender minha ausência
no decorrer deste curso e me apoiarem nos momentos
mais difíceis;
À Rosângela Nunes pela compreensão, apoio,
amor e carinho durante a realização deste trabalho.
5
RESUMO
Este trabalho descreve a contribuição no desenvolvimento de um software de gestão de manutenção, visando à otimização dos processos relacionados às rotinas de planejamento, prevenção e correção de falhas nas máquinas, decorridas durante as atividades realizadas na indústria do PIM (Pólo Industrial de Manaus). A implementação do software seguirá o padrão de desenvolvimento web MVC (Model-View-Controller), onde serão desenvolvidas rotinas de comunicação e gerenciamento do estado das informações contidas na base de dados, através do SGBD (Sistema de Gerenciamento de Bando de Dados) MySQL, utilizando os conceitos de orientação a objetos.
Palavras-chave : Gestão de Manutenção; MVC (Model-View-Controller); Desenvolvimento Web;
6
ABSTRACT
This paper describes the contribution in the development of a software of maintenance management, aiming at the optimization of procedures related to the routines of planning, prevention and correction of failures in the machines, that happen during the activities in the industry at PIM (Pólo Industrial de Manaus). The software is developed using the MVC (Model-View-Controller) design pattern, for which will be developed routines for communication and management of the information state contained in the database, through the DBMS (Block Management System Database) MySQL, using the concepts of object oriented model.
Key Words: Maintenance Management; MVC (Model-View-Controller);
Web Development;
7
SUMÁRIO
INTRODUÇÃO ..........................................................................................................11
1. MANUTENÇÃO DE MÁQUINA .............................................................................16 1.1 Introdução ...........................................................................................................16 1.2 Tipos de Manutenção..........................................................................................19 1.2.1. Manutenção Corretiva .....................................................................................20 1.2.1.1. Manutenção Corretiva Não Planejada..........................................................20 1.2.1.2. Manutenção Corretiva Planejada .................................................................21 1.2.2. Manutenção Preventiva...................................................................................22 1.2.3. Manutenção Preditiva......................................................................................23 1.2.4. Manutenção Detectiva.....................................................................................24 1.2.5. Engenharia de Manutenção ............................................................................25 1.3. Indicadores de Desempenho de Máquina..........................................................26
2. TECNOLOGIAS DE DESENVOLVIMENTO WEB.................................................30 2.1. Introdução ..........................................................................................................30 2.2. Plataforma de Desenvolvimento .NET ...............................................................32 2.2.1 Características da Plataforma .Net...................................................................32 2.2.2. Estrutura da Plataforma .NET .........................................................................33 2.3. .NET Framework ................................................................................................34 2.3.1. Common Language Runtime (CLR) ................................................................35 2.3.2. .NET Framework Class Library (BLC) .............................................................37 2.3.3. ADO .NET .......................................................................................................38 2.3.4. ASP .NET........................................................................................................39 2.3.5. Windows Forms...............................................................................................40 2.3.6. Common Language Specification (CLS) .........................................................40 2.3.7. Linguagem de Programação C#......................................................................41 2.4. Mono Rails – Implementação do MVC (Model-View-Controller) ........................42 2.5. Object Relational Mapping (ORM)......................................................................44 2.5.1. NHibernate ......................................................................................................45 2.5.2. Castle ActiveRecord........................................................................................47 2.6. Sistema Gerenciador de Banco de Dados (SGBD)............................................49 2.6.1 MySQL .............................................................................................................52
8
3. METODOLOGIA....................................................................................................54 3.1. Requisitos do Software.......................................................................................54 3.1.1. Diagrama de Classe........................................................................................56 3.1.2. Diagrama de Seqüência ..................................................................................60 3.3. Plano de Testes .................................................................................................65
4. DESENVOLVIMENTO DA CAMADA MODEL DO PROJETO MMS .....................66
CONCLUSÃO E TRABALHOS FUTUROS ...............................................................72
REFERÊNCIAS BIBLIOGRÁFICAS..........................................................................74
APÊNDICE A - Documento de Especificação (DER) ................................................77
APÊNDICE B – Código-Fonte das Classes Desenvolvidas para a Camada Model ..91
ANEXO 1 – Plano de Testes...................................................................................128
9
LISTA DE FIGURAS
Figura 1 – Resultado X Tipos de Manutenção..................................................................26 Figura 2 - Cálculo do MTBF .................................................................................................28 Figura 3 - Cálculo do MTTR.................................................................................................28 Figura 4 - Demonstração dos Indicadores na linha do tempo........................................29 Figura 5 - Arquitetura de duas camadas (cliente/servidor) .............................................30 Figura 6 - Arquitetura de várias camadas..........................................................................31 Figura 7 - Estrutura da plataforma .NET com as suas principais tecnologias .............34 Figura 8 - Estrutura do .NET framework ............................................................................35 Figura 9 - Funcionamento da CLR......................................................................................36 Figura 10 - Estrutura de um arquivo executável pelo CLR .............................................37 Figura 11 - Arquitetura ADO.NET .......................................................................................39 Figura 12 - Arquitetura ASP.NET ........................................................................................39 Figura 13 - Padrão MVC - separação em camadas.........................................................43 Figura 14 - Arquivo XML de mapeamento.........................................................................46 Figura 15 - Classe .Net .........................................................................................................46 Figura 16 - Mapeamento das tabelas do banco de dados..............................................47 Figura 17 - Diagrama de Bloco MVC..................................................................................47 Figura 18 - Implementação de Classe .NET utilizando ActiveRecord ..........................48 Figura 19 - Representação do mapeamento das tabelas com ActiveRecord .............49 Figura 20 - Configuração de um sistema de Banco de Dados.......................................52 Figura 21 - Diagramas existentes na UML 2.0 .................................................................56 Figura 22 - Diagrama de Classe (Usuários do Sistema).................................................57 Figura 23 - Diagrama de Classe (Dados da Máquina) ....................................................58 Figura 24 - Diagrama de Classe (Ordem de Serviço) .....................................................59 Figura 25 - Diagrama de Classe (Logs do Sistema) ........................................................60 Figura 26 - Diagrama de Seqüência de login do usuário................................................61 Figura 27 - Diagrama de Seqüência de cadastro de um usuário ..................................61 Figura 28 - Diagrama de Seqüência de Cadastro de uma Máquina .............................62 Figura 29 - Diagrama de Seqüência de Abertura de Ordem de Serviço Corretiva ....62 Figura 30 - Diagrama de Seqüência de Fechamento de Ordem de Serviço ...............63 Figura 31 - Diagrama de Seqüência de Indicadores de Manutenção 1 .......................64 Figura 32 - Diagrama de Seqüência de Indicadores de Manutenção 2 .......................64 Figura 33 - Classe Authentication.cs..................................................................................67 Figura 34 - Classe Machine.cs ............................................................................................68 Figura 35 - Classe ServiceOrder.cs....................................................................................69 Figura 36 - Classe MaintenanceReport.cs ........................................................................70 Figura 37 - Classe CorrectiveMaintenanceReport.cs ......................................................71 Figura 38 - Classe MachineStopLog.cs .............................................................................71
10
LISTA DE ABREVIATURAS
BCL Base Class Library
CLR Common Language Runtime
CLS Common Language Specification
CTS Common Type System
DER Documento de Especificação de Requesitos
HTML Hypertext Markup Language
IL Intermediate Language
JIT Just In Time
JVM Java Virtual Machine
MMS Maintenance Management System
MSIL Microsoft Intermediate Language
MTBF Mean Time Between Failures
MTTR Mean Time To Repair
MVC Model-View-Controller
OO Orientado a Objeto
ORM Object Relational Mapping
PE Portable Executable
RBM Reliability Based Maintenance
RCM Reliability Centered Maintenance
SGBD Sistema Gerenciador de Banco de Dados
SOAP Simple Object Access Protocol
TPM Total Productive Maintenance
XML Extensible Marckup Language
XSLT Extensible Stylesheet Language for Transformations
11
1. INTRODUÇÃO
Em um mercado altamente competitivo, melhorar a utilização das instalações
é fundamental para se alcançar a produtividade necessária à sobrevivência e
sucesso da empresa.
A manutenção, como função estratégica das organizações e responsável
direta em garantir a disponibilidade dos equipamentos e instalações, de modo a
atender a um processo de produção com confiabilidade, segurança e custos
adequados, tem uma importância capital nos resultados da empresa. Esses
resultados serão tanto melhores quanto mais eficaz for a gestão de manutenção.
A gestão de manutenção é um sistema que se baseia em dados técnico-
econômicos para o estabelecimento de um plano estratégico que prevê ações de
curto, médio e longo prazo. Diante de um mercado desafiador, competitivo e uma
grande diversificação de tipos de manutenção, necessita-se de ferramentas
(softwares) para dar suporte em todo processo de manutenção das máquinas e
facilitar tomadas de decisões cada vez mais ágeis.
Atualmente há aplicativos que fornecem ferramentas poderosas para
gerenciar importantes funções de negócios, mas na maioria dos casos, funcionam
sem levar em conta a individualidade e as necessidades específicas dos clientes.
“Assim como não há dois indivíduos com características e recursos idênticos,
também não existem duas empresas que executem processos e procedimentos da
mesma maneira. Portanto, para que um software realmente acrescente valor a uma
empresa, ele deve ser não apenas poderoso e escalável, mas também adaptável às
necessidades específicas e em constante mudança de seus clientes” [Izabel
Cristina, 2001].
1.1. Justificativa
Para atender a esta necessidade, desenvolver-se-á um software, utilizando os
conceitos de orientação a objetos e seguindo o padrão de desenvolvimento web
12
MVC (Model-View-Controller), que possa auxiliar o gestor (ou equipe) de
manutenção no monitoramento, mapeamento e coleta das informações relacionadas
com as rotinas de manutenção das máquinas envolvidas de forma direta e indireta
com a produção da empresa.
O padrão MVC (Model-View-Controller) divide o software em três camadas. A
camada Model contém os componentes da aplicação que são responsáveis pela
manutenção de estado das informações contidas das bases de dados. Na camada
View há os componentes responsáveis pela exibição da interface do software ao
usuário. A camada Controller é responsável pela lógica do software, manipulando os
componentes da camada Model através das solicitações feitas pela camada View.
Visando melhorar a qualidade do software e aumentar a produtividade no
processo de desenvolvimento, utilizar-se-á a engenharia de software através da
aplicação da metodologia de desenvolvimento de software SCRUN. “Scrum é um
modelo ágil de gestão de projeto de software, que se baseia no desenvolvimento
incremental das aplicações com ciclos de integrações curtos, permitindo um maior
controle durante o processo desenvolvimento” [Roger Pressman, 2002].
1.2. Objetivo Geral
Contribuir com o desenvolvimento de um sistema para auxiliar a gestão de
manutenção, através dos conceitos de orientação a objeto e utilizando o padrão de
desenvolvimento para aplicações Web MVC (Model-View-Controller).
1.3. Objetivos Específicos
• Analisar as especificações técnicas dos requisitos do software;
• Realizar a modelagem dos diagramas de classe e dos diagramas de
seqüência da camada Model;
• Desenvolver os componentes (classes) da camada Model;
13
• Implementar rotinas de testes para validar o fluxo lógico e o fluxo de
dados na estrutura interna dos componentes da camada Model;
1.4. Metodologia
Para a conclusão e atingir os objetivos deste projeto, aplicar-se-á uma
divisão nas etapas de desenvolvimento do software, seguindo uma cronologia de
tempo e datas empregadas pelo método adotado de desenvolvimento de projeto
SCRUN.
Com base nas análises técnicas dos requisitos do software (ver anexo),
serão desenvolvidos com auxílio das ferramentas JUDE Community e DBDesigner,
os diagramas de classes e os diagramas de seqüência.
Fazendo uso da tecnologia ASP.NET, da linguagem de programação C# e
ferramentas de desenvolvimento da plataforma .Net Framework, serão
implementados os componentes (classes) da camada Model, responsáveis pelas
consultas e manutenção do estado dos dados persistido no interior de uma base de
dados controlada por um Sistema de Gerenciamento de Banco de Dados (SGBD).
Durante o ciclo de desenvolvimento, implementar-se-á testes para validar os
fluxos lógicos e a confiabilidade dos resultados gerados pelas classes desenvolvidas
para a camada Model. Após a realização dos testes, durante reuniões com datas
previamente estabelecida pela engenharia de software, haverá o processo de
integração com os outros módulos desenvolvidos pela a equipe.
1.5. Organizaçao do trabalho
O contexto do trabalho será apresentado em seis (6) capítulos, onde o
segundo capítulo aborda as características relacionadas com a necessidade de
maior disponibilidade e confiablidade das máquinas envolvidas no processo
produtivo. Demonstra-se a necessidade de implantação e interação entre as fases
de projeto, fabricação, instalação, operação e manutenção na busca de aumentar a
14
disponibilidade e confiabilidade das máquinas. Apresentam-se os tipos de
manutenção disponíveis, também considerados políticas de manuteção:
• Manutenção Corretiva Não Planejada;
• Manutenção Corretiva Planejada;
• Manutenção Preventiva;
• Manutenção Preditiva;
• Manutenção Detectiva;
• Engenharia de Manutenção;
Para atingir a missão da manutenção, que é “garantir a disponibilidade da
função dos equipamentos e instalações de modo a atender a um processo de
produção ou de serviço com confiabilidade, segurança e custo adequado” [KARDEC,
2001], demonstra-se a necessidade de criar planos estratégicos de manutenção
baseados em informações obtidas no decorrer das atividades (manutenção) e a
realização de uma análise dos principais indicadores de disponibilidade das
máquinas: MTBF, MTTR e DownTime.
O terceiro capítulo demonstra as principais características e objetivos da
plataforma .NET no desenvolvimento web utilizando Sistemas Gerenciadores de
Banco de Dados (SGBD). Descreve-se sobre os componentes da arquitetura do
.NET framework:
• Common Language Runtime (CLR)
• .NET framework class library (BCL)
• ADO.NET
• ASP.NET
• Windows Forms
• Common Language Specification (CLS) ;
• Linguagens de Programação;
No quarto e quinto capítulo correspondem à metodologia e aos processos de
desenvolvimento do software, tendo que explicar, discutir e desmonstrar os
resultados obtidos. Os resultados demostrarão as classes (códigos) desenvolvidos,
a partir da análise realizada no documento de especificação de requisitos (DER),
15
gerado nas reuniões com o cliente. Também serão demonstrados os diagramas de
classe e sequência, necessários para o desenvolvimento da camada Model.
Finalmente no sexto capítulo apresenta-se as conclusões obtidas no
desenvolvimento deste trabalho e sugestões para trabalhos futuros.
16
2. MANUTENÇÃO DE MÁQUINA
2.1 Introdução
O crescimento da automação e da mecanização passou a indicar a
necessidade de maior disponibilidade, bem como maior confiabilidade, tudo isto na
busca da maior produtividade. Com isso o custo da manutenção também começou a
se levar muito em comparação com outros custos operacionais. Esse fato fez
aumentar os sistemas de planejamento e controle de manutenção que, hoje são
parte integrante da manutenção moderna [KARDEC, 2001].
A disponibilidade e confiabilidade dependem da interação e correta realização
das fases de implantação de um sistema:
• Projeto;
• Fabricação;
• Instalação;
• Operação;
• Manutenção;
Na fase do projeto, o levantamento de necessidades, inclusive o envolvimento
dos usuários (operação e manutenção), além dos dados específicos para sua
elaboração, nível de detalhamento, dentre outros, são de fundamental importância,
pois irão impactar diretamente nas demais fases, com conseqüência no
desempenho e na economia (custo-eficiência).
A fabricação deve ser devidamente acompanhada e incorporar os requisitos
de modernidade e aumento da confiabilidade dos equipamentos, além das
sugestões oriundas da prática de manutenção.
A fase de instalação deve prever cuidados com a qualidade da implantação
do projeto e as técnicas utilizadas para esta finalidade. Quando a qualidade não é
apurada, muitas vezes são inseridos pontos potenciais de falhas que se mantêm
17
ocultos por vários períodos e vêm a se manifestar muitas vezes quando o sistema é
fortemente solicitado.
As fases de manutenção e operação terão por objetivo garantir a função e o
desempenho dos equipamentos, sistemas e instalações no decorrer de sua vida útil.
Nesta fase da existência, normalmente são detectadas as deficiências geradas no
projeto, seleção de equipamentos e instalação.
Mesmo que a empresa detenha das melhores e mais modernas técnicas de
implementação do processo de manuteção, há a necessidade de uma grande
interação entre as fases descritas, pois caso contrário, a manutenção poderá
encontrar várias dificuldades de desempenho durante suas atividades.
As pessoas ou as equipes envolvidas, mostram-se também como um
importante e impactante fator para qualidade e confiabilidade do processo de
manutenção. As mesmas têm que apresentar-se qualificadas e dotadas de espírito
de equipe, na busca das melhores soluções para empresa.
“O trabalho da manutenção está sendo enobrecido onde, cada vez mais, o
pessoal da área precisa estar qualificado e equipado para evitar falhas e não para
corrigi-las” [KARDEC, 2001].
Esta nova postura é fruto dos novos desafios que se apresentam para as
empresas neste novo cenário de uma economia globalizada e altamente
competitiva, onde as mudanças se sucedem em alta velocidade e a manutenção,
como uma das atividades fundamentais do processo produtivo, precisa ser um
agente proativo [KARDEC, 2001].
Neste cenário a manutenção passa adotar características estratégicas,
voltadas para excelentes resultados. Não existem mais espaços para improvisos e
arranjos. As empresas e organizações para manter a competividade e a
sobrevivência, precisam de caraterísticas básicas:
• Competência;
• Criatividade;
18
• Flexibilidade;
• Velocidade;
• Cultura de mudança;
• Trabalho em equipe;
Aliado a isto, cada vez mais têm amadurecido as relações de parceria entre
as empresas e suas contratadas na área de manutenção. Neste contexto, uma nova
estratégia está sendo praticada com os chamados contratos de parceria baseados
em disponibilidade e confiabilidade das instalações, onde a contratada aumenta a
sua lucratividade à medida que melhora a disponibilidade e a confiabilidade das
instalações da empresa onde está atuando.
Neste tipo de contrato não mais se pagam “serviços”, mas “soluções”. Esta
mudança estratégica da manutenção tem reflexo direto nos resultados empresariais,
tais como:
� Aumento da disponibilidade;
� Aumento do faturamento e do lucro;
� Aumento da segurança pessoal e das instalações;
� Redução da demanda de serviços;
� Redução de custos;
“Ao invés de se falar em “mudança de cultura”, que é um processo lento não
condizente com as necessidades atuais, é preciso que a gestão implemente uma “cultura
de mudanças”, onde o inconformismo com a perpetuação de paradigmas e de práticas
seja uma constante” [KARDEC, 2001].
Para dar suporte a estas necessidades de mudanças e que a equipe de
gestão possa liderar este processo, tem sido colocado à disposição uma grande
variedade de ferramentas gerenciais.
“É importante ter em mente que são, simplesmente, ferramentas e, como tal,
a sua simples utilização não é sinônimo de bons resultados. Precisa-se
compreender que os execelentes resultados são decorrentes do uso correto destas
ferramentas” [KARDEC, 2001].
19
2.2 Tipos de Manutenção
A maneira pela qual é feita a intervenção nos equipamentos, sistemas ou
instalações caracteriza os vários tipos de manutenção existentes.
Existe uma variedade muito grande de denominações para classificar a
atuação da manutenção. Com isso, provoca certa confusão na caracterização dos
tipos de manutenção.
Por isso, é importante uma caracterização mais objetiva dos diversos tipos de
manutenção, de que, independente das denominações, todos se encaixem em um
dos seis tipos descritos a seguir.
Algumas práticas básicas definem os tipos principais de manutenção que são:
• Manutenção Corretiva Não Planejada;
• Manutenção Corretiva Planejada;
• Manutenção Preventiva;
• Manutenção Preditiva;
• Manutenção Detectiva;
• Engenharia de Manutenção;
Os diversos tipos de manutenção podem ser também considerados como
políticas de manutenção, desde que a sua aplicação seja o resultado de uma
definição gerencial ou política global da instalação, baseada em dados técnico-
econômicos [KARDEC, 2001].
Várias ferramentas disponíveis e adotadas hoje em dia, têm no nome a
palavra Manutenção. É importante observar que essas não são novos tipos de
manutenção, mas ferramentas que permitem a aplicação dos seis tipos principais de
manutenção citados anteriormente. Dentre elas, destacam-se:
• Manutenção Produtiva Total (TPM) ou Total Productive Maintenance;
20
• Manutenção Centrada na Confiabilidade (RCM) ou Reliability
Centered Maintenance;
• Manutenção Baseada na Confiabilidade (RBM) ou Reliability Based
Maintenance;
2.2.1. Manutenção Corretiva
“Ao atuar em um equipamento que apresenta um defeito ou um desempenho
diferente do esperado estamos fazendo manutenção corretiva. Assim, a manutenção não
é, necessariamente, a manutenção de emergência. A Manutenção Corretiva é a atuação
para a correção da falha ou do desempenho menor que o esperado” [KARDEC,2001].
Convém observar que existem duas condições específicas que levam à
manutenção corretiva:
• Desempenho deficiente apontado pelo acompanhamento das variáveis
operacionais;
• Ocorrência da falha;
Desse modo, a ação principal na Manutenção Corretiva é corrigir ou restaurar
as condições de funcionamento do equipamento ou sistema. A manutenção corretiva
poder ser dividida em duas classes:
• Manutenção Corretiva Não Planejada;
• Manutenção Corretiva Planejada;
2.2.1.1. Manutenção Corretiva Não Planejada
Normalmente a manutenção corretiva não planejada implica altos custos, pois
a quebra inesperada pode acarretar perdas de produção, perda da qualidade do
produto e elevados custos indiretos de manutenção. Além disso, quebras aleatórias
podem ter conseqüências bastante graves para o equipamento, isto é, a extensão
21
dos danos pode ser bem maior [KARDEC, 2001].
Quando uma empresa tem a maior parte de sua manutenção corretiva na
classe não planejada, impactará diretamente na sua competitividade e menor
redimentos do departamento de manutenção e seus equipamentos.
2.2.1.2. Manutenção Corretiva Planejada
“Manutenção Corretiva Planejada é a correção do desempenho menor que o
esperado ou da falha, por decisão gerencial, isto é, pela atuação em função de
acompanhamento preditivo ou pela decisão de operar até a quebra”
[KARDEC,2001].
Um trabalho planejado é sempre mais barato, detem de mais qualidades,
rápido e mais seguro do que um trabalho não planejado. A característica principal da
manutenção corretiva planejada é função da qualidade da informação fornecida pelo
acompanhamento do equipamento.
Mesmo que a decisão gerencial seja de deixar o equipamento funcionar até a
quebra, essa é uma decisão conhecida e algum planejamento pode ser feito quando
a falha ocorrer.
A adoção de uma política de manutenção corretiva planejada pode advir de
vários fatores:
• Possibilidade de compatibilizar a necessidade da intervenção com os
interesses da produção;
• Aspectos relacionados com a segurança – a falha não provoca
nenhuma situação de risco para o pessoal ou para a instalação;
• Melhor planejamento dos serviços;
• Garantia da existência de sobressalentes, equipamentos e
ferramental;
22
• Existência de recursos humanos com a tecnologia necessária para a
execução dos serviços e em quantidade suficiente, que podem,
inclusive, ser buscados externamente à organização.
2.2.2. Manutenção Preventiva
A manutenção preventiva procura com persistência evitar a ocorrência de
falhas, ou seja, procura prevenir. Isso demonstra características inversas à política
de manutenção corretiva.
“Manutenção preventiva é a atuação realizada de forma a reduzir ou evitar a
falha ou queda no desempenho, obedecendo a um plano previamente elaborado,
baseado em intervalos definidos de tempo” [KARDEC,2001].
As definições dos planos para manutenção preventiva são dificultadas por
informações disponibilizadas pelo fabricante, que em determinadas situações não
são tão precisas, quanto ao funcionamento do equipamento, além das condições
operacionais e ambientais de atuação.
Isso leva à existência de duas situações distintas na fase inicial de operação:
• Ocorrência de falhas antes de completar o período estimado para a
intervenção;
• Abertura de equipamento/reposição de componentes
prematuramente;
Para a utilização de uma política de manutenção preventiva, alguns fatores
devem serem levados em consideração:
• Quando não é possível a manutenção preditiva;
• Aspectos relacionados com a segurança pessoal ou da instalação que
tornam mandatória a intervenção, normalmente para substituição de
componentes.
23
• Por oportunidade em equipamentos críticos de difícil liberação
operacional.
• Em sistemas complexos e/ ou de operação contínua.
A manutenção preventiva será tanto mais conveniente quanto maior for a
simplicidade na reposição, quanto mais altos forem os custos de falhas, quanto mais
as falhas prejudicarem a produção e quanto maiores forem as implicações das
falhas na segurança pessoal e operacional [KARDEC, 2001].
A manutenção preventiva proporciona um conhecimento prévio das ações,
permitindo uma boa condição de gerenciamento das atividades e nivelamento de
recursos, além possibilitar um planejamento para o consumo de materiais [KARDEC,
2001].
2.2.3. Manutenção Preditiva
A manutenção preditiva, também conhecida por manutenção sob condição ou
manutenção com base no estado do equipamento, tem como objetivo a prevenção
de falhas através do acompanhamento de parâmetros diversos, permitindo a
operação contínua dos equipamentos ou sistemas pelo maior tempo possível.
Este acompanhamento é realizado através de medições e verificações com
equipamento produzindo.
“Manutenção Preditiva é a atuação realizada com base em modificação de
parâmetro de condição ou desempenho, cujo acompanhamento obedece a uma
sistemática” [KARDEC,2001].
As condições básicas para se adotar a manutenção preditiva são as
seguintes:
• O equipamento, sistema ou instalação devem permitir algum tipo de
monitoramento/medição.
24
• O equipamento, sistema ou instalação devem merecer esse tipo de
ação, em função dos custos envolvidos.
• As falhas devem ser oriundas de causas que possam ser
monitoradas e ter sua progressão acompanhada.
• Seja estabelecido um programa de acompanhamento, análise e
diagnóstico, sistematizado.
Os fatores que influenciam a utilização de uma política de manutenção
preditiva são os seguintes:
• Aspectos relacionados com a segurança pessoal e operacional.
• Redução de custos pelo acompanhamento constante das condições
dos equipamentos, evitando intervenções desnecessárias.
• Manter os equipamentos operando, de modo seguro, por mais tempo.
“É fundamental que a mão-de-obra da manutenção responsável pela análise
e diagnóstico seja bem treinada. Não basta medir, mas é preciso analisar os
resultados e formular diagnóstico” [KARDEC, 2001].
Embora isto possa parecer óbvio é comum encontrar-se, em algumas
empresas, sistemas de coleta e registro de informações de acompanhamento de
manutenção preditiva que não produzem ação de intervenção com a qualidade
equivalente aos dados registrados.
2.2.4. Manutenção Detectiva
“Manutenção Detectiva é a efetuada em sistemas de proteção buscando
detectar falhas ocultas ou não perceptíveis ao pessoal de operação e manutenção”
[KARDEC,2001] .
A identificação de falhas ocultas é executada por meio de sistema de
proteção que priorizam garantir a confiabilidade dos equipamentos. As equipes
25
responsáveis por este tipo de manutenção, devem receber treinamentos e
assessorias qualificadas.
Para auxiliar na execução deste tipo de manutenção, é cada vez maior a
utilização de computadores digitais em instrumentação e controle de processo nos
mais diversos tipos de plantas industriais.
Na manutenção detectiva, especialistas fazem verificações no sistema, sem
tirá-lo de operação. São capazes de detectar falhas ocultas, e preferencialmente
podem corrigir a situação, mantendo sistema operando.
2.2.5. Engenharia de Manutenção
“Praticar a engenharia de manutenção significa uma mudança cultural”
[KARDEC, 2001]. É deixar de ficar consertando continuadamente, para procurar as
causas básicas, modificar situações permanentes de mau desempenho, deixar de
conviver com problemas crônicos, melhorar padrões e sistemáticas, desenvolver a
manutenibilidade, dar feedback ao projeto, interferir tecnicamente nas compras
[KARDEC, 2001].
Na figura 1 mostra a evolução nas melhorias dos resultados à medida que as
diferentes técnicas vão sendo introduzidas.
26
Figura 1 – Resultado X Tipos de Manutenção
(KARDEC, 2001)
2.3. Indicadores de Desempenho de Máquina
Para atingir a missão da manutenção, que é “garantir a disponibilidade da
função dos equipamentos e instalações de modo a atender a um processo de
produção ou de serviço com confiabilidade, segurança e custo adequado” [KARDEC,
2001], precisa-se criar planos estratégicos de manutenção baseados em
informações obtidas no decorrer das atividades (manutenção) realizadas nos
equipamentos.
Com a implementação e utilização destes planos estratégicos de
manutenção, passará-se a conhecer o nível de confiabilidade e desempenho dos
equipamentos durante as atividades produtivas.
1 - Corretiva não planejada2- Preventiva3 - Preditiva e detectiva4 - Engenharia de manutenção
*
*
Res u
l tad
os
Tipos de manutenção
* quebra de paradigma
27
A confiabilidade é a probalidade que um equipamento, célula de produção,
planta ou qualquer sistema, possa desempenhar sua função requerida, por um
intervalo de tempo estabelecido, sob condições definidas de uso [KARDEC, 2001].
Os níveis de confiabilidade e desempenho dos equipamentos, poderão ser
estabelecidos através de indicadores, que notificarão e possibilitarão ações de
manutenções preventivas ou corretivas de forma mais eficaz, melhorando assim, o
tempo de disponilidade do equipamento e os custos relacionados.
Outras questões importantes poderão ser informadas pelos indicadores:
• Com que frequência ocorrem defeitos;
• Qual o tempo entre um defeito e outro;
• Qual o tempo até o primeiro defeito;
• Qual o tempo gasto para reparar cada defeito;
• Quais as chances de um sistema funcionar sem defeitos durante um
determinado período de tempo;
• Quais as chances de sistema estar funcionando em um determinado
instante;
Os principais indicadores de disponibilidade de máquinas são:
• MTBF;
• MTTR;
• Downtime;
O MTBF (Mean Time Between Failures) tempo médio entre falhas é média
aritmética dos tempos de funcionamento de máquinas, contando desde a colocação
da máquina em funcionamento ou quando nova, ou após a correção da falha até a
próxima falha [BRANCO, 2006]. A demonstração do cálculo do MTBF é visualizado
na figura 2.
28
Figura 2 - Cálculo do MTBF
O MTTR (Mean Time To Repair) tempo média para reparo é a média
aritmética dos tempos de reparo um sistema, de um equipamento ou item, ou seja,
aponta a média dos tempos que a equipe de manutenção leva para repor a máquina
em condições de operar desde a falha até o reparo ser dado como concluído e a
máquina ser aceita como em condições de operar [BRANCO, 2006]. A
demonstração do cálculo do MTBF é visualizado na figura 3.
Figura 3 - Cálculo do MTTR
O Downtime é o tempo total (Mean Forced Outage Time - MFOT) consumido
desde a notificação da falha até o instante de retorno da máquina à operação.
A figura 4 a seguir demonstra os indicadores na linha de tempo.
MTBF = [∑ ∑ )/( NCHD ]
HD = Tempo após a correção até a próxima falha NC = Quantidade de manutenções corretivas
MTTR = [∑ ∑ )/( NCHMI ]
HMI = Tempo de reparo NC = Quantidade de manutenções corretivas
29
Figura 4 - Demonstração dos Indicadores na linha do tempo
T0
DownTime
MTBF
MTTR
Notificação da Falha
Parada da Máquina
Início do Reparo
Retorno para Operação
DownTime
MTTR
Notificação da Falha
Parada da Máquina
Início do Reparo
Retorno para OperaçãoTempo
30
3. TECNOLOGIAS DE DESENVOLVIMENTO WEB
3.1. Introdução
Aplicações web são cada vez mais comuns em nosso cotidiano. Com o uso
intenso dessas aplicações, torna-se necessária a busca por soluções que possam
melhorar o seu desempenho, a sua escalabilidade e a sua disponibilidade.
As soluções para para este novo cenário de desenvolvimento web, foram
surgindo com a evolução da arquitetura de aplicação cliente/servidor (figura 5) – que
possui um ciclo básico de execução formado pela tríade requisição-processamento-
resposta – chamada também de arquitetura de duas camadas, para a arquitetura de
múltiplas camadas. Esta transição aconteceu naturalmente, à medida que camadas
adicionais começaram a surgir nas aplicações entre o cliente e o banco de dados.
Figura 5 - Arquitetura de duas camadas (cliente/servidor)
Diante deste novo cenário, há um aumento no número de desenvolvimento de
sistemas corporativos para utiliza-se no ambiente web. Onde buscam cada vez mais,
melhorar a divisão de tarefas durante o processo de desenvolvimento, aprimorar a
escalabilidade dos sistemas e facilitar a manutenção dos códigos fontes gerados.
Lógica de Apresentação
Lógica de Negócio
Lógica de Acesso a Dados
31
Agora com a utilização das multicamadas, agregou novas tecnologias ao
processo de desenvolvimento, possibilitanto assim, o surgimento de aplicações mais
complexas e dotadas de grande número de algoritmos. Num modelo de 4 camadas
(figura 6) pode-se observar, a separação das tarefas (papéis), onde cada
componente tem determinada responsabilidade para garantir o funcionamento do
todo.
Figura 6 - Arquitetura de várias camadas
A utilização desta arquitetura de várias camadas, criou à necessidade de
administrar as interações entre as camadas do sistema. Com isso passou-se a
utilizar padrões de projeto. Um dos padrões de projeto mais utilizado no
desenvolvimento web é chamado MVC1 [KOMOSINSKI, 2002].
O pradrão MVC (detalhes no item 2.4) apresenta importantes vantagens na
sua utilização:
• Independência de SGBD (Sistema Gerenciador de Banco de Dados) -
como o acesso à base de dados não será feito diretamente, mas sim
através da camada de dados (Model), é possível trocar de gerenciador
1 MVC (Model-View-Controller): padrão de divisão de papéis em camadas.
Lógica de Apresentação
Lógica de Negócio
Lógica de Acesso a Dados
32
de banco de dados sem comprometer a camada de persistência (banco
de dados) [ROMAN, 2002];
• Alta produtividade (componentes) - a separação em camadas, trás
consigo uma grande vantagem, que é a possibilidade de atribuir
diferentes atividades ao mesmo tempo, ao profissionais atuantes no
projeto [FALKNER, 2003];
3.2. Plataforma de Desenvolvimento .NET
A plataforma .NET, criada em 2000 e distribuída pela Microsoft, consiste em
um conjunto de ferramentas de desenvolvimento. É um ambiente independente de
linguagem para o desenvolvimento de aplicações corporativas e tem o intuito de
substituir o atual ambiente desktop win322 e COM3 [YAO, 2003].
3.2.1 Características da Plataforma .Net
Segundo Turtschi (2002), as principais características da plataforma .NET, são:
• Multilinguagem - através do uso de uma interface de definição de
linguagem, a MSIL (Microsoft Intermediate Language) ou somente IL
(Intermediate Language), ocorre a integração entre a maioria das
linguagens suportadas pela .NET;
• Independência de plataforma e processador - a MSIL é independente
de hardware e sistema operacional, possibilitando a geração de códigos
de máquina para várias plataformas nos mais variados tipos de
arquiteturas, desde que exista um framework apropriado para a
plataforma .NET [TURTSCHI, 2002];
2 Win32: plataforma de desenvolvimento de 32 bits sobre sistema operacional Windows 3 COM: Component Object Model ou modelo objetos componentes
33
• Gerenciamento automático de memória - todo código que é executado
no CLR (Common Language Runtime) (detalhes no item 2.3.6), é
chamado de código gerenciado, pois o mesmo controla toda a memória
trazendo muitas vantagens, como a integração entre as linguagens e
tratamento de exceções. Esta facilidade deve-se ao fato de que a
plataforma .NET, trata-se tudo como objeto. Sendo assim, a Microsoft
mudou a forma de como a arquitetura trata os objetos carregados na
memória, passando a usar o conceito de garbage collection (coletor de
lixo) (detalhes no item 2.3.7) [TURTSCHI, 2002];
• Suporte para padrões abertos - é compreensível que ocorra a abertura
de padrões para que a tecnologia não fique isolada, permitindo assim
que a mesma seja incorporada por outras tecnologias [TURTSCHI,
2002];
• Segurança - a distribuição de aplicações baseadas em componentes
exige segurança. A Microsoft mudou a maneira de controlar a segurança
da aplicação como fazia anteriormente com os seus sistemas
operacionais, com controles baseados em usuários, e resolveu seguir a
mesma metodologia empregada no Java, onde o código que não é
confiável é executado, mas sem acesso aos recursos críticos do sistema
[TURTSCHI, 2002];
• Performance e Escalabilidade – um grande ganho para o
desenvolvimento é proporcionado com a separação do código, dados e
apresentação visual para o usuário. Isto garante uma melhor
performance da aplicação e gera uma escalabilidade muito maior
[TURTSCHI, 2002].
3.2.2. Estrutura da Plataforma .NET
A estrutura da plataforma .NET é composta por quatro principais
componentes (figura 7):
• .NET Framework;
• .NET Enterprise Servers;
34
• Building Block Services;
• Microsoft Visual Studio .NET;
Figura 7 - Estrutura da plataforma .NET com as suas principais tecnologias
THAI (2003)
3.3. .NET Framework
O .NET framework é uma biblioteca de componentes de linguagem-neutra e
ambiente de execução, sendo responsável pelo gerenciamento e execução dos
aplicativos desenvolvidos em .NET.
Um dos objetivos do .NET Framework é trazer a reusabilidade ao
desenvolvimento da aplicação fornecendo uma estrutura de classes comuns aos
colaboradores que estão usando os compiladores para gerarem IL (Intermediate
Language) [THAI, 2001].
Segundo a Microsoft (2003) e Turtschi (2002) atualmente o framework suporta
as linguagens Perl, Python, COBOL, JScript, Eiffel, Haskell, Pascal, ML, Ada, APL,
C, C++, Visual Basic, C#, SmallTalk, Oberon, Scheme, Mercury, Oz e Objective
Caml. Além disto, suporta as tecnologias existentes para internet incluindo Hypertext
Markup Language (HTML), Extensible Markup Language (XML), Simple Object
Access Protocol (SOAP), Extensible Stylesheet Language for Transformations
(XSLT), Xpath e outros.
As classes do .NET framework estão disponíveis para que os programadores
35
possam usá-las caso seja necessário. Uma classe somente não poderá ser
estendida, se por ventura vir a ser fechada pela fabricante.
A arquitetura do .NET framework (figura 8) consiste dos seguintes
componentes:
• Common Language Runtime (CLR)
• .NET framework class library (BCL)
• ADO.NET
• ASP.NET
• Windows Forms
• Common Language Specification (CLS) ;
• Linguagens de Programação;
Figura 8 - Estrutura do .NET framework
(MICROSOFT, 2003)
3.3.1. Common Language Runtime (CLR)
36
O componente CLR (figura 9) é a parte mais importante do .NET framework,
pois é responsável pela execução do código MSIL [THAI, 2001].
Conforme Turtschi (2002), o CLR fornece uma execução segura, pois realiza
o
“gerenciamento de segurança e de memória, segurança do tipo e interoperabilidade de
interlinguagem. Um código não gerenciado pode gravar em áreas da memória que ele
não possui, executar instruções em locais arbitrários da memória e apresentar qualquer
outro mau comportamento que não possa ser gerenciado ou evitado pelo CLR”.
Figura 9 - Funcionamento da CLR
(MICROSOFT, 2003)
Em outras palavras o CLR, é a máquina virtual da plataforma .NET, assim
como a plataforma Java tem a sua própria JVM (Java Virtual Machine) [YAO, 2003].
O CLR utiliza a tecnologia de compilação Just In Time (JIT4) para transformar
o código MSIL no código nativo do equipamento, sendo que possui três tipos de JIT
(TURTSCHI, 2002):
1. Pré-JIT - o código MSIL é compilado para o código nativo de uma
única vez;
2. Econo-JIT - o código MSIL é compilado bit a bit para o código nativo,
liberando recursos da memória cache quando necessário;
4 JIT: Just in time, ou seja, em tempo de execução.
37
3. Normal-JIT - é o JIT padrão do .NET.
O código MSIL é compilado para o código nativo somente quando for utilizado
e o resultado é armazenado na memória cache. Essencialmente, a finalidade de um
compilador JIT é trazer um desempenho mais elevado ao código interpretado
colocando o código nativo compilado em um lugar reservado (cache), de modo que
quando a chamada seguinte é feita ao mesmo método/procedimento, o código da
memória cache seja executado, tendo por resultado um aumento na velocidade da
aplicação [TURTSCHI, 2002].
Assim como o Java gera um bytecode para ser interpretado pela máquina
virtual, o ambiente CLR, possuem um .NET PE (Portable Executable) file, que segue
alguns padrões pré-estabelecidos pela Microsoft (figura 10) [THAI, 2001].
Figura 10 - Estrutura de um arquivo executável pelo CLR
(THAI, 2001)
3.3.2. .NET Framework Class Library (BLC)
A .NET Framework Class Library, ou ainda, .NET Base Class Library (BCL),
38
reúne as bibliotecas que compõe o ambiente da plataforma. Isto compreende desde
as funções mais básicas até as mais complexas. Ressalta-se também que a
interoperação com a BCL, dá-se independente da linguagem usada, desde que seja
suportada pela plataforma, caracterizando assim o compartilhamento comum da
biblioteca [TURTSCHI, 2002].
3.3.3. ADO .NET
A tecnologia de acesso a dados da Microsoft ADO.NET, usa o XML (detalhes
no item 2.5.1) como formato de transmissão de dados entre os componentes. Isto
significa que o componente receptor não necessariamente precisa ser um
componente ADO.NET, desde que possa receber conjuntos de dados formatados
em XML, ressaltando assim a interoperabilidade entre os mais diversos e
heterogêneos ambientes [THAI, 2001].
A escalabilidade é outra das principais características desta tecnologia, onde
consegue-se um bom desempenho, sem degradar a performance do sistema. Isto
ocorre devido o acesso aos dados serem feitos através de um tipo de pool de
conexões, com o controle da conexão pelo objeto, somente reconectando-se quando
da nova solicitação do cliente e transmitindo os dados, diferentemente do modelo
cliente/servidor, quando a conexão ficava ativa e degradava o sistema quando
múltiplos acessos simultâneos eram realizados [THAI, 2001].
A produtividade também é realçada com o uso das classes desta tecnologia,
pois segue o conceito de Orientado a Objeto (OO), onde podemos herdar e estender
estas classes [THAI, 2001].
A figura 11 apresenta a arquitetura do ADO.NET.
39
Figura 11 - Arquitetura ADO.NET
(THAI, 2001)
3.3.4. ASP .NET
A tecnologia ASP.NET (figura 12) é uma evolução natural da linguagem
interpretada de scripts denominada ASP, que em conjunto com o framework .NET,
configura-se em um bom ambiente de desenvolvimento, com a real separação entre
o código e o design da aplicação. Entretanto, esta nova tecnologia permite que o
código fonte não seja necessariamente escrito em ASP, mas em qualquer outra
linguagem homologada para a plataforma .NET [TURTSCHI, 2002].
Figura 12 - Arquitetura ASP.NET
40
3.3.5. Windows Forms
“O Windows Forms é um conjunto de bibliotecas gerenciadas, que habilita
tarefas comuns de aplicativo como a leitura e a gravação no sistema de arquivos”
[MICROSOFT,2008].
No Windows Forms, um formulário é uma superfície visual na qual são
exibidas informações para o usuário. Normalmente, os aplicativos do Windows
Forms são criados pela inserção de controles em formulários e pelo
desenvolvimento de respostas a ações do usuário, como cliques do mouse ou
pressionamentos de teclas. “Um controle é um elemento discreto de interface do
usuário que exibe dados ou aceita a entrada de dados” [MICROSOFT, 2008].
O Windows Forms contém uma variedade de controles que podem ser
colocados em formulários: controles que exibem caixas de texto, botões, caixas
suspensas, botões de rádio e até mesmo páginas da web. Se os controles
existentes não atenderem às necessidades, é possível desenvolver controles
customizados.
3.3.6. Common Language Specification (CLS)
A Common Language Specification (CLS) é um conjunto de construções e
restrições que serve como guia para escritores de biblioteca e escritores de
compiladores. Permite que biblioteca sejam usadas totalmente de qualquer
linguagem que suporte a CLS e que essas linguagens se integrem umas com as
outras. A Common Language Specification é um subconjunto do Common Type
System [TAVARES, 2001].
“O Common Type System (CTS) é um sistema de tipos complexas, incorporado
41
ao Common Language Runtime (CLR), que aceita os tipos e operações encontradas na
maioria das linguagens de programação. O CTS aceita a implementação completa de
uma ampla gama de linguagens de programação” [TAVARES, 2001].
A Common Language Specification também é importante para
desenvolvedores de aplicativos que estejam escrevendo código a ser usado por
outros desenvolvedores. Quando os desenvolvedores projetam APIs acessíveis
publicamente seguindo as regras da CLS, essas APIs são facilmente usadas de
outras linguagens de programação voltadas para o Common Language Runtime
(CLR) [TAVARES, 2001].
3.3.7. Linguagem de Programação C#
“A linguagem de programação C# (lê-se C Sharp) é simples, mas poderosa, e
ideal para desenvolver aplicações web com ASP.NET” [LOTAR, 2007].
A linguagem C# é uma evolução C e C++. Com isso utiliza muitas
características do C++, como por exemplo, declarações, expressões e operadores.
O C# possui um mecanismo chamado Garbage collector (Coletor de Lixo),
característico da linguagem Java, que gerencia de forma automática, a memória
utilizada pelas aplicações e facilita o desenvolvimento de aplicações web e de
aplicações para desktop.
O C# é uma linguagem orientada a objetos com a qual podemos criar classes
que podem ser utilizadas por outras linguagens. Uma característica importante é que
ainda é possível utilizar os componentes COM, facilitando assim uma rápida
migração para um ambiente de desenvolvimento de alto nível sem precisar
reescrever todas as aplicações que você possui [LOTAR, 2007].
42
3.4. Mono Rails – Implementação do MVC (Model-View- Controller)
O MonoRail é um framework MVC para ASP.NET voltado para aplicações
web. Ele faz parte do Castle Project, que tem o objetivo fornecer um conjunto de
ferramentas simples para acelerar o desenvolvimento de aplicações desktop e web
[CASTLE, 2007].
“O MVC é um padrão de arquitetura, usado para separar em camadas as
aplicações WEB” [CAVANESS, 2002].
Com o uso do MVC (figura 2.9), consegue-se vantagens significativas no
desenvolvimento de aplicativos, através da separação das camadas. Isto possibilita
implementar com maior facilidade e clareza questões programáticas importantes
como a persistência de dados, controle de segurança, comunicação em rede e fluxo
de visualização.
Equipes de programação podem se concentrar em suas habilidades centrais
e integrar as camadas através de interfaces bem definidas. Esta separação permite
que aplicativos possam ser mais facilmente modificados e estendidos para atender a
novas exigências, bem como possibilitar que a interface com o usuário apresente
várias visões de um só modelo, sem interferir com a lógica de negócio [CAVANESS,
2002].
43
Figura 13 - Padrão MVC - separação em camadas
(CAVANESS, 2002)
Alur (2003) define as camadas do MVC como:
• Model (Modelo) - representa a camada onde a lógica do negócio vai
ser aplicada. O model prepara os dados para que a view consiga
exibi-los. Qualquer regra de negócio, acesso ao banco deve estar
nesta camada;
• View (Visão) - representa a camada que exibe os dados
processados pelo Model. A View também encaminha entradas de
dados do usuário para o Controller;
• Controller (Controlador) - é a camada que controla todas as
requisições e Views selecionadas pelo usuário. Ela interpreta o
44
pedido do usuário e encaminha para o model correto que prepara os
dados para retornar para a View de resposta. Uma aplicação é
constituída de vários controladores, geralmente um para cada
requisição.
Algumas linguagens de programação interpretadas como PHP e ASP, oferece
restrições ao uso do MVC, por causa da sua estrutura interna onde os códigos
HTML estão inseridos juntamente com os scripts das referidas linguagens no arquivo
fonte. Por outro lado, linguagens como Java e C#, são mais apropriadas, pois
definem claramente os objetos e ações de forma separada da interface. Novamente,
esta separação possibilita funcionalidade distinta das camadas, bem como a
extensão de aplicativos, reutilização de código e, conseqüentemente, menor tempo
e custo de desenvolvimento.
3.5. Object Relational Mapping (ORM)
Mapeamento objeto-relacional (ORM) é uma técnica de desenvolvimento
utilizada para reduzir diferença que existe entre os modelos de dados relacionais e
orientados a objeto. Esta diferença é causada quando se faz uso da programação
orientada a objeto utilizando banco de dados relacionais.
Com a utilização do ORM, as tabelas do banco de dados passam a serem
representadas através de classes e os registros de cada tabela são representados
como instâncias das classes correspondentes.
A relação entre as tabelas onde originam os dados e o objeto que os
disponibiliza é configurada pelo programador, isolando o código do programa das
alterações à organização dos dados nas tabelas do banco de dados.
Com esta técnica, o programador não precisa de se preocupar com os
comandos em linguagem SQL, pois irá usar uma interface de programação simples
que faz todo o trabalho de persistência.
45
Essas interfaces são ferramentas que gereciam e realização o mapeamento
de como as informações serão armazenadas (persistida) e capturas no banco de
dados. Para a plataforma Linux, pode citar-se como exemplo, as ferramentas
NHibernate e ActiveRecord.
3.5.1. NHibernate
“NHibernate é uma biblioteca (Framework) baseada em .NET para persistir os
objetos para bases de dados relacionais” [AÉCE, 2005].
Baseado em uma ferramenta de persistência de dados do Java, chamado
Hibernate, o NHibernate tem a finalidade de persistir os objetos .NET em uma base
de dados relacional subjacente. Isso facilita muito ao invés de escrever códigos SQL
dentro e fora da base de dados, pois o NHibernate gera o código SQL necessário,
certificando-se que os tipos e o valores são corretamente criados [AÉCE, 2005].
Para realizar o mapeamento das tabelas contidas no banco de dados
utilizando o NHibernate (figura 16), precisa-se criar as classes (figura 15) com as
propriedades que deseja-se armazenar (persistir) e um arquivo XML (figura 14), que
ficará responsável em informar ao NHibernate quais as propriedades da classe .NET
receberá as informações das colunas da tabela do banco de dados.
“XML é uma linguagem definida como o formato universal para dados
estruturados na Web. Esses dados consistem em tabelas, desenhos, parâmetros de
configuração, etc. A linguagem então trata de definir regras que permitem escrever
esses documentos de forma que sejam adequadamente visíveis ao computador”
[ALECRIM, 2006].
Para que o NHibernate funcione corretamente, cada classe .NET deverá
conter o seu respectivo arquivo XML de mapeamento. Este arquivos XML deverão
estar nomeado com o mesmo nome da classe e disposto no mesmo diretório da
46
classe.
Figura 14 - Arquivo XML de mapeamento
Figura 15 - Classe .Net
namespace MMS.Models{
using System;using NHibernate.Expression;
public class Maquina{private int id;private string codigo;private DateTime dataAquisicao;
public int Id{
get { return id; }set { id = value; }
}
public string Codigo{
get { return codigo; }set { codigo = value; }
}
public DateTime DataAquisicao{
get { return dataAquisicao; }set { dataAquisicao = value; }
}}
Maquina.cs
XMLM a c h i n e . h b m .x m l
<?xml version="1.0" encoding="utf-8" ?><hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
assembly=“MMS" namespace=“MMS.Model">
<class name=“tab_maquina"><id name=“id"> <generator class=“increment" />
</id><property name=“codigo" /><property name=“data_aquisicao" />
</class>
</hibernate-mapping>
�.hbm :é uma convenção usada pelo NHibernate para reconhecer automaticamente o arquivo como um arquivo de mapeamento
47
Figura 16 - Mapeamento das tabelas do banco de dados
3.5.2. Castle ActiveRecord
O ActiveRecord faz parte dos projeto open-source disponibilizado pelo Castle
Project. Sua implementação foi desenvolvida sob o NHibernate (figura 17), herdando
as características de possibilitar a persistência de objetos de maneira rápida e sem a
necessidade de programar utilizando diretamente a linguagem SQL.
Figura 17 - Diagrama de Bloco MVC
Maquina.cs
XML+Maquina.hbm.xml
Hibernate.cfg.xml
NHibernate
tab_maquina
Controller
View
ModelActiveRecord
Banco de Dados
48
Com a utilização do ActiveRecord no desenvolvimento da camada Model, do
padrão MVC (Model-View-Controller), a implementação das classes tornou-se mais
ágil. Pois não há, a necessidade de gerar um arquivo XML e uma classe
sepadaremente para representar uma tabela contida no banco de dados (Figura 18).
O desenvolvimento está focado apenas na implementação de uma única classe
contendo todas as informações necessárias para realizar o mapeamento da tabela
(Figura 19). A relação entre classe-tabela, passou a ser uma classe para uma
tabela.
Figura 18 - Implementação de Classe .NET utilizando ActiveRecord
Maquina.csMaquina.csnamespace MMS.Models{
using System;using Castle.ActiveRecord;using NHibernate.Expression;
public class Maquina{private int id;private string codigo;private DateTime dataAquisicao;
[PrimaryKey(“id”)]public int Id{
get { return id; }set { id = value; }
}
[Property(“codigo”)]public string Codigo{
get { return codigo; }set { codigo = value; }
}
[Property(“data_aquisicao”)]public DateTime DataAquisicao{
get { return dataAquisicao; }set { dataAquisicao = value; }
}}
}
XML
NHibernate
49
XML+ Maquina.csMaquina.hbm.xml
Web.config
Active Record Maquina.cs
NHibernate
tab_maquina
Figura 19 - Representação do mapeamento das tabelas com ActiveRecord
3.6. Sistema Gerenciador de Banco de Dados (SGBD)
Os bancos de dados e as suas tecnologias estão provocando um grande
impacto no crescimento do uso de computadores. É viável afirmar que eles
representam um papel crítico em quase todas as áreas em que os computadores
são utilizados, incluindo negócios, comércio eletrônico, engenharia, educação, entre
outras [ELMASRI, 2005].
“Um banco de dados é uma coleção de dados relacionais. Os dados são fatos
que podem ser gravados e que possuem um significado implícito” [ELMASRI, 2005].
A seguir mostra-se algumas propriedades implícitas que um banco de dados
possui:
• Representa alguns aspectos do mundo real;
• É uma coleção lógica e coerente de dados com algum significado
inerente;
• É projetato, contruído e povoado por dados, atendendo a uma proposta
específica;
50
• Possui um grupo de usuário definido e algumas aplicações
preconcebidas, de acordo com o interesse desse grupo de usuários;
O banco de dados contém tamanho e complexidade variável, possuindo
algumas fontes das quais os dados é derivado, alguns níveis de interação com os
eventos do mundo real e um público efetivamente interessado em seus conteúdos.
Um banco de dados computadorizado pode ser criado e mantido tanto por um
grupo de aplicativos escritos especialmente para essa tarefa, como por um sistema
gerenciador de bando de dados.
“Um sistema gereciador de bando de dados (SGBD) é uma coleção de
programas que permite aos usuários criar e manter um banco de dados” [ELMASRI,
2005].
Atualmente no mercado, há vários sistemas gerenciadores de banco de
dados, como por exemplo:
• MySQL;
• Microsoft SQL Server;
• Oracle;
• Postgree;
• Firebird;
• Interbase;
• DB2;
O SGBD é um sistema de software de propósito geral que facilita os
processos de:
• Definição;
• Construção;
• Manipulação e compartilhamento de bancos de dados entre vários
usuários e aplicações;
• Proteção e Manutenção do banco de dados;
51
A definição de um banco de dados implica especificar os tipos de dados, as
estruturas e as restrições para os dados a serem armazenados.
A construção de um banco de dados é o processo de armazenar os dados em
alguma mídia apropriada controlada pelo SGBD. A manipulação inclui algumas
funções, como:
• Pesquisas em banco de dados para recuperar um dado específico;
• atualização do banco;
• Gerar relatórios de dados;
O compartilhamento permite aos múltiplos usuários e programas acessar, de
forma concorrente, o banco de dados.
A proteção do sistema inclui a prevenção contra o mau funcionamento ou
falhas (crashes) no hardware ou software, e segurança contra acessos não
autorizados ou maliciosos.
Um banco de dados típico pode ter um ciclo de vida de muitos anos, por isso,
os SGBD devem ser capazes de manter um sistema de banco de dados que permita
a evolução dos requisitos que se alteram ao longo do tempo.
A definição de um sistema de banco de dados (figura 20), é formada pela
junção do banco de dados e o software SGBD.
52
Figura 20 - Configuração de um sistema de Banco de Dados
(ELMASRI, 2005)
3.6.1 MySQL
O MySQL é um dos sistemas de gerenciamento de banco de dados mais
populares, ocasionado pelo grande volume de desenvolvimento de aplicações web,
onde o mesmo é amplamente utilizado.
Outro fator que ajuda na popularidade do MySQL é sua disponibilidade para
praticamente qualquer sistema operacional, como Linux, FreeBSD (e outros
sistemas baseados em Unix), Windows e Mac OS X.
Programas de Aplicações / Conculstas (Queries)
SISTEMA DE BANDO DE DADOS
SOFTWARE SGBD
Programa para Processamento de Conculstas/Programas
Software para Acesso aos Dados Armazenados
Usuários/Programadores
Definição dos Dados Armazenados (metadados)
Banco de Dados Armazenados
53
Além disso, o MySQL é um software livre (open-source), o que significa que é
permitido estudá-lo ou alterá-lo conforme a necessidade.
Entre as características técnicas do SGBD MySQL, estão:
• Alta compatibilidade com linguagens como PHP, Java, Python, C#,
Ruby e C/C++;
• Baixa exigência de processamento (em comparação como outros
SGBD);
• Vários sistemas de armazenamento de dados (batabase engine), como
MyISAM, MySQL Cluster, CSV, Merge, InnoDB, entre outros;
• Recursos como transactions (transações), conectividade segura,
indexação de campos de texto, replicação, entre outros;
• Suporta grandes volumes dados;
• Instruções em SQL;
Um fato importante a ser destacado sobre o MySQL, é que esse SGBD
também possui uma licença comercial, ou seja, é possível obter suporte diferenciado
dos desenvolvedores.
54
4. METODOLOGIA
O produto final deste trabalho consiste em contribuir no desenvolvimento da
camada Model, do sistema de gerenciamento de manuntenção MMS (Maintenance
Management System), utilizando softwares livres.
O sistema é formado pelo desenvolvimento das camadas do padrão MVC e a
implementação das tabelas no SGBD MySQL. O desenvolvimento deste sistema,
seguiu uma cronologia de tempo e datas empregadas pelo método SCRUM,
adotado neste projeto.
Com base nas análises técnicas dos requisitos do software, descritos no
documento de especificação de requisitos – DER (ver apêndice), foram
desenvolvidos com auxílio da ferramenta JUDE Community e DBDesingner, os
diagramas de classes e os diagramas de seqüência.
Para o desenvolvimento das classes da camada Model, utilizou-se da
tecnologia ASP.NET, da linguagem de programação C# e do framework Castle
Active Record, que é responsáveis pelas consultas e manipulação das informações
persistidas do banco de dados controlado pelo SGBD MySQL.
Durante o ciclo de desenvolvimento, realizaram-se testes para validar os
fluxos lógicos e a confiabilidade dos resultados gerados pelas classes desenvolvidas
para a camada Model.
Após a realização dos testes, durante reuniões com datas previamente
estabelecida pela engenharia de software, houveram-se os processos de integração
com os outros módulos (camadas) desenvolvidos pela a equipe.
4.1. Requisitos do Software
55
O sistema MMS, como já dito anteriormente, foi desenvolvido para gerenciar o
processo de manutenção das máquinas. O desenvolvimento deste projeto seguiu o
documento de especificação de requisitos – DER (ver apêndice), gerado durante
reuniões com o Profo Marcelo A. Oliveira, que representa o cliente do sistema.
Alguns dos principais requisitos funcionais desse sistema são descritos
abaixo:
� MMS_CCS_RF_001 – Cadastro das Máquinas;
� MMS_CCS_RF_004 – Cadastro de Técnicos;
� MMS_CCS_RF_005 – Cadastro de Supervisores;
� MMS_CCS_RF_006 – Abertura de Ordem de Serviço;
� MMS_CCS_RF_007 – Fechamento de Ordem de Serviço;
� MMS_RS_RF _005 – Relatório de MTBF por máquina;
� MMS_RS_RF _007 – Relatório de MTTR;
� MMS_RS_RF _008 – Relatório de DownTime;
Como ferramenta de modelagem, foi utilizado o software livre Jude
Community, que possibilita a criação de diagramas UML em um formato padrão.
Esta ferramenta se encontra para download no site http://jude.change-
vision.com/jude-web/download/index.html.
De acordo MELO [16], “A UML define em sua versão 2.0 treze tipos de
diagramas, divididos em duas categorias: diagramas estruturais ou estáticos
(Structural Diagrams) e diagramas dinâmicos (Behavioral Diagrams), conforme
divisão mostrada na Figura 21”.
Diagramas Estruturais
Diagrama de Classes
Diagrama de Objetos
Diagrama de Componentes
Diagrama de Pacotes
Diagrama de Implantação
Diagrama de Estrutura Composta
56
Diagramas Dinâmicos
Diagrama de Casos de Uso
Diagrama de Interação:
- Diagrama de Visão Geral
- Diagrama de Seqüência
- Diagrama Temporal
- Diagrama de Comunicação
Diagrama de Atividades
Diagrama de Máquina de Estados
Figura 21 - Diagramas existentes na UML 2.0
Neste trabalho foram criados os diagramas de classes e os diagramas de
seqüência.
4.1.1. Diagrama de Classe
Segundo MELO [16], “Os diagramas de classes (Class Diagram) apresentam
elementos conectados por relacionamentos. Usado para exibir entidades do mundo
real, além de elementos de análise e projeto”.
No projeto MMS as classes desenvolvidas na camada Model, representam
uma relação 1:1, ou seja, para cada tabela contida no banco de dados MySQL, há
uma classe de mapeamento na camada Model.
Os diagramas de classe foram desenvolvidos com auxílio da ferramenta livre
DBDesigner versão 4. Com esta ferramenta disponível para download no site
http://www.fabforce.net/downloads.php, pode-se realizar o desenvolvimento das
tabelas, com seus devidos campos e relacionamento. Em conseqüência, realizam-se
a definição das classes com seus devidos relacionamentos. Com a utilização desta
ferramenta o processo de implementação das tabelas também se tornou mais ágil,
pois a mesma permite a criação de scripts SQL, para o desenvolvimento das tabelas
57
no banco de dados automaticamente.
No projeto MMS as classes foram organizadas em blocos, onde os mesmo
representam o contexto das informações e ações com que as classes iram
manipular. A figura 22 demonstra o bloco Usuário do Sistema , onde contém as
tabelas tab_authentication e tab_user. A partir destas tabelas foram desenvolvidas
as classes Authentication.cs e User.cs, que são responsáveis pelo controle de
acesso do sistema. A área em destaque vermelho da figura 22, representa o
relacionamento é de 1 para muitos (1:N).
Figura 22 - Diagrama de Classe (Usuários do Sistema)
A figura 23 demonstra o bloco Dados de Máquina , que contém as tabelas
tab_machine_model, tab_machine_manufacturer, tab_machine_type,
tab_machine_group, tab_line_stage, tab_assembly_line e tab_machine. A partir
1 . N
58
desta tabelas foram desenvolvidas as classes MachineModel.cs, Manufacturer.cs,
MachineType.cs, MachineGroup.cs, StageAssemblyLine.cs, AssemblyLine.cs e
Machine.cs respectivamente.
Estas classes são responsáveis pelo cadastro das máquinas, com as
informações necessárias para mapear e monitorar as mesmas durante o processo
produtivo e ocorrências de falhas.
Figura 23 - Diagrama de Classe (Dados da Máquina)
A figura 24 demonstra o bloco Ordem de Serviço , que contém as tabelas
tab_service_order, tab_maintenance_report, tab_preventive_maintenance_report,
tab_predictive_maintenance_report, tab_corrective_maintenance_report e
tab_failure_mode. A partir destas tabelas foram desenvolvidas as classes
ServiceOrder.cs, MaintenanceReport.cs, PreventiveMaintenanceReport.cs,
PredictiveMaintenanceReport.cs, CorrectiveMaintenance.cs e FailureMode.cs
59
respectivamente.
Estas classes são responsáveis em armazenar no SGBD MySQL, as
informações sobres as ocorrências de falhas, tipos de manutenção submetida e
modos de falhas, que darão o suporte necessário para o desenvolvimento dos
indicadores de máquinas já descritos anteriormente.
Figura 24 - Diagrama de Classe (Ordem de Serviço)
A figura 25 demonstra o bloco Logs do Sistema , que contém a tabela
tab_machine_stop_log. A partir desta classe foi desenvolvida a classe
MachineStopLog.cs, que responsável em armazenar as informações necessárias
para geração dos relatórios dos indicadores de máquinas: MTBF, MTTR e
Downtime.
1 : 1
60
Figura 25 - Diagrama de Classe (Logs do Sistema) 4.1.2. Diagrama de Seqüência
Segundo MELO [16] “Os diagramas de seqüências (Sequence Diagram)
mostra as interações que correspondem a um conjunto de mensagens trocadas
entre objetos e a ordem que essas mensagens acontecem”.
A seguir serão apresentado os principais diagramas de seqüência do projeto
MMS, onde os mesmos demonstram o fluxo das mensagens que ocorrem entre as
camadas MVC desenvolvidas no sistema.
A figura 26 demonstra o processo que ocorre entre as camadas MVC para
realizar o login de um usuário no sistema.
61
Figura 26 - Diagrama de Seqüência de login do usuário
A figura 27 demonstra o processo que ocorre entre as camadas MVC para
realizar o cadastro de um usuário para o sistema.
Figura 27 - Diagrama de Seqüência de cadastro de um usuário
A figura 28 demonstra o processo que ocorre entre as camadas MVC durante
o cadastro de uma máquina no sistema.
62
Figura 28 - Diagrama de Seqüência de Cadastro de uma Máquina
A figura 29 demonstra o processo que ocorre entre as camadas MVC durante
a abertura de uma nova ordem de serviço corretiva.
Figura 29 - Diagrama de Seqüência de Abertura de Ordem de Serviço Corretiva
63
A figura 30 demonstra o processo que ocorre entre as camadas MVC durante
o fechamento de uma ordem de serviço corretiva. A partir dos dados inseridos
durante o fechamento da ordem de serviço, serão gerados os relatório dos
indicadores de máquina descritos anteriormente.
Figura 30 - Diagrama de Seqüência de Fechamento de Ordem de Serviço Corrretiva
As figuras 31 e 32 demonstram o processo que ocorre entre as camadas
MVC durante a geração do relatório dos indicadores de máquina: MTBF, MTTR e
DownTime.
64
Figura 31 - Diagrama de Seqüência de Indicadores de Manutenção 1
Figura 32 - Diagrama de Seqüência de Indicadores de Manutenção 2
65
4.3. Plano de Testes
Para a realização dos testes do sistema MMS, foi elaborado um plano de
teste (ver anexo). Este documento tem como objetivo descrever as atividades e o
planejamento de execução dos testes, bem como as estratégias a serem tomadas
durante a execução.
O tipo de teste utilizado foi o “caixa-preta” (funcionais), pois o objetivo é
verificar se a funcionalidade está sendo executada corretamente, ou seja, se o
sistema responde corretamente a uma entrada do usuário e se o componente está
preparado para suportar possíveis condições de erro, tratando-as corretamente.
A cada conclusão de um módulo, a equipe de desenvolvimento realizou testes
para garantir o funcionamento do software de maneira adequada.
66
5. DESENVOLVIMENTO DA CAMADA MODEL DO PROJETO MMS
Neste capitulo são demonstradas as classes que foram desenvolvidas na
camada Model, a partir de análises técnicas realizadas nos diagramas de classe e
diagramas de seqüência, com propósito de atender os requisitos propostos pelo
cliente, contidos no documento DER (ver apêndice).
As classes desenvolvidas foram submetidas aos testes “caixa-preta” descritos
no Plano de Teste (ver anexo). As mesmas apresentaram resultados positivos, com
seus propósitos de funcionamento ocorrendo como o esperado. A seguir são
listadas as classes que foram desenvolvidas para a camada Model:
Authentication.cs
MMSSecurity.cs
User.cs
State.cs
MachineStopLog.cs
MMSLogger.cs
AssemblyLine.cs
Machine.cs
MachineGroup.cs
MachineModel.cs
MachineType.cs
Manufacturer.cs
StageAssemblyLine.cs
CorrectiveMaintenanceReport.cs
FailureMode.cs
MaintenanceReport.cs
PredictiveMaintenanceReport.cs
PreventiveMaintenanceReport.cs
ServiceOrder.cs
No decorrer deste capitulo serão demonstradas algumas classes
desenvolvidas na camada Model, onde seus respectivos códigos fontes seguirão em
apêndices.
Para utilizar o framework Castle Active Record no desenvolvimento das
classes da camada Model, é necessário a declaração do mesmo, juntamente com a
67
declaração do NHibernate. Como já mencionado anteriormente, o Castle Active
Record é uma camada acima do NHibernate, portanto é preciso declara-lo. A
declaração é realizada através de: using Castle.ActiveRecord e using
NHibernate.Expression respectivamente.
Na figura 33 é demonstrado como desenvolver um classe utilizando o Castle
Active Record. Na área azul em destaque, é realizada a declaração do nome da
classe e o mapeamento da tabela do banco de dados através da declaração
[ActiveRecor (“tab_authentication”). A declaração dos atributos (campos) da tabela
contido na banco de dados, é demonstrada na área vermelha em destaque. Para
manipular e alterar os dados da tabela é necessário a declaração dos métodos para
cada campo a ser manipulado. A área laranja em destaque, demonstra a declaração
dos métodos.
A classe Authentication.cs (Figura 33) é utilizada para realizar o login do
usuário no sistema.
Figura 33 - Classe Authentication.cs
68
A classe Machine.cs (Figura 34) é utilizada para realizar o cadastro de uma
máquina no sistema. A área azul em destaque na figura abaixo, é demonstra a
declaração dos relacionamentos desta classe com outras classes do sistema.
O framework Castle Active Record dá suporte a vários tipos de
relacionamentos. No desenvolvimento da camada Model do projeto MMS, foram
necessários dois tipos de relacionamentos:
� BelongsTo – utilizado na declaração dos relacionamentos um para muito
(1:N);
� OneToOne – utilizado na declaração dos relacionamentos um para um
(1:1);
Figura 34 - Classe Machine.cs
A classe ServiceOrder.cs (Figura 35) é utilizada nos três tipos de atividades
69
disponibilizada no sistema, relacionado a ordem de serviço: abertura, fechamento e
cancelamento de uma ordem de serviço.
Esta classe tem um relacionamento um para um (1:1), já demonstrado
anteriormente no capítulo 4, com a classe MaintenanceReport.cs. Desta forma,
neste projeto MMS, uma ordem de serviço sempre estará relacionada a algum dos
tipos de manutenção implementado no sistema:
� Manutenção Corretiva;
� Manutenção Preventiva;
� Manutenção Preditiva;
Figura 35 - Classe ServiceOrder.cs
Na classe MaintenanceReport.cs (Figura 36) é utilizado o conceito de
herança. Segundo DEITEL [12], “A herança é uma forma de reutilização de software
em que o programador cria uma classe que absorve dados e comportamentos de
uma classe existente e os aprimora com novas capacidades”. A reusabilidade de
70
software economiza tempo durante o desenvolvimento de programa.
A área azul em destaque na figura 36 demonstra o mapeamento da tabela do
banco de dados, utilizando o conceito de herança. Agora é necessário inserir
JoinedBase, para identificar que a classe MaintenanceReport.cs contém os atributos
(campos) comuns ao três tipos de manutenção implementado do sistema. Desta
forma, diminui a redundância de informações nas tabelas do banco de dados.
Figura 36 - Classe MaintenanceReport.cs
A classe CorrectiveMaintenanceReport.cs (Figura 37) é um exemplo das
classes que herdam de MaintenanceReport.cs.
71
Figura 37 - Classe CorrectiveMaintenanceReport.cs
A classe MachineStopLog.cs (Figura 38) é responsável pelos cálculos dos
indicadores de máquina: MTBF, MTTR e DownTime.
Figura 38 - Classe MachineStopLog.cs
72
6. CONCLUSÃO E TRABALHOS FUTUROS
Analisando de forma critica o trabalho realizado, pode-se concluir que o
mesmo alcançou os objetivos propostos. Tendo em vista, que foram implementados
os requisitos classificados como essenciais, no documento de especificação de
requisitos – DER.
O desenvolvimento de sistemas para o ambiente web, está em uma crescente
evolução, sendo um caminho natural dos novos projetos. Em virtude das
necessidades atuais que cada empresa tem, seja para comércio eletrônico,
integração de sistemas, redução de custos, escalabilidade, entre outros, as
tecnologias que hoje estão disponíveis, podem suprir estas necessidades.
Além do conhecimento alcançado sobre as tecnologias estudadas, o produto
final, que envolve a contribuição no desenvolvimento de um sistema para auxiliar o
gerenciamento de manutenção no PIM (Pólo Industrial de Manaus), também foi
bastante satisfatório. Visto que a solução funcionou como o esperado, além do
desenvolvimento utiliza-se de ferramentas gratuita.
Como proposta para trabalhos futuros, diversas possibilidades podem ser
percebidas. A evolução do sistema MMS, com novas implementação e requisitos,
aconteceram de forma gradativa com o surgimento de novos módulos para o
sistema. Poderão ser desenvolvidos módulos para auxiliar na elaboração do FMEA
(Failure Mode e Effect Analysis). Segundo KARDEC [12] “A Análise do Modo e
Efeito de Falha – FMEA é uma abordagem que ajuda a identificar e priorizar falhas
potenciais em equipamentos, sistemas ou processos. É geralmente utilizada como
um degrau para o estabelecimento do programa de Análise das Causas-Raízes da
Falha – RCFA (Root Cause Failure Analysis)”.
Com proposta, também poderá desenvolver um módulo para controlar e
auxiliar na reposição dos equipamentos e componentes utilizados durantes as
manutenções realizadas, de forma a otimizar e integrar todos os processos
74
REFERÊNCIAS BIBLIOGRÁFICAS [1]. LAFRAIA, João Ricardo Barusso. Manual de Confiabilidade, Mantenabilidade e
Disponibilidade. Rio de Janeiro: Qualitymark: Petrobras, 2001.
[2]. BRANCO FILHO, Gil. Indicadores e Índices de Manutenção. Rio de Janeiro:
Editora Ciência Moderna Ltda., 2006.
[3]. BRANCO FILHO, Gil. A Organização, o Planejamento e o Controle da
Manutenção. Rio de Janeiro: Editora Ciência Moderna Ltda., 2008.
[4]. SIQUEIRA, Iony Patriota de. Manutenção Centrada na Confiabilidade: Manual de
Implementação. Rio de Janeiro: Qualitymark, 2005, 408p.
[5]. PINTO, Alan Kardec; XAVIER, Júlio Aquino Nascif. Manutenção: Função
Estratégica. Rio de Janeiro: Qualitymark, 2001.
[7]. BRANCO FILHO, Gil. Dicionário de Termos de Manutenção, Confiabilidade e
Qualidade. Rio de Janeiro: Editora Ciência Moderna Ltda., 2006.
[8]. OLIVEIRA, Marcelo A. PDM – Plano Diretor de Manutenção. 2007, Manaus.
[9]. XENOS, H. G. Gerenciando a Manutenção Produtiva. Nova Lima: INDG
Tecnologia e Serviços Ltda, 2004.
[10]. BUENO, Luiz Henrique; SCHAAF,Sérgio. Aplicações Web com Visual Studio
.NET ASP.NET e C#. Alta Books, 2002.
[11]. MICROSOFT .NET, Framework e aplicativos WEB / Microsoft Corporation;
tradução Izabel Cristina de Mendonça, Ana Beatriz Tavares. Rio de Janeiro :
Campus, 2001.
[12]. DEITEL, H.M.; DEITEL, P.J. C++: Como Programar. Tradução Edson
75
Furmankiewicz; revisão técnica Fábio Lucchini. 6. ed. São Paulo: Pearson Prentice
Hall, 2006.
[13]. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de bando de dados.
Revisor técnico Luis Ricardo de Figueiredo. São Paulo: Pearson Addison Wesley,
2005.
[14]. PRESSMAN, Roger S. Engenharia de Software. 5.ed. Rio de Janeiro: McGraw-
Hill Interamericana do Brasil, 2002.
[15]. LOTAR, Alfredo. Como Programar com ASP.Net e C#. São Paulo: Novatec
Editora, 2007.
[16]. MELO, Ana Cristina. Desenvolvendo Aplicações com UML 2.0: Do Conceitual à
Implementação. Rio de Janeiro: Brasport, 2004.
[17]. KOMOSINSKI, Leandro J. Aplicações Cliente-Servidor via Web usando Java.
2002.
[18]. ROMAN, Ed. ET AL. Mastering Enterprise JavaBeans. Second Edition. 2002.
[19]. FALKNER, Jayson; Kevin, Jones.Servlets and JavaServer Pages – The J2EE
Technology Web Tier. Addison-Wesley. 2003.
[20]. TURTSCHI, Adrian ET AL. C# .NET Web Developer´s Guide. Syngress
Publishing, Inc., 2002.
[21]. THAI, Thuan; LAM, Hoang L. .NET Framework Essentials. O’Reilly Publisher.
2001.
[22].CAVANESS, Chuck. Jakarta Struts.O’Reilly, 2002.
[23]. ALUR, Deepark; CRUPI, John; MALKS, Dan. Core J2EE Patterns, As melhores
práticas e estratégias de design. Ed.Campus. 2004.
76
[24]. MICROSOFT, Corporation. Microsoft .NET. 2003. Página oficial do produto.
Disponível em: <http://www.microsoft.com/brasil/dotnet/default.asp>. Acesso em: 25
mai. 2008.
[25]. YAO, Paul; DURANT, David. Programming the .NET Compact Framework –
Chapter 1. 2003. Disponível em: <http://www.paulyao.com> Acesso em: 15 mai.
2008.
[26]. Microsoft ASP.NET MVC. Disponível em: < http://www.asp.net/mvc> Acesso
em: 27 mai. 2008.
[27]. ASP.NET MVC Framework. Disponível em:
<http://weblogs.asp.net/scottgu/archive/2007/11/13/asp-net-mvc-framework-part
1.aspx> Acesso em: 22 mai. 2008.
[28]. Padrão Arquitetural MVC e suas aplicações para Web. Disponível em: <
<http://www.slideshare.net/rafael.ufs/padro-arquitetural-mvc-e-suas-aplicaes-para-
web> Acesso em: 22 mai. 2008.
[29]. ASP.NET MVC – Criando aplicativos Web sem Web Forms. Disponível em:
<http://msdn.microsoft.com/pt-br/magazine/cc337884.aspx> Acesso em: 22 mai.
2008.
78
DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS
MMS – Maintenance Management System
HISTÓRICO DE ALTERAÇÕES
VERSÃO DATA AUTOR PRINCIPAIS ALTERAÇÕES
0.1 24/03/2008 Deyvyson Criação da DER. 0.2 27/03/2008 Deyvyson Requisitos de interface.
0.3 08/04/2008 Deyvyson Alteração na descrição dos componentes.
0.4 04/12/2008 Deyvyson Alteração na descrição dos componentes.
79
Sumário
1 Introdução........................................................................................................................... 80
1.1 Objetivo e Escopo........................................................................................................ 80
1.2 Descrição do Produto .................................................................................................. 80
2 Definições e Abreviaturas ................................................................................................... 81
3 Referências ........................................................................................................................ 81
4 Requisitos Funcionais......................................................................................................... 82
4.1 Componente - Cadastros no Sistema .......................................................................... 82
4.2 Componente - Consultas no Sistema........................................................................... 83
4.3 Componente – Relatórios do Sistema.......................................................................... 84
5 Requisitos de Interface ....................................................................................................... 86
5.1 Interface com Usuário.................................................................................................. 86
6 Outros Requisitos ............................................................................................................... 90
6.1 Requisitos de Segurança de Acesso ........................................................................... 90
80
Introdução
O projeto de conclusão de curso MMS – Maintenance Management System desenvolvido pelos alunos de Engenharia da Computação – Antônio Deyvyson Bezerra Duarte, Diego Nascimento, Rafael Pinto, Marcelo Silva Pereira, Paollo Maciel Gomes - consiste em desenvolver um sistema para controle de manutenção de máquinas, tendo como base os requisitos da Nokia. O MMS auxiliará o gestor de manutenção em tomada de decisão mas ágil diante dos resultados apresentados durante um determinado período de análise. Determinará alguns índices, como: frequência de falhas ocorridas (MTBF), tempo de resolução para um determinado problema (MTTR), downtime, entre outros. Este sistema poderá funcionar tanto no sistema operacional Linux quanto no Windows. Objetivo e Escopo
Objetivo deste documento é identificar e descrever os requisitos do trabalho de conclusão de curso MMS – Maintenance Management System de acordo com a especificações relatadas pelo cliente Prof. Marcelo A. Oliveira.
Descrição do Produto O MMS desenvolvido permitirá armazenar informações das falhas e ações tomadas para solucionar as mesmas, amazenar informações técnicas de cada máquina, entre outras. O MMS proporcionará uma maior facilidade aos técnicos no controle de ordem de serviços abertas a ele. Facilitará os supervisores responsáveis pela a abertura das ordem de serviços, visualizar os status das mesmas no sistema. Tratamento das informações para que relatórios e consultas sejam de formas mais rápidas.
81
Definições e Abreviaturas
TERMO DESCRIÇÃO MMS Maintenance Management System
OS Ordem de Serviço
MTBF Tempo Médio entre Falhas
MTTR Tempo Médio de Reparo
Referências # DOCUMENTO REVISÃO DATA
Disponível em:
82
Requisitos Funcionais Componente - Cadastros no Sistema [MMS_CCS_RF_001] Cadastro de Máquina
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter, para que as atividades ocorram, cadastradas as máquinas.
OBS: Este item tem como pré-requisito, um cadastro do grupo de máquina.
[MMS_CCS_RF_002] Cadastro de Linha de Montagem
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter cadastro das linhas de montagens, que serão compostas por uma ou várias máquinas, um ou vários supervisor (es).
OBS: Mas para existir uma linha, precisa-se primeiro conter cadastro pelo menos uma máquina.
[MMS _CCS_RF_003] Cadastro de Grupo de Máquina
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá ser cadastrado um grupo de máquina, que pode representar uma ou várias máquinas.
OBS: [MMS_CCS_RF_004] Cadastro de Técnicos
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá ser cadastrado os técnicos responsáveis pelo atendimento das OS abertas. O mesmo poderá visualizar todas as OS abertas e fechá-las.
OBS: O técnico também poderá visualizar todas as OS fechadas.
83
[MMS_CCS_RF_005] Cadastro de Supervisor
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter cadastro dos supervisores responsáveis em abrir as OS no sistema.
OBS: O supervisor poderá visualizar todas as OS abertas e fechadas. [MMS_CCS_RF_006] Abertura de Ordem de Serviço
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS as aberturas de OS, serão efetuadas pelo supervisor, contendo informações de sua hora de abertura, nome do supervisor e descrição do problema identificado.
[MMS_CCS_RF_007] Fechamento de Ordem de Serviço
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS os fechamento de OS serão efetuadas pelo técnico responsável pelas mesmas, contendo informações de sua hora de fechamento, nome do técnico responsável, descrição da falha, modo de falha, causa da falha e ação para evitar ocorrência da falha.
Componente - Consultas no Sistema [MMS_CS_RF_001] Consulta de histórico de falha
Prioridade: Essencial � Importante � Desejável
Estabilidade: � Estável Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter consulta de histórico relacionado com as falhas anteriores ocorridas com as máquina. Assim auxiliará em ações a serem tomadas para solucionar um problema ocorrido na máquina atualmente.
OBS:
84
[MMS_CS_RF_002] Consulta de informações técnicas das máquinas
Prioridade: � Essencial Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter consultas das informações técnicas das máquinas.
OBS: [MMS_CS_RF_003] Consulta de Ordem de Serviço Abertas
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter consultas de todas as OS abertas. [MMS_CS_RF_004] Consulta de ordem de serviço fechadas
Prioridade: Essencial �Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter consultas de todas as OS fechadas.
OBS:
Componente – Relatórios do Sistema
[MMS_RS_RF_001] Relatório de MTBF por estágio de linha Prioridade: � Essencial � Importante Desejável
Estabilidade: �Estável � Pouco estável Instável
Origem:
Descrição: No MMS deverá conter relatório do índice de MTBF por estágio de linha.
O MTBF é o índice usado para calcular freqüência de uma determinada falha.
[MMS_RS_RF _002] Relatório de MTBF por linha
Prioridade: � Essencial Importante � Desejável
Estabilidade: �Estável Pouco estável � Instável
85
Origem:
Descrição: No MMS deverá conter o relatório do índice de MTBF. Onde neste caso será analisado o MTBF por cada linha da fábrica.
OBS: O período de tempo, data de início e término a serem analisados, deverão ser configuráveis.
[MMS_RS_RF _003] Relatório de MTBF por turno Prioridade: � Essencial � Importante Desejável
Estabilidade: �Estável � Pouco estável Instável
Origem:
Descrição: No MMS deverá conter relatório do índice de MTBF analisando por turno.
OBS: O período de tempo, data de início e término a serem analisados, deverão ser configuráveis.
[MMS_RS_RF _004] Relatório de MTBF por grupo Prioridade: � Essencial � Importante Desejável
Estabilidade: �Estável � Pouco estável Instável
Origem:
Descrição: No MMS deverá conter relatório do índice de MTBF analisando por grupo.
OBS: O período de tempo, data de início e término a serem analisados, deverão ser configuráveis.
[MMS_RS_RF _005] Relatório de MTBF por máquina Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter relatório do índice de MTBF analisando por máquina.
OBS: O período de tempo, data de início e término a serem analisados, deverão ser configuráveis.
[MMS_RS_RF _006] Relatório de MTBF da fábrica
Prioridade: � Essencial Importante � Desejável
Estabilidade: �Estável Pouco estável � Instável
Origem:
86
Descrição: No MMS deverá conter relatório do índice de MTBF analisando toda a fábrica.
OBS: O período de tempo, data de início e término a serem analisados, deverão ser configuráveis.
[MMS_RS_RF _007] Relatório de MTTR por máquina
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter relatório do índice de MTTR – responsável por medir o tempo de resolução de um determinado problema.
OBS: O período de tempo, data de início e término a serem analisados, deverão ser configuráveis.
[MMS_RS_RF _008] Relatório de DownTime por máquina
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter relatório do índice de Downtime (responsável em medir o tempo total de parada de uma máquina).
OBS: O período de tempo, data de início e término a serem analisados, deverão ser configuráveis.
Requisitos de Interface Interface com Usuário
[MMS_VS_RF_001] Cadastro de Máquina Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter uma interface para cadastro das máquinas a serem analisadas. Nesta interface terá os seguintes campos: - Código da Máquina; - Nome da máquina; - Data do Cadastro;
87
OBS: O código das máquina serão compostos pelo o número de série de cada máquina.
[MMS_VS_RF_002] Cadastro de Técnicos
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter uma interface para cadastro dos técnicos. Nesta interface terá os seguintes campos: - Código da Máquina; - Nome da máquina; - Data do Cadastro;
OBS: O código das máquina serão compostos pelo o número de série de cada máquina.
[MMS_VS_RF_003] Cadastro de Supervisor (es)
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter uma interface para cadastro do (s) supervisor (es). Nesta interface terá os seguintes campos: - Código do supervisor; - Nome do supervisor; - Data do cadastro; - Linha responsável;
OBS: O código do supervisor será gerado pelo sistema automaticamente.
[MMS_VS_RF_004] Cadastro de Grupo de Máquina
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter uma interface para cadastro do (s) grupo (s) de máquina (s). Nesta interface terá os seguintes campos: - Código do grupo; - Nome do grupo;
88
OBS: O código do grupo de máquina será gerado pelo sistema automaticamente.
[MMS_VS_RF_005] Cadastro das Linhas
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter uma interface para cadastro da (s) linha (s) a ser (em) analisada (s). Nesta interface terá os seguintes campos: - Código da linha; - Nome da linha; - Data do cadastro;
OBS: O código do grupo de máquina será gerado pelo sistema automaticamente.
[MMS_VS_RF_006] Cadastro dos Setores da Linha
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter uma interface para cadastro dos setores da linha. Nesta interface terá os seguintes campos: - Código do setor de linha; - Nome do setor; - Data do cadastro;
OBS: O código do setor de linha será gerado pelo sistema automaticamente.
[MMS_VS_RF_007] Abertura da Ordem de Serviço
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
89
Descrição: No MMS deverá conter uma interface para aberturas das ordens de serviços. Nesta interface terá os seguintes campos: - Código da OS; - Código da máquina; - Nome da máquina; - Nome do supervisor; - Descrição da falha; - Data de abertura da OS; - Hora de abertura da OS;
OBS: - O código da OS será gerado pelo sistema automaticamente. - A data de abertura terá que se lida do sistema, não sendo configurada pelo usuário.
[MMS_VS_RF_009] Fechamento da Ordem de Serviço
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: No MMS deverá conter uma interface para o fechamento das ordens de serviços. Nesta interface terá os seguintes campos: - Código da OS; - Nome do técnico; - Código da máquina; - Nome da máquina; - Modo de falha; - Descrição da falha; - Causa; - Ação tomada; - Ação para evitar ocorrência da falha; - Data do fechamento da OS; - Hora do fechamento da OS;
OBS: - A data do fechamento terá que se lida do sistema, não sendo configurada pelo usuário.
[MMS_VS_RF_010] Interface Principal do Sistema
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
90
Descrição: No MMS deverá conter uma interface principal para gerenciamento do sistema.
OBS:
Outros Requisitos Requisitos de Segurança de Acesso
[MMS_ RSA_RF_001] Controle de Acesso
Prioridade: Essencial � Importante � Desejável
Estabilidade: Estável � Pouco estável � Instável
Origem:
Descrição: O controle de acesso no MMS, deverá ser realizado através de perfis, onde cada perfil terá suas devidas permissões de acesso.
92
Classe: Authentication.cs
namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_authentication")] public class Authentication : ActiveRecordBase { private int id; private string authId; private User user; private DateTime lastAccess; [PrimaryKey("id")] public int Id { get{return id;} set{id = value;} } [Property("authentication_id")] public string AuthenticationID { get{return authId;} set{authId = value;} } [BelongsTo("tab_user_id")] public User User { get{return user;} set{user = value;} } [Property("last_access")] public DateTime LastAccess { get{return lastAccess;} set{lastAccess = value;} } public static Authentication FindByAuthenticationID(string id) { return (Authentication) FindOne(typeof(Authentication), Expression.Eq("AuthenticationID", id)); } } }
93
Classe: MMSSecurity.cs
namespace MMS.Models { using System.Security.Cryptography; using System.Text; public static class MMSSecurity { public static string GetMD5Secret(string text) { byte[] pass = Encoding.UTF8.GetBytes(text); MD5 md5 = new MD5CryptoServiceProvider(); return Encoding.UTF8.GetString(md5.ComputeHash(pass)); } } } Classe: User.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_user")] public class User : ActiveRecordBase { /* * Constantes * */ public const string PROFILE_TECHNICIAN = "TE"; public const string PROFILE_SUPERVISOR = "SU"; public const string PROFILE_ENGINEER = "EN"; /* * Atributos * */ private int id; private string login; private string password; private string name; private string address; private long mobilePhone; private long homePhone; /* Relacionamentos */
private IList<MaintenanceReport> reports = new List<MaintenanceReport>(); private IList<ServiceOrder> serviceOrders = new List<ServiceOrder>();
94
private string profile; [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("usr_login")] public string Login { get { return login; } set { login = value; } } [Property("usr_password")] public string Password { get { return password; } set { password = value; } } [Property("usr_name")] public string Name { get{return name;} set{name = value;} } [Property("usr_address")] public string Address { get{return address;} set{address = value;} } [Property("usr_mobile_phone")] public long MobilePhone { get{return mobilePhone;} set{mobilePhone = value;} } [Property("usr_home_phone")] public long HomePhone { get{return homePhone;} set{homePhone = value;} } [HasMany(Table = "tab_maintenance_report", ColumnKey = "tab_user_id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<MaintenanceReport> Reports {
95
get { return reports; } set { reports = value; } } [HasMany(Table = "tab_service_order", ColumnKey = "tab_user_id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<ServiceOrder> SORequestList { get { return serviceOrders; } set { serviceOrders = value; } } [Property("usr_profile")] public string Profile { get{return profile;} set{profile = value;} } public override void Create() { this.Password = MMSSecurity.GetMD5Secret(this.Password); base.Create(); } static public User FindByLoginInfo(string login, string password) { string passwd = MMSSecurity.GetMD5Secret(password); return (User) FindOne(typeof(User), Expression.Eq("Login", login), Expression.Eq("Password", passwd)); } static public User[] FindAll() { return (User[])FindAll(typeof(User)); } public static User[] FindByProfile(string profile) { return (User[])FindAll(typeof(User), new Order[]{Order.Asc("Name")}, Expression.Eq("Profile", profile)); } static public User FindById(int id) { return (User)FindByPrimaryKey(typeof(User), id); } } } Classe: AssemblyLine.cs
96
namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_assembly_line")] public class AssemblyLine : ActiveRecordBase { private int id; private string name; private string description; private IList<AssemblyLineStage> stages = new List<AssemblyLineStage>(); [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("name")] public string Name { get { return name; } set { name = value; } } [Property("description")] public string Description { get{return description;} set{description = value;} } [HasMany(Table = "tab_line_stage", ColumnKey = "tab_assembly_line_id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<AssemblyLineStage> Stages { get { return stages; } set { stages = value; } } public static AssemblyLine[] FindAll() { return (AssemblyLine[])FindAll(typeof(AssemblyLine)); } public static AssemblyLine FindById(int id) { return (AssemblyLine)FindByPrimaryKey(typeof(AssemblyLine), id); } } }
97
Classe: Machine.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_machine")] public class Machine : ActiveRecordBase { private int id; private string code; private DateTime acquisitionDate; private DateTime guaranteeDate; private float operationVoltage; private float departureCurrent; private float ratedCurrent; private float frequency; private float departureCoefficient; private string aditionalInformation; /* Relacionamentos */ private MachineModel machineModel; private MachineType machineType; private MachineGroup machineGroup; private AssemblyLineStage assemblyLineStage; private IList<ServiceOrder> serviceOrders = new List<ServiceOrder>(); [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("code")] public string Code { get { return code; } set { code = value; } } [Property("acquisition_date")] public DateTime AcquisitionDate { get { return acquisitionDate; } set { acquisitionDate = value; } } [Property("guarantee_date")] public DateTime GuaranteeDate
98
{ get { return guaranteeDate; } set { guaranteeDate = value; } } [Property("operation_voltage")] public float OperationVoltage { get { return operationVoltage; } set { operationVoltage = value; } } [Property("departure_current")] public float DepartureCurrent { get { return departureCurrent; } set { departureCurrent = value; } } [Property("rated_current")] public float RatedCurrent { get { return ratedCurrent; } set { ratedCurrent = value; } } [Property("frequency")] public float Frequency { get { return frequency; } set { frequency = value; } } [Property("departure_coefficient")] public float DepartureCoefficient { get { return departureCoefficient; } set { departureCoefficient = value; } } [Property("aditional_information")] public string AditionalInformation { get { return aditionalInformation; } set { aditionalInformation = value; } } [BelongsTo("tab_machine_model_id")] public MachineModel MachineModel { get{return machineModel;} set{machineModel = value;} } [BelongsTo("tab_machine_type_id")]
99
public MachineType MachineType { get { return machineType; } set { machineType = value; } } [BelongsTo("tab_machine_group_id")] public MachineGroup MachineGroup { get { return machineGroup; } set { machineGroup = value; } } [BelongsTo("tab_line_stage_id")] public AssemblyLineStage AssemblyLineStage { get { return assemblyLineStage; } set { assemblyLineStage = value; } } [HasMany(Table = "tab_service_order", ColumnKey = "tab_machine_id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<ServiceOrder> ServiceOrders { get { return serviceOrders; } set { serviceOrders = value; } } public static Machine[] FindAll() { return (Machine[])FindAll(typeof(Machine)); } public static Machine FindById(int id) { return (Machine)FindByPrimaryKey(typeof(Machine), id); } } } Classe: MachineGroup.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_machine_group")] public class MachineGroup : ActiveRecordBase { private int id;
100
private string name; private string description; private IList<Machine> machines = new List<Machine>(); [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("name")] public string Name { get { return name; } set { name = value; } } [Property("description")] public string Description { get { return description; } set { description = value; } } [HasMany(Table = "tab_machine", ColumnKey = "tab_machine_group_id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<Machine> Machines { get { return machines; } set { machines = value; } } public static MachineGroup[] FindAll() { return (MachineGroup[])FindAll(typeof(MachineGroup)); } public static MachineGroup FindById(int id) { return (MachineGroup)FindByPrimaryKey(typeof(MachineGroup), id); } } } Classe: MachineModel.cs namespace MMS.Models { using System; using System.Collections; using Castle.ActiveRecord;
101
using NHibernate.Expression; [ActiveRecord("tab_machine_model")] public class MachineModel : ActiveRecordBase { private int id; private string name; private string description; private Manufacturer manufacturer; public MachineModel() { } [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("name")] public string Name { get { return name; } set { name = value; } } [Property("description")] public string Description { get{return description;} set{description = value;} } [BelongsTo("tab_machine_manufacturer_id")] public Manufacturer Manufacturer { get { return manufacturer; } set { manufacturer = value; } } public static MachineModel[] FindAll() { return (MachineModel[])FindAll(typeof(MachineModel)); } public static MachineModel FindById(int id) { return (MachineModel)FindByPrimaryKey(typeof(MachineModel), id); } } }
102
Classe: MachineType.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_machine_type")] public class MachineType : ActiveRecordBase { private int id; private string name; private string description; private IList<Machine> machines = new List<Machine>(); [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("name")] public string Name { get { return name; } set { name = value; } } [Property("description")] public string Description { get { return description; } set { description = value; } } [HasMany(Table = "tab_machine", ColumnKey = "tab_machine_type_id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<Machine> Machines { get { return machines; } set { machines = value; } } public static MachineType[] FindAll() { return (MachineType[])FindAll(typeof(MachineType)); } public static MachineType FindById(int id) { return (MachineType)FindByPrimaryKey(typeof(MachineType), id);
103
} } } Classe: Manufacturer.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_machine_manufacturer")] public class Manufacturer : ActiveRecordBase { private int id; private string name; private string address; private long phone; private IList<MachineModel> machineModels = new List<MachineModel>(); [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("name")] public string Name { get { return name; } set { name = value; } } [Property("address")] public string Address { get{return address;} set{address = value;} } [Property("phone")] public long Phone { get{return phone;} set{phone = value;} }
104
[HasMany(Table = "tab_machine_model", ColumnKey = "tab_machine_manufacturer_id",
Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<MachineModel> MachineModels { get { return machineModels; } set { machineModels = value; } } public static Manufacturer[] FindAll() { return (Manufacturer[])FindAll(typeof(Manufacturer)); } public static Manufacturer FindById(int id) { return (Manufacturer)FindByPrimaryKey(typeof(Manufacturer), id); } } } Classe: StageAssemblyLine.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_estagio_linha_montagem")] public class StageAssemblyLine : ActiveRecordBase { private int id; private string stageNameLine; private AssemblyLine assemblyLine; private IList<Machine> machine = new List<Machine>(); public StageAssemblyLine() { } [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("nome_estagio_linha")] public string StageNameLine {
105
get { return stageNameLine; } set { stageNameLine = value; } } [BelongsTo("cad_linha_montagem_id")] public AssemblyLine AssemblyLine { get { return assemblyLine; } set { assemblyLine = value; } } [HasMany(Table = "tab_cad_maquina", ColumnKey = "id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<Machine> Machine { get { return machine; } set { machine = value; } } public static StageAssemblyLine[] FindAll() {
return (StageAssemblyLine[])FindAll(typeof(StageAssemblyLine), new Order[] { Order.Asc("StageNameLine") });
} public static StageAssemblyLine FindById(int id) { return (StageAssemblyLine)FindByPrimaryKey(typeof(StageAssemblyLine), id); } } } Classe: TechnicalInformation.cs namespace MMS.Models { using System; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_inf_tecnica")] public class TechnicalInformation : ActiveRecordBase { private int id; private float operationVoltage; private float currentDeparture; private float currentRated; private float frequency; private float coefficientDeparture; private Machine machine;
106
public TechnicalInformation() { } [PrimaryKey(PrimaryKeyType.Foreign)] public int Id { get { return id; } set { id = value; } } [Property("tensao_funcionamento")] public float OperationVoltage { get { return operationVoltage; } set { operationVoltage = value; } } [Property("corrente_partida")] public float CurrentDeparture { get { return currentDeparture; } set { currentDeparture = value; } } [Property("corrente_nominal")] public float CurrentRated { get { return currentRated; } set { currentRated = value; } } [Property("frequencia")] public float Frequency { get { return frequency; } set { frequency = value; } } [Property("coeficiente_partida")] public float CoefficientDeparture { get { return coefficientDeparture; } set { coefficientDeparture = value; } } [OneToOne] public Machine Machine { get { return machine; } set { machine = value; } } public static ExtraInformation[] FindAll() {
107
return (ExtraInformation[])FindAll(typeof(ExtraInformation), new Order[] { Order.Asc("Id") });
} public static ExtraInformation FindById(int id) { return (ExtraInformation)FindByPrimaryKey(typeof(ExtraInformation), id); } } } Classe: CorrectiveMaintenanceReport.cs namespace MMS.Models { using System; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_corrective_maintenance_report")] public class CorrectiveMaintenanceReport : MaintenanceReport { private string problemActionCorrect; private string problemCause; private string preventiveAction; private FailureMode failureMode; [JoinedKey("tab_maintenance_report_tab_service_order_id")] public override int Id { get { return id; } set { id = value; } } [Property("problem_corrective_action")] public string ProblemCorrectionAction { get { return problemActionCorrect; } set { problemActionCorrect = value; } } [Property("problem_cause")] public string ProblemCause { get { return problemCause; } set { problemCause = value; } } [Property("preventive_action")] public string PreventiveAction { get { return preventiveAction; } set { preventiveAction = value; }
108
} [BelongsTo("tab_failure_mode_id")] public FailureMode FailureMode { get { return failureMode; } set { failureMode = value; } } public static CorrectiveMaintenanceReport[] FindAll() {
return(CorrectiveMaintenanceReport[])FindAll(typeof(CorrectiveMaintenanceReport));
} } } Classe: FailureMode.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_failure_mode")] public class FailureMode : ActiveRecordBase { private int id; private string name; private string description; private IList<CorrectiveMaintenanceReport> correctiveMaintenances = new List<CorrectiveMaintenanceReport>(); public FailureMode() { } [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("name")] public string Name { get { return name; } set { name = value; }
109
} [Property("description")] public string Description { get { return description; } set { description = value; } } [HasMany(Table = "tab_corrective_maintenance", ColumnKey = "tab_failure_mode_id", Inverse = true, Cascade = ManyRelationCascadeEnum.AllDeleteOrphan)] public IList<CorrectiveMaintenanceReport> CorrectiveMaintenanceReports { get { return correctiveMaintenances; } set { correctiveMaintenances = value; } } public static FailureMode[] FindAll() { return (FailureMode[])FindAll(typeof(FailureMode)); } public static FailureMode FindById(int id) { return (FailureMode)FindByPrimaryKey(typeof(FailureMode), id); } } } Classe: MaintenanceReport.cs namespace MMS.Models { using System; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_maintenance_report"), JoinedBase] public class MaintenanceReport : ActiveRecordBase { protected int id; // id da ordem de serviço private User technician; // Técnico Responsável private ServiceOrder serviceOrder; // Ordem de serviço relacionada private DateTime attendanceBeginTime; // Data e Hora do Início do atendimento private DateTime attendanceEndTime; // Data e Hora do Fim do atendimento private bool machineStopped; // Houve parada da máquina? private DateTime machineStopTime; // Data e Hora em que a máquina parou private DateTime machineRestartTime; // Data e Hora em que a máquina voltou a funcionar public MaintenanceReport() {
110
} [PrimaryKey(PrimaryKeyType.Foreign, "tab_service_order_id")] public virtual int Id { get{return id;} set{id = value;} } [OneToOne] public ServiceOrder ServiceOrder { get{return serviceOrder;} set{serviceOrder = value;} } [BelongsTo("tab_user_id")] public User Technician { get{return technician;} set{technician = value;} } [Property("attendance_begin_time")] public DateTime AttendanceBeginTime { get{return attendanceBeginTime;} set{attendanceBeginTime = value;} } [Property("attendance_end_time")] public DateTime AttendanceEndTime { get{return attendanceEndTime;} set{attendanceEndTime = value;} } [Property("machine_stopped")] public bool MachineStopped { get{return machineStopped;} set{machineStopped = value;} } [Property("machine_stop_time")] public DateTime MachineStopTime { get{return machineStopTime;} set{machineStopTime = value;} } [Property("machine_restart_time")] public DateTime MachineRestartTime { get{return machineRestartTime;}
111
set{machineRestartTime = value;} } public virtual void Close() { this.ServiceOrder = ServiceOrder.FindById(this.Id); this.ServiceOrder.Close(); Update();
MachineStopLog.NotifyCorrectiveStop(ServiceOrder.Machine, MachineStopTime, MachineRestartTime, AttendanceBeginTime, AttendanceEndTime, ServiceOrder.OpenTime, ServiceOrder.CloseTime);
} }/* class */ }/* namespace */ Classe: PredictiveMaintenanceReport.cs namespace MMS.Models { using System; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_predictive_maintenance_report")] public class PredictiveMaintenanceReport: MaintenanceReport { private string resultDescription; private string problemDescription; [JoinedKey("tab_maintenance_report_tab_service_order_id")] public override int Id { get { return id; } set { id = value; } } [Property("result_description")] public string ResultDescription { get { return resultDescription; } set { resultDescription = value; } } [Property("problem_description")] public string ProblemDescription { get { return problemDescription; } set { problemDescription = value; } } public static PredictiveMaintenanceReport[] FindAll()
112
{ return (PredictiveMaintenanceReport[])FindAll(typeof (PredictiveMaintenanceReport));
} }/*class*/ } Classe: PreventiveMaintenanceReport.cs namespace MMS.Models { using System; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_preventive_maintenance_report")] public class PreventiveMaintenanceReport : MaintenanceReport { private string resultDescription; [JoinedKey("tab_maintenance_report_tab_service_order_id")] public override int Id { get { return id; } set { id = value; } } [Property("result_description")] public string ResultDescription { get { return resultDescription; } set { resultDescription = value; } } public static PreventiveMaintenanceReport[] FindAll() {
return(PreventiveMaintenanceReport[])FindAll(typeof(PreventiveMaintenanceReport));
} } } Classe: ServiceOrder.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord;
113
using NHibernate.Expression; [ActiveRecord("tab_service_order")] public class ServiceOrder : ActiveRecordBase { /* * Constantes * */ /* Status da Ordem de Serviço */ public const string STATUS_OPENED = "OP"; public const string STATUS_CLOSED = "CL"; public const string STATUS_CANCELED = "CA"; /* Tipo de Manutenção a qual a ordem de serviço está relacionada */ public const string MAINTENANCE_TYPE_CORRECTIVE = "CV"; public const string MAINTENANCE_TYPE_PREDICTIVE = "PD"; public const string MAINTENANCE_TYPE_PREVENTIVE = "PV"; /* * Atributos da classe * */ protected int id; // id da ordem de serviço private User requestUser; // Usuário solicitante private Machine machine; // Máquina referente a solicitação private string title; // Título da Ordem de serviço (Preenchido pelo líder técnico) private string description; // Descrição da Ordem de serviço (Preenchido pelo líder técnico) private DateTime openTime; // Data e Hora da Abertura da Ordem de Serviço private DateTime closeTime; // Data e Hora do Fechamento da Ordem de Serviço private DateTime cancelTime;// Data e Hora do Cancelamento da Ordem de Serviço private string status; // Status da OS: OP = OPENED, CL = CLOSED, CA = CANCELED private string maintenanceType; // Tipo da OS: CV = CORRECTIVE, PV = PREVENTIVE, PD = PREDICTIVE private MaintenanceReport report; // relatário de manutenção [PrimaryKey("id")] public int Id { get{return id;} set{id = value;} } [BelongsTo("tab_machine_id")] public Machine Machine { get{return machine;} set{machine = value;} } [BelongsTo("tab_user_id")] public User RequestUser
114
{ get{return requestUser;} set{requestUser = value;} } [OneToOne] public MaintenanceReport Report { get{return report;} set{report = value;} } [Property("so_title")] public string Title { get{return title;} set{title = value;} } [Property("so_description")] public string Description { get{return description;} set{description = value;} } [Property("so_open_time")] public DateTime OpenTime { get{return openTime;} set{openTime = value;} } [Property("so_close_time")] public DateTime CloseTime { get{return closeTime;} set{closeTime = value;} } [Property("so_cancel_time")] public DateTime CancelTime { get{return cancelTime;} set{cancelTime = value;} } [Property("so_status")] public string Status { get{return status;} set{status = value;} } [Property("so_maintenance_type")]
115
public string MaintenanceType { get{return maintenanceType;} set{maintenanceType = value;} } public virtual void Open() { MaintenanceReport mr; Status = ServiceOrder.STATUS_OPENED; OpenTime = DateTime.Now; if(MaintenanceType == ServiceOrder.MAINTENANCE_TYPE_CORRECTIVE) mr = new CorrectiveMaintenanceReport(); else if(MaintenanceType == ServiceOrder.MAINTENANCE_TYPE_PREVENTIVE) mr = new PreventiveMaintenanceReport(); else mr = new PredictiveMaintenanceReport(); mr.ServiceOrder = this; mr.Create(); } public void Close() { Status = ServiceOrder.STATUS_CLOSED; CloseTime = DateTime.Now; Update(); } public void Cancel() { Status = ServiceOrder.STATUS_CANCELED; CancelTime = DateTime.Now; Update(); } public static ServiceOrder[] FindAll() {
return (ServiceOrder[])FindAll(typeof(ServiceOrder), new Order[]{Order.Asc("OpenTime")});
} public static ServiceOrder[] FindOpened() {
return (ServiceOrder[])FindAll(typeof(ServiceOrder), new Order[]{Order.Asc("OpenTime")}, Expression.Eq("Status", ServiceOrder.STATUS_OPENED));
} public static ServiceOrder[] FindClosed() {
116
return (ServiceOrder[])FindAll(typeof(ServiceOrder), new Order[]{Order.Asc("CloseTime")}, Expression.Eq("Status", ServiceOrder.STATUS_CLOSED));
} public static ServiceOrder[] FindCanceled() {
return (ServiceOrder[])FindAll(typeof(ServiceOrder), new Order[]{Order.Asc("CancelTime")}, Expression.Eq("Status", ServiceOrder.STATUS_CANCELED));
} public static ServiceOrder FindById(int id) { return (ServiceOrder) FindByPrimaryKey(typeof(ServiceOrder), id); } public static ServiceOrder[] FindByFilter(User u, string status) { Order[] order; if(status == ServiceOrder.STATUS_CLOSED) order = new Order[]{Order.Asc("CloseTime")}; else if(status == ServiceOrder.STATUS_CANCELED) order = new Order[]{Order.Asc("CancelTime")}; else order = new Order[]{Order.Asc("OpenTime")}; return (ServiceOrder[]) FindAll(typeof(ServiceOrder), order, Expression.Eq("RequestUser.Id", u.Id),
Expression.Eq("Status", status)); }
public static ServiceOrder[] FindByFilter(User u, string status, DateTime iDate, DateTime eDate)
{ Order[] order; string dateFilter = "OpenTime"; DateTime initialDate = iDate.AddDays(-1); DateTime endDate = eDate; if(status == ServiceOrder.STATUS_CLOSED) { order = new Order[]{Order.Asc("CloseTime")}; dateFilter = "CloseTime"; } else if(status == ServiceOrder.STATUS_CANCELED) { order = new Order[]{Order.Asc("CancelTime")}; dateFilter = "CancelTime"; } else { order = new Order[]{Order.Asc("OpenTime")}; }
117
if(u != null) { return (ServiceOrder[]) FindAll(typeof(ServiceOrder), order, Expression.Eq("RequestUser.Id", u.Id), Expression.Eq("Status", status), Expression.Between(dateFilter, initialDate, endDate)); } return (ServiceOrder[]) FindAll(typeof(ServiceOrder), order, Expression.Eq("Status", status), Expression.Between(dateFilter, initialDate, endDate)); } }/* Class */ } Classe: MachineStopLog.cs namespace MMS.Models { using System; using System.Collections.Generic; using Castle.ActiveRecord; using NHibernate.Expression; public class IndexMachineInformation { private Machine machine; private int maintenanceCount; private double mtbf; private double mttr; private double downTime;
public IndexMachineInformation(Machine m, double mtbf, double mttr, double downTime, int mc)
{ this.Machine = m; this.MTBF = mtbf; this.MTTR = mttr;
this.DownTime = downTime; this.MaintenanceCount = mc; } public Machine Machine { get{return machine;} set{machine = value;} }
118
public double MTBF { get{return mtbf;} set{mtbf = value;} } public double MTTR { get{return mttr;} set{mttr = value;} } public double DownTime { get{return downTime;} set{downTime = value;} } public int MaintenanceCount { get{return maintenanceCount;} set{maintenanceCount = value;} } } [ActiveRecord("tab_machine_stop_log")] public class MachineStopLog : ActiveRecordBase { public const string STOP_CAUSE_CORRECTIVE = "CV"; public const string STOP_CAUSE_PREDICTIVE = "PD"; public const string STOP_CAUSE_PREVENTIVE = "PV"; public const string STOP_CAUSE_OTHER = "OT"; /* relacionamentos */ private Machine machine; private MachineGroup machineGroup; private AssemblyLine assemblyLine; private AssemblyLineStage lineStage; private int id; private DateTime downTime; private DateTime upTime; private string stopCause; private DateTime attendanceBegin; private DateTime attendanceEnd; private DateTime osOpenTime; private DateTime osCloseTime; public MachineStopLog() { }
public MachineStopLog(Machine machine, DateTime downTime, DateTime upTime, DateTime attendanceBegin, DateTime attendanceEnd, DateTime osOpenTime, DateTime osCloseTime, string cause)
119
{ this.Machine = machine; this.MachineGroup = machine.MachineGroup; this.LineStage = machine.AssemblyLineStage; this.AssemblyLine = LineStage.AssemblyLine; this.StopCause = cause; this.DownTime = downTime; this.UpTime = upTime; this.AttendanceBegin = attendanceBegin; this.AttendanceEnd = attendanceEnd; this.OsOpenTime = osOpenTime; this.OsCloseTime = osCloseTime; System.Console.WriteLine("Log Created!"); } [PrimaryKey("id")] public int Id { get{return id;} set{id = value;} } [Property("down_time")] public DateTime DownTime { get{return downTime;} set{downTime = value;} } [Property("up_time")] public DateTime UpTime { get{return upTime;} set{upTime = value;} } [Property("stop_cause")] public string StopCause { get{return stopCause;} set{stopCause = value;} } [Property ("attendance_begin")] public DateTime AttendanceBegin { get{return attendanceBegin;} set{attendanceBegin = value;} } [Property ("attendance_end")] public DateTime AttendanceEnd { get{return attendanceEnd;}
120
set{attendanceEnd = value;} } [Property ("os_open_time")] public DateTime OsOpenTime { get{return osOpenTime;} set{osOpenTime = value;} } [Property ("os_close_time")] public DateTime OsCloseTime { get{return osCloseTime;} set{osCloseTime = value;} } [BelongsTo("tab_machine_id")] public Machine Machine { get{return machine;} set{machine = value;} } [BelongsTo("tab_machine_group_id")] public MachineGroup MachineGroup { get{return machineGroup;} set{machineGroup = value;} } [BelongsTo("tab_assembly_line_id")] public AssemblyLine AssemblyLine { get{return assemblyLine;} set{assemblyLine = value;} } [BelongsTo("tab_line_stage_id")] public AssemblyLineStage LineStage { get{return lineStage;} set{lineStage = value;} } private static double GetTotalHours(DateTime iDate, DateTime eDate) { TimeSpan diff = eDate.Subtract(iDate); return ((double)(diff.Days*24)) + ((double)diff.Hours) + ((double)diff.Minutes/60.0); } private static double GetTotalMinutes(DateTime iDate, DateTime eDate) { TimeSpan diff = eDate.Subtract(iDate);
121
return ((double)(diff.Days*24)) + ((double)diff.Hours/60.0) + ((double)diff.Minutes); }
public static MachineStopLog[] FindByMachineMTBF(Machine machine, DateTime iDate, DateTime eDate)
{ DateTime end = eDate.AddHours(23); end = end.AddMinutes(59);
return (MachineStopLog[]) FindAll(typeof(MachineStopLog), new Order[]{Order.Asc("DownTime")}, Expression.Eq("Machine.Id", machine.Id), Expression.Or(Expression.Between("DownTime", iDate, end), Expression.Between("UpTime", iDate, end)));
} public static MachineStopLog[] FindByMachineMTTR(Machine machine, DateTime iDate, DateTime eDate) { DateTime end = eDate.AddHours(23); end = end.AddMinutes(59);
return (MachineStopLog[]) FindAll(typeof(MachineStopLog), new Order[]{Order.Asc("AttendanceBegin")}, Expression.Eq("Machine.Id", machine.Id), Expression.Or(Expression.Between("AttendanceBegin", iDate, end), Expression.Between("AttendanceEnd", iDate, end)));
} public static MachineStopLog[] FindByMachineDownTime(Machine machine, DateTime iDate, DateTime eDate) { DateTime end = eDate.AddHours(23); end = end.AddMinutes(59);
return (MachineStopLog[]) FindAll(typeof(MachineStopLog), new Order[]{Order.Asc("OsOpenTime")}, Expression.Eq("Machine.Id", machine.Id), Expression.Or(Expression.Between("OsOpenTime", iDate, end), Expression.Between("OsCloseTime", iDate, end)));
} public static MachineStopLog[] FindByMachineGroup(MachineGroup group) {
return (MachineStopLog[]) FindAll(typeof(MachineStopLog), new Order[]{Order.Asc("DownTime")}, Expression.Eq("MachineGroup.Id", group.Id));
} public static MachineStopLog[] FindByAssemblyLine(AssemblyLine line) { return (MachineStopLog[]) FindAll(typeof(MachineStopLog), new Order[]{Order.Asc("DownTime")}, Expression.Eq("AssemblyLine.Id", line.Id));
122
} public static MachineStopLog[] FindByLineStage(AssemblyLineStage stage) {
return (MachineStopLog[]) FindAll(typeof(MachineStopLog), new Order[]{Order.Asc("DownTime")}, Expression.Eq("LineStage.Id", stage.Id));
}
private static void NotifyStop(Machine machine, DateTime downTime, DateTime upTime, DateTime attendanceBegin, DateTime attendanceEnd, DateTime osOpenTime, DateTime osCloseTime, string cause)
{ MachineStopLog log = new MachineStopLog(machine, downTime, upTime, attendanceBegin, attendanceEnd, osOpenTime, osCloseTime, cause);
if(log.Machine == null) System.Console.Write("MACHINE IS NULL"); if(log.MachineGroup == null) System.Console.Write("MACHINE GROUP IS NULL"); if(log.AssemblyLine == null) System.Console.Write("ASSEMBLY LINE IS NULL"); if(log.LineStage == null) System.Console.Write("ASSEMBLY LINE STAGE IS NULL"); log.Create(); }
public static void NotifyCorrectiveStop(Machine machine, DateTime downTime, DateTime upTime, DateTime attendanceBegin, DateTime attendanceEnd, DateTime osOpenTime, DateTime osCloseTime)
{ MachineStopLog.NotifyStop(machine, downTime, upTime, attendanceBegin, attendanceEnd, osOpenTime, osCloseTime, MachineStopLog.STOP_CAUSE_CORRECTIVE);
}
public static void NotifyPredictiveStop(Machine machine, DateTime downTime, DateTime upTime, DateTime attendanceBegin, DateTime attendanceEnd, DateTime osOpenTime, DateTime osCloseTime)
{ MachineStopLog.NotifyStop(machine, downTime, upTime, attendanceBegin, attendanceEnd, osOpenTime, osCloseTime, MachineStopLog.STOP_CAUSE_PREDICTIVE);
}
public static void NotifyPreventiveStop(Machine machine, DateTime downTime, DateTime upTime, DateTime attendanceBegin, DateTime attendanceEnd, DateTime osOpenTime, DateTime osCloseTime)
{ MachineStopLog.NotifyStop(machine, downTime, upTime, attendanceBegin, attendanceEnd, osOpenTime, osCloseTime, MachineStopLog.STOP_CAUSE_PREVENTIVE);
}
123
public static void NotifyOtherStop(Machine machine, DateTime downTime, DateTime upTime, DateTime attendanceBegin, DateTime attendanceEnd, DateTime osOpenTime, DateTime osCloseTime)
{ MachineStopLog.NotifyStop(machine, downTime, upTime, attendanceBegin, attendanceEnd, osOpenTime, osCloseTime, MachineStopLog.STOP_CAUSE_OTHER);
}
public static IndexMachineInformation GetIndexFromMachine(Machine machine, DateTime iDate, DateTime eDate)
{ MachineStopLog[] MTBFLogs = MachineStopLog.FindByMachineMTBF(machine, iDate, eDate); MachineStopLog[] MTTRLogs = MachineStopLog.FindByMachineMTTR(machine, iDate, eDate); MachineStopLog[] DownTimeLogs = MachineStopLog.FindByMachineDownTime(machine, iDate, eDate);
double tbf = 0.0; double ttr = 0.0; double down = 0.0; double mtbf = 0.0; double mttr = 0.0; double downTime = 0.0; for(int i=0; i < MTBFLogs.Length; i++) { if((i) < MTBFLogs.Length) { tbf += GetTotalHours(MTBFLogs[i].DownTime, MTBFLogs[i].UpTime); } } for(int i=0; i < MTTRLogs.Length; i++) { if((i) < MTTRLogs.Length) {
ttr += GetTotalMinutes(MTTRLogs[i].AttendanceBegin, MTTRLogs[i].AttendanceEnd);
} } for(int i=0; i < DownTimeLogs.Length; i++) { if((i) < DownTimeLogs.Length) {
down += GetTotalHours(DownTimeLogs[i].OsOpenTime, DownTimeLogs[i].OsCloseTime);
} } /* Cálculo do Índice MTBF */ if(MTBFLogs.Length == 0)
124
{ mtbf = 0.0; } else { mtbf = Math.Round(((double)(tbf/(double)MTBFLogs.Length)),2); } /* Cálculo do Índice MTTR */ if(MTTRLogs.Length == 0) { mttr = 0.0; } else { mttr = Math.Round(((double)(ttr/(double)MTTRLogs.Length)),2); } /* Cálculo do Índice DownTime */ if(DownTimeLogs.Length == 0) { downTime = 0.0; } else { double timeTotal; timeTotal = (GetTotalHours(iDate, eDate) + 24); downTime = Math.Round(((down*100)/timeTotal),3); System.Console.WriteLine("timeTotal: " + timeTotal); System.Console.WriteLine("down: " + down); System.Console.WriteLine("downTime: " + downTime); } return new IndexMachineInformation(machine, mtbf, mttr, downTime, MTBFLogs.Length); } } } Classe: MMSLogger.cs /* * Modelo do arquivo de Log: * * <log date="10-10-2008"> * <message time="20:30:57" user="dnascimento"> * Inner Exception: An Exception Has Ocurred! * </message> * </log>
125
* */ namespace MMS.Models { using System; using System.Xml; using System.IO; public static class MMSLogger { public const string PATH="Content/log/"; public static XmlDocument Load(string fileName) { XmlDocument doc = new XmlDocument(); if(!File.Exists(MMSLogger.PATH + fileName)) CreateLog(fileName); doc.Load(MMSLogger.PATH + fileName); return doc; } private static string GetExceptionMessage(Exception e, string msg) { string str = msg; str += "Message: " + e.Message + "<br/>"; str += "StackTrace:<br/>" + e.StackTrace + "<br/>"; if(e.InnerException != null) { str = GetExceptionMessage(e.InnerException, str); } return str; } public static void Log(Exception e) { MMSLogger.Log(null, e); } public static void Log(User u, Exception e) { string msg = GetExceptionMessage(e, ""); MMSLogger.Log(u, msg); } public static void Log(string message) { MMSLogger.Log(null, message); }
126
public static void Log(User u, string message) { try { DateTime now = DateTime.Now; string fileName = now.Day + "-" + now.Month + "-" + now.Year + ".xml"; XmlDocument doc = Load(fileName); XmlElement root = doc.DocumentElement; XmlElement eMsg = doc.CreateElement("message"); XmlAttribute time = doc.CreateAttribute("time"); time.Value = now.Hour + ":" + now.Minute + ":" + now.Second; eMsg.SetAttributeNode(time); if(u != null) { XmlAttribute user = doc.CreateAttribute("user"); user.Value = u.Login; eMsg.SetAttributeNode(user); } eMsg.InnerText = message; root.AppendChild(eMsg); doc.Save(MMSLogger.PATH + fileName); } catch(Exception e) { System.Console.WriteLine(e.Message); } } public static void CreateLog(string fileName) { try { DateTime now = DateTime.Now; XmlDocument doc = new XmlDocument(); XmlElement root = doc.CreateElement("log"); doc.AppendChild(root); XmlAttribute logDate = doc.CreateAttribute("date"); logDate.Value = now.Day + "-" + now.Month + "-" + now.Year; root.SetAttributeNode(logDate); doc.Save(MMSLogger.PATH + fileName); } catch(XmlException e) { System.Console.WriteLine(e.Message);
127
} } } } Classe: MMSLogger.cs namespace MMS.Models { using System; using Castle.ActiveRecord; using NHibernate.Expression; [ActiveRecord("tab_state")] public class State : ActiveRecordBase { private int id; private string acronym; private string name; [PrimaryKey("id")] public int Id { get { return id; } set { id = value; } } [Property("acronym")] public string Acronym { get { return acronym; } set { acronym = value; } } [Property("name")] public string Name { get { return name; } set { name = value; } } static public State[] FindAll() { return (State[])FindAll(typeof(State)); } static public State FindById(int id) { return (State)FindByPrimaryKey(typeof(State), id); } } }
129
Plano de Testes
MMS
Cliente: Marcelo A. Oliveira.
SISTEMA DE GERENCIAMENTO DE MANUTENÇÃO
Versão 1.0 Responsável:
Raphael Souza
130
Histórico de Alterações
Data Versão Descrição Autor 01/11/08 1.0 Criação do documento Raphael Souza 05/11/08 1.1 Correção do documento Raphael Souza 04/12/08 1.2 Correção do documento Antônio Deyvyson
131
Sumário
Introdução ................................................................................................................................. 132
Objetivo..................................................................................................................................... 132
Sobre o produto......................................................................................................................... 132
Escopo....................................................................................................................................... 132
Abreviações usadas neste documento ....................................................................................... 132
Estratégias ................................................................................................................................. 132
Alvo de testes ............................................................................................................................ 133
Testes de requisitos funcionais.................................................................................................. 133
Teste de Usabilidade ................................................................................................................. 133
132
Introdução
Objetivo Este documento tem como objetivo descrever as atividades e o planejamento de execução dos testes do projeto MMS, bem como estratégias a serem tomadas, os testes a serem realizados, recursos e o cronograma de atividades.
Sobre o produto
O projeto MMS é um software para gerenciamento de manutenção, onde o mesmo auxiliará o gestor de manutenção em tomada de decisão de forma mais ágil, diante dos resultados apresentados durante um determinado período de análise. Determinará alguns índices, como: frequência de falhas ocorridas (MTBF), tempo de resolução para um determinado problema (MTTR), downtime, entre outros. O software será executado em um bronwser de internet.
Escopo Este documento irá abordar os seguintes níveis de testes: Testes de Integração e usabilidade do software MMS.
Abreviações usadas neste documento
Abreviação Significado MMS Maintenance Management System MTBF Tempo Médio entre Falhas
MTTR Tempo Médio de Reparo
O.S Ordem de Serviço
Estratégias O tipo de teste a ser utilizado será o “caixa-preta” (funcionais), pois o objetivo é verificar se a funcionalidade está sendo executada corretamente, ou seja, se o sistema responde corretamente a uma entrada do usuário e se o componente está preparado para suportar possíveis condições de erro, tratando-as corretamente. Como não se dispõe de ferramentas de teste automatizadas, as possíveis entradas e análise das saídas serão feitas manualmente. Nos testes realizados durante o desenvolvimento, a cada
133
Sprint, ou conclusão de um módulo, a equipe de desenvolvimento deverá realizar testes para garantir que o software funciona de maneira adequada.
Alvo de testes A listagem abaixo identifica os itens que foram identificados como alvos de teste.
Testes de requisitos funcionais Verificar:
• Login no sistema;
• Cadastro de usuário;
• Autenticação do usuário;
• Cadastro de máquina;
• Verificar entradas de dados, observando qual tipo alfanumérico;
• Testar a consistência do Banco de Dados;
• Verificação das mensagens de erros;
• Verificação de todos os botões, de confirmação, de saída e de fechamento;
• Testar limite de entrada de dados em cada campo.
• Teste de interface, com vários tipos de browsers;
• Teste de segurança do Banco de dados;
• Testar as seções das páginas;
Teste de Usabilidade Objetivo da técnica
Verificar o nível de facilidade de uso do software pelos usuários. É dividido em: 1 - Preparação (instalação do aplicativo em PC); 2 – Utilização da navegabilidade. Verificar a funcionalidade do produto. (Varrer os menus dos e opções disponíveis);
Técnica No fim de cada módulo concluído aplicar testes básicos de entradas de dados, e verificar se a saída é esperada.
Estratégia Teste das principais funcionalidades do produto do ponto de vista de usabilidade.
Critérios de O usuário deverá conseguir executar com sucesso todas as