contribuic¸ao para o desenvolvimento de um˜ sistema para ... · criar equipes responsaveis por...

Diego de Freitas Nascimento

Contribuicao para o Desenvolvimento de umSistema para Gestao de Manutencao Industrial

Manaus - AM

2008

Diego de Freitas Nascimento

Contribuicao para o Desenvolvimento de umSistema para Gestao de Manutencao Industrial

Monografia submetida a Coordenacao deGraduacao da Universidade Paulista - UNIP,como requisito parcial para obtencao do Tıtulode Bacharel em Engenharia da Computacao

Orientador: Fabio Cardoso

Co-orientador: Marcelo Oliveira

UNIVERSIDADE PAULISTA - UNIP

Manaus - AM

2008

Trabalho de conclusao de curso sob o tıtulo “Contribuicao para o Desenvolvimento de um

Sistema para Gestao de Manutencao Industrial”, defendido por Diego de Freitas Nascimento

e aprovado em 15 de dezembro de 2008, em Manaus, Estado do Amazonas, pela banca exami-

nadora constituıda pelos professores:

Prof. Fabio Souza Cardoso, Doutorando.Orientador

Prof. Marcelo A. Oliveira, MSc.Co-orientador/Examinador

Prof. Danielle Lima, MestrandoExaminador

DEDICATORIA

Dedico este trabalho aos meus pais Geraldo da Silva Nascimento e Maria de Nazare de

Freitas Nascimento, aos meus irmaos Filipe e Micael de Freitas Nascimento e tambem a minha

namorada Carla Leao.

AGRADECIMENTOS

Ao termino deste trabalho, deixo aqui meus sinceros agradecimentos:

– a Deus por tudo;

– ao Prof. Fabio Cardoso pela orientacao;

– a todos os professores do Departamento de Ciencias Exatas pelos valiosos ensinamentos;

– a minha famılia, pelo apoio;

– aos amigos do curso de Engenharia de Computacao;

– a todos que direta ou indiretamente contribuıram para a realizacao deste trabalho.

Resumo

Este trabalho descreve a contribuicao no desenvolvimento de um software para auxılio dagestao de manutencao em fabricas no PIM (Polo Industrial de Manaus). Utilizando o padraode projeto MVC (Model-View-Controller), Tecnologias de desenvolvimento Web e Sistemasde banco de dados, o software visa automatizar e integrar algumas atividades desenvolvidasna engenharia de manutencao como: geracao de indicadores com base em dados previamentecadastrados, acompanhamento das maquinas e linhas de montagem e acompanhamento de or-dens de servico para realizacao de manutencoes.

Palavras-chave: MVC (Model-View-Controller);Desenvolvimento Web;Gestao de Manutencao;

Abstract

This paper describes the contribution in the development of software to aid in the man-agement of maintenance in factories in PIM (Polo Industrial de Manaus). Using the MVC(Model-View-Controller) design pattern, web development tecnologies and database systems,the software aims to automate and integrate some activities in maintenance engineering like:generation of indicators based on data previously registered, monitoring of machines and as-sembly lines and monitoring of service orders to perform maintenance.

Key Words: MVC (Model-View-Controller);Web Development;Maintenance Management;

Sumario

Lista de Figuras

INTRODUCAO p. 11

Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

1 MANUTENCAO INDUSTRIAL p. 13

1.1 Historico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

1.2 Tipos de Manutencao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

1.2.1 Manutencao Corretiva . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

1.2.2 Manutencao Preventiva . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

1.2.3 Manutencao Preditiva . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

1.3 Engenharia de Manutencao . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

1.3.1 Indicadores de Desempenho . . . . . . . . . . . . . . . . . . . . . . p. 16

1.3.1.1 MTBF (Mean Time Between Failure) . . . . . . . . . . . . p. 16

1.3.1.2 MTTR (Mean Time To Repair) . . . . . . . . . . . . . . . p. 16

1.3.1.3 DownTime . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

2 TECNOLOGIAS PARA DESENVOLVIMENTO DE SOFTWARE p. 18

2.1 Aplicacoes Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

2.2 Padrao MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.3 Framework.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.3.1 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

2.3.2 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22

2.4 ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.4.1 WebForms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.5 Framework MonoRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

3 METODOLOGIA p. 25

3.1 Analise de Requisitos do Cliente . . . . . . . . . . . . . . . . . . . . . . . . p. 25

3.2 Geracao de Requisitos Tecnicos . . . . . . . . . . . . . . . . . . . . . . . . p. 26

3.3 Escolha das Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

3.4 Modelagem do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

4 DESENVOLVIMENTO DA CAMANDA CONTROLLER p. 28

CONCLUSAO p. 31

Referencias Bibliograficas p. 32

Apendice A -- BaseController.cs p. 33

Apendice B -- BaseAjaxController.cs p. 34

Apendice C -- AssemblyLineController.cs p. 35

Apendice D -- AssemblyLineStageController.cs p. 37

Apendice E -- AuthenticationFilter.cs p. 39

Apendice F -- EngineerAjaxController.cs p. 41

Apendice G -- EngineerController.cs p. 42

Apendice H -- FailureModeController.cs p. 45

Apendice I -- HomeController.cs p. 47

Apendice J -- LoginPageController.cs p. 48

Apendice K -- MachineController.cs p. 50

Apendice L -- MachineGroupController.cs p. 52

Apendice M -- MachineModelController.cs p. 54

Apendice N -- MachineTypeController.cs p. 56

Apendice O -- ManufacturerController.cs p. 58

Apendice P -- ServiceOrderController.cs p. 60

Apendice Q -- SupervisorAjaxController.cs p. 61

Apendice R -- SupervisorController.cs p. 62

Apendice S -- TechnicianAjaxController.cs p. 65

Apendice T -- TechnicianController.cs p. 66

Apendice U -- UserController.cs p. 71

Anexo A -- Documento de Especificacao de Requisitos p. 73

Anexo B -- Plano de Testes p. 87

Lista de Figuras

2.1 Camadas de uma aplicacao web [Proprio Autor] . . . . . . . . . . . . . . . . p. 19

2.2 Divisao das camadas de uma aplicacao MVC [Macoratti 2008] . . . . . . . . p. 20

2.3 Estrutura do Framework .NET [ClawHammer 2006] . . . . . . . . . . . . . p. 21

4.1 Estrutura de Diretorios de uma Aplicacao Monorail. [Propria Autoria] . . . . p. 29

11

INTRODUCAO

As industrias no PIM (Polo Industrial de Manaus) tem se adaptado ao novo conceito de

manutencao como funcao estrategica com o objetivo de aumentar a disponibilidade de seus

equipamentos e instalacoes, e consequentemente garantir boa produtividade.

A gestao de manutencao utiliza indicadores gerados de manutencoes ja realizadas, para fu-

turo planejamento da estrategia de manutencao. Para o acesso a estes indicadores, o gestor ne-

cessita de alguns dados provenientes de manutencoes ocorridas por motivo de parada de equipa-

mentos. De acordo com a analise dos indicadores, a tendencia e o gestor adequar as estrategias

de manutencao para que diminuam as falhas, resultando em aumento da disponibilidade dos

equipamentos utilizados na producao. Porem, para que o gestor obtenha estes indicadores, e

necessaria uma coleta de informacoes referentes as manutencoes, o que naturalmente resulta na

necessidade de ferramentas para o auxılio do gestor.

Justificativa

Muitas empresas, utilizam softwares nao especializados para a geracao e analise dos indi-

cadores necessarios para a engenharia de manutencao, como planilhas eletronicas. Devido a

esta limitacao, as atividades relacionadas a engenharia de manutencao se torna mais lentas,

pois muito tempo e desperdicado com a preparacao destes indicadores. Com a tecnologia

disponıvel atualmente e observando esta dificuldade, surgiram alguns softwares para gestao

de manutencao, os quais sao utilizados em algumas industrias. Porem, ainda existem algumas

lacunas com relacao a automatizacao dos processos executados pela engenharia de manutencao.

Observando o cenario atual, percebe-se que ha necessidade nao so de softwares para gestao de

