UNIVERSIDADE PAULISTA - UNIP COORDENAÇÃO DE … · Monografia submetida à Coordenação de ......

135
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 GERENCIAMENTO DE MANUTENÇÃO INDUSTRIAL – CAMADA MODEL MANAUS 2008

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

73

envolvidos com a manutenção.

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.

77

APÊNDICE A - Documento de Especificação (DER)

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.

91

APÊNDICE B – Código-Fonte das Classes Desenvolvidas para a Camada Model

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); } } }

128

ANEXO 1 – Plano de Testes

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

134

êxito funcionalidades principais. Considerações especiais

Na fase final os testes devem ser realizados por pessoas pouco habituadas ao produto.