manutencao, mas sim de sistemas integrados onde haja uma interacao entre toda equipe de

manutencao.

12

Objetivos

Objetivo Geral

Contribuir com o desenvolvimento de um sistema para auxiliar a gestao de manutencao em

industrias no Polo Industrial de Manaus.

Objetivos Especıficos

• Aplicar tecnicas de coleta e analise de requisitos;

• Contribuir com a elaboracao da modelagem do sistema utilizando linguagem UML;

• Implementar o modulo Controller;

• Elaborar rotinas de testes internos para validar as funcionalidades do Modulo;

• Integrar o modulo Controller com o modulo View e o modulo Model;

• Elaborar casos de testes para validar o modulo Controller ja integrado;

Estrutura do Trabalho

Este trabalho esta organizado em 4 capıtulos. No capıtulo 1 e iniciado o desenvolvimento

do trabalho com o embasamento teorico sobre manutencao industrial. Nele, sao apresentados

conceitos basicos sobre manutencao, assim como a evolucao da mesma na industria mundial.

O capıtulo 2 aborda os modelos de desenvolvimento de softwares comerciais, as principais

tecnologias disponıveis e as caracterısticas de cada uma.

No capıtulo 3 e apresentada a metodologia utilizada no desenvolvimento deste projeto de

forma a explicar cada etapa do mesmo descrevendo as principais atividades, como estas foram

executadas e as ferramentas utilizadas.

No capıtulo 4 e apresentado o desenvolvimento da camada Controller, sendo esta camada o

foco deste trabalho, descrevendo a estrutura da camada, seu funcionamento basico e a aplicacao

da mesma no projeto.

Por fim, e apresentada a conclusao deste trabalho com os resultados do projeto e como este

pode ser melhorado em trabalhos futuros.

13

1 MANUTENCAO INDUSTRIAL

1.1 Historico

Durante todo o processo de crescimento da insdustria, existiram alguns marcos quando

falamos de manutencao.

Aproximadamente ate o ano de 1914, dentro do processo industrial, a manutencao tinha

uma importancia secundaria e nao existiam equipes de manutencao dentro das industrias. Todas

as atencoes eram voltadas para a producao e a mesma era explorada ate o acontecimento de uma

falha. Este cenario mudou a partir da primeira guerra mundial, quando as industrias passaram a

criar equipes responsaveis por efetuar a manutencao corretiva. Para a epoca, devido a pequena

demanda de servicos comparando com as demandas atuais, a equipe de manutencao corretiva

era suficiente para garantir a boa producao da industria.

Apos os anos 30, com o aumento da demanda de servicos, a tolerancia a falhas passou a

diminuir. Isto levou as grandes empresas a criarem um departamento especıfico de manutencao

responsavel por, nao so corrigir mas tambem evitar as falhas. A partir de entao, a manutencao

passou a ser encarada como uma necessidade dentro das industrias, o que reflete ate os dias de

hoje.

A partir de 1966, as industrias passaram a estudar melhores formas de executar a manutencao

com o objetivo de diminuir o custo das manutencoes e aumentar o tempo de producao. Foi

quando comecaram a surgir os indicativos de manutencao que eram resultados de analises das

manutencoes ja executadas.

Estes indicativos ainda sao estudados e utilizados na insdustria atual e sao considerados ex-

tremamente necessarios para que a gestao de manutencao possa atuar com eficiencia e procurar

sempre melhorar a forma como e feito o trabalho de manutencao. [Bonifacio 2005]

14

1.2 Tipos de Manutencao

A manutencao industrial pode ser classificada de acordo com a sua forma de intervencao.

Dentre as diversas classificacoes de manutencao, destacam-se as seguinte:

• Manutencao Corretiva

• Manutencao Preventiva

• Manutencao Preditiva

• Manutencao Detectiva

Neste trabalho seram abordadas apenas as manutencoes corretiva, preventiva e preditiva.

1.2.1 Manutencao Corretiva

“A manutencao corretiva e a atuacao para correcao da falha ou do desempenho menor que

o esperado” [Nascif 2001]. Ou seja, nao ha necessidade de haver a parada de uma maquina

para que haja uma intervencao corretiva. De acordo com Kardec e Nascif [Nascif 2001] a

manutencao corretiva ainda pode ser classificada em manutencao corretiva planejada e manutencao

corretiva nao planejada.

A manutencao corretiva nao planejada, e uma manutencao de alto custo, pois geralmente

exige um tempo maior para a mobilizacao da equipe de manutencao. Alem disso, quando

ocorrem falhas inesperas, a maquina pode sofrer danos maiores devido a uma pequena falha.

Logo, toda empresa busca a eliminacao de manutencoes corretivas nao planejadas.

A manutencao corretiva planejada e bem menos custosa que a nao planejada por muitos

fatores. Segundo Kardec e Nascif [Nascif 2001], a manutencao corretiva planejada ocorre de-

vido um desempenho abaixo do esperado ou devido a um acompanhamento preditivo. Porem,

a manutencao corretiva planejada nao precisa ocorrer imediatamente apos uma das cituacoes

colocadas. A gerencia pode optar por aguardar o acontecimento da falha, o que nao muda a

caracterıstica da manutencao, pois geralmente a equipe de manutencao faz algum tipo de plane-

jamento para quando a falha ocorrer.

1.2.2 Manutencao Preventiva

Como o proprio nome ja diz, a manutencao preventiva tem como objetivo garantir a prevencao

contra ocorrencia de falhas. Este tipo de manutencao busca evitar a manutencao corretiva.

15

O principal indicador da manutencao preventiva e o tempo, pois este tipo de manutencao

se basea em estatısticas e muitas vezes em informacoes disponibilizadas pelos fabricantes dos

equipamentos utilizados na industria. Ou seja, determinadas lubrificacoes ou troca de pecas de-

vem ser feitas com uma determinada frequencia para garantir o bom funcionamento do equipa-

mento. Kardec e Nascif [Nascif 2001] define manutencao preventiva como: “a atuacao real-

izada de forma a reduzir ou evitar a falha ou queda no desempenho, obedecendo a um plano

previamente elaborado, baseado em intervalos definidos de tempo”.

1.2.3 Manutencao Preditiva

“Manutencao Preditiva e a atuacao realizada com base em modificacao de parametro de

condicao ou desempenho, cujo acompanhamento obedece a uma sistematica” [Nascif 2001].

Ou seja, a manutencao preditiva, diferente da preventiva, deixa de tomar parametros estatısticos

para avaliar parametros reais do equipamento em questao. Kardec e Nascif [Nascif 2001] ainda

defedem a ideia de que nao basta ter equipamentos apropriados para realizacao da manutencao

preditiva. Ha necessidade de equipes de manutencao bem treinadas para realizar a leitura dos

equipamentos de medicao e gerar diagnosticos precisos para definir se e ou nao e necessaria uma

intervencao corretiva planejada no equipamento avaliado. Este tipo de manutencao envolve um

custo inicial maior para implantacao dos aparelhos de medicao nos equipamentos que serao

monitorados, porem o retorno e gratificante. Na manutencao preventiva por exemplo, existe a

possibilidade de haver gastos desnecessarios realizando troca de pecas que na verdade ainda

estao em perfeitas condicoes de uso.

A manutencao preditiva, se bem aplicada, chega a ser mais economica que a manutencao

preventiva pois as manutencoes corretivas so sao realmente executadas quando e detectada a

necessidade da troca.

1.3 Engenharia de Manutencao

A manutencao convencional tem como alvo o efeito dos problemas, ou seja, ela simples-

mente age com base nos efeitos de um problema, muitas vezes sem determinar a causa do

mesmo. A engenharia de manutencao propoe acabar com problemas descobrindo e atacando di-

retamente a causa destes. Segundo Kardec e Nascif [Nascif 2001], engenharia de manutencao e

deixar de consertar equipamentos continuamente, melhorar padroes e sistematicas para resolucao

de problemas e participar tecnicamente das compras de equipamentos.

16

A engenharia de manutencao, alem de utilizar tecnicas preventivas, preditivas e detectivas,

utiliza alguns indicadores para que possa ser avaliado o estado atual do processo em questao e

implementar melhorias com relacao aos metodos de manutencao.

1.3.1 Indicadores de Desempenho

O principal objetivo dos indicadores de desempenho em uma industria e avaliar a confi-

abilidade dos equipementos ou linhas de producao desta industria. Segundo Kardec e Nascif

[Nascif 2001], a confiabilidade e a probalidade que um sistema (equipamento, linha de mon-

tagem, etc.), possa desempenhar sua funcao de forma esperada, por um intervalo de tempo

estabelecido. Neste trabalho serao abordados tres indicadores, os quais sao considerados os

mais relevantes. Eles sao o MTBF (Mean Time Between Failure), o MTTR (Mean Time To

Repair) e o DownTime.

1.3.1.1 MTBF (Mean Time Between Failure)

O MTBF e o tempo medio entre falhas, ou seja, e a media aritmetica dos tempos em que

um determinado equipamento esteve em funcionamento apos a ocorrencia de uma falha. Logo,

considerando CF o perıodo entre a correcao de uma falha e a ocorrencia da proxima falha e

QMC a quantidade de manutencoes corretivas ocorridas, podemos calcular o MTBF atraves da

equacao 1.1.

MT BF = ∑CF∑QMC

(1.1)

1.3.1.2 MTTR (Mean Time To Repair)

O MTTR (Mean Time To Repair) tempo media para reparo e a media aritmetica dos tempos

de reparo de um sistema, de um equipamento ou item, ou seja, aponta a media dos tempos

que a equipe de manutencao leva para repor a maquina em condicoes de operar, desde a falha

ate o reparo ser dado como concluıdo e a maquina ser aceita como em condicoes de operar

[Filho 2006]. Sendo T R o tempo de reparo e QMC a quantidade de manutencoes corretivas, o

MTTR de pode ser calculado atraves da equacao 1.2.

MT T R = ∑T R∑QMC

(1.2)

17

1.3.1.3 DownTime

O DownTime, tambem conhecido como MFOT (Mean Force Outage Time), e o tempo total

de uma parada devido a uma falha. Ou seja, e o perıodo entre a deteccao de uma falha e o

reinıcio da operacao do equipamento em questao.

18

2 TECNOLOGIAS PARA DESENVOLVIMENTO DE SOFTWARE

Podemos classificar os softwares comerciais basicamente em dois tipos: softwares para

desktop, os quais interagem diretamento com o sistema operacional, e softwares para web, os

quais sao executados em um servidor web e visualizados em um navegador.

A principal diferenca entre estes dois modelos de software esta na maneira como o software

e executado, porem este pequeno detalhe traz algumas vantagens e desvantagens para cada

modelo.

Os sistemas para desktop, interagem de forma mais natural com o sistema operacional po-

dendo utilizar inumeras funcionalidades oferecidas pelo mesmo como acesso aos perifericos

(porta serial, portas usb, etc.) atraves dos seus respectivos drivers e outras funcionalidades do

proprio sistema. Atraves desta interface com o sistema operacional, os sistemas para desk-

top tambem podem utilizar recursos de rede utilizando as API‘s do sistema para comunicacao

atraves do protocolo TCP/IP, UDP, etc.

Devido a estas caracterısticas, geralmente os softwares para industria, onde e necessaria

a comunicacao com muitos dispositivos externos, sao desenvolvidos neste modelo. Porem

quando falamos de sistemas integrados, onde muitos usuarios interagem atraves do sistema,

ha um esforco muito grande para o desenvolvimento da camada de rede, sendo necessario criar

pelo menos dois softwares distintos, o software servidor e o software cliente.

Ja os sistemas desenvolvidos para web, disfrutam das funcionalidades oferecidas pelo nave-

gador para utilizar os recursos de rede. Os navegadors sao aplicacoes para desktop que utilizam

as funcionalidades do sistema operacional para se comunicar com um servidor web atraves do

protocolo HTTP (Hypertext Transfer Protocol). Logo, os sistemas para web nao precisam con-

ter camadas de rede em sua estrutura, o que resulta em um ganho consideravel de tempo no

desenvolvimento de aplicacoes deste tipo. Devido a esta caracterıstica, as aplicacoes web sao

cada vez mais comuns em nosso cotidiano, principalmente em sistemas integrados.

19

2.1 Aplicacoes Web

Uma aplicacao web e composta pelo menos por tres camadas mais o banco de dados con-

forme a Figura 2.1.

Figura 2.1: Camadas de uma aplicacao web [Proprio Autor]

A camada de apresentacao e responsavel por exibir os dados processados ao usuario, assim

como disponibilizar um interface para que o mesmo navegue atraves da aplicacao. A camada

de negocios e uma das principais camadas e e responsavel por todo tratamente e processamento

dos dados para disponibiliza-los para a camada de apresentacao. A camada de acesso ao banco

e uma camada intermediaria que interage diretamente com o banco de dados e oferece uma

interface para a camada de negocios acessar os dados do banco. E por fim existe o banco de

dados que de fato armazena as informacoes utilizadas pela aplicacao.

Para o desenvolvimento de cada camada, existem tecnologias que proporcionam determi-

nadas facilidades. Por isso, e muito comum que sistemas web utilizem inumeras tecnologias

distintas para executar suas tarefas, cada uma proporcionando uma determinada facilidade para

o desenvolvedor.

A forma na qual estas camadas estao organizadas, depende diretamente da implementacao

da aplicacao. Porem existem padroes de projetos que propoem a organizacao destas camadas de

forma a separa-las em modulos. Um dos padroes que tem se destacado ultimamente e o padrao

MVC (Model-View-Controller).

O padrao MVC pode ser implementado com qualquer linguagem de programacao utilizada

na web. Geralmente, ja existem Frameworks prontos que implementam o padrao, facilitando

o desenvolvimento destas aplicacoes de forma que o desenvolvedor nao precisa concentrar

20

esforcos para codigos fora do escopo da aplicacao em questao.

Os frameworks mais utilizados sao o Cake para linguagem PHP, o Ruby On Rail’s para

linguagem Ruby e atualmente, tem se destacado muito, o MonoRail para ASP.NET.

2.2 Padrao MVC

O padrao MVC e um modelo de tres camadas: Modelo, Visualizacao e Controle. A camada

de modelo (Model) e composta pela logica de negocios e a logica de acesso ao banco de dados.

A camada de visualizacao (View) e responsavel pela logica de apresentacao e a camada de

controle (Controller) e responsavel pela integracao das duas camadas, Visualizacao e Modelo.

A figura 2.2 ilustra a divisao das camadas do modelo MVC.

Figura 2.2: Divisao das camadas de uma aplicacao MVC [Macoratti 2008]

2.3 Framework.NET

Segundo Lotar [Lotar 2007], o Framework .NET e um componente de software que suporta

a execucao e o desenlvimento de uma nova geracao de aplicacoes e XML web services. Ja

Cembranelli [Cembranelli 2003], diz que o framework .NET e um conjunto de ferramentas para

criar, construir e testar aplicacoes .NET e consiste basicamente de dois componentes principais:

Common Language Runtime (CLR) e as bibliotecas de classe Base Class Library (BCL). A BCL

oferece recursos para uma serie de necessidades de desenvolvimento, como entrada e saıda de

arquivo, banco de dados, XML, etc. A CLR e um ambiente de tempo de execucao (runtime) que

realiza tarefas, tais como: gerenciamento de memoria, coleta de lixo, seguranca, tratamento de

21

erro, controle de versao e suporte de instalacao. A principal tarefa da CLR e realizar a interface

entre aplicacoes .NET e o sistema operacional.

2.3.1 Estrutura

De acordo com a figura 2.3, o framework .NET pode ser dividido em 5 (cinco) camadas:

Figura 2.3: Estrutura do Framework .NET [ClawHammer 2006]

A primeira camada e composta pelas linguagens de programacao suportadas pela CLS

(Common Language Specification).

A segunda camada e composta pelas bibliotecas de classe utilizadas para desenvolver aplica-

tivos .NET. As duas bibliotecas ja disponibilizadas pelo framework sao: Windows Form para

aplicacoes desktop e a Web Forms para aplicacoes ASP.NET. E importante comentar que nao e

obrigatorio o uso destas bibliotecas para o desenvolvimento de aplicacoes .NET. Podem ser uti-

lizados outros frameworks auxiliares como por exemplo: O Microsoft MVC Framework, Castle

Active Record, Castle MonoRail, entre outros.

A terceira camada e responsavel pelo acesso a bases dados, ou seja, sao ferramentas disponi-

bilizadas pelo framework para trabalhar com o acesso a base de dados, sejam estas, bancos de

dados ou arquivos XML (Extensible Markup Language).

A quarta camada contem a BCL (Base Class Library) com classes basicas para desen-

volvimento de aplicacoes .NET. Esta biblioteca e necessaria para o desenvolvimento de qual-

22

quer aplicacao .NET, seja esta utilizada direta ou indiretamente. Todos os frameworks para

desenvolvimento de aplicacoes .NET disponibilizados utilizam a BCL para execucao de tarefas

basicas de interface com o sistema operacional.

A quinta camada e composta apenas pela CLR que e responsavel pela interpretacao das

aplicacoes .NET e a realizacao da interface entre as aplicacoes e o sistema operacional.

Abaixo destas cinco camadas esta o sistema operacional, que interage diretamente com a

CLR para a execucao de codigos nativos.

2.3.2 Caracterısticas

As caracterısticas mais relevantes do framework .NET, segundo Turtchi [Turtschi 2002],

sao:

• Multilinguagem - Uma aplicacao ASP.NET, pode ser desenvolvida em varias linguagens

diferentes, desde que estas estejam dentro do padrao determinado pela CLS (Common

Language Specification). Isto e possıvel pois o framework .NET possui uma linguagem

intermediaria chamada MSIL (Microsoft Intermediate Language), a qual e gerada durante

o processo de construcao da aplicacao;

• Independencia de Plataforma - a MSIL e independente de hardware e sistema opera-

cional, possibilitando a geracao de codigos de maquina para varias plataformas nos mais

variados tipos de arquiteturas, desde que exista um framework apropriado para a plataforma

.NET [Turtschi 2002];

• Possui Gerenciamento automatico de memoria - todo codigo que e executado no CLR

(Common Language Runtime), e chamado de codigo gerenciado, pois o mesmo con-

trola toda a memoria trazendo muitas vantagens, como a integracao entre as linguagens

e tratamento de excecoes. Esta facilidade deve-se ao fato de que o .NET, trata-se tudo

como objeto. Sendo assim, a Microsoft mudou a forma de como a arquitetura trata os

objetos carregados, passando a usar o conceito de garbage collection (coletor de lixo)

[Turtschi 2002];

• Suporte a padroes abertos - e compreensıvel que ocorra a abertura de padroes para que

a tecnologia nao fique isolada, permitindo assim que sua tecnologia seja incorporada por

outras, podendo ser estendida alem dos proprios domınios [Turtschi 2002];

23

• Seguranca - a distribuicao de aplicacoes baseadas em componentes exige seguranca. A

Microsoft mudou a maneira de controlar a seguranca da aplicacao como fazia anterior-

mente com os seus sistemas operacionais, com controles baseados em usuarios, e resolveu

seguir a mesma metodologia empregada no Java, onde o codigo que nao e confiavel e ex-

ecutado, mas sem acesso aos recursos crıticos do sistema [Turtschi 2002];

• Performance e Escalabilidade - um grande ganho para o desenvolvimento e proporcionado

com a separacao do codigo, dados e apresentacao visual para o usuario. Isto garante uma

melhor performance da aplicacao e gera uma escalabilidade muito maior. [Turtschi 2002]

Apesar da utilizacao da linguagem C# como linguagem de programacao padrao para o pro-

jeto, um dos fatores cruciais para escolha desta tecnologia foi o suporte a integracao de varias

linguagens de programacao em um mesmo software. Isto e possivel gracas a padronizacao

de tipos definida pela CLS (Common Language Specification). A CLS, segundo Cembranelli

[Cembranelli 2003] e uma especificacao que estabelece as regras que um compilador deve

seguir para que seu codigo compilado seja capaz de ser executado dentro da CLR. Dessa

maneira, o codigo compilado de diferentes linguagens de programacao pode ser executado den-

tro do mesmo ambiente de tempo de execucao. Este e um fator muito interessante, tendo em

vista que cada linguagem de programacao possui caracterısticas que podem facilitar o desen-

volvimento do projeto.

2.4 ASP.NET

O ASP.NET e um modelo de desenvolvimento unificado que inclui os servicos necessarios

para desenvolver aplicacoes web com o mınimo de codigo. Ou seja, para criar uma aplicacao

web com ASP.NET, podemos utilizar inumeras classes do Framework .NET, pois o ASP.NET

faz parte dele [Lotar 2007].

Devido o modelo ASP.NET ser um modelo web, toda aplicacao ASP.NET e executada

em um servidor web e consequentemente as informacoes trafegam atraves do protocolo HTTP.

Quando uma requisicao e enviada para o servidor, o servidor executa a aplicacao correspondente

a solicitacao.

2.4.1 WebForms

O WebForms e um framework disponibilizado junto com o framework .NET pela prorpia

Microsoft que permite que as aplicacoes web possam ter um comportamento parecido com

24

o comportamento de aplicacoes para desktop. Ao haver uma resiquicao por parte do cliente

(Aplicacao Web), o servidor retorna o resultado para o prorpio formulario que enviou as requisicoes.

Este processo e chamado de “PostBack”.

2.5 Framework MonoRail

O Framework MonoRail e um framework Web para desenvolvimento de aplicacoes no

padrao MVC. Este foi desenvolvido para suprir a necessidade de frameworks MVC para .NET

o que ate entao era muito difıcil de se encontrar. Pelo fato de ser baseado em um conhecido

framework, o Ruby On Rails para linguagem ruby, o MonoRail ja e bastante utilizado por muitos

desenvolvedores web e tem mostrado um bom desempenho. Alem disso, o Monorail e com-

patıvel com o Mono, um framework .NET para sistemas Linux. Esta e uma grande vantagem

comparando o com outros frameworks que foram desenvolvidos especıficamente para o sistema

operacional Windows. Os desenvolvedores do MonoRail tiveram a preocupacao de utilizar as

funcionalidades disponıveis para os dois sistemas operacionais. Logo, pode-se desenvolver sis-

temas no padrao MVC e ainda executa-los em servidores linux que possuam o Mono.

25

3 METODOLOGIA

Para a realizacao deste trablaho, as atividades foram divididas em algumas etapas, seguindo

uma ordem cronologica. A primeira delas e a coleta e analise de requisitos da qual foi gerado

o DER 1 (ver Anexo A), seguida pela geracao de requisitos tecnicos. A partir dos requisitos

tecnicos, foi possıvel determinar quais as tecnologias que melhor se adequam as necessidades

do projeto. Atraves de pesquisas no site de busca “www.google.com.br” foram escolhidas as

tecnologias. Com todos os requisitos analisados, o escopo do projeto ja bem definido e as

tecnologias ja determinadas, o sistema foi modelado com o auxılio da ferramenta JUDE Com-

munity, uma ferramenta para criacao de diagramas UML, sendo gerados os diagramas de caso

de uso, diagramas de classe e os diagramas de sequencia.

Utilizando o SDK 2 da plataforma ASP.NET para ambiente linux, foram implementadas

as classes da camada Controller, de forma a integrar as camadas View e Model do sistema. Em

paralelo ao desenvolvimento desta camada, foram feitos testes intermediarios de integracao com

as outras camadas para garantir a confiabilidade de cada componente da camada Controller.

Apos a finalizacao de cada atividade, ou desenvolvimento de cada componente, sao feitas

as integracoes com as outras camadas e testes de caixa preta 3.

Com a finalizacao da primeira versao do prototipo, foi elaborado o plano de testes (Anexo

B) o qual foi utilizado como referencia para realizacao dos testes do prototipo.

3.1 Analise de Requisitos do Cliente

A analise de requisitos foi feita atraves de entrevistas com o Professor Marcelo Oliveira

da Universidade Paulista, o qual tambem atua como profissional na area de engenharia de

manutencao. As entrevistas foram feitas de duas formas, algumas diretamente em reunioes

1Documento de Especificacao de Requsitos2Kit para desenvolvimento de software3Testes realizados para verificar o comportamento da aplicacao em geral, sem analisar os elementos internos

de cada componente.

26

com toda equipe de desenvolvimento e outras atraves de questionarios. As primeiras entrevistas

foram feitas em formato de reunioes com a equipe, para o entendimento por parte da equipe

com relacao ao escopo do software. Apos o escopo estar bem definido, foram utilizados ques-

tionarios para a eliminacao de duvidas por parte da equipe e geracao de novos questionamentos

relacionados ao sistema. A partir dos requisitos obtidos com o cliente, estes foram separados

em requisitos funcionais e requisitos nao-funcionais.

“Os requisitos funcionais sao aqueles que descrevem o comportamento do sistema, suas

acoes para cada entrada, ou seja, e aquilo que descreve o que tem que ser feito pelo sistema.

Sao o cerebro do projeto, ja que descrevem as funcionalidades que o sistema deve dispor”.

[Nunes]

“Os requisitos nao funcionais sao aqueles que expressam como deve ser feito (nao confundir

requisitos nao funcionais com design). Em geral se relacionam com padroes de qualidade como

confiabilidade, performance, robustez, etc. Sao muito importantes, pois definem se o sistema

sera eficiente para a tarefa que se propoe a fazer ou nao. Um sistema ineficiente certamente nao

sera usado. Neles tambem sao apresentados restricoes e especificacoes de uso para os requisitos

funcionais”.[Nunes]

3.2 Geracao de Requisitos Tecnicos

Com todos os requisitos do cliente definidos, foram gerados requisitos tecnicos. Estes

requisitos definem o que precisa ser desenvolvido para que os requisitos passados pelo cliente

sejam atendidos. E tambem nesta etapa que sao definidas as tecnologias a serem utilizadas para

o desenvolvimento do projeto.

3.3 Escolha das Tecnologias

De acordo com os requisitos tecnicos ja definidos, foram escolhidas as tecnologias para

atender as necessidades do projeto. Dentre as estao estao:

• Sistema Operacional Linux - Sistema Operacional Livre e de Codigo Aberto;

• Framework .NET Mono - Pacote com compiladores, biblioteca de classes e aplicacoes

para auxılio de desenvolvimento de aplicacoes .NET em ambiente Linux;

• Framework MonoRail - Framework MVC para aplicacoes .NET;

27

• Framework ActiveRecord - Biblioteca de classes disponıveis para acesso a banco de dados

utilizando orientacao a objeto.

• MySql - Gerenciador de banco de dados Livre;

• Ferramentas para construcao de codigo em ambiente Linux - Constituıda pelo Make,

autoconfig, etc.

Estas tecnologias foram escolhidas com base nos seguintes fatores:

• Custo - Foram escolhidas tecnologias livres. Nao necessariamente de codigo aberto;

• Disponibilidade de Documentacao - Este ponto e muito importante, pois muitas tecnolo-

gias foram desconsideradas devido a falta de documentacao disponıvel;

• Maturidade da Tecnologia - Procurou-se utilizar tecnologias ja testadas e utilizadas no

mercado de desenvolvimento de software;

3.4 Modelagem do Sistema

Nesta etapa, os requisitos ja estao bem definidos, e com o auxilio de ferramentas para

modelagem UML, sao criados os diagramas de caso de uso, diagrama de classe e diagra-

mas de sequencia. Os diagramas referem-se as classes de negocio, desenvolvidas na camada

Model. O Controller, foco deste trabalho, esta associado diretamente a camda Model (Logica

de Negocios), pois o mesmo utiliza metodos das classes do model para acessar dados do banco

e fornecer informacoes a camada da View.

A camada Controller foi desenvolvida de acordo com o modelo proposto pelo framework

MVC Monorail. Devido a isso, nao foi necessaria a criacao de diagramas de classe ou sequencia

especıficos para esta camada. Logo, os diagramas nao serao contemplados nestes trabalho.

No capıtulo 4 sera mostrado o modelo utilizado para o desenvolvimento da camada.

28

4 DESENVOLVIMENTO DA CAMANDA CONTROLLER

A camada Controller e a camada central de uma aplicacao MVC. Esta camada e responsavel

por integrar a camada Model e a camada View, ou seja, a camada Controller manipula dados na

base de dados atraves do modulo Model e os disponibiliza para a camada View.

Antes de falar sobre como e feita essa integracao, e importante entender a estrutura de uma

aplicacao MVC utilizando o framework MonoRail e o fluxo da mesma.

Uma aplicacao web MVC inicia quando uma requisicao e enviada ao servidor no qual a

mesma e residente. O servidor executa a aplicacao correspondente e a mesma interpreta o

endereco da requisicao de forma a determinar qual Controller sera responsavel por atender a

requisicao. Apos a interpretacao do endereco, um objeto do modulo Controller e instanciado e

um determinado metodo e chamado. Este metodo faz o tratamento dos dados em questao e os

envia para View. A view e responsavel simplesmente por receber estes dados e formata-los de

forma a fornecer uma visualizacao dos mesmos ao usuario.

Para implementar esta interface, o framework MonoRail ja disponibiliza uma classe chamada

SmartDispatcherController a qual possui alguns atributos e metodos utilizados na comunicacao

com a camada View. Dentre os atributos utilizados, pode-se destacar o Flash e o PropertyBag,

que sao vetores que armazenam objetos e sao acessados pela camada View.

Como exemplo, no apendice J temos a classe LoginPageController, a qual e responsavel

pelo controle de acesso da aplicacao. Ao acessar a pagina de login, digitar o nome de usuario e

senha e pressionar o botao Entrar, o metodo Logon da classe LoginPageController e executado.

O mesmo utiliza o objeto User (Camada Model) para verificar se existe um usuario cadastrado

no banco de dados com o mesmo nome e a mesma senha digitada. Apos uma verificacao com

sucesso, o metodo DoLogon e executado e a tela principal da aplicacao e mostrada ao usuario

pela camada View atraves dos metodos Redirect.

Toda classe da camada Controller segue este mesmo padrao de desenvolvimento. Ao criar

a classe, cada metodo implementado deve ser responsavel por executar uma determinada tarefa

e passar os resultados para camada View.

29

Alem do entendimento deste padrao, e importante entender como e organizada a estrutura

de diretorios de uma aplicacao MonoRail, pois esta organizacao influencia diretamente em como

a camada Controller interage com a camada View.

A Figura 4.1 mostra como esta organizada uma aplicacao Monorail.

Figura 4.1: Estrutura de Diretorios de uma Aplicacao Monorail. [Propria Autoria]

Basicamente, a aplicacao e dividida em 5 diretorios principais:

• bin - E o diretorio onde sao armazenados os arquivos binarios da aplicacao. E o principal

diretorio de qualquer aplicacao ASP.NET;

• Content - Neste diretorio sao armazenados arquivos utilizados pela aplicacao, como ima-

gens, folhas de estilo, etc;

30

• Controllers - Onde sao armazenados os arquivos fonte da camada Controller. Este di-

retorio e utilizado apenas durante o desenvolvimento.

• Models - Neste diretorio ficam os arquivos fonte da camada Model. Tambem e utilizado

apenas durante o desenvolvimento.

• Views - Este diretorio contem varios outros subdiretorios os quais armazenas arquivos de

layout da camada View. Este e fundamental para o funcionamento da aplicacao. Com

excecao dos diretorios shared, macros e layouts, todos os diretorios dentro de Views sao

referentes a um controller. Por exemplo, o diretorio loginpage contem as Views rela-

cionadas com a classe da camada Controller LoginPageController.

31

CONCLUSAO

Com base nos requisitos propostos, pode-se concluir que o resultado foi satisfatorio, pois

todos os requisitos determinados como necessarios foram implementados.

Alem do prototipo funcional como resultado deste projeto, muitos conhecimentos foram

adquiridos nao so na area de desenvolvimento de sistemas web, mas tambem na area da gestao

de manutencao industrial. Logo, todos os objetivos foram alcancados.

Para trabalhos futuros, ainda existem muitas funcionalidades que podem ser implementados

e agregadas a este projeto, tendo em vista que este pode ser considerado apenas um modulo de

um sistema ainda maior contendo funcionalidades como controle de materiais utilizados na

manutencao, geracao de FMEA (Failure Mode and Effect Analysis), etc.

32

Referencias Bibliograficas

[Bonifacio 2005]BONIFaCIO, M. A. Manutencao Industrial: Uma discussao entre a relacaodos investimentos aplicados e os resultados operacionais e ambientais obtidos. Dissertacao(Mestrado) — Centro Universitario de Araraquara, Sao Paulo, 2005.

[Cembranelli 2003]CEMBRANELLI, F. ASP.NET Guia do Desenvolvedor. [S.l.: s.n.], 2003.

[ClawHammer 2006]CLAWHAMMER. Novidades do visual studio .net. Disponıvel emhttp://www.baboo.com.br/absolutenm/templates/content.asp?articleid=5002. 2006.

[Filho 2006]FILHO, G. B. Indicadores e Indices de Manutencao. [S.l.: s.n.], 2006.

[Filho 2006]FILHO, G. B. Indicadores e Indices de Manutencao. [S.l.: s.n.], 2006.

[Lafraia 2001]LAFRAIA, J. R. B. Manual de Confiabilidade, Mantenabilidade e Disponibili-dade. [S.l.: s.n.], 2001.

[Levitt 2003]LEVITT, J. Complete Guide to Preventive and Predictive Maintenance. [S.l.: s.n.],2003.

[Lotar 2007]LOTAR, A. Como Programar com ASP.NET e C#. [S.l.: s.n.], 2007.

[Macoratti 2008]MACORATTI, J. C. Padroes de projeto : O modelo mvc - model view con-troller. Disponıvel em http://www.macoratti.net/vbn mvc.htm. 2008.

[Nascif 2001]NASCIF, A. K. J. Manutencao - Funcao Estrategica. [S.l.: s.n.], 2001.

[Nunes]NUNES, B. Analise de requisitos - funcionais x nao funcionais. Disponıvel emhttp://maozinhadaweb.blogspot.com/2007/05/anlise-de-requisitos-funcionais-x-no.html.

[Siqueira 2005]SIQUEIRA, I. P. de. Manutencao Centrada na Confiabilidade - Manual deImplementacao. [S.l.: s.n.], 2005.

[Turtschi 2002]TURTSCHI. VERIFICAR. [S.l.: s.n.], 2002.

33

APENDICE A -- BaseController.cs

namespace MMS.Controllers

{

using Castle.MonoRail.Framework;

using MMS.Models;

[Layout("default"), Rescue("generalerror")]

[FilterAttribute(ExecuteEnum.BeforeAction, typeof(AuthenticationFilter))]

public abstract class BaseController : SmartDispatcherController

{

public User CurrentUser

{

get

{

User u = (User)Session["currentUser"];

if(u != null)

{

u.Refresh();

}

return u;

}

}

}/* class */

}/* namespace */

34

APENDICE B -- BaseAjaxController.cs


{


using MMS.Models;

public abstract class BaseAjaxController : SmartDispatcherController

{

public User CurrentUser

{

get

{

User u = (User)Session["currentUser"];

if(u != null)

{

u.Refresh();

}

return u;

}

}

}/* class */

}/* namespace */

35

APENDICE C -- AssemblyLineController.cs


{

using System;


using MMS.Models;

public class AssemblyLineController : BaseController

{

public void Show(int id)

{

}

public void Edit(int id)

{

PropertyBag["assemblyline"] = AssemblyLine.FindById(id);

}

public void New()

{

}

public void List()

{

PropertyBag["assemblylines"] = AssemblyLine.FindAll();

}

/* CRUD Methods */

public void Create([DataBind("assemblyline")] AssemblyLine aLine)

{

try

{

aLine.Create();

}

catch (Exception e)

{

Flash["error"] = e;

}

RedirectToAction("list");

36

}

public void Update([DataBind("assemblyline")] AssemblyLine al)

{

try

{

al.Update();

}

catch (Exception e)

{

Flash["error"] = e.Message;

}


}

public void Delete(int id)

{

try

{

AssemblyLine line = AssemblyLine.FindById(id);

line.Delete();

}

catch (Exception e)

{


}


}

}

}

37

APENDICE D -- AssemblyLineStageController.cs


{

using System;


using MMS.Models;

public class AssemblyLineStageController : BaseController

{

/* View Methods */


{

}


{


PropertyBag["assemblylinestage"] = AssemblyLineStage.FindById(id);

}

public void New()

{


PropertyBag["assemblylinestages"] = AssemblyLineStage.FindAll();

}

public void List()

{

PropertyBag["assemblylinestages"] = AssemblyLineStage.FindAll();

}

/* CRUD Methods */

public void Create([DataBind("assemblylinestage")] AssemblyLineStage assemblyLineStage)

{

try

{

assemblyLineStage.Create();

}

catch (Exception e)

38

{

Flash["error"] = e;

}


}

public void Update([DataBind("assemblylinestage")] AssemblyLineStage stage)

{

try

{

stage.Update();

}

catch (Exception e)

{


}


}


{

try

{

AssemblyLineStage stage = AssemblyLineStage.FindById(id);

stage.Delete();

}

catch (Exception e)

{


}


}

}

}

39

APENDICE E -- AuthenticationFilter.cs


{

using System;


using MMS.Models;

public class AuthenticationFilter : IFilter

{

public bool Perform(ExecuteEnum exec, IRailsEngineContext context, Controller controller)

{

/*

* Checa a existencia da session de usuario

* */

if(context.Session.Contains("currentUser"))

{

/*

* Autentica o usuario se ainda n~ao estiver autenticado

* */

if(!context.Session.Contains("AUTHENTICATION"))

{

Authentication newauth = new Authentication();

newauth.AuthenticationID = CreateAuthenticationID(context);

newauth.User = (User)context.Session["currentUser"];

newauth.LastAccess = DateTime.Now;

newauth.Create();

context.Response.CreateCookie("AUTH_ID", newauth.AuthenticationID, DateTime.Now.AddDays(1));

context.Session["AUTHENTICATION"] = newauth;

}

return true;

}

else

{

Authentication auth = Authentication.FindByAuthenticationID(context.Request.ReadCookie("AUTH_ID"));

40

if(auth != null)

{

context.Session["currentUser"] = auth.User;

context.Session["AUTHENTICATION"] = auth;

return true;

}

}

context.Flash["warning"] = "Usuario n~ao autenticado! Favor entre com o login e a senha";

context.Response.Redirect("loginpage", "index");

return false;

}

public string CreateAuthenticationID(IRailsEngineContext context)

{

string id = context.Request.UserHostAddress;

DateTime now = DateTime.Now;

id += "-" + now.Minute + "-" + now.Second + "-" + now.Ticks;

return id;;

}

}

}

41

APENDICE F -- EngineerAjaxController.cs


{

using System;


using MMS.Models;

public class EngineerAjaxController : BaseAjaxController

{

public void ServiceOrderList(string status)

{

if(status == ServiceOrder.STATUS_CLOSED ||

status == ServiceOrder.STATUS_CANCELED)

{

DateTime begin = DateTime.Now.AddDays(-3);

PropertyBag["serviceorders"] = ServiceOrder.FindByFilter(null, status, begin, DateTime.Now);

}

else

{

PropertyBag["serviceorders"] = ServiceOrder.FindOpened();

}

RenderView("serviceorderlist.vm");

}

}

}

42

APENDICE G -- EngineerController.cs


{

using System;

using System.Collections.Generic;


using MMS.Models;

using NHibernate;

public class EngineerController : BaseController

{

public void Index()

{

RedirectToAction("serviceorderlist");

}


{


if(status != ServiceOrder.STATUS_CLOSED &&

status != ServiceOrder.STATUS_OPENED &&

status != ServiceOrder.STATUS_CANCELED)

{


}


}

public void AddServiceOrder()

{

PropertyBag["machines"] = Machine.FindAll();

}

public void Open([DataBind("serviceorder")] ServiceOrder so)

{

try

{

so.RequestUser = CurrentUser;

so.Open();

43


}

catch(Exception e)

{

Flash["error"] = "Aconteceu um erro inesperado. Por favor comunique a equipe de desenvolvimento!";

MMSLogger.Log(CurrentUser, e);

RedirectToAction("addserviceorder");

}

}

public void ViewServiceOrder(string id)

{

try

{

ServiceOrder so;

int soId = Convert.ToInt32(id);

if(soId <= 0)

throw new FormatException("ServiceOrder.Id menor que 0(Zero)");

so = ServiceOrder.FindById(soId);

PropertyBag["report"] = so.Report;

}

catch(ObjectNotFoundException nfe)

{

MMSLogger.Log(CurrentUser, nfe);

}

catch(FormatException fe)

{

Flash["error"] = "Erro: O formato da url digitada e invalido";

Flash["warning"] = "Por favor, evitar utilizar a barra de endereco "

Flash["warning"] += "para acessar funcionalidades do sistema!";

MMSLogger.Log(CurrentUser, "Usuario digitou uma url em formato invalido!");

MMSLogger.Log(CurrentUser, fe);


}

catch(Exception e)

{


Flash["error"] = "Ocorreu uma falha inesperada. "

Flash["error"] = "Favor comunicar a equipe de desenvolvimento do sistema!";


}

}

public void ViewMachine(int id)

{

if(id == 0)


44

PropertyBag["machine"] = Machine.FindById(id);

}

public void MTBF(DateTime iDate, DateTime eDate)

{

IList<IndexMachineInformation> l = new List<IndexMachineInformation>();

Machine[] machines = Machine.FindAll();

DateTime begin = iDate;

DateTime end = eDate;

if(begin.Year == 1)

{

//begin = DateTime.Now.AddDays(-10);

begin = DateTime.Now.Date;

}

if(end.Year == 1)

{

//end = DateTime.Now.AddDays(10);

end = DateTime.Now.Date;

}

foreach(Machine machine in machines)

{

l.Add(MachineStopLog.GetIndexFromMachine(machine, begin, end));

PropertyBag["information"] = l;

}

}

} // class

} // namespace

45

APENDICE H -- FailureModeController.cs


{

using System;


using MMS.Models;

public class FailureModeController : BaseController

{

/* View Methods */


{

}


{

PropertyBag["failuremode"] = FailureMode.FindById(id);

}

public void New()

{

}

public void List()

{

PropertyBag["failuremodes"] = FailureMode.FindAll();

}

/* CRUD Methods */

public void Create([DataBind("failuremode")] FailureMode failureMode)

{

try

{

failureMode.Create();

}

catch (Exception e)

{


}

46


}

public void Update([DataBind("failuremode")] FailureMode mode)

{

try

{

mode.Update();

}

catch (Exception e)

{

Flash["error"] = "N~ao foi possıvel atualizar os dados do modo de falha!";

Flash["exception"] = e;

}


}


{

try

{

FailureMode mode = FailureMode.FindById(id);

mode.Delete();

}

catch (Exception e)

{

Flash["error"] = "N~ao foi possıvel remover o modo de falha!";


}


}

}

}

47

APENDICE I -- HomeController.cs


{

using System;


public class HomeController : BaseController

{

public void Index()

{

}

}

}

48

APENDICE J -- LoginPageController.cs


{

using System;


using MMS.Models;

[Layout("login"), Rescue("generalerror")]

public class LoginPage : SmartDispatcherController

{

public void Index()

{

}

public void Logon(string login, string password)

{

User u = User.FindByLoginInfo(login, password);

if(u != null)

{

Session["currentUser"] = u;

DoLogon(u);

return;

}

Flash["warning"] = "Senha ou Login incorretos!";

RedirectToAction("index");

}

public void DoLogon(User u)

{

string controller = "loginpage";

if(u.Profile == "SU")

controller = "supervisor";

else if(u.Profile == "TE")

controller = "technician";

else if(u.Profile == "EN")

controller = "engineer";

else if(u.Profile == "AD")

controller = "administrator";

49

else

controller = "login";

Redirect(controller, "index");

}

public void Logoff()

{

if(Session.Contains("AUTHENTICATION"))

{

Authentication auth = (Authentication)Session["AUTHENTICATION"];

if(auth != null)

{

try

{

auth.Delete();

}

catch(Exception e)

{

Flash["error"] = "N~ao foi possıvel remover a autenticac~ao do usuario do banco!";


}

}

}

Session.Clear();

RedirectToAction("index");

}

}

}

50

APENDICE K -- MachineController.cs


{

using System;


using MMS.Models;

public class MachineController : BaseController

{

/* View Methods */


{


}


{


PropertyBag["manufacturers"] = Manufacturer.FindAll();

PropertyBag["machinetypes"] = MachineType.FindAll();

PropertyBag["machinegroups"] = MachineGroup.FindAll();


}

public void New()

{





}

public void List()

{


}

/* CRUD Methods */

51

public void Create([DataBind("machine")] Machine machine)

{

try

{

machine.Create();

}

catch (Exception e)

{

Flash["error"] = e;

}


}

public void Update([DataBind("machine")] Machine machine)

{

try

{

machine.Update();

}

catch (Exception e)

{


}


}


{

try

{

Machine m = Machine.FindById(id);

m.Delete();

}

catch (Exception e)

{


}


}

}

}

52

APENDICE L -- MachineGroupController.cs


{

using System;


using MMS.Models;

public class MachineGroupController : BaseController

{

/* View Methods */


{

}


{

PropertyBag["machinegroup"] = MachineGroup.FindById(id);

}

public void New()

{

}

public void List()

{


}

/* CRUD Methods */

public void Create([DataBind("machinegroup")] MachineGroup group)

{

try

{

group.Create();

}

catch (Exception e)

{

Flash["error"] = e;

}

53


}

public void Update([DataBind("machinegroup")] MachineGroup group)

{

try

{

group.Update();

}

catch (Exception e)

{


}


}


{

try

{

MachineGroup group = MachineGroup.FindById(id);

group.Delete();

}

catch (Exception e)

{


}


}

}

}

54

APENDICE M -- MachineModelController.cs


{

using System;


using MMS.Models;

public class MachineModelController : BaseController

{

/* View Methods */


{

}


{


PropertyBag["machinemodel"] = MachineModel.FindById(id);

}

public void New()

{


}

public void List()

{

PropertyBag["machinemodels"] = MachineModel.FindAll();

}

/* CRUD Methods */

public void Create([DataBind("machinemodel")] MachineModel model)

{

try

{

model.Create();

}

catch (Exception e)

{

55

Flash["error"] = e;

}


}

public void Update([DataBind("machinemodel")] MachineModel model)

{

try

{

model.Update();

}

catch (Exception e)

{


}


}


{

try

{

MachineModel model = MachineModel.FindById(id);

model.Delete();

}

catch (Exception e)

{


}


}

}

}

56

APENDICE N -- MachineTypeController.cs


{

using System;


using MMS.Models;

public class MachineTypeController : BaseController

{

/* View Methods */


{

}


{

PropertyBag["machinetype"] = MachineType.FindById(id);

}

public void New()

{

}

public void List()

{


}

/* CRUD Methods */

public void Create([DataBind("machinetype")] MachineType type)

{

try

{

type.Create();

}

catch (Exception e)

{


}

57


}

public void Update([DataBind("machinetype")] MachineType type)

{

try

{

type.Update();

}

catch (Exception e)

{


}


}


{

try

{

MachineType type = MachineType.FindById(id);

type.Delete();

}

catch (Exception e)

{


}


}

}

}

58

APENDICE O -- ManufacturerController.cs


{

using System;


using MMS.Models;

public class ManufacturerController : BaseController

{

/* View Methods */


{

}


{

PropertyBag["manufacturer"] = Manufacturer.FindById(id);

}

public void New()

{

}

public void List()

{


}

/* CRUD Methods */

public void Create([DataBind("manufacturer")] Manufacturer manufacturer)

{

try

{

manufacturer.Create();

}

catch (Exception e)

{

Flash["error"] = e;

}

59


}

public void Update([DataBind("manufacturer")] Manufacturer m)

{

try

{

m.Update();

}

catch (Exception e)

{


}


}


{

try

{

Manufacturer m = Manufacturer.FindById(id);

m.Delete();

}

catch (Exception e)

{


}


}

}

}

60

APENDICE P -- ServiceOrderController.cs


{

using System;


using MMS.Models;

public class ServiceOrderController : BaseController

{

public void ViewOpen(int requestId)

{


}

public void CloseViewPredictive(int id)

{

}

public void CloseViewPreventive(int id)

{

}

public void CloseViewCorrective(int id)

{

}

public void ViewCancel()

{

}

}// class

}

61

APENDICE Q -- SupervisorAjaxController.cs


{

using System;


using MMS.Models;

public class SupervisorAjaxController : BaseAjaxController

{


{



{


PropertyBag["serviceorders"] = ServiceOrder.FindByFilter(CurrentUser,

status,

begin,

DateTime.Now);

}

else

{


ServiceOrder.STATUS_OPENED);

}


}

}

}

62

APENDICE R -- SupervisorController.cs


{

using System;


using NHibernate;

using MMS.Models;

public class SupervisorController : BaseController

{

public void Index()

{


}

public SupervisorController()

{

}


{


}


{




{


ServiceOrder.STATUS_OPENED);

}

PropertyBag["serviceorders"] = ServiceOrder.FindByFilter(CurrentUser, status);

}


{

try

{

63


if(soId <= 0)


PropertyBag["serviceorder"] = ServiceOrder.FindById(soId);

}


{


}


{


Flash["warning"] = "Por favor, evitar utilizar a ";

Flash["warning"] += "barra de endereco para acessar funcionalidades do sistema!";




}

catch(Exception e)

{


Flash["error"] = "Ocorreu uma falha inesperada. ";

Flash["error"] += "Favor comunicar a equipe de desenvolvimento do sistema!";


}

}


{

try

{


so.Open();


}

catch(Exception e)

{

Flash["error"] = "Aconteceu um erro inesperado. ";

Flash["error"] += "Por favor comunique a equipe de desenvolvimento!";



}

}

public void Cancel(string id)

{

try

{

64


if(soId <= 0)


ServiceOrder so = ServiceOrder.FindById(soId);

so.Cancel();

}


{


}


{


Flash["warning"] = "Por favor, evitar utilizar a";




}

catch(Exception e)

{


Flash["error"] = "Ocorreu uma falha inesperada. ";

Flash["error"] += Favor comunicar a equipe de desenvolvimento do sistema!";

}


}

}/* class */

}/* namespace */

65

APENDICE S -- TechnicianAjaxController.cs


{

using System;


using MMS.Models;

public class TechnicianAjaxController : BaseAjaxController

{


{



{


PropertyBag["serviceorders"] = ServiceOrder.FindByFilter(null,

status,

begin,

DateTime.Now);

}

else

{


}


}

}

}

66

APENDICE T -- TechnicianController.cs


{

using System;


using NHibernate;

using MMS.Models;

public class TechnicianController : BaseController

{

public TechnicianController()

{

}

public void Index()

{


}


{





{


}


}

public void FailureHistory()

{

string maintenanceType = ServiceOrder.MAINTENANCE_TYPE_CORRECTIVE;

PropertyBag["reports"] = MaintenanceReportLog.FindCorrectiveFilter(DateTime.Now,DateTime.Now,

maintenanceType);



67

PropertyBag["users"] = User.FindAll();

}

public void FindReportLog()

{


string maintenanceType = ServiceOrder.MAINTENANCE_TYPE_CORRECTIVE;

PropertyBag["reports"] = MaintenanceReportLog.FindCorrectiveFilter(begin,

DateTime.Now,

maintenanceType);

}


{

try

{

ServiceOrder so;


if(soId <= 0)


so = ServiceOrder.FindById(soId);


}


{


}


{


Flash["warning"] = "Por favor, evitar utilizar a barra de ";

Flash["warning"] += "endereco para acessar funcionalidades do sistema!";




}

catch(Exception e)

{


Flash["error"] = "Ocorreu uma falha inesperada. Favor comunicar";

Flash["error"] = " a equipe de desenvolvimento do sistema!";


}

}

public void ViewMachine(int id)

{

if(id == 0)


68


}


{


}


{

try

{


so.Open();


}

catch(Exception e)

{

Flash["error"] = "Aconteceu um erro inesperado. ";

Flash["error"]"Por favor comunique a equipe de desenvolvimento!";



}

}

public void ChangeServiceOrderStatus(string soaction, int id)

{

ServiceOrder so;

if(id <= 0)

{


return;

}

try

{

so = ServiceOrder.FindById(id);

}

catch(Exception e)

{


Flash["error"] = "N~ao foi possıvel encontrar a ordem de servico selecionada!";


return;

}

if(soaction == "Cancelar")

{

69

so.Cancel();


return;

}

else if(soaction == "Fechar")

{

RedirectToAction("closeview", "id=" + id);

return;

}


}

public void CloseView(string id)

{

try

{


if(soId <= 0)

throw new FormatException("Id da Ordem de servico Invalido!");

ServiceOrder so = ServiceOrder.FindById(soId);


PropertyBag["technicians"] = User.FindByProfile(User.PROFILE_TECHNICIAN);


}


{


Flash["warning"] = "Por favor, evitar utilizar a ";





}

catch(Exception e)

{


Flash["error"] = "Ocorreu um erro inesperado no sistema. ";



}

}

public void CloseCorrective([DataBind("report")] CorrectiveMaintenanceReport mr)

{

try

{

mr.Close();

}

70

catch(Exception e)

{


Flash["error"] = "Ocorreu um erro inesperado no sistema. ";


}


}

public void ClosePreventive([DataBind("report")] PreventiveMaintenanceReport mr)

{

try

{

mr.Close();

}

catch(Exception e)

{


Flash["error"] = "Ocorreu um erro inesperado no sistema.";

Flash["error"] += " Favor comunicar a equipe de desenvolvimento do sistema!";

}


}

public void ClosePredictive([DataBind("report")] PredictiveMaintenanceReport mr)

{

try

{

mr.Close();

}

catch(Exception e)

{


Flash["error"] = "Ocorreu um erro inesperado no sistema.";

Flash["error"] += " Favor comunicar a equipe de desenvolvimento do sistema!";

}


}

}/* class */

}/* namespace */

71

APENDICE U -- UserController.cs


{

using System;

using System.Collections.Generic;


using MMS.Models;

public class UserController : BaseController

{

/* View Methods */


{

PropertyBag["user"] = User.FindById(id);

}


{

PropertyBag["user"] = User.FindById(id);

}

public void New()

{

}

public void List()

{

PropertyBag["users"] = User.FindAll();

}

/* CRUD Methods */

public void Create([DataBind("user")] User user)

{

try

{

user.Create();

}

catch (Exception e)

{

72


Flash["error"] = "Erro durante o cadastro do usuario.";

}


}

public void Update([DataBind("user")] User u)

{

try

{

User user = User.FindById(u.Id);

user.Name = u.Name;

user.MobilePhone = u.MobilePhone;

user.HomePhone = u.HomePhone;

user.Password = u.Password;

user.Profile = u.Profile;

user.Update();

}

catch (Exception e)

{


}


}


{

try

{

User u = User.FindById(id);

u.Delete();

}

catch (Exception e)

{


}


}

}

}

73

ANEXO A -- Documento de Especificacao deRequisitos

87

ANEXO B -- Plano de Testes

contribuic¸ao para o desenvolvimento de um˜ sistema para ... · criar equipes responsaveis por...

Documents