Your SlideShare is downloading. ×
Aplicação da Engenharia de Domínio em um software para PPP
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Aplicação da Engenharia de Domínio em um software para PPP

966

Published on

Estudo e aplicação da Engenharia de Domínio em um software para emissão do PPP.

Estudo e aplicação da Engenharia de Domínio em um software para emissão do PPP.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
966
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SOFTWARE DÁVISSON HÚDSON CHAVES BERNADETE ELIEZER DUTRA GONÇALVES RICARDO LUIZ DA SILVA CHAGAS APLICANDO A ENGENHARIA DE DOMÍNIO NA CONSTRUÇÃO DE UM FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO Campos dos Goytacazes/RJ 2007
  • 2. DÁVISSON HÚDSON CHAVES BERNADETE ELIEZER DUTRA GONÇALVES RICARDO LUIZ DA SILVA CHAGAS APLICANDO A ENGENHARIA DE DOMÍNIO NA CONSTRUÇÃO DE UM FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO Trabalho de Conclusão de Curso apresentado ao Centro Federal de Educação Tecnológica de Campos como requisito parcial para conclusão do Curso de Tecnologia em Desenvolvimento de Software. Orientadora: Profª. Aline Pires Vieira de Vasconcelos, D.Sc. Campos dos Goytacazes/RJ 2007
  • 3. DÁVISSON HÚDSON CHAVES BERNADETE ELIEZER DUTRA GONÇALVES RICARDO LUIZ DA SILVA CHAGAS APLICANDO A ENGENHARIA DE DOMÍNIO NA CONSTRUÇÃO DE UM FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO Trabalho de Conclusão de Curso apresentada ao Centro Federal de Educação Tecnológica de Campos como requisito parcial para conclusão do Curso de Tecnologia em Desenvolvimento de Software. Aprovados em 20 de setembro de 2007. Banca Avaliadora: ________________________________________________________ Profª. Aline Pires Vieira de Vasconcelos, D.Sc. (Orientadora) ______________________________________________ Profª. Ana Sílvia R. Santiago, M.Sc. ______________________________________________ Prof. Marcelo Machado Feres, M.Sc.
  • 4. Dados de Catalogação na Publicação (CIP) B517a Bernadete, Dávisson Húdson Chaves. Aplicando a engenharia de domínio na construção de um framework de emissão do perfil profissiográfico previdenciário / Dávisson Húdson Chaves Bernadete, Eliezer Dutra Gonçalves, Ricardo Luiz da Silva Chagas. – Campos dos Goytacazes, RJ : [s.n.], 2007. 109 f. ; il. Orientadora: Aline Pires Vieira de Vasconcelos. Monografia (Tecnologia de Desenvolvimento de Software). Centro Federal de Educação Tecnológica de Campos. Campos dos Goytacazes, RJ, 2007. Bibliografia: f. 79-84. 1. Framework – Programa de computador. 2. Software - Desenvolvimento. 3. Sistema de informação gerencial. 4. Sistema de recuperação da informação. I. Gonçalves, Eliezer Dutra. II. Chagas, Ricardo Luiz da Silva. III. Vasconcelos, Aline Pires Vieira de , orient. IV. Título. CDD – 005.3
  • 5. AGRADECIMENTOS Dávisson: Primeiramente, agradeço a Deus pelas minhas conquistas baseada em esforço e dedicação, por ter aberto portas em meu caminho que levam à vitória sobre todas as coisas. Sua força é maior em todos os sentidos, e por isso me ajudaram nos momentos de dificuldade. Agradeço à Aline, nossa orientadora, por ajudar e compreender nossos erros no projeto, e incentivar a busca por novas áreas de conhecimento. Agradeço aos meus amigos por me darem força e incentivo, em especial aos companheiros da minha cidade Conceição de Macabu, que viajam constantemente comigo na busca do ensino que o CEFET proporciona, e aos meus colegas de classe, pessoas capazes e que se ajudam mutuamente na busca do saber. Agradeço também ao meu amigo Eliezer, que além de ser um dos membros do projeto, me ajudou num momento no qual estava desempregado, quase trancando a matrícula, e ele me conseguiu uma bolsa de inicialização cientifica na UENF. Isso se explica devido à dependência do emprego para manter os meus estudos, já que moro em outra cidade . E por último, mas não menos importante, a minha família e amigos de trabalho, por ter compreendido meus momentos de ausência dedicados ao estudo. Eliezer: Primeiramente agradeço ao meu Senhor e Salvador Jesus Cristo por ter morrido em uma cruz para me salvar. A Minha esposa, Michele, que teve paciência e amor para comigo. NEOQUEAV. Aos meus pais, Devanil e Marlene, por cuidarem de mim e sempre me apoiarem em todos os momentos. Agradeço aos professores do CEFET Campos pelo conhecimento proporcionado, em especial a orientadora do projeto Profª. Drª. Aline Pires que incansavelmente corrigiu esse trabalho e ajudou em todo o seu desenvolvimento. Ao colega de classe, Alamir Rodrigues pelo apoio durante o curso. Aos amigos Dávisson e Ricardo pelos esforços na elaboração desse trabalho. Aos amigos da UENF: Alexandre pela a ajuda na implementação do Framework; André Luiz, Maritza e Vanuzia por terem me recebido de braços abertos e terem se tornardo meus amigos. Ricardo: Quero agradecer primeiro a Deus por ter me dado forças para chegar até o fim desta jornada, pois sem ele nada seria possível. Também a toda minha família, e principalmente a minha esposa, que entendeu todas as minhas dificuldades, falhas, e me ajudou e incentivou para que eu continuasse. Agradeço também à nossa orientadora Aline, que soube entender as limitações e dificuldades na elaboração do trabalho, e também a todos os professores do CEFET por transmitir o conhecimento que adquiri nesse tempo. Por fim queria agradecer a todos os colegas da turma, que estiveram sempre unidos e se ajudando, principalmente o Eliezer que num momento de dificuldade após meu casamento me ajudou muito com a matéria acumulada. Enfim, a todos que nesta etapa da minha vida contribuíram de alguma forma para que eu alcançasse o sucesso, obrigado.
  • 6. RESUMO Este projeto visa a aplicação de técnicas de reutilização de software para a construção de um framework para a emissão do Perfil Profissiográfico Previdenciário (PPP). As técnicas empregadas englobam a Engenharia de Domínio, envolvendo principalmente a Análise de Domínio (AD), e princípios de frameworks, como a determinação de seus pontos configuráveis (i.e. hot-spots). O PPP representa um documento histórico-laboral dos trabalhadores, que deve ser entregue ao Instituto Nacional de Seguro Social (INSS) por ocasião de encerramento de contrato ou término da prestação de serviço, aposentadoria especial ou afastamento do trabalho por fatores de segurança, saúde ou incapacidade. Ele deve conter todo o histórico-laboral do trabalhador, abrangendo, cronologicamente por período, informações administrativas (setor, cargo, função etc.), ambientais e biológicas relacionadas ao trabalhador, para fins de comprovação e controle, e minimização de fraudes. O PPP está integrado à gestão de pessoal, permitindo o monitoramento e registro dos fatores de risco que afetem a saúde do trabalhador e a sua segurança, de modo a organizar e individualizar as informações contidas em diversos setores da empresa. Com isso, o INSS comprova as condições para habilitação de benefícios e serviços previdenciários. Através da AD, visa-se determinar aspectos comuns e variáveis entre empresas no que diz respeito à administração de pessoal e emissão do PPP, permitindo, dessa forma, o desenvolvimento de artefatos reutilizáveis de software. É utilizado o ambiente Odyssey, desenvolvido pela COPPE/UFRJ, para apoiar o processo, pois o desenvolvimento voltado à reutilização envolve maior esforço do que aquele voltado a uma aplicação específica. Palavras-chave: Engenharia de Domínio (ED), Perfil Profissiográfico Previdenciário (PPP), Frameworks, Gestão de Recursos Humanos (GRH), Análise de Domínio (AD), Variabilidade e Opcionalidade.
  • 7. ABSTRACT This project involves the application of software reuse techniques aiming at the construction of a framework for the emission of the Providenciary Profissiographic Profile (PPP). The employed techniques encompass Domain Engineering, mainly involving Domain Analysis (DA), and principles of frameworks, as the determination of its configuration points (i.e. hot- spots). The PPP represents a historical-labor document of the workers, that must be delivered to the National Institute of Social Security (INSS) in the occurrence of contract or provision of services ending, special retirement, or removal of the work for security factors, health problems or incapacity. It must contain all the description-labor of the worker, enclosing, chronologically by period, administrative information (department, post, function etc.), biological and environmental information, allowing the INSS to get evidences and to control the worker conditions, minimizing frauds. The PPP is integrated to the staff management, allowing the monitoring and recording of risk factors that affect the health and security of the worker. Therefore, it is possible to organize and individualize the information contained in the diverse set of company departments. Through the PPP, the INSS can prove the conditions to give benefits and providence services. Through the DA, it is possible to determine common and variable aspects among companies in respect to the staff administration and emission of the PPP, allowing, the development of reusable software artifacts. The Odyssey environment, developed by COPPE/UFRJ, is used to support the process, since the development for reuse requires a greater effort than the one involving a specific application. Keywords: Domain Engineering (DE), Providenciary Profissiographic Profile (PPP), Frameworks, Staff Management, Domain Analysis (DA), Variabilities and Optionalities.
  • 8. LISTA DE FIGURAS Figura 2.1 Ciclo de Vida da Engenharia de Domínio (OLIVEIRA, 2006) ...................... 19 Figura 2.2 Fases da Engenharia de Domínio (UFPE, 2007a) .......................................... 20 Figura 2.3 Um modelo genérico de desenvolvimento para/com reuso ............................ 22 Figura 2.4 Modelos de domínio (i.e. características, casos de uso e classes) e suas ligações de rastreabilidade no ambiente Odyssey ............................................................ 25 Figura 2.5 Características conceituais e funcionais da notação Odyssey-FEX ............... 28 Figura 2.6 Classificações das características ................................................................... 30 Figura 2.7 Propriedades ortogonais da notação Odyssey-FEX ........................................ 30 Figura 2.8 Classificação ortogonal das características na notação Odyssey-FEX ........... 31 Figura 3.1 Diagrama de Contextos do Domínio de Gestão de Recursos Humanos ......... 40 Figura 3.2 Diagrama de Características Conceituas de Cargo ......................................... 41 Figura 3.3 Diagrama de Característica Conceituas de Local ........................................... 42 Figura 3.4 Diagrama de Características Conceituas do Colaborador .............................. 43 Figura 3.5 Diagrama de Características Conceituas dos Históricos do Colaborador ...... 44 Figura 3.6 Diagrama de Características Conceituais de Risco ........................................ 47 Figura 3.7 Diagrama de Características Conceituais do PPRA .................................... 51 Figura 3.8 Diagrama de Características Funcionais da montagem do PPRA .................. 52 Figura 3.9 Diagrama de características conceituais de PCMSO .................................... 53 Figura 3.10 Diagrama de características conceituais de Exame ...................................... 55 Figura 3.11 Diagrama de características conceituais de Histórico de Exame .................. 56 Figura 3.12 Diagrama de Classes de parte do subdomínio de Administração de Pessoal – Características de Colaborador ..................................................................................... 57 Figura 3.13 Diagrama de Classe do subdomínio de Administração de Pessoal – Históricos ......................................................................................................................... 58 Figura 3.14 Diagrama de Classe do subdomínio de Segurança – Montagem do PPRA .. 59 Figura 3.15 Opções de Mapeamentos no Odyssey .......................................................... 59 Figura 3.16 Diagrama de Classe do subdomínio de Medicina – Históricos .................... 60 Figura 3.17 Diagrama de Casos de Uso ........................................................................... 61 Figura 3.18 Wizard de mapeamento de características funcionais para casos de uso no ambiente Odyssey ............................................................................................................ 61 Figura 4.1 Arquitetura Lógica do Java EE 5 (SILVA e MOREIRA, 2006) .................... 65
  • 9. Figura 4.2 Retorno do Servlet para a página local.jsp .................................................... 69 Figura 4.3 Página local.jsp interagindo com o Servlet ................................................... 69 Figura 4.4 Cadastro de Cargo em JSP que mostra a tela de cargo ................................... 70 Figura 4.5 Exemplo de código do arquivo persistence.xml ............................................. 71 Figura 4.6 Mapeamento de persistência da Classe Cargo ................................................ 72 Figura 4.7 Exemplo de código do relacionamento muitos para um unidirecinal ............. 73 Figura 4.8 Implentação de persitência na classe Cargo ................................................... 74
  • 10. LISTA DE TABELAS Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006) ....... 27 Tabela 2.2 Tipos de Características no ambiente Odyssey .............................................. 29 Tabela 2.3 Relacionamentos da notação Odyssey-FEX .................................................. 31 Tabela 3.1 Obrigatoriedade de Emissão do Perfil Profissiográfico Previdenciário ......... 38 Tabela 3.2 Limites de tolerância para ruído contínuo ou intermitente ............................ 48
  • 11. LISTA DE SIGLAS AD Análise de Domínio API Application Programming Interface ASO Atestado de Saúde Ocupacional BD Banco de dados CAT Comunicação de Acidente do Trabalho CLT Consolidação das Leis do Trabalho CNPJ Cadastro Nacional de Pessoa Jurídica CRUD Create, Read, Update e Delete EA Engenharia de Aplicação ED Engenharia de Domínio EJB Enterprise JavaBeans EPC Euipamento de Proteção Coletiva EPI Equipamento de Proteção Individual GRH Gestão de Recursos Humanos GUJ Grupo de Usuários Java HH Homem Hora HTML HyperText Markup Language IN Instruções Normativas JEE Java Enterprise Edition JMS Java Message Service JMX Java Management Extensions JPA Java Persistência API JSF JavaServer Faces JSP JavaServer Pages JSTL JSP Standard Tag Library MP Medidas Provisórias MTE Ministério do Trabalho e Emprego MVC Model View Control NR Normas Regulamentadoras OMG Object Management Group OO Orientação a Objeto PCMSO Programa de Controle Médico de Saúde Ocupacional POJO Plain Old Java Objects PPP Perfil Profissiográfico Previdenciário PPRA Programa de Prevenção a Riscos Ambientais SESMT Serviço Especializado em Engenharia e Segurança em Medicina do Trabalho SGBD Sistema Gerenciadores de Bando de Dados UML Unified Modeling Language
  • 12. SUMÁRIO LISTA DE FIGURAS....................................................................................................... 7 LISTA DE TABELAS .................................................................................................... 8 LISTA DE SIGLAS ......................................................................................................... 9 CAPÍTULO 1: INTRODUÇÃO ................................................................................... 13 1.1 Motivação ....................................................................................................... 13 1.2 Objetivos ........................................................................................................ 15 1.3 Organização da Monografia 15 CAPÍTULO 2: REFERENCIAL TEÓRICO .............................................................. 17 2.1 Introdução ....................................................................................................... 17 2.2 Engenharia de Domínio .................................................................................. 18 2.2.1 Análise de Domínio.......................................................................... 22 2.2.2 O Ambiente de Reutilização de Software Odyssey ......................... 24 2.2.2.1 A Notação Odyssey-FEX ................................................. 26 2.3 Frameworks .................................................................................................... 31 2.3.1 Tipos de Frameworks ...................................................................... 33 2.4 Considerações Finais ...................................................................................... 33 CAPÍTULO 3: ANÁLISE DE DOMÍNIO PARA A CONSTRUÇÃO DO FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO ...................................................................................................... 35 3.1 Introdução ....................................................................................................... 35 3.2 Análise de Domínio ....................................................................................... 35 3.2.1 Descrição do Domínio ..................................................................... 36 3.2.2 Contextos ......................................................................................... 39 3.2.3 Subdomínio de Administração de Pessoal ...................................... 41 3.2.3.1 Características de Cargos e Locais ................................... 41 3.2.3.2 Características de Colaborador e seus Históricos ............. 42 3.2.4 Subdomínio de Segurança ............................................................... 46 3.2.4.1 Características dos Riscos ................................................ 47 3.2.4.2 Características dos Equipamentos de Proteção ................ 49 3.2.4.3 Características do PPRA ................................................... 50 3.2.5 Subdomínio Medicina ..................................................................... 52
  • 13. 3.2.5.1 Características de PCMSO ............................................... 53 3.2.5.2 Características dos Exames .............................................. 54 3.2.5.3 Histórico de Exames.......................................................... 55 3.3 Mapeamento do Modelo de Características para o Modelo de Classes ......... 56 3.4 Mapeamento do Modelo de Características para o modelo de Casos de Uso 60 CAPITULO 4: TECNOLOGIAS EMPREGADAS NO FRAMEWORK ................ 63 4.1 Introdução ....................................................................................................... 63 4.2 Java Enterprise Edition ................................................................................... 64 4.2.1 Arquiteturas Multicamadas ............................................................. 64 4.2.2 Servidor de Aplicação ..................................................................... 65 4.2.3 Enterprise JavaBeans ....................................................................... 67 4.2.4 Servlets ............................................................................................ 68 4.2.5 JavaServer Pages ............................................................................. 69 4.2.6 Java Persistência API ...................................................................... 70 4.2.6.1 Mapeamento de Entidades ................................................ 72 4.2.4.2 Persistência a Entidades .................................................... 73 4.4 Considerações Finais ...................................................................................... 74 CAPITULO 5: CONCLUSÕES E TRABALHOS FUTUROS .................................. 76 5.1 Conclusões ................................................................................................ 76 5.2 Contribuições e Benefícios do Trabalho .................................................. 77 5.3 Dificuldades Encontradas ......................................................................... 77 5.4 Trabalhos Futuros ..................................................................................... 78 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................... 79 Apêndice A: Casos de Uso para o Controle e Emissão do Perfil Profissiográfico Previdenciário ............................................................................................................................... 85 Apêndice B: Diagrama de Classe para Emissão e Controle do Perfil Profissiográfico Previdenciário ............................................................................................................................... 96 Apêndice C: Exemplo de Listagem dos Códigos ......................................................................... 97 Apêndice D: Exemplo de Telas do Sistema ..................................................................... 102 Anexo A: Perfil Profissiográfico Previdenciário (PPP) ................................................................ 104
  • 14. CAPÍTULO 1: INTRODUÇÃO 1.1 Motivação A sociedade atualmente está diante dos avanços tecnológicos impostos pelo mundo, e não dispõem de muito tempo. Nesse contexto, o software é extremamente necessário ao atendimento desses ideais. Porém, não basta apenas que os softwares sejam disponibilizados, é preciso que estes tenham qualidade e que sejam produzidos com eficiência para atendimento ao seu cliente. Assim, percebe-se que a sociedade necessita de sistemas que utilizem técnicas sistemáticas com tempo de desenvolvimento menor possível, mas com toda qualidade que possa apresentar. Baseando-se no que foi citado, é apresentado o fator da reutilização de software, que consiste basicamente no processo de criação de sistemas de software a partir de outros que já existiam antes, o que diminui o custo do software em si e minimiza pesquisas extensas de trabalhos posteriores em cima de um mesmo projeto ou idéia. Para que a reutilização seja efetiva, uma vez que o desenvolvimento voltado à reutilização envolve grande esforço, a idéia é que se crie um projeto utilizando-se métodos e ferramentas de análise e modelagem de software, como a Engenharia de Domínio (ED), Análise de Domínio (AD), Engenharia de Aplicação (EA) etc., dando base para projetos futuros que venham a reutilizar a estrutura do sistema. Isso possibilita a criação ou expansão para sistemas mais complexos em menos tempo. Para aplicar a reutilização de software, uma das técnicas possíveis de ser adotada é a Engenharia de Domínio, que oferece um apoio sistemático à reutilização desde o início do seu ciclo de vida, apoiando a reutilização também de artefatos de análise e de projeto, ao invés de somente a reutilização de código. A ED trabalha na criação de soluções genéricas que venham a ser reutilizadas pelas aplicações do domínio, ressaltando as suas variabilidades, que, por sua vez, se mostram bastante importantes, pois deixam claro os pontos onde os sistemas se assemelham para serem reutilizados e os pontos onde se diferem para serem avaliados mais cautelosamente e estudados para implementação. A Análise de Domínio (AD) oferece suporte para o reuso sistemático e em larga escala, através da captura das características comuns e das variabilidades entre os sistemas do
  • 15. 14 domínio. A AD é inicializada logo após a conclusão do seu planejamento na ED, ou seja, a AD, uma das etapas da ED, cria um arcabouço propício de reuso para a implementação dentro de um escopo bem definido. Aplicando os conhecimentos adquiridos em reutilização focada na ED, pode-se desenvolver um projeto voltado para a implementação de um domínio estruturado dentro de um framework. O domínio escolhido foi a emissão do Perfil Profissiográfico Previdenciário (PPP). Um framework é um conjunto de classes que cooperam para construir um sistema reutilizável para uma classe específica de software (GAMMA, HELM, JOHNSON e VLISSIDES, 2000). Isso permite que seja construído uma estrutura genérica para um domínio específico, com divisão de classes e objetos, ou seja, os frameworks definem a arquitetura do domínio. O PPP deve ser entendido como uma monitoração histórico-laboral de um colaborador de uma determinada empresa. Esse domínio trata especificamente de toda a vida de um colaborador (um colaborador pode ser um trabalhador próprio da empresa, um contratado ou prestador de serviços terceirizado) dentro da empresa, como níveis de segurança a que foi submetido, riscos a saúde a que foi exposto, e tudo que foi causado por esses fatores individualmente ou coletivamente. O INSS pode solicitar o PPP quando da necessidade de envio do mesmo, ou seja, pode ser por motivo de algum acidente em que o colaborador necessite se aposentar, ou permanecer inativo por tempo indeterminado, ou ainda contraia alguma doença relativa ao seu trabalho onde se expõe a fatores prejudiciais apontados ou relacionados pelo Programa de Prevenção a Riscos Ambientais (PPRA) ou pelo Programa de Controle Médico e Saúde Ocupacional (PCMSO), abrangendo, cronologicamente por período, as informações administrativas (setor, cargo, função etc.), ambientais e biológicas relacionadas ao trabalhador, para fins de comprovação e controle, e minimização de fraudes. A comprovação do direito a aposentadoria especial será feita mediante Perfil Profissiográfico Previdenciário (PPP). Esse domínio foi escolhido por apresentar características que demonstram claramente a necessidade de implementação por framework, pois ele é obrigatório a toda administração de recursos humanos, uma vez que é exigido pelo INSS, além de variar de uma empresa para outra como em divisões de setores, nomenclaturas, especificações etc. Dessa forma, apresenta variabilidades. Devido ao fato de ser um domínio complexo e pouco trivial, implica em um desafio alcançável com esforço e dedicação, mas, que na verdade, se demonstra propício para a representação da ED aliada aos conceitos de framework..
  • 16. 15 1.2 Objetivos O objetivo desse projeto é explorar o desenvolvimento de software voltado à reutilização, explorando algumas técnicas baseadas em reutilização, como Engenharia de Domínio (ED), Frameworks e Análise de Domínio (AD), tendo sido escolhido como estudo de caso o domínio de emissão do Perfil Profissiográfico Previdenciário (PPP). Visa-se ainda conhecer um ambiente de modelagem baseado em reutilização, aprimorando o conhecimento adquirido, e assim sendo possível a construção de um framework para o referido domínio. O ambiente adotado é o Odyssey (ODYSSEY, 2007), que apóia as atividades da ED e se encontra disponível para uso, provendo suporte à reutilização com base em modelos de domínio. Como tecnologia de implementação, utilizou-se a linguagem JEE (Java Enterprise Edition) e tecnologias adjacentes como Enterprise Java Bean, Jboss etc., por ser a linguagem que hoje está presente no mercado e que também beneficia o desenvolvimento para reutilização através da idéia de componentes de software dos Java Beans. Mas vale ressaltar que a base da modelagem é independente da linguagem, ou seja, o projeto pode ser implementado em qualquer linguagem de programação orientada a objeto. O principal objetivo aqui, entretanto, é contribuir para trabalhos futuros, apresentando a base do sistema para reutilização, deixando assim o framework pronto para ser instanciado por diferentes aplicações para diferentes empresas. 1.3 Organização da Monografia Este projeto está organizado em mais 4 capítulos, além desta Introdução. No capítulo 2, é apresentado um referencial teórico, onde observa-se mais detalhadamente o conceito de Engenharia de Domínio (ED), Análise de Domínio (AD), conceitos de reutilização de software no ambiente Odyssey (ODYSSEY, 2007) e Frameworks. Este capítulo busca referenciar a abordagem de cada um desses fatores nos artefatos do domínio. Aqui também são destacados os conceitos de variabilidades no ambiente e os tipos de frameworks destacados na literatura.
  • 17. 16 O capítulo 3 apresenta a aplicação das técnicas descritas no capítulo 2 para a construção de um modelo de domínio para a emissão do Perfil Profissiográfico Previdenciário (PPP), representando um conjunto de classes que podem ser reutilizados para implementar ou criar aplicações. No capítulo 4, demonstram-se as tecnologias empregadas para a implementação do framework, como: Java, o servidor de aplicação Jboss, EJB (Enterprise Java Bean), Servlets, JSP (JavaServer Pages) e o JPA (Java Persistence API), utilizando o Hibernate como framework de persistência. No capítulo 5, e último, são apresentadas algumas conclusões obtidas durante o desenvolvimento do projeto. Fala-se das possibilidades para trabalhos futuros, além de benefícios obtidos e dificuldades encontradas pelo grupo no desenvolvimento baseado em reutilização e no uso de um ambiente de desenvolvimento para apoio a essas atividades.
  • 18. CAPÍTULO 2: REFERENCIAL TEÓRICO 2.1 Introdução Atualmente, grande parte do software já está sendo criado a partir de outros, ou de partes já existentes, pois a cada dia o software está ficando mais complexo e a demanda por ele só aumenta. Com isso, a reutilização é uma atividade que está sendo muito disseminada pela comunidade de desenvolvimento de software. Ela pode ser definida como o processo de criação de sistemas de software a partir de software preexistente (KRUEGER, 1992), trazendo consigo a promessa de aumentar a produtividade e diminuir custos do desenvolvimento, além de melhorar a qualidade do produto, através da reutilização de artefatos de software já testados e utilizados em outros contextos (FRAKES e KANG, 2005). Ela representa uma sub-área da Engenharia de Software que cresce cada vez mais. No contexto da Engenharia de Software, diferentes abordagens buscam melhorar a qualidade dos artefatos1 de software, bem como diminuir o tempo e o esforço necessários para produzi-los, assim como abordagens de reutilização. A reutilização não é uma técnica nova, ela já vem sendo realizada desde o início da Engenharia de Software, porém, anteriormente, se reutilizava apenas bibliotecas de rotinas ou partes de código em ambientes de programação. Com o passar do tempo e o surgimento do paradigma de desenvolvimento de sistemas orientado a objetos (OO), a reutilização ganhou mais força, pois as classes passaram a encapsular dados e funções, e então a parte reutilizável aumentou a sua granularidade, o que ajudou a alcançar ainda mais os objetivos da reutilização. Percebeu-se que era muito vantajoso, principalmente se isto fosse feito desde o início do ciclo de vida do software e com o avanço das pesquisas passou-se a se fazer não apenas a reutilização de código, mas também a de outros artefatos, como artefatos de análise e de projeto. O uso de técnicas de reutilização desde as fases iniciais do desenvolvimento de aplicações facilita a reutilização de componentes em fases mais avançadas do desenvolvimento (ODYSSEY, 2007). Uma das abordagens da Engenharia de Software que busca a melhora no desenvolvimento através da reutilização são os frameworks. Um framework é um conjunto de 1 Artefato é o termo usado para qualquer produto do trabalho de desenvolvimento de software.
  • 19. 18 classes cooperantes que constroem um projeto reutilizável para uma específica classe de software (GAMMA et al, 2000). Estas estruturas de classes quando estendidas e adaptadas permitem produzir aplicações específicas. Produzir uma especificação adequada a uma família de aplicações com características similares (i.e. um domínio) e reutilizar esta especificação no desenvolvimento de aplicações específicas são preocupações no desenvolvimento de frameworks. Sua grande vantagem é o reuso não apenas de código, mas também de projeto. A fim de apoiar a especificação de um conjunto de aplicações, a Engenharia de Domínio representa uma outra abordagem de reutilização de software que pode ser adotada em conjunto com os frameworks. Ela também visa a criação de artefatos para um determinado domínio com o objetivo de serem reutilizados e será discutida com mais detalhes a seguir. Partindo desta Introdução, o restante do capítulo está organizado da seguinte forma: a a Seção 2.2 aborda conceitos inerentes à Engenharia de Domínio; a Seção 2.3 trata do assunto frameworks; e a Seção 2.4 apresenta algumas considerações finais. 2.2 Engenharia de Domínio A Engenharia de Domínio (ED) pode ser definida como: "o processo de identificação e organização do conhecimento sobre uma classe de problemas, i.e. o domínio do problema, para apoiar a sua descrição e solução" (PRIETO-DIAZ e ARANGO, 1991). Ela é responsável pela criação de artefatos para aplicações que compartilhem características em comum, definindo uma família de aplicações ou domínio. Com isso, ao se identificar as semelhanças e as diferenças de um domínio, ou seja, as suas variabilidades e opcionalidades, pode-se tornar viável a reutilização dos artefatos produzidos tanto para sistemas em desenvolvimento como para sistemas futuros do mesmo domínio. A ED se preocupa em produzir artefatos de software reutilizáveis com princípios que norteiam a modularidade, como: a criação de módulos com interfaces pequenas, explícitas e em pequena quantidade, e o uso do princípio da ocultação de informação (UFSC, 2007). Este tem sido o principal elemento de orientação para a produção de bibliotecas de artefatos reutilizáveis. O objetivo da ED é identificar, construir, catalogar e disseminar um conjunto de componentes de software que têm aplicabilidade a software existente e futuro, em um particular domínio de aplicação (PRESSMAN, 2006). Na ED, todos os artefatos produzidos
  • 20. 19 são catalogados e armazenados de forma que possam ser utilizados a qualquer momento por outra aplicação que esteja no mesmo domínio. A Engenharia de Domínio envolve o processo de busca, análise, manipulação e formalização das informações do domínio relevantes para a implementação de um programa de reutilização. O resultado final de um processo de ED são os modelos de domínio. Enquanto a ED é voltada à construção de artefatos reutilizáveis para várias aplicações, ou seja, é voltada ao desenvolvimento para reutilização, a Engenharia de Aplicação (EA) é responsável por implementar aplicações através da instanciação dos artefatos que foram produzidos pela ED, conforme mostra a Figura 2.1. A Engenharia de Aplicações se dedica ao estudo das melhores técnicas, processos e métodos para a produção de aplicações, no contexto do desenvolvimento com reutilização. A EA se utiliza da ED buscando componentes de software que estejam disponíveis para a reutilização como em uma biblioteca. As duas trabalham em conjunto fazendo com que os artefatos produzidos sejam reutilizados em qualquer aplicação que se encontre no mesmo domínio. A EA pode produzir feedback para a ED, no sentido da descoberta de novos artefatos reutilizáveis durante o desenvolvimento de novas aplicações no domínio. Figura 2.1 Ciclo de Vida da Engenharia de Domínio (OLIVEIRA, 2006) O objetivo da ED é que a reutilização de software seja realizada desde o início do ciclo de vida para que o software alcance o sucesso, sendo que os artefatos produzidos são ao mesmo tempo específicos para o domínio em questão e genéricos o suficiente para atender a toda a variedade de aplicações possíveis àquele domínio. Dessa forma, a ED propõe as
  • 21. 20 seguintes fases ou macro-atividades que sistematizam a construção do modelo de domínio: Planejamento, Análise, Projeto e Implementação do domínio. A Figura 2.2 mostra uma visão geral das fases da ED. A Análise de Domínio (AD) deve ter início assim que é concluído o seu planejamento, envolvendo um estudo de viabilidade. Durante esta fase são originados alguns documentos, como o glossário do domínio, onde estão documentados todos os conceitos encontrados no domínio que servem como entrada para a fase de Projeto do Domínio, conforme apresenta a figura. Figura 2.2 Fases da Engenharia de Domínio (UFPE, 2007a) A fase de Planejamento é o início do processo e tem o objetivo de fazer as estimativas de recursos utilizados na ED, de custos, cronogramas e, principalmente, a Análise de Viabilidade do domínio (veja Figura 2.2). Como em qualquer outro ramo de atividade, o desenvolvimento de um software, ou de um modelo de domínio, não deve ser feito sem que antes se tenha uma visão geral de custo, mercado, e prazo de retorno do investimento, que não costuma ser curto, ainda mais em se tratando de desenvolvimento baseado em reutilização. No desenvolvimento baseado em reutilização, um grande investimento inicial deve ser feito no desenvolvimento dos artefatos reutilizáveis antes mesmo que qualquer aplicação do domínio possa ser desenvolvida. Neste contexto, para que não ocorra nenhuma surpresa no futuro, é necessário que antes de tudo se faça uma Análise da Viabilidade do domínio.
  • 22. 21 Dentre as atividades que são realizadas nesta etapa, podemos destacar o estudo de mercado do domínio, para saber a existência de clientes e possíveis concorrentes, e a partir daí se for constatado o potencial econômico, faz-se um estudo do domínio para identificar superficialmente suas variabilidades. Com base nestas informações, o passo seguinte é verificar se a documentação disponível sobre o domínio é suficiente para o seu estudo e a extração de seus conceitos (Figura 2.2). Deve-se verificar a maturidade do domínio, ou seja, o quanto de documentação, sistemas existentes e informação disponível este possui, e ainda se os requisitos em comum são estáveis para justificar o desenvolvimento para reutilização. A partir daí, estima-se o esforço e recursos necessários ao desenvolvimento e o tempo de retorno do investimento, sendo possível dar um parecer sobre a viabilidade do domínio. Após o planejamento e o parecer final dando um sinal verde, ou seja, constatando a viabilidade do domínio, inicia-se então a Análise de Domínio (AD). Nesta fase, o objetivo principal é entender os conceitos gerais do domínio, e produzir modelos de requisitos que mostrem as semelhanças e diferenças do domínio, as quais podem ser representadas através de opcionalidades e variabilidades nos artefatos do domínio. A Análise de Domínio é a atividade onde é delimitado o escopo do domínio e também onde são determinadas as características comuns e variáveis de uma família de aplicações (OLIVEIRA, 2006). O modelo mais comumente utilizado para a modelagem de variabilidades e opcionalidades é o modelo de características (features). Uma característica, segundo Kang et al. (1990), pode ser definida como “um aspecto, uma qualidade, ou uma característica visível ao usuário, proeminente ou distinta, de um sistema (ou sistemas) de software”. O modelo de características representa as características de uma família de sistemas em um domínio, suas semelhanças e diferenças e as relações entre elas (KANG et al., 1990). A etapa de Projeto de Domínio visa, principalmente, a especificação de arquiteturas de software específicas de domínio (DSSAs – Domain Specific Software Architectures) com base nos requisitos, variabilidades e opcionalidades levantados para o domínio. Uma DSSA representa uma coleção de componentes especializados para um determinado tipo de tarefa (domínio), generalizados para que seja possível seu uso efetivo através do domínio e compostos em uma estrutura padronizada (topologia) efetiva para a construção de aplicações (HAYES, 1994). Uma DSSA deve atender aos requisitos de referência, i.e. funcionais e não- funcionais do domínio. Arquiteturas de referência são criadas para serem configuradas e estendidas durante o processo de instanciação de aplicações, representando um framework para o domínio.
  • 23. 22 Após a etapa de Projeto, a última etapa que a ED engloba, como foi descrito anteriormente, é a Implementação do Domínio. Nesta etapa, as oportunidades de reutilização do modelo, que foram identificadas nas fases de Análise e de Projeto, serão implementadas na forma de componentes ou classes de objetos reutilizáveis. Pode-se realizar também a extração desses artefatos de sistemas legados existentes no domínio ou a busca desses componentes em bibliotecas de software, sendo então reaproveitados para a construção de novas aplicações no mesmo domínio. Figura 2.3 Um modelo genérico de desenvolvimento para/com reuso (GUIZZARDI, 2007) Podemos concluir, conforme mostra a Figura 2.3, que o objetivo da Engenharia de Domínio é, durante o processo de conversão do conhecimento de desenvolvedores acerca do domínio, criar um repositório de componentes, produzindo um conjunto de artefatos passíveis de reutilização na Engenharia de Aplicação (denominada de Engenharia de Software na Figura). Dessa forma, como mostrado na figura 2.3, um projeto de domínio da ED pode ser reutilizado para várias aplicações específicas na Engenharia de Software ou EA. 2.2.1 Análise de Domínio Uma vez que a etapa de Análise de Domínio é a mais explorada neste trabalho, por ser a base para uma abordagem de ED de sucesso, ela é detalhada nesta seção. Ela envolve a
  • 24. 23 especificação dos requisitos do domínio, assim como a Análise de Requisitos de um software envolve a sua especificação de requisitos. Requisitos adequadamente compreendidos e especificados são a base para um desenvolvimento de software com sucesso. O estudo e o entendimento dos problemas e requisitos de um domínio é a principal atividade da Análise de Domínio. PRIETO-DIAZ e ARANGO (1991) definem a AD como “o processo de identificar e organizar o conhecimento a respeito de uma classe de problemas, i.e. o domínio do problema, de maneira a apoiar a descrição e solução de tais problemas”. Isto é fundamental para que os artefatos próprios, que serão gerados desse estudo, possam ser reutilizados em aplicações ou outros softwares que pertençam ao mesmo domínio. Além disso, nesta fase são identificadas as variabilidades do domínio, ou seja, os pontos dentro deste domínio onde existirão semelhanças e diferenças, definindo-se os aspectos comuns entre as aplicações que poderão ser instanciadas a partir deste modelo de domínio. Alguns métodos conhecidos e utilizados para especificar as variabilidades do domínio são: o FODA (KANG et al., 1990), FORM (KANG et al., 2002), FODACom (VICI e ARGENTIERI, 1998), FeatuRSEB (GRISS et al., 1998), ODM (SIMOS e ANTHONY,1998), Odyssey-DE (BRAGA, 2000) e CBD-Arch-DE (BLOIS, 2006). O método CBD-Arch-DE é suportado pelo ambiente de reutilização Odyssey da COPPE/UFRJ (ODYSSEY, 2007) e emprega a notação Odyssey-FEX, que é adotada neste trabalho e explicada na seção a seguir. Para facilitar a Análise de Domínio é recomendável que se defina o escopo do domínio, pois sabendo o que se está analisando, evita-se que a análise se torne uma atividade interminável e às vezes sem nenhum objetivo real e específico. Por outro lado, tem que se tomar cuidado para não restringir muito este domínio a ponto de, ao final, não se gerar nenhum artefato útil às aplicações do domínio. Após definido o escopo do domínio, deve-se extrair as suas características (features). A partir do modelo de características, devem ser derivados os demais modelos do domínio, com o objetivo de refletir os conceitos, funcionalidades e aspectos tecnológicos do domínio. Tanto requisitos funcionais quanto não-funcionais são analisados como features, as quais representam as partes comuns e variáveis dos sistemas. O modelo de características é o modelo de mais alto nível de abstração na ED e identifica o que é opcional ou mandatório em um domínio, e também o que pode variar. A seção 2.2.2, a seguir, descreve a importância dos ambientes de reutilização para apoiar o desenvolvimento baseado em reutilização, destacando o ambiente Odyssey (ODYSSEY, 2007). Este ambiente está disponível para uso e adota a notação Odyssey-FEX para a modelagem de características.
  • 25. 24 2.2.2 O Ambiente de Reutilização de Software Odyssey Todo software está continuamente sujeito a modificações, motivadas por diversos fatores. Como exemplo, temos: a correção de erros encontrados por desenvolvedores e usuários, o surgimento de novas tecnologias, as alterações no ambiente de operação e o desenvolvimento incremental. Dessa forma, o desenvolvimento de software deve ser realizado com o apoio de ambientes que permitam a sua contínua evolução. O mesmo vale para modelos desenvolvidos para um domínio. A fim de que a reutilização de software possa se tornar efetiva, uma vez que envolve grande esforço, ela deve ser realizada com o apoio de um ambiente de desenvolvimento de software baseado em reutilização (MOURA, CARVALHO e SILVA, 2006). Não só um ambiente que permita acompanhar a evolução dos modelos desenvolvidos, mas também que apóie a própria especificação dos modelos de análise e projeto do domínio e geração do código, além da reutilização dos artefatos desenvolvidos através da Engenharia de Aplicação. Uma infra-estrutura de suporte à reutilização baseada em modelos de domínio pode ajudar na utilização efetiva da reutilização durante o desenvolvimento de software, fornecendo métodos, ferramentas e procedimentos que são adequados para a especificação de modelos e aplicações do domínio. Um ambiente de desenvolvimento baseado em reutilização, disponível para utilização e desenvolvido em nível nacional é o ODYSSEY (ODYSSEY, 2007). Trata-se de um protótipo acadêmico, desenvolvido pela equipe de reutilização da COPPE/UFRJ. O principal objetivo do Odyssey é prover mecanismos, baseados em reutilização, para o desenvolvimento de software, servindo como um arcabouço onde modelos conceituais, arquiteturas de software, e modelos implementacionais são especificados para domínios de aplicação previamente selecionados. O Odyssey implementa a notação Odyssey-FEX (OLIVEIRA, 2006) para a modelagem de características do domínio e suas variabilidades. Não foi encontrado um ambiente comercial com as funcionalidades para apoio à reutilização que o Odyssey oferece, como: • Desenvolvimento para reutilização, através de processos de Engenharia de Domínio, permitindo o desenvolvimento de modelos reutilizáveis de domínio. • Desenvolvimento com reutilização, através da Engenharia de Aplicação, permitindo a instanciação de aplicações a partir dos modelos de domínio, onde
  • 26. 25 é feito o recorte do domínio, determinando-se as características que devem compor as aplicações (a ressalva se faz para as características obrigatórias do domínio, que devem ser sempre selecionadas). • Mapeamentos e ligações de rastreabilidade entre modelos em diferentes níveis de abstração, como mostra a Figura 2.4, permitindo a reutilização dos diferentes modelos de domínio que devem compor as aplicações (BLOIS, 2006). • Instanciação de padrões de projeto e arquiteturais em modelos de domínio e de aplicações. • Engenharia reversa dinâmica e estática (VASCONCELOS, 2007). • Desenvolvimento orientado a modelos (i.e. MDA – Model-Driven- Architecture), permitindo a geração de modelos de componentes específicos para uma plataforma a partir de modelos independentes de plataforma (MAIA, 2006). Figura 2.4 Modelos de domínio (i.e. características, casos de uso e classes) e suas ligações de rastreabilidade no ambiente Odyssey (VASCONCELOS, 2007). A figura 2.4 mostra um modelo de características construído utilizando a notação Odyssey-FEX. Neste exemplo, é considerado o domínio de Software para Controle Escolar.
  • 27. 26 O ambiente Odyssey está disponível para download, em sua versão light, na página http://reuse.cos.ufrj.br/odyssey, onde também podem ser obtidos artigos, dissertações e teses que descrevem as suas funcionalidades. Ele possui funcionalidades essenciais e secundárias para a ED e a EA. As funcionalidades essenciais compõem o núcleo (kernel) do ambiente, sendo baixadas com ele, e as funcionalidades secundárias estão disponíveis na forma de plugins, sendo baixadas de dentro do próprio Odyssey sob demanda. Dessa forma, em função das funcionalidades oferecidas, o ambiente Odyssey é adotado neste trabalho para apoiar o processo de Engenharia de Domínio e construção de um framework para o domínio. A seguir, é apresentada a notação Odyssey- FEX para a modelagem de características e variabilidades do domínio. 2.2.2.1 A Notação Odyssey-FEX A notação Odyssey-FEX foi elaborada a partir do refinamento da notação proposta por MILER (2000), que vem a ser uma extensão do método FODA de (KANG et al., 1990). Ela permite a representação de variabilidades no modelo de características do domínio. O modelo de características da Odyssey-FEX incorpora além dos relacionamentos triviais entre características (i.e. alternativo , implementador por etc.), relacionamentos da UML. A representação de variabilidades deve estar o mais coerente possível na mesma família de sistemas. Para tanto, é de suma importância que essa variabilidade expressa no modelo de características seja também estendida para outros modelos de nível mais baixo de abstração, como o modelo de classes, de casos de uso e de componentes. Neste sentido, Oliveira (2006) propõe regras de mapeamento para a propagação das variabilidades para os demais modelos de domínio, através do estabelecimento de correspondências semânticas entre os elementos do metamodelo de características (OLIVEIRA, 2006) e os elementos do metamodelo da UML (OMG, 2005). As características definidas na notação Odyssey-FEX e disponíveis no ambiente Odyssey devem ser utilizadas em fases distintas do desenvolvimento de um software. A Tabela 2.1 apresenta a taxonomia de características na notação Odyssey-FEX.
  • 28. 27 Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006) Como já dito, essas características devem ser mapeadas para os demais artefatos do domínio, como classes e casos de uso, e as características tecnológicas mapeadas para artefatos da fase de projeto de domínio, como classes ou componentes utilitários e de infra- estrutura. Ainda podemos subdividir as características de domínio em funcionais e conceituais. As características funcionais estão ligadas aos casos de uso e as conceituais aos conceitos ou classes de um domínio. Para efeito de demonstração, é apresentado na figura 2.6 Ícone Tipo de Característica Características de Domínio – Características intimamente ligadas à essência do domínio. Representam as funcionalidades e/ou os conceitos do modelo e correspondem a casos de uso e componentes estruturais concretos. CaracterísticasdeAnálise Características de Entidade – São os atores do modelo. Entidades do mundo real que atuam sobre o domínio. Podem, por exemplo, expor a necessidade de uma interface com o usuário ou de procedimentos de controle. Características de Ambiente Operacional - Características que representam atributos de um ambiente que uma aplicação do domínio pode usar e operar. Ex: tipo de terminal, sistemas operacionais, bibliotecas etc. CaracterísticasdeProjeto(Tecnológicas) Características de Tecnologia de Domínio - Características que representam tecnologias utilizadas para modelar ou implementar questões específicas de um domínio. Ex: métodos de navegação em um domínio de aviões. Características de Técnicas de Implementação – Características que representam tecnologias utilizadas para implementar outras características, podendo ser compartilhadas por diversos domínios. Ex: técnicas de sincronização.
  • 29. 28 um exemplo desse modelo referente a um domínio de matrícula e transferência em uma instituição de nível superior no ambiente Odyssey. Figura 2.5 Características conceituais e funcionais da notação Odyssey-FEX (VASCONCELOS, 2007) Na Figura 2.5, a Secretária representa uma Característica de Entidade, ou seja, um usuário do domínio. Matricular Aluno e Realizar Transferência de Instituição são Características de Domínio funcionais que darão origem a casos de uso ou métodos/operações do domínio. Por outro lado, Escola, Curso, Graduação, Pos-Graduação e Ensino a Distância são Características de Domínio conceituais que darão origem às classes ou atributos no domínio. Na notação Odyssey-FEX a variabilidade pode ser classificada como pontos de variação, variantes ou invariantes. A descrição da variabilidade encontra-se na tabela 2.2.
  • 30. 29 Característica Definição Pontos de Variação Determinados pontos em um sistema de software onde decisões são tomadas a respeito, por exemplo, de qual variante será utilizada. Em outras palavras, pontos de variação refletem a parametrização no domínio de uma maneira abstrata e são configuráveis através das variantes. De acordo com a descrição encontrada em (SCHMID, 1997), que considera o uso de frameworks como técnica de reutilização de software, os pontos de variação dão origem aos hot-spots no Projeto do Domínio. Tais hot-spots podem ter diferentes alternativas de configuração, que distinguem as aplicações que serão construídas a partir do framework. Variantes Alternativas de implementação disponíveis para um ponto de variação são denominados Variantes. Em outras palavras, são elementos necessariamente ligados a um ponto de variação, que atuam como alternativas para se configurar aquele ponto de variação. Invariantes Os elementos “fixos”, que não são configuráveis no domínio. Considerando o uso de frameworks como técnica de Projeto de Domínio, tais elementos invariantes são denominados frozen-spots (SCHMID, 1997). Tabela 2.2 Tipos de Características no ambiente Odyssey Seguindo esse princípio podemos verificar que essa classificação é de extrema importância para o desenvolvimento de um projeto baseado em reutilização, pois se identifica quais pontos podem ser configuráveis na aplicação, mais especificamente em seu domínio. Assim demonstramos na figura 2.6 a característica de Transmissão classificada como ponto de variação, e Manual e Automático classificadas como variantes de Transmissão, conforme a notação Odyssey-FEX. Os pontos de variação podem ser mapeados para herança ou implementação de interface em modelos de classes.
  • 31. 30 Figura 2.6 Classificações das características Além da variabilidade, as características também podem apresentar a propriedade da opcionalidade. Esta faz referência à obrigatoriedade de uma característica, ou seja, aqui ela pode ser classificada como mandatória ou opcional. São mandatórias quando necessárias a qualquer aplicação do domínio ou opcionais quando não são necessárias em pelo menos uma das aplicações instanciadas a partir do domínio que a deu origem. Uma característica na notação Odyssey-FEX pode possuir propriedades ortogonais de variabilidade e opcionalidade como demonstrado na figura 2.7. Figura 2.7 Propriedades ortogonais da notação Odyssey-FEX Na notação Odyssey-FEX as características mandatórias têm contorno cheio e as opcionais têm contorno tracejado. No exemplo da Figura 2.5 tem-se Realizar Transferência e Ensino Distância como opcional e Matricular Alunos, Escola e Curso como mandatórios por exemplo, vale lembrar que o conceito dessas características será explicado mais adiante. Em relação aos relacionamentos possíveis entre características, segundo OLIVEIRA (2006), na notação Odyssey-FEX relacionamentos são utilizados para ajudar a expressar o domínio, muitos deles importados da UML (OMG, 2005) como composição, agregação,
  • 32. 31 generalização e assossiação. A tabela 2.3 demonstra os relacionamentos específicos na notação Odyssey-FEX: Representação Descrição Alternativo (Alternative) - Relacionamento entre um ponto de variação e suas variantes, denota a pertinência de uma variante a um determinado ponto de variação. RelacionamentosEspecíficos naOdyssey-FEX Implementado por (Implemented By) - Relacionamento entre Características de Domínio e Características Tecnológicas, ou entre Características Tecnológicas que se encontram em camadas diferentes. Ligação de Comunicação (Communication Link) - Relacionamento existente entre Características de Entidade e Características de Domínio. Cumpre o mesmo papel do relacionamento de associação entre atores e casos de uso na UML (OMG, 2004) Tabela 2.3 Relacionamentos da notação Odyssey-FEX A figura 2.8 representa um exemplo um exemplo de relacionamento: Figura 2.8 Exemplo de relacionamento da notação Odyssey-FEX 2.3 Frameworks A reutilização de software, conforme já mencionado, deve ser utilizada com o propósito de facilitar o trabalho do desenvolvedor de aplicações. Isso se dá, por exemplo,
  • 33. 32 através de um projeto de software genérico, proporcionando uma melhoria na qualidade do sistema, através da reutilização constante do projeto e redução no tempo de desenvolvimento. Com isso, o desenvolvedor que cria aplicações se concentra nos aspectos específicos da sua aplicação. Os frameworks têm esse objetivo de fornecer soluções genéricas e reutilizáveis para variados problemas de projeto de software. Um framework é um conjunto de classes cooperantes que constroem um projeto reutilizável para uma classe específica de software (GAMMA et al, 2000). Essa especificação pode ser utilizada para a construção de diferentes domínios, definindo a estrutura geral, divisão de classes e objetos e suas responsabilidades. Os frameworks definem a arquitetura do domínio. De acordo com (GAMMA et al, 2000), os frameworks estão se tornando cada vez mais comuns e importantes. Eles representam a maneira pela qual os sistemas orientados a objetos conseguem maior reutilização. Com os frameworks, é possível criar um software mais rapidamente. Porém, isso reduz a possibilidade de decisões estruturais, pois quase toda a infra-estrutura já foi definida e validada. Além disso, é importante perceber que não se deve criar um framework muito específico para abordar somente um determinado problema de uma aplicação em particular, mas sim visando um domínio como um todo (MOURA, CARVALHO e SILVA, 2006). A arquitetura deve funcionar para todas as aplicações do domínio e conforme uma aplicação evolui, o framework também devem evoluir. Isso mostra que o processo para construir um framework, assim como todo processo de software voltado à reutilização, é muito complexo, pois ele não deve ser encarado como uma aplicação tradicional, e sim permitir uma variação de suas características. Dentro de qualquer domínio, existem as características i.e. (features) que permitem identificar suas funcionalidades e conceitos, assim como as suas variabilidades e opcionalidades. As características comuns a todas as aplicações do domínio e invariáveis dão origem aos frozen-spots (pontos fixos) dos frameworks. Esses pontos fixos são representados por características invariantes e mandatórias e estão definidos no framework de forma inalterável para todas as aplicações do domínio, por exemplo, através de classes concretas. Existem também os hot-spots (pontos variáveis), que representam as características variáveis nas diferentes aplicações de um domínio, ou seja, os pontos de variação e opcionais. Essas características devem ser genéricas, pois devem ser adaptadas às necessidades da aplicação, sendo representadas, por exemplo, através de classes abstratas, métodos abstratos, métodos template e outros padrões de projeto do GAMMA et al (2000).
  • 34. 33 2.3.1 Tipos de Frameworks De acordo com a forma de reutilização, os frameworks podem ser classificados, como: caixa branca (white box); caixa preta (black box) ou caixa cinza (gray box). Nos frameworks caixa branca, o reuso acontece por herança ou extensão, sendo necessário conhecer os detalhes de como o framework trabalha. É importante que o desenvolvedor domine o funcionamento, para a partir disso, criar novas classes que deverão implementar ou estender as classes abstratas. O framework caixa preta não exige que o desenvolvedor conheça os detalhes da implementação do framework, exigindo apenas que a classe use a composição de objetos e delegação em vez de herança. Já nos frameworks caixa cinza, existe uma mistura dos outros dois tipos de frameworks, caixa branca e caixa preta, ou seja, o reuso pode ocorrer por herança e composição simultaneamente. Os frameworks podem ainda ser classificados de acordo com o seu escopo, da seguinte forma: • Frameworks de Infra-estrutura: apóiam a infra-estrutura de sistemas em diferentes domínios de aplicação, oferecendo serviços como persistência, segurança, busca, interfaces gráficas etc. • Frameworks de Integração: são utilizados para integrar aplicações e componentes distribuídos (ex: middleware, como Corba). • Frameworks de Aplicação: são dirigidos a um domínio específico de aplicações, ou seja, a uma família de aplicações em uma determinada área. 2.4 Considerações Finais Este capítulo abordou técnicas de reutilização de software, destacando a importância dessa sub-área na Engenharia de Software. A Engenharia de Domínio, uma das técnicas apresentadas, cria um modelo de domínio de aplicação, que é utilizado como base para a instanciação de aplicações específicas. A Análise de Domínio é uma das principais atividades da ED, pois permite estabelecer o escopo e requisitos do domínio, bem como as suas variabilidades e opcionalidades. As aplicações do domínio são instanciadas com base nessas variabilidades e opcionalidades do domínio.
  • 35. 34 Durante o projeto do domínio, uma arquitetura de software genérica que atenda aos requisitos do domínio é desenvolvida. Ela fornece a entrada para o projeto das aplicações, podendo ser representada como um framework do domínio. As aplicações devem estender e adaptar os hot-spots durante a instanciação do framework. De um modo geral, a principal motivação para a reutilização está relacionada ao aumento dos níveis de qualidade e produtividade no desenvolvimento de software. O aumento de qualidade é uma conseqüência da reutilização de componentes que foram previamente documentados, testados e aprovados. O aumento da produtividade é resultado de uma redução no tempo de desenvolvimento, evitando a reconstrução de partes do sistema que já existem. A partir da Análise de Domínio utilizando a notação Odyssey-FEX, esse trabalho de conclusão de curso tem o objetivo de construir um framework de aplicação para a emissão e controle do Perfil Profissiográfico Previdenciário. Esse framework será analisado e projetado nos capítulos 3 e 4, seguindo os princípios de reutilização de software apresentados neste capítulo.
  • 36. 35 CAPÍTULO 3: ANÁLISE E PROJETO DE DOMÍNIO PARA A CONSTRUÇÃO DO FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO 3.1 Introdução Neste capítulo, as técnicas de reutilização apresentadas no capítulo 2 são aplicadas para a especificação do domínio que envolve a Emissão do Perfil Profissiográfico Previdenciário (PPP). O PPP, como já mencionado, é o documento histórico-laboral do trabalhador, que tem por objetivo informar ao Instituto Nacional do Seguro Social (INSS) as informações administrativas (documentação, cargos exercidos, locais de trabalho etc.), ambientais (riscos no ambiente, concentração etc.), biológicas (exames médicos) e a efetiva exposição do trabalhador a agentes nocivos. O modelo do PPP encontra-se no Anexo A. O ambiente de reutilização Odyssey (ODYSSEY, 2007) é utilizado para apoiar o processo. Esse ambiente aplica a notação Odyssey-FEX (OLIVEIRA, 2006) para a modelagem das opcionalidades e variabilidades do domínio, apresentada no capítulo 2, que define a semântica dos elementos funcionais, conceituais e tecnológicos utilizados na modelagem de domínio, incluindo seus relacionamentos. O capítulo está organizado da seguinte forma: a seção 3.2 apresenta a Análise de Domínio realizada para a determinação dos conceitos e funcionalidades inerentes à emissão do PPP. Na seção 3.2.2 são apresentados os Contextos ou subdomínios com seus respectivos atores. As características dos subdomínios Administração de Pessoal, Segurança e Medicina são apresentadas nas respectivas seções: 3.2.3; 3.2.4 e 3.2.5. A seção 3.3 apresenta o mapeamento do modelo de características para o modelo de classes e por último a seção 3.4 que mostra o mapeamento do modelo de características para o modelo de casos de uso. 3.2 Análise de Domínio Nesse ponto do trabalho, é apresentado o domínio analisado através de descrição textual e modelos.
  • 37. 36 Um dos pontos inerentes ao PPP é que trabalhadores que estejam sujeitos a condições especiais que prejudiquem a sua saúde ou integridade física possuem o direito a Aposentadoria Especial (PR, 1999a). A comprovação do direito a aposentadoria especial será feita mediante Perfil Profissiográfico Previdenciário (PPP), no padrão estabelecido pelo Instituto Nacional do Seguro Social (INSS), como já mencionado pode ser encontrado no Anexo A. Além disso, de acordo com o risco de acidente de trabalho, cada empresa contribui com um percentual diferente, incidindo sobre o total da remuneração paga, a saber: 1 % para risco leve; 2% risco médio; e 3% caso o risco de acidente seja grave. Por exemplo, um trabalhador que exerce a atividade de cultivo de arroz terá 2% do salário recolhido para o INSS, já a atividade de produção de tubos de aço tem recolhimento de 3% (vide site PR, 1999a). É importante destacar que essa contribuição é devida à empresa e não ao funcionário. Uma vez que o domínio que envolve a Emissão do Perfil Profissiográfico Previdenciário é bastante amplo e complexo, optou-se pela sua divisão em subdomínios que são apresentados em diagramas de contextos, de acordo com a notação Odyssey-FEX, onde é possível verificar a interdependência dos mesmos. Para cada subdomínio, são apresentas suas características, relacionamentos, opcionalidades e variabilidades. A partir desse modelo de características, é gerado o modelo de classes, que representa o framework para o PPP, e o modelo de casos de uso, através de regras de mapeamento definidas pela notação Odyssey- FEX. Esse mapeamento é realizado pelo ambiente Odyssey, seguindo as regras propostas por OLIVEIRA (2006), que realiza a consistência Inter-Modelos para possibilitar uma representação coerente dos requisitos de domínio, suas opcionalidades e variabilidades, em diferentes níveis de abstração. Dessa forma, através da proposta da Odyssey-FEX, o domínio do PPP é modelado no ambiente de reutilização Odyssey, onde toda a análise de requisitos é representada, mantendo a opcionalidade e variabilidade das características nos diferentes níveis de abstração do domínio. 3.2.1 Descrição do domínio A Gestão de Recursos Humanos (GRH) tem como objetivo administrar, descobrir talentos, cuidar da saúde e segurança do capital humano. Essa gestão é fundamentada, na
  • 38. 37 maioria dos casos, pela Consolidação das Leis do Trabalho (CLT) e várias outras leis, como: Instruções Normativas (IN), Normas Regulamentadoras (NR), Medidas Provisórias (MP) e acordos coletivos da categoria (vide site do MTE, 2007). Esta Consolidação estatui as normas que regulam as relações individuais e coletivas de trabalho nela previstas (CLT, Art.1º). Essas leis, ou atos administrativos, norteiam as relações do trabalho para os aspectos jurídicos. O domínio de GRH requer adaptações gerencias para atender plenamente as necessidades de cada empresa. Novos problemas organizacionais e gerenciais devem ser tratados para cada caso particular. Dessa forma, apresenta requisitos em comum e requisitos que variam de uma aplicação para outra, justificando a realização de uma Análise de Domínio. Além disso, trata-se de um domínio muito abrangente, pois envolve vários subdomínios, como: Administração de Pessoal; Segurança e Medicina no Trabalho; Recrutamento; Treinamento; Cargos e Salários; e Apontamentos de Horário de Trabalho. Para cada subdomínio, devem ser observadas as leis e os aspectos gerenciais que norteiam o seu funcionamento. Os subdomínios do GRH podem ser definidos da seguinte forma: Administração de Pessoal: envolve a administração de cadastros básicos, como empresas (i.e. filiais), locais de trabalho (i.e. departamentos, setores), cargos, funções, horários de trabalho, salário etc., e seus respectivos históricos, necessários a uma adequada gestão de pessoal. Trata a emissão de uma folha de pagamento, controlando a admissão, férias e rescisões. Segurança: fundamentado pela Norma Regulamentadora da Saúde e Segurança no Trabalho (NR 18) e pelo Programa de Prevenção dos Riscos Ambientais (PPRA - NR 9) (MTE, 2007), o objetivo desse subdomínio é controlar e prevenir acidentes e sinistros, garantindo a integridade física do colaborador em face aos riscos existentes no ambiente de trabalho. Medicina: é regulamentada pelo Programa de controle Médico e Saúde Ocupacional (PCMSO -NR 7) (MTE, 2007). Tem por objetivo manter a prevenção e a promoção da saúde do colaborador e também é norteada pela Instrução normativa 99 de 05/12/2003 (MPS, 2003). Mantém a ficha médica, controla atendimentos, resultados de exames e suas periodicidades etc. Treinamento: envolve o controle da gestão do conhecimento, controle de cursos, instrutores, participantes, alocação de salas, aplicação e correção de avaliações. Recrutamento: administra requisições para aberturas de vagas, vagas em aberto, cadastramento de currículos e triagens para seleções. A admissão,
  • 39. 38 funcionalidade do subdomínio de Administração de Pessoal, só é realizada após as seleções. Dessa forma, esse subdomínio é responsável pela administração dos testes, currículos etc. Cargos e Salários: implementa e controla a política salarial com base nos descritivos dos cargos, requisitos de formação e habilidades, avaliações, carreiras e competências. Apontamentos de Horário de Trabalho: controla os horários de trabalho, escalas de revezamento, realizando o cálculo de horas extras, faltas, atrasos, saídas intermediárias. O objetivo desse subdomínio é controlar e gerenciar os horários, realizando apenas a referência de Homem Hora (HH) trabalhadas, extras e faltas. Já com as quantidades referências lançadas, o subdomínio de Administração de pessoal realiza os cálculos dos valores dessas horas com seus respectivos percentuais. Apesar da abrangência do domínio exposto, o foco do presente trabalho se restringe à emissão do PPP e a todas as funcionalidades e conceitos necessários para embasar esta emissão. A seleção deste recorte do domínio e, conseqüentemente, do estabelecimento deste foco para o presente projeto, se deve ao fato da Instrução Normativa Nº 99 de 5/12/2003 (MPS, 2003) estabelecer a obrigatoriedade desse relatório para todos os trabalhadores a partir de 01/01/2004, dependendo do ramo de atividade da empresa e da exposição a agentes nocivos. Segue na Tabela 3.1 a descrição das situações em que o PPP deve ser emitido pela empresa. Rescisão Por ocasião da rescisão do contrato de trabalho ou da desfiliação da cooperativa, ou do sindicato, o PPP deve ser emitido em duas vias, com fornecimento de uma das vias para o trabalhador, mediante recibo. Simples conferência Para simples conferência por parte do trabalhador, pelo menos uma vez ao ano, quando da avaliação global anual do Programa de Prevenção de Riscos Ambientais - PPRA. Com isso, o trabalhador poderá acompanhar os riscos ambientais a que está submetido e verificar o resultado dos exames médicos. Na requisição da aposentadoria Para fins de requerimento de reconhecimento de períodos laborados em condições especiais. Para fins de análise de benefícios por incapacidade, a partir de 1º de janeiro de 2004, quando solicitado pelo INSS. Por solicitação das autoridades Quando solicitado pelas autoridades competentes. Tabela 3.1 Situações de Obrigatoriedade de Emissão do Perfil Profissiográfico Previdenciário (IN 99, Art. 148 § 8º) (MPS, 2003)
  • 40. 39 Dessa forma, devido à obrigatoriedade de emissão do PPP e da sua importância, pois a empresa que não mantiver o PPP atualizado, ou emitir documentos em desacordo com os respectivos laudos técnicos, estará sujeita à penalidade prevista no Art. 133 da Lei Nº 8.213 de 1991 (PR, 1991b), e ainda devido ao fato do controle da emissão desse relatório ser mais incomum que o controle sobre outras atividades da GRH, ele foi escolhido como foco do presente projeto. A análise de domínio e o desenvolvimento do projeto estão baseados apenas nas características básicas de Segurança, Medicina e de Administração de Pessoal necessárias à emissão e controle do PPP. 3.2.2 Contextos Conforme mencionado, o domínio de GRH está dividido nos seguintes subdomínios: Administração de Pessoal, Treinamento, Recrutamento, Cargos e Salários, Segurança, Apontamentos de Horário de Trabalho e Medicina. Na Figura. 3.1, são apresentados os subdomínios, no ambiente Odyssey, que são representados em diagrama através de contextos (OLIVEIRA, 2006). Através deste diagrama, observamos as ligações dos atores, i.e. usuários do domínio, com seus respectivos subdomínios. Os atores deste domínio são: Profissional de Segurança, Profissional de Medicina e Agente de RH. Na notação Odyssey-FEX, atores são denominados entidades. Abaixo segue uma descrição sucinta dos atores e suas respectivas atribuições. • Profissional de Segurança Responsável pela definição e implantação de rotinas de segurança e no trabalho, analisando riscos por locais e/ou cargos, funções etc. Responsável também pelas definições de distribuição de Equipamento de Proteção Individual (EPI) e Equipamento de Proteção Coletiva (EPC) e acompanhamento/treinamento de rotinas de segurança. • Profissional de Medicina Define e controla o Programa de Controle Médico de Saúde Ocupacional (PCMSO), realiza exames periódicos e laboratoriais. Responsável pela saúde ocupacional da empresa. Realiza atendimentos de emergência.
  • 41. 40 • Agente de RH Responsável pelo controle das rotinas de admissão, férias, rescisões, cadastros de locais, funções, colaboradores, admissões, férias e seus respectivos históricos. Figura 3.1 Diagrama de Contextos do Domínio de Gestão de Recursos Humanos no ambiente Odyssey É possível observar no diagrama de contextos (figura 3.1) a dependência dos subdomínios de Medicina, Segurança, Treinamento, Recrutamento, Cargos e Salários com relação ao de Administração de Pessoal, que contém empresas, colaboradores, cargos, locais, funções e várias outras características que são utilizadas por todos os outros subdomínios. A dependência do subdomínio Medicina com Segurança, observada na figura 3.1 através da seta indicativa, existe devido ao fato das definições do Programa de Prevenção dos Riscos Ambientais (PPRA) serem analisadas primeiramente, sendo possível somente após esta análise de riscos, realizar a montagem do Programa de Controle Médico de Saúde Ocupacional (PCMSO), que irá definir os exames clínicos e laboratoriais de acordo com os riscos, assim como suas respectivas periodicidades.
  • 42. 41 Nas seções a seguir, são analisadas as características desses subdomínios necessárias à implementação e emissão do PPP. 3.2.3 Subdomínio de Administração de Pessoal Esse subdomínio gerencia cadastros básicos do GRH, além de controlar a admissão, emissão da Folha de Pagamento e rescisões de contrato. O Objetivo é manter todas as informações funcionais sobre o funcionário, como, por exemplo, alocação legal do trabalhador na empresa (histórico de filial), alocação gerencial (locais do componente organizacional), muitas vezes denominado departamento ou seção, o cargo ocupado com seus descritivos e suas funções. A seguir, são apresentadas as características desse subdomínio. 3.2.3.1 Características de Cargos e Locais O Cargo é a nomenclatura utilizada para o conjunto de atribuições e a posição hierárquica na empresa, devendo ser registrado no contrato de trabalho e na Carteira de Trabalho e Previdência Social (CTPS). Figura 3.2 Diagrama de Características Conceituas de Cargo Cada cargo possui um código que é a sua Classificação Brasileira de Ocupação (CBO), essa classificação foi construída pelo Ministério do Trabalho e Emprego (MTE) e tem o objetivo de organizar os diferentes programas de políticas no trabalho, facilitando assim o estudo e a geração de informações estatísticas. Sua presença é obrigatória no PPP. Um outro
  • 43. 42 fator importante é a descrição do cargo, que segundo a Instrução Normativa (IN) 99/2003, em seu Anexo XV (MPS, 2003) deve informar a descrição das atividades, físicas ou mentais, realizadas pelo trabalhador, por força do poder de comando a que se submete. O CBO e a descrição representam, dessa forma, características pertencentes a Cargo, conforme mostra a Figura 3.2. No momento do mapeamento para o diagrama conceitual, a característica Descrição irá se transformar em atributo de Cargo, já a característica CBO será mapeada como uma classe. A característica Cargo é um Ponto de Variação (VP) que poderá ser estendido de acordo com a estrutura de cargos existente em cada empresa. A característica de Local tem o objetivo de definir a forma que a empresa utiliza para gerenciar seus componentes organizacionais. Por exemplo, em locais pode ser definido um organograma com dois dígitos por quebra, com a seguinte máscara de divisão: 00 – Gerência 00.00 – Departamento 00.00.00 – Seção Para montar essa estrutura é necessário que cada local tenha uma referência do seu nível hierárquico superior, essa definição pode ser observada na figura 3.3 com o auto- relacionamento de local. A característica de Local é uma estrutura que permite a criação dos componentes que organizam os locais de trabalho em departamentos e/ou seções, gerência ou de qualquer forma que retrata a organização lógica da empresa. Dessa forma, a característica Local representa um Ponto de Variação (VP) que deverá ser estendida através de suas variantes que representam seus departamentos, setores etc. Figura 3.3 Diagrama de Característica Conceituas de Local 3.2.3.2 Características de Colaborador e seus Históricos Outras responsabilidades do subdomínio Administração de Pessoal é manter atualizado todas as movimentações do colaborador, como a mudança de cargo e local. Todas
  • 44. 43 essas movimentações são registradas nos Históricos. Os relacionamentos do colaborador com os históricos, mostram que é possível um colaborador ter vários históricos, como mostra a figura 3.5. Todo aquele que participa de alguma atividade direta ou indireta na prestação de serviço para uma empresa é chamado de colaborador. O diagrama de características apresentado na figura 3.4 apresenta o característica Colaborador como mandatória, pois o colaborador é a principal característica do domínio de GRH e é um ponto de variação, tendo o Empregado e Terceiro como suas variantes opcionais, devido à possibilidade uma empresa possuir somente Terceiros ou somente Empregados. Conforme apresentado no capítulo 2, os pontos de variação são mapeados para hot-spots. Tais hot-spots podem ter diferentes alternativas de configuração, que distinguem as aplicações que serão construídas a partir do framework. Apesar da característica conceitual Colaborador na figura 3.4, não demonstrar graficamente a opção de Ponto de Variação (VP), o relacionamento de Colaborador para Empregado/Terceiro representa essa definição, tendo o Colaborador como (VP) e Terceiro/Empregado como suas variantes. Figura 3.4 Diagrama de Características Conceituas do Colaborador O empregado é todo aquele que tem um vínculo empregatício com a empresa, onde essa instituição é responsável pelo pagamento de salário, recolhimento de impostos e emissão de documentos legais exigidos pelo MTE. O Terceiro, por sua vez, é todo profissional que atua sem vínculo empregatício com a empresa na qual está prestando serviço, porém existem vários aspectos legais que a empresa tomadora de serviço é obrigada a administrar, por exemplo, a estrutura do PPRA. Segundo a legislação, a empresa contratante de serviços de terceiros deverá informar à contratada os riscos ambientais relacionados à atividade que desempenha e auxiliá-la na elaboração e na implementação dos respectivos do Programa de
  • 45. 44 controle Médico e Saúde Ocupacional (PCMSO) e Programa de Prevenção dos Riscos Ambientais (PPRA) (MPS, 2003). A empresa deve manter toda a estrutura funcional de seus colaboradores atualizada em históricos de cargos pelos quais cada um deles já passou, locais de trabalho e funções, registrando a data da mudança. Esses históricos estão presentes na seção de dados administrativos, nos campos lotação e atribuição do PPP, como mostra o Anexo A. Os relacionamentos do colaborador com os históricos, mostram que é possível um colaborador ter vários históricos, como mostra a Figura 3.5. Cada histórico deve conter a data início e a data fim do colaborador no cargo, local, função etc. Figura 3.5 Diagrama de Características Conceituas dos Históricos do Colaborador O relacionamento de associação de Empresa com relação ao Colaborador, identifica para qual empresa o colaborador possui vínculo. As características Colaborador e Empresa são mandatórias. Para empresas que possuem várias filiais, a característica HisLotacao, que representa as trocas de entre filiais da mesma empresa ou para empresa tomadoras de serviço.
  • 46. 45 Essa característica é representa no campo 13.2 do PPP, onde é apresentado através do CNPJ/CEI da filial ou da tomadora de serviço. O Histórico de Local (HisLocal) representa o campo 13.3 do PPP, onde deverá ser indicada todas as trocas de locais, i.e. setores ou departamentos no qual o trabalhador atuou. A diferença do Histórico de Local (HisLocal) para o Histórico de Filial (HisLotacao) é devido o histórico de local representar, apenas, a estrutura organizacional gerencial da empresa, já o Histórico de Filial representa uma característica opcional que demonstra a alocação legal do trabalhador. A Função muitas vezes é confundida com cargo, porém ela indica um conjunto de tarefas utilizadas para implementar a departamentalização. A Instrução Normativa 99/2003, em seu Anexo XV (MPS, 2003) revela que a função é o lugar administrativo na estrutura organizacional da empresa, onde o trabalhador tenha atribuição de comando, chefia, coordenação, supervisão ou gerência. Função é uma característica de opcional, como mostra a Figura 3.5, todas as trocas de funções devem ser realizadas nos históricos de função HisFunção. Diferentemente de cargos, funções não apresentam a CBO. O Histórico de Registro Ambiental e Biológico (HisRegAmbBio), característica mandatória que registra os colaboradores responsáveis pelas informações ambientais e biológicas. Segundo Instrução Normativa 99/2003, em seu Anexo XV (MPS, 2003), o PPP deve apresentar informações sobre os responsáveis pelos registros ambientais e biológicos, por período. No diagrama de Classes (Apêndice B), é possível verificar a presença de um atributo denominado tipReg, na classe HisRegAmbBio Esse atributo é responsável por classificar o histórico como registro ambiental ou biológico. Por isso, cada característica HisRegAmbBio (figura 3.5) possui apenas o relacionamento para 1 (um) colaborador. A Comunicação de Acidente de Trabalho (CAT), característica apresentada na figura 3.5, deve ser emitida e apresentada a Previdência Social no máximo em 24 horas, após o acidente. Essa notificação é realizada através do formulário chamado (CAT). Esse formulário apresenta informações de dados sobre a documentação do empregador, colaborador, informações sobre o acidente e atendimentos médicos. Para a emissão do PPP, de acordo com a Instrução Normativa 99/2003, em seu Anexo XV (MPS, 2003), só são necessárias as seguintes informações: Registro da CAT na Previdência Social; Data do Acidente e o Número da CAT. De acordo com o relacionamento de Colaborador para a CAT, um colaborador pode ter se acidentado várias vezes ou nenhuma.
  • 47. 46 3.2.4 Subdomínio de Segurança Este subdomínio trata da parte de Segurança do Trabalho. Com o conceito de reutilização, um software pode ser usado tanto para uma indústria como para uma loja. Com isso, o conceito de segurança se torna totalmente diferente, pois os riscos que existem em uma indústria são muito diferentes dos riscos existentes em uma loja, e até mesmo os riscos de uma loja podem ser diferentes dos riscos de outra. Portanto, a segurança é definida de um modo genérico, para que cada empresa possa ajustar a sua realidade, de acordo com os seus riscos. A segurança em um ambiente de trabalho, na verdade, representa um conjunto de medidas que visam extinguir, ou pelo menos minimizar, qualquer risco que venha a causar algum acidente ou doença ocupacional no setor de trabalho, buscando proteger a integridade do trabalhador bem como a sua capacidade de trabalho. A Segurança do Trabalho estuda diversas disciplinas como Introdução à Segurança, Higiene e Medicina do Trabalho, Prevenção e Controle de Riscos em Máquinas, Equipamentos e Instalações, Psicologia na Engenharia de Segurança, Gerência de Riscos etc. No entanto, é dada ênfase apenas à parte de segurança, prevenção e doenças causadas por más condições do ambiente de trabalho, pois é o que interessa para o propósito do projeto, que é a emissão do PPP. De acordo com a Norma Regulamentadora 9 - Riscos Ambientais (NR9) da Secretaria de Segurança e Saúde no Trabalho do Ministério do Trabalho e Emprego (MTE, 2007), todo empregador ou instituição que admite trabalhador e mantém algum vínculo empregatício é obrigado por lei a implantar um Programa de Prevenção a Riscos Ambientais (PPRA), que tem por objetivo a prevenção da saúde dos trabalhadores através da antecipação e do reconhecimento das condições e dos riscos no ambiente de trabalho, tanto aqueles que já existem quanto aqueles que ainda surgirão, para que após reconhecidos, eles possam ser controlados. Esses riscos podem ser físicos, químicos ou biológicos. Por isso o reconhecimento antecipado é tão importante, pois sendo conhecido pode-se então estudar o risco e se descobrir formas de controlá-lo. O objetivo principal da segurança é evitar a ocorrência de acidentes, ou a presença de agentes causadores de danos à saúde. Além de visar evitar também a exposição do trabalhador a estes agentes ou a condições adversas que possam vir a causar algum tipo de dano a sua saúde. Segue a descrição das características deste subdomínio.
  • 48. 47 3.2.4.1 Características dos Riscos De acordo com cada ambiente de trabalho, os riscos são diferentes. A legislação de segurança do trabalho brasileira considera como riscos ambientais, aqueles relacionados a agentes físicos, químicos e biológicos. Os agentes físicos são aqueles decorrentes de processos e equipamentos produtivos e podem ser: • ruídos e vibrações; • pressões anormais em relação a pressão atmosférica; • temperaturas extremamente altas ou baixas e; • radiações ionizantes e não-ionizantes. Os agentes químicos são aqueles decorrentes de manipulação e processamento de matérias primas, onde se destacam: • poeiras; • fumos, névoas e neblina; • gases e vapores. Os agentes biológicos são aqueles oriundos da manipulação, transformação e modificação de seres vivos microscópicos, como: • genes; • bactérias; • fungos; • bacilos; • parasitas; • protozoários; • vírus e outros. Figura 3.6 Diagrama de Características Conceituais de Risco A figura 3.6 mostra que um risco tem um tipo e um tipo pode ter de zero a vários riscos associados a ele e também o PPRA (Programa de Prevenção a Riscos
  • 49. 48 Ambientais) é feito para um risco somente, mas um risco pode ter de zero a vários PPRAs associados a ele. Tabela 3.2 Limites de tolerância para ruído contínuo ou intermitente Para que sejam considerados fatores de riscos ambientais, os agentes físicos, químicos ou biológicos precisam estar presentes no ambiente de trabalho em determinadas concentrações e intensidades e o tempo máximo de exposição do trabalhador a eles é determinado por limites pré-estabelecidos. Na NR15 denominada Atividades e Operações Insalubres, revelado que: entende-se por Limite de Tolerância, para os fins desta Norma, a concentração ou intensidade máxima ou mínima, relacionada com a natureza e o tempo de exposição ao agente, que não causará dano à saúde do trabalhador, durante a sua vida laboral (MTE, 2007). Isto significa que deve existir um limite para que o trabalhador fique exposto ao Nível de ruído dB (A) Máxima exposição diária PERMISSÍVEL 85 8 horas 86 7 horas 87 6 horas 88 5 horas 89 4 horas e 30 minutos 90 4 horas 91 3 horas e trinta minutos 92 3 horas 93 2 horas e 40 minutos 94 2 horas e 15 minutos 95 2 horas 96 1 hora e 45 minutos 98 1 hora e 15 minutos 100 1 hora 102 45 minutos 104 35 minutos 105 30 minutos 106 25 minutos 108 20 minutos 110 15 minutos 112 10 minutos 114 8 minutos 115 7 minutos
  • 50. 49 risco, este limite varia de acordo com risco a que ele é exposto e, portanto, varia de risco para risco. No diagrama de classe (Apêndice B), é possível perceber isto, através da classe PPRA que tem associada a ela o risco, que por sua vez tem associada a si o tipo de risco, onde é definido a que grupo este risco pertence. Com isso, é possível analisar este risco e aferir sua intensidade para determinar o tipo de PPRA que será montado. Como exemplo, veja a tabela 3.2, dos limites estabelecidos para nível de ruído medidos em decibéis (dB). A função do departamento de Segurança de uma empresa é justamente a identificação de todos os riscos existentes, e que poderão vir a existir em função da alteração de um processo produtivo, da troca de uma máquina, da mudança de um ambiente de trabalho etc., que possa vir a causar danos aos trabalhadores daquele setor. 3.2.4.2 Características dos Equipamentos de Proteção Os equipamentos de proteção individual (EPIs) e equipamentos de proteção coletiva (EPCs) são equipamentos destinados à proteção dos trabalhadores a riscos que ameacem a sua segurança e que não foram eliminados por meio de métodos organizacionais. O EPI é todo meio ou dispositivo de uso pessoal destinado a proteger a integridade física do trabalhador durante a sua atividade laboral. Ele visa neutralizar a ação do agente causador de acidente contra o corpo da pessoa que usa o equipamento. Como exemplo, tem-se: luvas, óculos de proteção, capacetes, botas etc. Os EPCs, por sua vez, representam equipamentos de proteção coletiva, devendo proteger todos os trabalhadores expostos a determinado risco. Como exemplo, podemos citar o enclausuramento acústico de fontes de ruído, a ventilação dos locais de trabalho, a proteção de partes móveis de máquinas e equipamentos, a sinalização de segurança, a cabine de segurança biológica, capelas químicas, cabine para manipulação de radioisótopos, extintores de incêndio, dentre outros. Os EPIs e os EPCs entram na montagem do PPRA como um meio de proteção ao trabalhador, caso o risco não tenha sido amenizado por outra forma qualquer. Eles estão associados ao PPRA, figura 3.7 (vide também diagrama de classe no Apêndice B), e será utilizado aquele que for mais conveniente ao tipo de risco à que ele se destina.
  • 51. 50 3.2.4.3 Características do PPRA O PPRA tem a finalidade de aplicar técnicas de higiene e segurança ocupacional, definindo assim uma política com a direção da empresa e atribuindo responsabilidades, integrando toda a organização e envolvendo e comprometendo empregados e empregadores. A responsabilidade pela elaboração e implementação do Programa é total do empregador, que deve cuidar de sua eficácia, sua abrangência e intensidade, que será diferenciada em cada local, cargo ou função, dependendo do risco e da necessidade de controle. O objetivo principal do PPRA é evitar a ocorrência de acidentes, ou a presença de agentes causadores de danos à saúde, assim também como a exposição do trabalhador a estes agentes ou a condições adversas que podem vir a causar algum tipo de dano à sua saúde. Para a montagem de um PPRA, geralmente uma firma especializada é contratada para fazer o levantamento dos riscos, ou caso a empresa possua o SESMT (Serviço Especializado em Segurança e Medicina no Trabalho) este setor é responsável por este levantamento, que serve para descobrir a existência ou não dos riscos presentes no ambiente de trabalho através de medições das concentrações dos contaminantes (substâncias e compostos químicos) ou das intensidades dos agentes físicos (ruído, vibrações, calor, etc), para posterior comparação com os respectivos limites de tolerância da NR 15 (MTE, 2007) ou American Conference of Governamental Industrial Hygienists (ACGIH) (PRESTOMED, 2007). No caso de existir um risco que sua intensidade seja nociva à saúde (vide tabela 3.2, por exemplo), é emitido o Laudo Técnico de Condições Ambientais do Trabalho (LTCAT), que é um parecer circunstanciado e conclusivo das condições ambientais a que o funcionário foi exposto, devendo, contudo, refletir a realidade no momento da consecução da vistoria (PRESTOMED, 2007). Após a emissão do LTCAT é função do engenheiro do trabalho identificar quem está submetido ao risco, em quais cargos, locais, funções etc. estarão sujeitos à ação nociva do risco e tentar amenizar esta ação através do PPRA. Caso o risco não seja amenizado ao ponto de não causar danos à saúde são utilizados EPIs, ou EPCs para se tentar atenuar ou reduzir a nocividade do agente de modo a neutralizar seus efeitos no colaborador daquele cargo, local ou função.
  • 52. 51 Figura 3.7 Diagrama de Características Conceituais do PPRA A característica conceitual PPRA, apresenta na figura 3.7, é mandatória, sendo um Ponto de Variação (VP) e tem como suas variantes: PPRACargo, PPRACargoLocal, PPRALocal, PPRAColaborador e PPRAFuncão que são características opcionais. Portanto, numa implementação específica do framework serão pontos variáveis do PPRA. O risco também é uma característica conceitual mandatória, e será selecionado de acordo com o PPRA, cada PPRA apresenta um único Risco. A montagem de um PPRA poderá ser feita pela combinação de um cargo, local, por um cargo em um determinado local ou função. O PPRA deve ser montado para um risco específico, após isso o engenheiro de segurança no trabalho irá analisar se o risco está associado a um colaborador, uma função, cargo ou local. Estas características se relacionam com seus determinantes, por exemplo, o PPRACargo se relaciona com o Cargo, e assim por diante. A figura 3.8 apresenta as características funcionais do PPRA. Essas características, de acordo com a notação Odyssey-FEX (OLIVEIRA, 2006), podem ser mapeadas para casos de uso ou métodos das classes. Esse mapeamento será realizado na seção 3.2.7.
  • 53. 52 Figura 3.8 Diagrama de Características Funcionais da montagem do PPRA 3.2.5 Subdomínio Medicina A base do subdomínio de Medicina está no Programa de Controle Médico de Saúde Ocupacional (PCMSO) de que trata a Norma Regulamentadora 7 – Exames Médicos (NR7), previsto pelo MTE, sob o número 3214 de 08/06/1978 (MTE, 2007). O PCMSO tem o objetivo de promoção e preservação da saúde do conjunto dos seus trabalhadores. A NR7 estabelece os parâmetros mínimos e diretrizes gerais, norteada com a Instrução Normativa Nº 99 de 5/12/2003 (MPS, 2003), a serem observados na execução do PCMSO, podendo os mesmos serem ampliados mediante negociação coletiva de trabalho. Os riscos existentes devem ser estudados e informados a comissão responsável para implementação do PCMSO. O PCMSO deve considerar aspectos individuais e coletivos dentro de um ambiente de trabalho, relacionando a saúde e o trabalho. Um médico só estará apto para elaborar o PCMSO, após ser realizado o levantamento de riscos ou quando o próprio cargo exige um PCMSO (MPS, 2003). O subdomínio de medicina está voltado para referenciar a parte de controle médico dentro de uma empresa, como por exemplo: ficha médica, atendimentos, exames etc., porém na próxima seção serão aborados somente os dados do PPP em seus pontos relevantes,
  • 54. 53 estando mais voltado para os Exames Médicos Clínicos, Complementares e Monitoração Biológica que são regidos através de quadros específicos a serem seguidos para complemento do PPP. Segue a descrição das características deste subdomínio. 3.2.5.1 Características do PCMSO O Programa de Controle Médico de Saúde Ocupacional (PCMSO) deve ser aplicado em caráter de prevenção, rastreamento e diagnóstico precoce dos agravos à saúde relacionados ao trabalho, inclusive de natureza subclínica, além da constatação da existência de casos de doenças profissionais ou danos irreversíveis à saúde dos trabalhadores. Esse recurso deve estar presente em todas as empresas, não só as que possuem uma quantidade considerável de funcionários, mas todas, principalmente as que têm possibilidades de riscos maiores. Figura 3.9 Diagrama de características conceituais de PCMSO Como mostra a Figura 3.9, o PCMSO é abordado como um ponto de variação, pois pode-se observar que existem as características opcionais que estão ligadas a ele, ou seja, que
  • 55. 54 o compõe para formar os dados dos exames. Essas características são definidas como variantes, pois é necessário apenas uma delas para montar o PCMSO. No caso, por exemplo, de PCMSOLocalCargo tem-se o relacionamento de um local e um cargo ao mesmo tempo, devido a Local e Cargo poderem simbolizar algo que ocorre ao mesmo tempo nessas características. Por exemplo, existe uma bactéria que causa danos à saúde em um determinado local, mas que afeta somente os trabalhadores de um determinado cargo que utiliza um material de trabalho, que em contato com essa bactéria pode penetrar na pele e causar câncer, assim o PCMSO deve controlar e definir exames para os trabalhadores, que estão alocados dentro daquele local e exercem o cargo específico. O relacionamento de PCMSO com Exame identifica quais exames deverão ser emitidos para determinado PCMSO, ou seja, observando as relações de cargo, local e função, é possível ver qual caminho seguir no exame. O exame pode ou não estar ligado a vários PCMSOs, mas o PCMSO necessariamente deve estar ligado a um exame. A característica conceitual de exame irá compilar todas essas informações de acordo com os riscos levantados pelo PPRA, ou seja, a característica de exame agrupa todos os dados relacionados aos exames exigidos pelo PCMSO em função dos riscos apresentados, dessa forma o médico do trabalho tem autonomia para identificar os exames necessários de acordo com o local, cargo, função, entre outros fatores adjacentes. Pode-se reafirmar, de um modo geral, que o principal objetivo do PCMSO é a promoção e a preservação da saúde dos trabalhadores, bem como a prevenção e diagnóstico precoce das doenças relacionadas às funções desempenhadas e ao ambiente de trabalho a que se submete o colaborador de uma empresa, realizado potencialmente pelo Médico do Trabalho especializado. Vale ressaltar que as características ligadas ao ambiente de trabalho devem estar ligadas previamente ao PPRA, pois este é que vai determinar os riscos nos quais os trabalhadores estão expostos num determinado ambiente. 3.2.5.2 Características dos Exames O exame é um dos pontos mais importantes a ser abordado no subdomínio de Medicina junto ao PCMSO, pois ele está relacionado com o PPRA. Aqui deve-se obter de forma geral informações sobre os exames médicos obrigatórios, clínicos e complementares, realizados para o trabalhador, constantes nos Quadros I e II, da NR-07 do MTE (MTE, 2007).
  • 56. 55 As avaliações clínicas devem abranger anamnese ocupacional e exame físico e mental, de acordo com os tipos de exames exigidos. Figura 3.10 Diagrama de características conceituais de Exame A Figura 3.10 apresenta a característica conceitual de exame que deve estar relacionada com as características conceituais de ItemExame e TipoExame. Assim identifica- se que um exame vai estar ligado a um tipo de exame, e o exame definirá os itens de exame a serem tratados ou avaliados. No item de exame deve estar toda a relação de itens para um determinado exame. Deve estar vinculado a tabela de agentes biológicos de que dispõe a NR4 (MTE, 2007). Os tipos de exames são: admissional, periódico, de retorno ao trabalho, de mudança de função, demissional, entre outras. Um exame admissional, por exemplo, trata dos exames que devem ser realizados antes que o trabalhador assuma suas atividades e o de retorno ao trabalho obrigatoriamente no primeiro dia da volta ao trabalho, no caso de ausência igual ou superior a 30 dias, por motivo de acidente de natureza ocupacional ou não, afastamento por doença, parto, etc. 3.2.5.3 Histórico de Exames Os históricos dos exames devem mostrar todas as situações ocorridas com o colaborador alocado na empresa, ou seja, todos os exames realizados pelo mesmo. O Histórico de Exames deve estar diretamente ligado ao Exame, pois ele define todo o mapa de risco através dos resultados dos exames que relacionam os itens de exames avaliados em um determinado exame. Essa característica tem o objetivo de descrever os exames realizados pelo colaborador, identificando os pontos a serem considerados para emissão de um PPP, como períodos dos exames ou entre os exames, resultados positivos ou negativos, natureza dos exames e tipo de exame.
  • 57. 56 Figura 3.11 Diagrama de características conceituais de Histórico de Exame Como mostra a Figura 3.11, a característica conceitual de HisExame está relacionada com o Exame e o Colaborador. Um colaborador pode possuir vários históricos de exame relacionados a exames específicos. Os exames devem ser compostos por itens requeridos como citado anteriormente, e esses itens geram resultados nos exames. Os resultados gerados devem constar no histórico de exame para ser atribuído a um colaborador. De um modo geral pode-se referenciar um histórico de exame como sendo os exames realizados por um colaborador dentro da empresa em datas específicas, ou seja, quando da necessidade da realização de um determinado exame. 3.3 Mapeamento do Modelo de Características para o Modelo de Classes A partir do modelo de características implementado no Odyssey, será gerado o modelo de classes da Unified Modeling Language (UML). O ambiente Odyssey usa alguns estereótipos para diferenciar variabilidade e opcionalidade dos elementos no modelo de classes, geradas a partir das características. Características conceituais podem ser mapeadas para uma classe ou atributo, já as características funcionais podem ser mapeadas para um caso de uso ou método. As opcionalidades devem ser apresentadas no diagrama com o estereótipo <<optional>>. Os pontos de variação devem ser expressos com a notação <<vp>>, o que significa que essa classe pode ser modificada de acordo com a necessidade da aplicação,
  • 58. 57 sendo esses pontos também conhecidos como HotSpots. Ainda temos o estereótipo <<variant>> que indica as alternativas de configuração de um determinado VP. A seguir são apresentados exemplos de mapeamentos de características para o Modelo de Classes. Figura 3.12 Diagrama de Classes de parte do subdomínio de Administração de Pessoal – Características de Colaborador A figura 3.12 demonstra o mapeamento para o subdomínio de Administração de Pessoal a partir do modelo de características apresentado na figura 3.5. Pode-se perceber a indicação de características opcionais através do estereótipo citado anteriormente <<optional>>, demonstrado através de HisLotação, Empregado, e Terceiro, por exemplo. As classes Empregado e Terceiro são as alternativas de configuração de Colaborador, essas alternativas não são excludentes, ou seja, podem as duas coexistirem numa mesma aplicação. O estereótipo <<Abstract>>, em Colaborador, demonstra que a classe deve ser estendida em Empregado ou na classe Terceiro, herdando os métodos e atributos da classe Colaborador. Vale ressaltar que para alguns pontos de variação ou hotspots, as opções de extensão não precisam ficar explícitas no modelo de domínio.
  • 59. 58 Na figura 3.13, identifica-se pontos de variação <<vp>> como Função e Hisfunção, que conforme explicação dada anteriormente, indica que são pontos de configuração das aplicações do domínio, nesse caso no subdomínio de Administração de Pessoal. Figura 3.13 Diagrama de Classe do subdomínio de Administração de Pessoal - Históricos Na figura 3.14, pode-se observar o ponto de variação <<vp>> existente no PPRA e suas variações <<variant>> através de PPRALocal, PPRACargo, PPRALocalCargo, PPRAFuncao e PPRAColaborador, que se encontram no modelo de classes do Apêndice B. O estereótipo <<absract>> significa que todos os pontos de variação irão estender o PPRA. A classe PPRA é uma das mais importantes na arquitetura do PPP e está diretamente ligado aos riscos a que o colaborador está submetido.
  • 60. 59 Figura 3.14 Diagrama de Classe do subdomínio de Segurança – Montagem do PPRA Os métodos montrarPPRA, selecionarRiscos da classe PPRA (figura 14), são características funcionais no modelo da figura 3.7 e foram mapeadas para métodos, através de uma opções de heurísticas do Odyssey. A figura 3.15 demonstra a heurística, onde é possível escolher o tipo do mapeamento que será gerado. Figura 3.15 Opções de Mapeamentos no Odyssey A figura 3.16 demonstra parte do modelo de classes do subdomínio de Medicina, correspondente ao modelo de características da Figura 3.11.
  • 61. 60 Figura 3.16 Diagrama de Classe do subdomínio de Medicina - Históricos O mapeamento do metamodelo de características Odyssey-FEX para o diagrama de classes da UML tem o intuito de representar as variabilidades em artefatos de níveis de abstração mais baixos, bem como verificar a consistência inter-modelos. O diagrama de classe completo para emissão e controle do PPP encontra-se no Apêndice B. 3.4 Mapeamento do Modelo de Características para o modelo de Casos de Uso O Modelo de casos de uso foi obtido através de características funcionais. A Figura 3.17 apresenta o resultado do mapeamento de parte das características funcionais para o modelo de casos de uso realizado no ambiente Odyssey. Vale ressaltar que as características funcionais do diagrama de características foram mapeadas para casos de uso, mas existem casos em que uma característica funcional é mapeada para um método de uma classe. Quando isso acontece seu mapeamento para o caso de uso deve ser desabilitado. A figura 3.18 demonstra o mapeamento de características funcionais para casos de uso no ambiente Odyssey.
  • 62. 61 Figura 3.17 Diagrama de Casos de Uso Figura 3.18 Wizard de mapeamento de características funcionais para casos de uso no ambiente Odyssey O ambiente Odyssey já gera algumas partes dos casos de uso, aqui foi gerado automaticamente os casos de uso relacionados com a parte de segurança. Alguns exemplos de mapeamentos apresentados na Figura 3.17 são os seguintes: • Seguindo as regras de mapeamento de BLOIS (2006), implementadas no Odyssey, os relacionamentos de agregação no diagrama de características foram mapeados com a notação <<include>> , ou seja, uma inclusão dos casos de uso: Selecionar EPIEPC, Selecionar Risco e Registrar Item de Exame nos casos de uso base.
  • 63. 62 • As características funcionais opcionais, mostradas na Figura 3.9, foram mapeadas para <<extends>>, pois estas são as variantes de MontarPPRA, que é um ponto de variação, tornando-se então casos de uso de extensão do caso de uso base. • O caso de uso Cadastrar Resultado dos Exames foi mapeado com a notação <<optional>>, devido o PPP não exigir os resultado dos exames por item aferido. Por exemplo, em um exame de Hemograma Completo são analisados vários itens, porém o PPP só exige as opções: Normal ou Alterado. • O ponto de variação é explicitado com o estereótipo <<variation point>> em Montar PPRA e a variante com <<variant>> nos casos de uso SelecionarColaborador, SelecionarLocal, SelecionarCargo e SelecionarFunção. A descrição dos casos de uso se encontra no Apêndice A.
  • 64. 63 CAPITULO 4: TECNOLOGIAS EMPREGADAS NO FRAMEWORK 4.1 Introdução Para o desenvolvimento de um software, seja ele científico, comercial ou acadêmico, os profissionais envolvidos neste processo, passam por um grande desafio, pois “Projetar software orientado a objetos é custoso, mas projetar software reutilizável orientado a objetos é ainda mais custoso” (GAMMA., 2000). O paradigma da orientação a objetos existe desde o inicio da década de 70, mas mesmo nos dias de hoje, ainda não é totalmente adotado por boa parte dos programadores, mesmo comprovada a sua eficácia. O problema de se desenvolver software com linguagens procedurais, é que estes softwares costumam serem pouco reutilizáveis e também de difícil manutenção. Este fato acaba por delimitar o tempo de vida do software, pois uma aplicação que seja inflexível, pouco manutenível e resistente a mudanças está praticamente com seus dias contados e será rapidamente descartada, devido ao grande avanço das tecnologias atualmente. Por outro lado, o software que foi criado utilizando as melhores práticas de orientação a objetos, aliado às técnicas de reutilização e frameworks será flexível, seja para mudanças de requisitos do usuário ou mudanças das tecnologias, e terá a sua expectativa de vida aumentada. Visto isso, este é o grande desafio para os desenvolvedores, criar softwares reutilizáveis no paradigma de orientação a objetos, para poder usufruir todas as vantagens oferecidas por este paradigma e pela reutilização. Este capítulo visa à representação das tecnologias empregadas para a construção do framework como linguagem e serviços associados à arquitetura, ao passo que nos capítulos anteriores (2 e 3) é feito uma abordagem às técnicas de análise e modelagem do sistema e a modelagem do sistema em si. Como exemplo, parte dos códigos necessários para implementação do controle de Cargos para o PPP foram inclusos no Apêndice C.
  • 65. 64 4.2 Java Enterprise Edition Este trabalho foi baseado em Java Enterprise Edition (JEE), que é voltada para aplicações multicamadas. O Java EE (JAVA 2EE ou Java 2 EnterpriseEdition) é uma plataforma de programação de computadores que faz parte da plataforma Java. Esta plataforma é voltada para criar soluções do lado do servidor, oferecendo soluções para acesso remoto de clientes a objetos e serviços instalados em um servidor de aplicações. A especificação Java EE fornece a implementação de recursos fundamentais para a implantação de quaisquer aplicações profissionais, como segurança na comunicação entre o cliente e o servidor de aplicações, controle simples e eficiente de transações, e muito mais (SILVA e MOREIRA, 2006). Ela é voltada para a criação de aplicações multicamadas baseadas em componentes que são executados em um servidor de aplicações. Esta plataforma contém uma série de especificações, cada uma com funcionalidades distintas, dentre elas as que foram usadas neste trabalho foram: EJB (Enterprise JavaBeans) – implementa o gerenciamento de objetos de negócio no servidor, JSP (JavaServer Pages)- uma especialização do servlet que permite que conteúdo dinâmico seja facilmente desenvolvido, Servlet - utilizados para o desenvolvimento de aplicações Web com conteúdo dinâmico e JPA (Java Persistência API) – um framework utilizado para controlar a persistência dentro do Java, que serão descritas mais detalhadamente a seguir. 4.2.1 Arquiteturas Multicamadas Existem diversos padrões arquiteturais que podem ser aplicados em um sistema, mas um padrão bem conhecido e aplicado durante a concepção de um software é o padrão Camadas (BUSCHMANN, 1996), onde a arquitetura é dividida em vários tipos de componentes, que possuem responsabilidades bem definidas. Aqui foram usadas três camadas: modelo, visão e controlador. O modelo encapsula os dados e a funcionalidade do negócio, sendo independente de representações de saída e tratamento das interações dos usuários com a aplicação; a visão mostra as informações para os usuários, sendo responsável pelos formatos de saída específicos e obtendo seus dados a partir do modelo; e o controlador
  • 66. 65 trata os eventos de entrada dos usuários disparados nas interfaces, que são traduzidos para requisições de serviços ao modelo ou à visão (VASCONCELOS, 2007). A arquitetura multicamadas pode ser dividida da seguinte forma: • Apresentação: camada responsável pela interface do programa, por exemplo, as páginas JSP. • Lógica de Negócio: camada onde residem as tarefas e regras que governam o processo e que definem a maneira como os dados serão acessados e processados. • Persistência: camada responsável por salvar o estado do objeto, geralmente em um SGBD (Sistema gerenciador de Banco de Dados). • Arquitetura Java EE 5 está centrada na arquitetura de cinco camadas, onde cada camada está logicamente separada e fracamente acoplada com a camada adjacente (ALUR, MALKS e CRUPI, 2003). Figura 4.1 Arquitetura Lógica do Java EE 5 (SILVA e MOREIRA, 2006). A Figura 4.1 mostra a distribuição de 5 camadas, destacando as três camadas envolvidas diretamente por tecnologias da Arquitetura Java EE 5. 4.2.2 Servidor de Aplicação Em informática, um servidor é um sistema de computação que fornece serviços a uma rede de computadores. Os servidores de aplicação são responsáveis por fornecer serviços que
  • 67. 66 os sistemas distribuídos necessitam e que são muito complexos de se desenvolver, por isso eles foram criados para que os profissionais de desenvolvimento não percam o foco e se concentrem apenas na implementação e lógica do negócio. Alguns dos serviços que todo servidor de aplicações deve providenciar são (ROMAN et al., 2004): • Invocações de método remoto: o cliente deve conectar-se aos componentes implantados no servidor por meio de uma conexão de rede. Questões como solicitações de métodos e gerenciamento de parâmetros devem ser tratadas de forma transparente para o cliente. • Balanceamento de carga: os servidores de aplicação podem atender a centenas (e até milhares) de clientes simultaneamente. Caso um servidor esteja sobrecarregado, os clientes devem ser dirigidos para o servidor com a carga mais leve. • Recuperação de falhas transparente: os clientes deverão ser redirecionados para outros servidores sem interrupção de serviço se um servidor ou a rede cair, em uma velocidade aceitável para o problema do negócio. • Clustering: é o processo de replicar o estado de um servidor de aplicação para todos os outros servidores, de modo que os clientes possam utilizar um servidor diferente caso o servidor que tenha as informações falhe. Dentre os servidores disponíveis no mercado, o JBoss é hoje, sem dúvida nenhuma, o servidor de aplicação que mais vem chamando a atenção no mundo J2EE (JBOSS, 2007), e foi o servidor escolhido para a implementação neste trabalho. Várias características fazem dele uma opção inteligente. O JBoss é um container que possui o desenvolvimento mais ativo do mercado por se tratar de um produto Open Source, tendo no mundo uma grande comunidade de desenvolvimento. Este container dá liberdade para se desenvolver aplicações que utilizem EJB (Enterprise Java Beans), aplicações WEB em JSP, e outros recursos como camada de persistência de dados Hibernate. É um Servidor JavaEE completo e certificado, e é um produto robusto e maduro, validado por grandes aplicações em grandes empresas. O JBoss é baseado em uma arquitetura de microkernel JMX (Java Management Extensions), onde todos os módulos que compõem o servidor, além das próprias aplicações, são componentes (MBeans) - plugados- ou substituídos dinamicamente, em tempo real, sem a necessidade de paradas no servidor. Esta funcionalidade proporciona grande flexibilidade e robustez ao servidor.
  • 68. 67 Num cenário atual, onde os desenvolvedores têm cada vez maiores restrições orçamentárias, mas ao contrário enormes pressões para resultados cada vez maiores, uma alternativa de servidor de aplicação open source de grande qualidade é uma ótima alternativa. Dessa forma, o JBoss está se tornando parte fundamental nas decisões de TI das grandes corporações. 4.2.3 Enterprise JavaBeans Enterprise JavaBeans (EJB), é uma arquitetura de componentes multi-plataforma para o desenvolvimento de aplicações Java distribuídas, escaláveis e orientadas a objetos. É uma especificação (não é um produto) do Java EE usada na camada de negócios, com o objetivo de facilitar o trabalho do desenvolvedor para que ele não tenha que se preocupar com aspectos de infra-estrutura. Nesta camada residem as tarefas e regras que governam o processo e que definem a maneira como os dados serão acessados e processados. EJB é a arquitetura padrão Java para o desenvolvimento e instalação de aplicações de negócio distribuídas baseadas em componentes residentes no lado do servidor. Ela é um container que trata de problemas que envolvem o gerenciamento de objetos de negócio distribuídos numa arquitetura multicamada e fornece um grande número de serviços úteis manipulando alguns dos aspectos que mais consomem tempo para escrever aplicações distribuídas, pois disponibiliza transações declarativas que eliminam a necessidade de escrever código de gerenciamento de transações, e também fornece segurança declarativa eliminando a necessidade de escrever código de segurança. Aplicações escritas nesta arquitetura são escaláveis, transacionais e seguras, depois de escritas estas aplicações podem ser instaladas em qualquer servidor que suporte a especificação EJB. Existem três tipos de Enterprise Beans que são: Session beans, Entity beans e Message-Driven beans. As Session beans são uma extensão lógica do cliente no servidor, ou seja, elas representam um cliente no servidor e existem apenas durante a duração de uma única sessão cliente-servidor. Elas representam através de seus métodos o workflow do componente, podem ser sem estado (stateless session bean), um conjunto de procedimentos serviços de software que não necessitam variáveis de instância ou qualquer outro tipo de
  • 69. 68 estado interno, ou podem manter estado conversacional com o cliente entre métodos e transações (stateful session bean). As Entity beans são a representação de entidades armazenadas em um mecanismo de persistência (geralmente um banco de dados) ou numa aplicação existente. Elas provêem uma interface simplificando o acesso e a manipulação dos dados de um banco de dados, além de garantir, através do servidor, que os dados do bean serão salvos em um estado consistente. As Message_Driven beans combinam características de um session bean e um JMS (Java Message Service), permitindo requisições assíncronas via mensagens JMS 4.2.4 Servlets Servlets são pequenos programas feitos em Java que encapsulam alguma funcionalidade inerente à sua aplicação web. Servlets são objetos Java que rodam em uma aplicação no servidor, pode-se fazer uma analogia com os Applets, para responder pedidos do cliente, e não precisam ser executados em outro processo, ou seja, o processamento é executado dentro de um thread do processo do servidor. Pode-se dizer que os servlets, de modo geral, são usados para processamento e armazenamento de dados mandados por um formulário HTTP, acessar um conteúdo dinâmico ou para gerenciar o estado de informação sobre uma conexão HTTP. Na verdade, a API de servlet de Java oferece mecanismos adequados à adaptação qualquer servidor baseado em requisições e respostas, mas é em aplicações web que servlets têm sido mais utilizados, além disso, a API de servlets fornece uma visão orientada a objetos facilitando a escrita de aplicações web. Requisições e respostas HTTP são encapsuladas como objetos, e o desenvolvedor pode ler uma resposta do usuário e escrever conteúdo dinâmico. Requisições são manipuladas por servlets – objetos que manipulam um conjunto particular de requisições HTTP (SILVA e MOREIRA, 2006). Basicamente trabalhamos com dois métodos no servlet: o GET e o POST principalmente em um request. Observe o exemplo da figura 4.2 servlet retornando para uma página JSP que foi implementada nesse projeto:
  • 70. 69 request.setAttribute("localAtual", localAtual); RequestDispatcher dispatcher = request.getRequestDispatcher("/local.jsp"); dispatcher.forward(request, response); Figura 4.2 Retorno do Servlet para a página local.jsp Vejam que ele chama uma página chamada local através da extensão jsp na implementação do request que deve responder trazendo essa página. Servlets trabalham basicamente com request e response. 4.2.5 JavaServer Pages Páginas JavaServer Pages (JSP) são facilmente codificadas e produzem conteúdos reutilizáveis. O JSP é uma extensão de servlets que também permite especificar conteúdo dinamicamente no lado do servidor. Podem ser criadas tags próprias para realizar por exemplo, um acesso ao banco de dados, assim o desenvolvedor define a IU com tags do tipo HyperText Markup Language (HTML) e ainda há um conjunto de tags padronizadas chamadas JSTL (JSP Standard Tag Library) que facilitam a vida do desenvolvedor. Além disso, os desenvolvedores podem integrar várias tecnologias de visualização, pois o JSF oferece interfaces plugáveis. Vejamos um exemplo de JSP (figura 4.3) interagindo com o Servlet através da simbologia $ no local atual: <input name="txtcodloc" type="text" id="txtcodloc" size="10" maxlength="10" onchange="" value="${localAtual.codLoc}"/> <input name="txtnomLoc" type="text" id="txtnomLoc" size="35" maxlength="35" value="${localAtual.nomLoc}"/> Figura 4.3 Página local.jsp interagindo com o Servlet
  • 71. 70 Figura 4.4 Cadastro de Cargo em JSP que mostra a tela de cargo. A figura 4.4 mostra a tela de cadastro de cargo e as informações necessárias para registrar essa informação. 4.2.6 Java Persistência API O Java EE 5.0 possui novas APIs (Application Programming Interface) que aumentam a produtividade dos desenvolvedores, diminuindo os esforços para codificação. A Java Persistence API (JPA) padroniza as operações de persistência sobre tabelas em entidades Java, definindo uma especificação para objeto-relacional. Na JPA, os objetos persistentes são chamados de entidades (entities), que representam um objeto simples, denominado POJO (Plain Old Java Objects) e são representadas por um conjunto de dados persistido no banco. Cada entidade possui um identificador (chave
  • 72. 71 primária). Para que uma entidade possa ser persistente devemos associá-la a um contexto de persistência (persistence context), que permite a conexão com o banco de dados. Todas as operações básicas em entidades, como criação, exclusão e alteração são controladas pelo Entity Manager, que é uma implementação da interface javax.persistence.EntityManager A implementação da persistência é feita por um provedor de persistência, ele define o funcionamento das interfaces definidas pela especificação JPA. Dessa forma o provedor é que define a forma de sincronismo com o banco de dados. Essas configurações são realizados no arquivo presistence.xml. <?xml version="1.0" encoding="UTF-8" ?> - <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"> - <persistence-unit name="PPP"> <jta-data-source>java:/PostgresDS</jta-data-source> - <properties> <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect" /> <property name="hibernate.show_sql" value="true" /> <property name="hibernate.format_sql" value="true" /> </properties> </persistence-unit> </persistence> Figura 4.5 Exemplo de código do arquivo persistence.xml A Figura 4.5, apresenta a configuração do Hibernate, que foi utilizado como o provedor de persitência para o desenvolvimento desse trabalho (HIBERNATE, 2007). Antes da especificação JPA, a utilização do Hibernate era realizada através de um mapeamento da classe/atributos com tabela/campos para uma arquivo Extensible Markup Language (XML). Com a implementação JPA essa configuração é desnecessária. A JPA pode mapear automaticamente seus objetos Java para uma variedade de banco de dados relacionais. O desenvolvedor pode usar a JPA fora de um servidor de aplicações, em programas Java simples, usando provedores de persistência que implementam a especificação. Na próxima seção será apresentado os mapeamentos.
  • 73. 72 4.2.6.1 Mapeamento de Entidades Para que uma classe se torne persistente, é preciso seguir algumas convenções e definir alguns metadados (anotações). Uma entidade é uma classe, rotulada através da notação @Entity. No código a seguir, a classe Cargo representa uma entidade e atributo codCar é o identificador da entidade, especificado através da anotação @Id. package br.cefet.campos.info.taii20071n.perfil.model; import javax.persistence.*; @Entity public class Cargo { @Id private int codCar; private String titCar; private String codCbo; private String desCar; public Cargo() { } } Figura 4.6 Mapeamento de persistência da Classe Cargo No exemplo da Figura 4.6, o JPA considera que a tabela do banco de dados possui o mesmo nome da entidade (Cargo), e os atributos têm o mesmo nome dos campos da tabela. Através das anotações @Table e @Columm é possível mudar a forma de mapeamento, alterando o nome da tabela e do campo. A fim de modelar conceitos do mundo real, as entidades devem ser capazes de formar relacionamentos complexos. Diversos tipos de relacionamentos são possíveis, os mais comuns são: um para muitos (@OneToMany); muitos para um (@ManyToOne) e muitos para muitos (@ManyToMany).
  • 74. 73 @Entity public class PPRALocalCargo { @Id private int codppra; @ManyToOne @JoinColumn(name="codcar") private Cargo codcar; @ManyToOne @JoinColumn(name="codris") private Risco codris; @ManyToOne @JoinColumn(name="codloc") private Local codloc; private String tecuti; private String itencon; private Date datfim; @Entity public class Cargo { @Id private int codCar; private String titCar; @Entity public class Local { @Id private int codLoc; private String nomLoc; private String desLoc; @Entity public class Risco { @Id private int codris; private String tipris; private String desris; Figura 4.7 Exemplo de código do relacionamento muitos para um unidirecinal. A figura 4.7 mostra um exemplo de relacionamento de muitos-para-um unidirecional em que a classe PPRALocalCargo possui uma referência para um objeto das classes Local, Cargo e Risco. Este relacionamento surge quando muitas entidades referenciam uma única entidade, a entidade referenciada não tem conhecimento do relacionamento. 4.2.6.2 Persistência a Entidades Como mencionado anteriormente, a interface EntityManager é responsável pelas operações de persistência. Nesse trabalho, foi implementado a persistência a partir do servidor de Aplicação JBoss e declarada a notação @PersistenceContext para criação de um container. As definições de configuração da conexão e entidades estão no arquivo de configuração persistence.xml. A classe EntityManager define os principais métodos para execução de operações CRUD (Create, Read, Update e Delete) com entidades. As inserções são realizadas através do método persist(), a exclusão através do método remove() e a alteração através do método merge(). O método find() é utilizado para localizar.
  • 75. 74 @Stateless public class CargoHelper implements ICargoHelper { @PersistenceContext (unitName = "PPP") private EntityManager entCargo; public void save(Cargo cargo ){ Cargo car = entCargo.find(Cargo.class, cargo.getCodCar()); if (car == null) entCargo.persist(cargo); else entCargo.merge(cargo); } public void delete(Cargo local){ Cargo mCargo = entCargo.merge(local); entCargo.remove(mCargo);} public Cargo busca(int codCar){ return entCargo.find(Cargo.class, codCar); } } Figura 4.8 Implentação de persitência na classe Cargo A figura 4.8 mostra a classe CargoHelper que utiliza uma variável Entity Manager, para realizar todas as operações de inclusão, alteração, exclusão e consulta. Nessa classe, injeção de dependências surge para simplificar a vida do programador, já que o gerenciador de entidades (EntityManager) é instanciado e controlado pelo servidor de aplicações. O código de persistência é muito simples, e até mesmo consultas que seriam complexas ficam simples na linguagem de consulta da JPA. 4.4 Considerações Finais O Java EE hoje é uma importante ferramenta de desenvolvimento tendo várias vantagens e facilidades ao desenvolvedor. Abordamos algumas práticas em códigos simples para demonstrar suas interligações. Além disso, oferece segurança em seu ambiente de desenvolvimento.
  • 76. 75 A linguagem do JEE e suas tecnologias mostram-se bem aperfeiçoadas e integradas. Essa linguagem possui mecanismos sofisticados como a reflexão e a serialização de objetos e é uma linguagem distribuída, robusta e segura. Aqui está-se realizando implementação na linguagem Java EE com o banco de dados PostgreSQL que também é uma ferramenta poderosa de desenvolvimento de banco. Acreditamos que essa aliança proporcione um ambiente de fácil entendimento no projeto de construção de um framework, apesar de possuir bastante ferramenta como as JSF, java Beans, JPA e alguma integração com Hibernate.
  • 77. 76 CAPITULO 5: CONCLUSÕES E TRABALHOS FUTUROS 5.1 Conclusões Estamos vivendo em uma era onde tempo é dinheiro e a concorrência entre as empresas é cada dia mais acirrada. Com isso, a reutilização entra como uma poderosa ferramenta, pois ela traz benefícios que determinam a competitividade entre as organizações deixando na frente quem se utiliza dessa técnica. Porém, é preciso cautela para sua implantação, pois a reutilização, quando usada, deve ser adotada por todos os desenvolvedores e toda a equipe tem que estar envolvida no processo para que tudo corra bem, pois os investimentos de implantação desta técnica não são poucos e os benefícios só serão vislumbrados em projetos futuros, os seja, o retorno não é imediato. Por isso, é preciso comprometimento de toda a equipe e da gerência. Além disso, há ainda dificuldades como a compreensão dos artefatos recuperados, produzidos por outros desenvolvedores, a garantia da qualidade dos artefatos, a composição de aplicações a partir de componentes, e até mesmo barreiras psicológicas como a “síndrome do não foi inventado aqui”, entre outras dificuldades (MOURA, CARVALHO e SILVA, 2006). Por outro lado, o investimento apesar de ser alto e trazer algumas dificuldades, traz também retornos positivos como: a redução dos custos e tempo de desenvolvimento de aplicações; provável aumento da qualidade do software, pois os artefatos reutilizados são mais confiáveis e consistentes na medida que já foram testados em outra aplicação; uma estrutura mais flexível que facilita a evolução e manutenção do software; e a conformidade com os padrões de desenvolvimento. Visto isso, é preciso analisar muito bem para se tomar a decisão certa, pois existem os dois lados da moeda. Dessa forma, a reutilização tem seus prós e contras, mas sem dúvida nenhuma, a relação custo x benefício será favorável se a empresa souber administrar bem essas dificuldades e explorar melhor ainda os benefícios.
  • 78. 77 5.2 Contribuições e Benefícios do Trabalho Este trabalho apresentou mais uma contribuição para a reutilização de software, criando artefatos e analisando um domínio através da Engenharia de Domínio que incorpora em seu processo uma etapa de análise, que visa explicitar a variabilidade, i.e, aspectos comuns e específicos inerentes a uma família de sistemas. Apesar do domínio de Gestão de Recursos Humanos ser comum, não existem muitas aplicações voltadas para empresas, focando a emissão do PPP. Portanto, este trabalho apresenta contribuições na construção de um framework neste ramo de negócio. 5.3 Dificuldades Encontradas Foram encontradas muitas dificuldades na realização deste trabalho, uma delas foi quanto ao ambiente de reutilização (ODYSSEY, 2007) que foi usado na modelagem. Por ser uma ferramenta ainda desconhecida e voltada à reutilização, foi necessário antes aprender a usá-la para depois começar o desenvolvimento, e isto custou um tempo a mais que o previsto. Além disso, para a correta utilização do ambiente Odyssey, foi necessário aprender um novo paradigma, i.e. a Engenharia de Domínio. Somadas a essas dificuldades, a delimitação do escopo foi mais uma barreira, por se tratar de um domínio muito amplo (Gerência de Recursos Humanos), havendo a necessidade de se limitar esse domínio, dividindo-o em subdomínios para que a análise ficasse focada no objetivo do trabalho (criar um framework para a emissão do PPP). Enfim, como Engenharia de Domínio, Framework e muitos outros temas eram conceitos novos, houve a necessidade de muito estudo e pesquisa para aprendê-los. No entanto, a experiência foi ótima e trouxe muito conhecimento ao grupo.
  • 79. 78 5.4 Trabalhos Futuros Como a ênfase do trabalho foi a reutilização de software, todo o desenvolvimento foi voltado para a modelagem no ambiente de reutilização Odyssey e de acordo com a análise do domínio em questão. Como já foi dito anteriormente, as técnicas de reutilização foram aplicadas para a especificação do domínio que envolve a emissão do Perfil Profissiogáfico Previdenciário, estando contido num domínio maior de Gerência de Recursos Humanos. Como este domínio é muito amplo, ele foi dividido em subdomínios, porém nem todos foram analisados. A partir deste ponto, é possível que se amplie o escopo para os demais subdomínios, analisando-se as necessidades mais emergenciais das empresas. Uma outra possibilidade de trabalho futuro seria a instanciação de aplicações no ambiente Odyssey a partir do framework gerado, através do processo de Engenharia de Aplicação. Neste processo, características específicas (features) do modelo de características do domínio podem ser selecionadas para as aplicações, levando a um recorte do framework. Ainda com a evolução deste trabalho, sendo instanciadas novas aplicações a partir deste ponto, o modelo de características pode ser atualizado, assim como os demais modelos de domínio e, conseqüentemente, o próprio framework, através de novas características e funcionalidades do domínio que venham a ser descobertas.
  • 80. 79 REFERÊNCIAS BIBLIOGRÁFICAS ALUR, Deepak; MALKS, Dan; CRUPI, John. Core J2EE Patterns: Best Practices and Design Strategies. 2a ed. New York: Prentice-Hall, 2003. AREA SEG, 2007. Introdução à Segurança do Trabalho em Perguntas e Respostas. Disponível em http://www.areaseg.com/seg/. Ùltima consulta em 24/06/2007 BLOIS, A. P. T. B., Uma Abordagem de Projeto Arquitetural Baseado em Componentes no Contexto de Engenharia de Domínio. Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2006. BLOIS, A.P., BECKER, K., WERNER, C.M.L., 2004, "Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes". In: IV Workshop de Desenvolvimento Baseado em Componentes, pp. 15-20, João Pessoa, Paraíba, Brasil. BOSCH, J., 2004, "Software Variability Management". In: Proceedings of the 26th International Conference on Software Engineering (ICSE’04), pp. 720-721, Scotland, UK. BRAGA, Regina; "Busca e Recuperação de Componentes em Ambientes de Reutilização de Software", Tese de Doutorado – COPPE/Sistemas, Dezembro 2000. BUSCHMANN, Frank et al. Pattern-Oriented Software Archietcture: Volume 1 – A System of Patterns. New York: John Wiley & Sons, 1996. CUNHA, Gabriela Elisa da; HERBERT, Juliana Silva. Proposta de Padrões de Software para a Reutilização Sistemática em Sistemas de Software Orientados a Objetos. Universidade do Vale do Rio dos Sinos – UNISINOS, 2003. Disponível em http://www.cin.ufpe .br/~sugarloafplop/articles/wp/GabrielaUnisinos_novo.pdf. Última consulta em 10/08/2007 DEXTRA, 2007. JBOSS - Alternativa Open Source para Servidores Java. Artigo. Disponível em http://www.dextra.com.br/empresa/artigos/jboss.htm. Última consulta em 25/08/2007
  • 81. 80 GAMMA, Erich, HELM, Richard, JOHNSON, Ralph, VLISSIDES, J., Padrões de Projeto: Soluções Reutilizáveis de Software orientado a Objetos, Trad., Bookman, 2000. GUJ, 2007. Grupo de Usuários Java. . Disponível em: http://www.guj.com.br/. Última Consulta em 10/08/2007 GUIZZARDI, Giancarlo. Um modelo genérico de processo de desenvolvimento de software para e com reuso. Disponível em: http://www.loa-cnr.it/Guizzardi/Cap2.pdf. Ultima consulta em: 08/09/2007. HIBERNATE, 2007. Disponível em: http://www.hibernate.org/397.html). Última Consulta em 02/07/2007. IMSL (1995): The IMSL Product Family, WWW Document http://www.vni.com/index.html, Visual Numerics, Inc: Houston, Texas. ISEG NET, 2007. Riscos Ambientais e Acidentes de Trabalho. Disponível em http://www.isegnet.com.br/2index.asp?id=3. Última consulta em 15/04/2007 JBOSS, 2007. JBoss Enterprise Application Platform. Disponível em http://www.br. redhat.com/pdf/jboss/Enterprise_ApplicationPlatform.pdf. Última consulta em 25/08/2007. JEE, 2007. Java Enterprise Edition. A plataforma para o software enterprise-class. Disponível em http://www.iride.com.br/technology-jee-portal.do;jsessionid=F63D99CE7 5DF6440AD56 C31C7C0E132F. Última consulta em 25/08/2007 JOHNSON, Ralph E.; Foote B. Designing Reusable Classes. Journal of Object Oriented Programming – JOOP, [s.1.], Junho/Julho 1988. JUNIOR, Fernando Goulart. Java 2 Enterprise Edition – J2EE – Versão UCB. Disponível em http://www.ucb.br/prg/professores/fgoulart/j2ee_ejb.pdf Última consulta em 22/08/2007 JÚNIOR, Nelson Miller. A Engenharia de Aplicações no Contexto da Reutilização Baseada em Modelos de Domínio. Resumo da Tese apresentada à COPPE/UFRJ como parte dos
  • 82. 81 requisitos necessários para a obtenção do grau de Mestre em Ciências (M.Sc.), 2000. Disponível em http://www.cos.ufrj.br/index.php?option=com_publicacao&task=visualizar& id=812. Última consulta em 17/08/2007 LANI WAY, 2007. Servidores de Aplicações J2EE. Disponível em http://www.laniway. com.br/br/corporativo/j2ee.doc.Última consulta em 25/08/2007 LIGHT CLINIC – Medicina do Trabalho. Disponível em http://www.lightclinic.com.br/ ?pagina=PPRA. Última consulta em 26/05/2007 LIMA e SILVA, F.H.A. Barreiras de Contenção. In: Oda, L.M. & Avila, S.M. (orgs.). Biossegurança em Laboratórios de Saúde Pública. Ed. M.S., p.31-56, 1998. ISBN: 85-85471- 11-5 Ultima consulta em 13/04/2007 LOA, 2007. Um modelo genérico de processo de desenvolvimento de software para e com reuso. Disponível em http://www.loa-cnr.it/Guizzardi/Cap2.pdf. Última consulta em 02/07/2007 LOZANO, Fernando. Servidores de Aplicação Java EE com TomCat e JBOSS. Disponível em http://www.lozano.eti.br/. Última consulta em 25/08/2007 MANN, Kito D. JavaServer Faces in Action. Greenwich: Manning, 2005. MAIA, Natanael Elias Nascimento. Engenharia de Software, 2006. Odyssey-MDA: Uma Abordagem para a Transformação de Modelos. MEYER, B. Object-oriented software construction. Englewood Cliffs: Prentice Hall, 1988. MILER, Nelson; “A Engenharia de Aplicações no Contexto da Reutilização baseada em Modelos de Domínio”, Tese de Mestrado - COPPE/Sistemas, Julho 2000. MOURA, Ana M.; CARVALHO Jonnathan dos Santos; SILVA, Rogério de Jesus. Abordagens de Reutilização de Software e sua Aplicação no Domínio de Arrecadação Tributária Municipal. Monografia de Pós Graduação - CEFET Campos. Dezembro de 2006.
  • 83. 82 MTE, 2007. Ministério do Trabalho e Emprego: Disponível em: http://www.mte.gov.br/. Última Consulta em 14/08/2007. MPS, 2003. Ministério da Previdência Social. Instrução Normativa Nº 99 de 5/12/2003. Disponível em: http://www.mpas.gov.br. Última Consulta em 01/10/2007. ODYSSEY, 2007. “Odyssey SDE”. Disponível em: http://reuse.cos.ufrj.br/odyssey. Última Consulta em 14/08/2007. OLIVEIRA, R. F., Formalização e Verificação de Consistência na Representação de Variabilidades. Tese de M.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2006. PR, 1999a. Presidência da República. DECRETO No 3.048, DE 6 DE MAIO DE 1999. Disponível em: http://www.planalto.gov.br/ccivil_03/decreto/D3048.htm. Última consulta em 01/09/2007. PR, 1991b. Presidência da República. LEI Nº 8.213, DE 24 DE JULHO DE 1991. Disponível em: http://www.planalto.gov.br/ccivil/leis/L8213cons.htm. Última consulta em 01/09/2007. PRESSMAN, R.S., Engenharia de Software, Trad., McGraw Hill, 6º ed. , São Paulo, 2006. PREE, W. Design patterns for object oriented software development. Reading: Addison- Wesley, 1994. PRESTOMED, 2007. Segurança e Medicina no Trabalho – LTCAT (Laudos Técnicos), Avaliações Ambientais (Higiene Ocupacional). Disponível em: http://www.prestomed.com.br/ geral.php?pagina=interno/conteudo.php&tipo=8. Última consulta em 09/09/2007. ROMAN, Ed et al. Dominando Enterprise JavaBeans: 2ª Edição. Porto Alegre: Bookman, 2004. SANTANA, Vilma; NOBRE, Letícia; E WALDVOGEL, Bernadete Cunha, 2005. Acidentes de trabalho no Brasil entre 1994 e 2004: uma revisão: Disponível em
  • 84. 83 http://www.scielo.br/scielo.php?pid=S1413-81232005000400009&script=sci_arttext&tlng. Última consulta em 12/04/2007 SDN, 2007. Sun Developer Network. Enterprise JavaBeans Technology. Disponível em http://java.sun.com/products/ejb/. Última consulta em 25/08/2007 SESI, 2007. Serviço Social da Industria. Disponível em http://www.sesipr.org.br /saude/FreeComponent85content294.shtml. Última consulta em 02/03/2007. SILVA, Alexandre Gomes; MOREIRA, Maicon Estevam. Desenvolvimento de Sistemas Corporativos Empregando Java EE 5. Trabalho de Conclusão de Curso - CEFET Campos. Novembro de 2006. SPINOLA, Eduardo Oliveira. Introdução ao EJB 3.0 e o Enterprise Beans Components - Parte I . Artigo. Disponível em http://www.devmedia.com.br/articles/viewcomp.asp?comp=1596. Última consulta em 25/08/2007 TEIXEIRA, H. V., “Geração de Componentes de Negócio a partir de Modelos de Análise”, Tese de Mestrado – COPPE/Sistemas, Março 2003. UFPE, 2007a. ABC – Reuso e componentes de Software. Disponível em: http://www.cin.ufpe.br/~aa2/ABC/processo_index.html. Ultima consulta em 08/09/2007 UFPE, 2007b. Universidade Federal de Pernambuco. Engenharia de Domínio. Disponível em http://www.cin.ufpe.br/~aa2/ABC/engdominio.html. Última consulta em 17/08/2007 UFRJ, 2007. Universidade Federal do Rio de Janeiro – Laboratório de Engenharia de Software – COPPE UFRJ. Equipe de Reutilização de Software. Disponível em http://reuse.cos.ufrj.br/site/pt/index.php?option=com_content&task=view&id=20&Itemid=22 Última consulta em 15/08/2007 UFSC, 2007. Universidade Federal de Santa Catarina - Desenvolvimento orientado a objetos com frameworks, padrões e componentes. Disponível em http://www.inf.ufsc.br/~ricardo /ine660600.html. Última consulta em 15/08/2007
  • 85. 84 UNICAMP, 2007. Diretoria Geral de Recursos Humanos - Pró-Reitoria de Desenvolvimento Universitário. Dispnível em http://www.dgrh.unicamp.br/noticia.shtml?idNoticia=446. Última consulta em 20/05/2007 UNEAP, 2007. Programa de Prevenção de Riscos Ambientais. Disponível em http://www.bauru.unesp.br/curso_cipa/artigos/ppra.htm. Última consulta em 22/03/2007 TÉCNICAS DE ENGENHARIA DE SOFTWARE. Disponível em http://www.redes. unb.br/material/ESOO/T%E9cnicas%20da%20Engenharia%20de%20Software%202.pdf. Última consulta em 05/08/2007 VASCONCELOS, A. P. V., Uma Abordagem de apoio à Criação de Arquiteturas de Referência de Domínio baseada na Análise de Sistemas Legados. Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil 2007. WERNER, Cáudia; BRAGA, Regina; ZOPELARI, Mônica; BARROS, Márcio e MURTA, Leonardo. Odyssey-LE: Uma Infra-Estrutura de Reutilização para o Domínio de Processamento Legislativo. COPPE/UFRJ - Programa de Engenharia de Sistemas Universidade Federal do Rio de Janeiro – 2000. Disponível em http://reuse.cos.ufrj.br/prometeus/publicacoes/enial00.pdf. Última consulta em 02/07/2007 WIKI, 2007.– Wikipédia. Disponível em http://pt.wikipedia.org/wiki/Java_EE. Última consulta em 25/08/2007
  • 86. 85 APÊNDICE A: CASOS DE USO PARA O CONTROLE E EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO Subdomínio Administração de Pessoal CDU01 – Cadastrar Empresa Ator: Agente de Recursos Humanos Fluxo Principal 1. O Agente de RH informa código da Empresa. 2. O Sistema verifica a existência da Empresa e caso exista recupera os dados para edição, caso contrário abre uma nova Empresa para edição. 3. O agente de RH informa os dados da Empresa. 4. O Sistema inclui/atualiza o Cadastro da Empresa. Fluxo Alternativo 1a. O código da Empresa informada não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código da Empresa. 2a. O Sistema verifica que Empresa já está cadastrada: • O Sistema recupera os dados da Empresa. 3a. O Agente de RH solicita a exclusão da Empresa. • O Sistema verifica se existem informações ligadas a Empresa (Colaborador, Histórico de Filial) e em caso positivo o pedido de exclusão é rejeitado caso contrário o sistema solicita uma confirmação do pedido de exclusão. • O Agente de RH confirma o pedido de exclusão • O Sistema exclui a Empresa. Campo Descrição Tipo Requerido codEmp Código Inteiro Sim razSoc Razão Social String Sim cnpj CNPJ String Não cnae CNAE String Não logradouro Logradouro String Não municipio Logradouro String Não uf UF String Não ddd DDD String Não telfone Telefone String Não nomeResp Nome do Responsável String Não nitres NIT do Responsável String Não cei CEI String Não
  • 87. 86 CDU02 – Cadastrar Local Ator: Agente de Recursos Humanos Fluxo Principal 1. O Agente de RH informa código do Local. 2. O Sistema verifica a existência do Local e caso exista recupera os dados para edição, caso contrário abre um novo Local para edição. 3. O agente de RH informa os dados do Local. 4. O Sistema inclui/atualiza o Cadastro do Local. Fluxo Alternativo 1a. O código do Local informado não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Local. 2a. O Sistema verifica que Local já está cadastrado: • O Sistema recupera os dados do Local. 3a. O Agente de RH solicita a exclusão do Local. • O Sistema verifica se existem informações ligadas ao Local (Histórico, Colaborador) e em caso positivo o pedido de exclusão é rejeitado caso contrário o sistema solicita uma confirmação do pedido de exclusão. • O Agente de RH confirma o pedido de exclusão • O Sistema exclui o Local. Campo Descrição Tipo Requerido codLoc Código do Local Inteiro[10] Sim nomLoc Nome do Local String[35] Sim desLoc Descrição do Local String[450] Não locPai Local Pai Local Não CDU03 – Cadastrar Cargo Ator: Agente de Recursos Humanos Fluxo Principal 1. O Agente de RH informa código do Cargo. 2. O Sistema verifica a existência do Cargo e caso exista recupera os dados para edição, caso contrário abre um novo Cargo para edição. 3. O agente de RH informa os dados do Cargo. 4. O Sistema inclui/atualiza o Cadastro do Cargo. Fluxo Alternativo 1a. O código do Cargo informado não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Cargo. 2a. O Sistema verifica que Cargo já está cadastrado: • O Sistema recupera os dados do Cargo.
  • 88. 87 3a. O Agente de RH solicita a exclusão do Cargo. • O Sistema verifica se existem informações ligadas ao Cargo (Histórico, Colaborador) e em caso positivo o pedido de exclusão é rejeitado caso contrário o sistema solicita uma confirmação do pedido de exclusão. • O Agente de RH confirma o pedido de exclusão • O Sistema exclui o Cargo. Campo Descrição Tipo Requerido codCar Código do Cargo Inteiro[10] Sim titCar Título do Cargo String[35] Sim codCbo Código do CBO String[10] Não desCar Descritivo do Cargo String[450] Não CDU04 - Cadastrar Colaborador Ator: Agente de Recursos Humanos Fluxo Principal 1. O Agente de RH informa código da Empresa e a Matrícula do Colaborador. 2. O Sistema verifica a existência do Colaborador e caso exista recupera os dados para edição, caso contrário abre um novo Colaborador para edição. 3. O agente de RH informa os dados do Colaborador. 4. O Sistema inclui/atualiza o Cadastro de Colaborador. Fluxo Alternativo 1a. O código da Empresa e Colabprador informado não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação da Empresa e do Colaborador. 2a. O Sistema verifica que Colaborador já está cadastrado: • O Sistema recupera os dados do Colaborador. 3a. O Agente de RH solicita a exclusão do Colaborador. • O Sistema verifica se existem informações ligadas ao Cargo (Históricos) e em caso positivo o pedido de exclusão é rejeitado caso contrário o sistema solicita uma confirmação do pedido de exclusão. • O Agente de RH confirma o pedido de exclusão • O Sistema exclui o Colaborador. Campo Descrição Tipo Requerido codEmp Código da Empresa Empresa Sim matricula Matrícula Inteiro Sim nome Nome String Sim datNasc Data de Nascimento Data Não sexo Sexo String Não numCtps Número CTPS String Não
  • 89. 88 serCtps Série CTPS String Não ufCtps UF CTPS String Não revezamento Refezamento String Não pisPasep PIS ou PASEP String Não brpdh Código BRPDH String Não datAdm Data de Admissão String Não codGfip Código GIFIP String Não regConsClasse Código no Conselho de Classe String Não CDU05 – Registrar o Cargo do Colaborador (Histórico de Cargo) Ator: Agente de Recursos Humanos Fluxo Principal 1. O Agente de RH informa a Empresa, Matrícula do colaborador, Código do Cargo e Data da alteração. 2. O Sistema verifica a existência do Histórico e caso exista recupera os dados para edição, caso contrário abre um novo Histórico de Cargo para edição. 3. O agente de RH informa os dados do Histórico. 4. O Sistema inclui/atualiza o Histórico de Cargo. Fluxo Alternativo 1a. A Empresa, Matrícula do colaborador, Código do Cargo e Data da alteração informado não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação da (Empresa ou Matrícula do colaborador ou Código do Cargo ou Data da alteração). 2a. O Sistema verifica que Histórico de Cargo já está cadastrado: • O Sistema recupera os dados Histórico. 3a. O Agente de RH solicita a exclusão do Histórico. • O Agente de RH confirma o pedido de exclusão • O Sistema exclui o Historio de Cargo. Campo Descrição Tipo Requerido codEmp Código da Empresa Empresa Sim matricula Matrícula do Colaborador Colaborador Sim codCargo Código do Cargo Cargo Sim datIni Data Inicial Date Sim datFim Data Final Date Não CDU06 – Alocar Colaborador em um Local (Histórico de Local) Ator: Agente de Recursos Humanos Fluxo Principal 1. O Agente de RH informa a Empresa, Matrícula do colaborador, Código do Local e Data da alteração. 2. O Sistema verifica a existência do Histórico e caso exista recupera os dados para edição, caso contrário abre um novo Histórico de Local para edição.
  • 90. 89 3. O agente de RH informa os dados do Histórico. 4. O Sistema inclui/atualiza o Histórico de Local. Fluxo Alternativo • 1a. A Empresa, Matrícula do colaborador, Código do Local e Data da alteração informado não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação da (Empresa ou Matrícula do colaborador ou Código do Local ou Data da alteração). 2a. O Sistema verifica que Histórico de Local já está cadastrado: • O Sistema recupera os dados Histórico. 3a. O Agente de RH solicita a exclusão do Histórico. • O Agente de RH confirma o pedido de exclusão • O Sistema exclui o Historio de Local. Campo Descrição Tipo Requerido codEmp Código da Empresa Empresa Sim matricula Matrícula do Colaborador Colaborador Sim codLocal Código do Local Cargo Sim datIni Data Inicial Date Sim datFim Data Final Date Não Subdomínio Segurança CDU07 – Cadastrar Risco Ator: Agente de Recursos Humanos Fluxo Principal 2. O Agente de RH informa código do Risco 2. O Sistema verifica a existência do Risco e caso exista recupera os dados para edição, caso contrário abre um novo Risco para edição. 3. O agente de RH informa os dados do Risco. 4. O Sistema inclui/atualiza o Cadastro do Risco. Fluxo Alternativo 1a. O código do Risco informado não possui as características esperadas. 1. O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Risco. 2a. O Sistema verifica que Risco já está cadastrado: 1. O Sistema recupera os dados do Risco. 3a. O Agente de RH solicita a exclusão do Risco. • O Sistema verifica se existem informações ligadas ao Risco (PPRA) e em caso positivo o pedido de exclusão é rejeitado caso contrário o sistema solicita uma confirmação do pedido de exclusão. • O Agente de RH confirma o pedido de exclusão
  • 91. 90 • O Sistema exclui o Risco. Campo Descrição Tipo Requerido codRis Código do Risco Inteiro Sim desRis Descrição String Sim tipRis Tipo String Não CDU08 – Cadastrar EPI/EPC Ator: Agente de Recursos Humanos Fluxo Principal 1. O Agente de RH informa código do Equipamento 2. O Sistema verifica a existência do Equipamento e caso exista recupera os dados para edição, caso contrário abre um novo Equipamento para edição. 3. O agente de RH informa os dados do Equipamento. 4. O Sistema inclui/atualiza o Cadastro Equipamento. Fluxo Alternativo 1a. O código do Equipamento informado não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Equipamento. 2a. O Sistema verifica que Equipamento já está cadastrado: • O Sistema recupera os dados do Equipamento. 3a. O Agente de RH solicita a exclusão do Equipamento. • O Sistema verifica se existem informações ligadas ao Equipamento (PPRA) e em caso positivo o pedido de exclusão é rejeitado caso contrário o sistema solicita uma confirmação do pedido de exclusão. • O Agente de RH confirma o pedido de exclusão • O Sistema exclui o Equipamento. Campo Descrição Tipo Requerido codEq Código do Equipamento Inteiro Sim desEP Descrição String Sim ca Certificado de Aprovação String Não tip EPI/EPC String Não CDU09 - Montar PPRA por Local/Cargo Fluxo Principal 1. O Profissional de Segurança seleciona o Cargo e o Local. 2. O Profissional de Segurança seleciona o Risco. 3. O Profissional de Segurança informa a data inicio de validade do PPRA. 4. O Sistema verifica a existência do PPRA e caso exista recupera os dados para edição, caso contrário abre uma nova ficha para edição. 5. O Sistema inclui/atualiza o PPRA.
  • 92. 91 Fluxo Alternativo 1a. O código do Cargo e do Local informados não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Cargo e do Local. 2a. O código do Risco informado não possui as características esperadas. 1. O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Risco. 3a. O data informada não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação da Data. 4a. O Sistema verifica se o PRRA já está cadastrado: 1. O Sistema recupera os dados do PPRA para a edição. 2. O Profissional de segurança solicita a exclusão. • O Profissional de Saúde confirma o pedido de exclusão. • O Sistema exclui o PPRA. Campo Descrição Tipo Requerido codLocal Código do Local Local Sim codCargo Código do Cargo Cargo Sim codRisco Risco Risco Sim datIni Inicio Date Sim datFim Data da Solução Date Não fatRis Fator de Risco String Não tecUti Técnicas Utilizadas String Não epiEfz EPI Eficaz? String Não epcEfz EPC Eficaz? String Não itenCon Intensidade de Concentração String Não epiepc Listas de EPI/EPC EPIEPC Não Subdomínio Medicina CDU10 - Cadastrar Exame Fluxo Principal 1. O Profissional de Saúde informa código do exame. 2. O Sistema verifica a existência do exame e caso exista recupera os dados para edição, caso contrário abre uma nova ficha para edição. 3. O Profissional de Saúde informa os dados do Exame. 4. O Profissional de Saúde informa os Itens de Exame. 5. O Sistema inclui/atualiza o Exame e os Itens de Exame. Fluxo Alternativo 1a. O código do exame informado não possui as características esperadas.
  • 93. 92 1. O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do exame. 2a. O Sistema verifica que exame já está cadastrado: 1. O Sistema recupera os dados do Exame e de seus Itens para edição. 3a. O Profissional de saúde solicita a exclusão do Exame. • O Sistema verifica se existem informações ligadas ao exame (Histórico, Itens e o PCMSO) e em caso positivo o pedido de exclusão é rejeitado caso contrário o sistema solicita uma confirmação do pedido de exclusão. • O Profissional de Saúde confirma o pedido de exclusão • O Sistema exclui o exame e os Itens ligados somente a ele (Itens de Exame) Campo Descrição Tipo Requerido codExm Código do Exame Inteiro Sim momExm Descrição String[30] Sim tipExm Tipo String Sim refSeq Exame (R/S) String[1] Sim CDU11 – Registrar Resultado de Exame do Colaborador (Histórico de Exame) Fluxo Principal 1. O Profissional de Saúde seleciona o Colaborador e o Exame. 2. O Profissional de Saúde informa a data de realização. 3. O Sistema verifica a existência do Histórico e caso exista recupera os dados para edição, caso contrário abre uma nova ficha para edição. 4. O Profissional de Saúde informa resultado dos Itens do Exame. 5. O Sistema inclui/atualiza o Histórico e os resultados do Exame. Fluxo Alternativo 1a. O código do colaborador e/ou do exame informado não possui as características esperadas. 1. O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Colaborador. 2. O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Exame. 2a. O Sistema verifica que o Histórico de Exame já está cadastrado: 1. O Sistema recupera os dados do Histórico de Exame e de seus Resultados para a edição. 3a. O Profissional de saúde solicita a exclusão. 1. Do Histórico do Exame: O Profissional de Saúde confirma o pedido de exclusão. 2. Do Resultado exame: O Profissional de Saúde confirma o pedido de exclusão. • O Profissional de Saúde confirma o pedido de exclusão • O Sistema exclui o exame e os Itens ligados somente a ele (Itens de Exame) Campo Descrição Tipo Requerido codEmp Empresa Empresa Sim
  • 94. 93 matricula Colaborador Colaborador Sim codExm Código do Exame Exame Sim datRea Data da Realização Data Sim result Indicação do Resultado String Não CDU12 – Emitir o Perfil Profissiográfico Previdenciário Padrão do Relatório: Perfil Profissiográfico Previdenciário Fluxo Principal 1. O Profissional de Segurança/Medina ou o Agente de Rh seleciona o Colaborador. 2. Sistema recupera os dados do Colaborador e de sua respectiva Empresa, Históricos de Locais, Históricos de Cargos, CAT e descrição dos cargos. – Sistema gera “I - SEÇÃO DADOS ADMINISTRATIVOS”. 3. Sistema recupera os dados do PPRA de acordo com as informações obtidas no item 2. Para cada Histórico do colaborador é verificado a presença da Montagem de um PPRA. Sistema gera “II - SEÇÃO DE REGISTROS AMBIENTAIS”. 4. Sistema recupera os dados do Histórico de exames, Resultados, e informações dos Responsáveis pelo Registro Ambiental de acordo com as informações obtidas no item 1. Sistema gera “III- SEÇÃO DE RESULTADOS DE MONITORAÇÃO BIOLÓGICA”. 5. Sistema recupera os dados dos Responsáveis pela emissão do relatório de acordo com as informações obtidas no item 1. Sistema gera “IV - - RESPONSÁVEIS PELAS INFORMAÇÕES”. Fluxo Alternativo 1a. O código do colaborador informado não possui as características esperadas. • O Sistema informa o ocorrido, rejeita a entrada e solicita novamente a identificação do código do Colaborador.
  • 95. 94 APÊNDICE B: DIAGRAMA DE CLASSE PARA EMISSÃO E CONTROLE DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO
  • 96. 95 APÊNDICE C: EXEMPLO DE LISTAGEM DOS CÓDIGOS cargo.jsp <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%> <head> <title>PPP - Perfil Profissiografico Previdenci&aacute;rio - Cargo</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <link rel="stylesheet" href="mm_entertainment.css" type="text/css" /> <style type="text/css"> <!-- .style1 {font-size: 12px} --> </style> </head> <body bgcolor="#14285f"> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr bgcolor="02021e"> <td colspan="4" rowspan="2" nowrap="nowrap"><p>&nbsp;</p> <p>&nbsp;</p></td> <td height="58" nowrap="nowrap" colspan="2" id="logo" valign="bottom">PPP</td> <td width="45">&nbsp;</td> </tr> <tr bgcolor="02021E"> <td height="57" nowrap="nowrap" colspan="2" id="tagline" valign="top">PERFIL PROFISSIOGR&Aacute;FICO PREVIDENCI&Aacute;RIO </td> <td width="45">&nbsp;</td> </tr> <tr> <td colspan="7" bgcolor="#cc3300"><img src="mm_spacer.gif" alt="" width="1" height="2" border="0" /></td> </tr> <tr> <td colspan="7"><img src="mm_spacer.gif" alt="" width="1" height="2" border="0" /></td> </tr> <tr> <td colspan="7" bgcolor="#cc3300"><img src="mm_spacer.gif" alt="" width="1" height="1" border="0" /></td> </tr> <tr> <td colspan="7">&nbsp;<br /> &nbsp;<br /> </td> </tr> <tr> <td width="155" valign="top" height="370"> <table border="0" cellspacing="0" cellpadding="0" width="155" id="navigation"> <tr> <td width="155" height="40"><a>Empresa</a></td> </tr> <tr> <td width="155" height="40"><a href="LocalServlet?nomeform=carregar">Local</a></td> </tr> <tr> <td width="155" height="40"><a href="CargoServlet?nomeform=carregar">Cargo</a></td> </tr> <tr> <td width="155" height="40"><a>Colaborador</a></td> </tr> <tr> <td width="155" height="40"><a>Hist&oacute;rico de Local </a></td> </tr> <tr> <td width="155" height="40"><a>Hist&oacute;rico de Cargo </a></td>
  • 97. 96 </tr> <tr> <td height="40"><a href="RiscoServlet?nomeform=carregar">Risco </a></td> </tr> <tr> <td height="40"><a>EPIEPC</a></td> </tr> <tr> <td height="40"><a href="PPRALocalCargoServlet?nomeform=carregar">PPRA </a></td> </tr> <tr> <td height="40"><a>Exame</a></td> </tr> <tr> <td height="40"><a>Resultado do Exame </a></td> </tr> </table></td> <td width="1" bgcolor="#445DA0"><img src="mm_spacer.gif" alt="" width="1" height="1" border="0" /></td> <td width="50"><img src="mm_spacer.gif" alt="" width="50" height="1" border="0" /></td> <td colspan="2" valign="top"><img src="mm_spacer.gif" alt="" width="304" height="1" border="0" /><br /> <table width="904" height="453" border="0" cellpadding="0" cellspacing="0"> <tr> <td width="904" height="60" class="pageName">Cargo</td> </tr> <tr> <td height="263" class="bodyText"><form id="frmcargo" name="frmcargo" method="post" action="http://localhost:8080/WebPPP/PrincipalServlet"> <table width="581" border="0"> <tr> <td width="140"><div align="right"><span class="style1">C&oacute;digo do Cargo</span></div></td> <td width="431"><label> <input name="txtcodcar" type="text" id="txtcodcar" size="10" maxlength="10" value="${cargoAtual.codCar}" /> </label></td> </tr> <tr> <td><div align="right"><span class="style1">T&iacute;tulo do Cargo</span></div></td> <td><label> <input name="txttitcar" type="text" id="txttitcar" size="35" maxlength="35" value="${cargoAtual.titCar}" /> </label></td> </tr> <tr> <td><div align="right"><span class="style1">Descritivo do Cargo</span></div></td> <td><label> <textarea name="txtdescar" cols="50" rows="9" id="txtdescar"> ${cargoAtual.desCar}</textarea> </label></td> </tr> <tr> <td><div align="right"><span class="style1">C&oacute;digo do CBO</span></div></td> <td><label> <input name="txtcodcbo" type="text" id="txtcodcbo" size="10" maxlength="10" value="${cargoAtual.codCbo}"/> </label></td><td>&nbsp;</td> </tr> <tr> <td>&nbsp;</td> <td><table width="427" border="0"> <tr> <hr> <input type="submit" name="Submit" value="Incluir/Alterar" onclick ="return incluir()"/> <input type="submit" name="Submit" value="Excluir" onclick ="excluir()"/> <input type="submit" name="Submit" value="Novo" onclick ="novo();"/> <input type="submit" name="Submit" value="Anterior" onclick ="anterior();"/> <input type="submit" name="Submit" value="Próximo" onclick ="proximo()"/> <hr> </tr> <tr>
  • 98. 97 <td>&nbsp;</td> <td>&nbsp;</td> </tr> </table></td> </tr> </table> </form> <p>&nbsp;</p> </td> </tr> </table> </td> <td width="4" valign="top"><img src="mm_spacer.gif" alt="" width="1" height="10" border="0" /><br /> <br /></td> <td width="45">&nbsp;</td> </tr> <tr> <td width="155">&nbsp;</td> <td width="1"></td> <td width="50">&nbsp;</td> <td width="24">&nbsp;</td> <td width="2767">&nbsp;</td> <td width="4">&nbsp;</td> <td width="45">&nbsp;</td> </tr> </table> </body> </html> CargoServlet.java package br.cefet.campos.info.taii20071n.perfil.control; import java.io.IOException; import java.io.PrintWriter; import java.util.List; import java.util.Properties; import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.NamingException; import javax.servlet.RequestDispatcher; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import br.cefet.campos.info.taii20071n.perfil.model.Cargo; import br.cefetcampos.info.taii20071n.perfil.pesistence.ICargoHelper; public class CargoServlet extends javax.servlet.http.HttpServlet{ private List<Cargo> cargos; private Cargo cargoAtual; private int posicao; protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { doPost(request, response); } protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String nomeForm = request.getParameter("nomeform"); if ("carregar".equals(nomeForm)) {
  • 99. 98 this.carregar(request, response); return;} if ("proximo".equals(nomeForm)) { if (cargos.size() > (posicao+1)) { posicao++; cargoAtual = cargos.get(posicao); request.setAttribute("cargoAtual", cargoAtual); } RequestDispatcher dispatcher = request.getRequestDispatcher("/cargo.jsp"); dispatcher.forward(request, response); return; } if ("anterior".equals(nomeForm)) { if ((posicao-1) >= 0) { posicao--; cargoAtual = cargos.get(posicao); request.setAttribute("cargoAtual", cargoAtual); } RequestDispatcher dispatcher = request.getRequestDispatcher("/cargo.jsp"); dispatcher.forward(request, response); return;} if ("novo".equals(nomeForm)){ cargoAtual = new Cargo(); request.setAttribute("cargoAtual", cargoAtual); RequestDispatcher dispatcher = request.getRequestDispatcher("/cargo.jsp"); dispatcher.forward(request, response); return;} if ("excluir".equals(nomeForm)){ ICargoHelper ihelper = getcargoHelper(); ihelper.delete(cargoAtual); cargoAtual = new Cargo(); request.setAttribute("cargoAtual", cargoAtual); RequestDispatcher dispatcher = request.getRequestDispatcher("/cargo.jsp"); dispatcher.forward(request, response); return;} if (nomeForm.equalsIgnoreCase("incluir")) { int codCar = Integer.parseInt(request.getParameter("txtcodcar")); String titCar = request.getParameter("txttitcar"); String desCar = request.getParameter("txtdescar"); String codCbo = request.getParameter("txtcodcbo"); System.out.println(desCar); Cargo cargo1 = new Cargo(codCar, titCar, codCbo, desCar); ICargoHelper cargoHelper = getcargoHelper(); cargoHelper.save(cargo1); this.carregar(request, response); return; } }
  • 100. 99 private Context getInitialContext() { try { Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); properties.put(Context.PROVIDER_URL, "localhost:1099"); context context = new InitialContext(properties); return context; } catch (NamingException e) { return null; } } private ICargoHelper getcargoHelper() { try { return (ICargoHelper) getInitialContext().lookup( "CargoHelper/local"); } catch (NamingException e) { e.printStackTrace(); return null; } } private void carregar(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ posicao = 0; ICargoHelper helper = getcargoHelper(); cargos = helper.buscarTodosCargos(); if (cargos.size() > 0) cargoAtual = cargos.get(0); request.setAttribute("cargoAtual", cargoAtual); request.setAttribute("cargos", cargos); RequestDispatcher dispatcher = request.getRequestDispatcher("/cargo.jsp"); dispatcher.forward(request, response); return;} } CargoHelper.java package br.cefetcampos.info.taii20071n.perfil.pesistence; import java.util.List; import javax.ejb.Stateless; import javax.persistence.EntityManager; import javax.persistence.PersistenceContext; import javax.persistence.Query; import br.cefet.campos.info.taii20071n.perfil.model.Cargo; @Stateless public class CargoHelper implements ICargoHelper { @PersistenceContext (unitName = "PPP") private EntityManager entCargo; public void save(Cargo cargo ){ Cargo car = entCargo.find(Cargo.class, cargo.getCodCar()); if (car == null) { entCargo.persist(cargo); }
  • 101. 100 else entCargo.merge(cargo); } public void delete(Cargo local){ Cargo mCargo = entCargo.merge(local); entCargo.remove(mCargo); } public Cargo busca(int codCar){ return entCargo.find(Cargo.class, codCar); } public List<Cargo> buscarTodosCargos() Query query = entCargo.createQuery("select l from Cargo l"); List<Cargo> cargos = query.getResultList(); return cargos; } } ICargoHelper.java package br.cefetcampos.info.taii20071n.perfil.pesistence; import java.util.List; import javax.ejb.Local; @Local public interface ICargoHelper { void save(br.cefet.campos.info.taii20071n.perfil.model.Cargo cargo); void delete(br.cefet.campos.info.taii20071n.perfil.model.Cargo cargo); br.cefet.campos.info.taii20071n.perfil.model.Cargo busca(int codCar); List<br.cefet.campos.info.taii20071n.perfil.model.Cargo> buscarTodosCargos(); } Cargo.java package br.cefet.campos.info.taii20071n.perfil.model; import javax.persistence.*; @Entity public class Cargo { @Id private int codCar; private String titCar; private String codCbo; private String desCar; public Cargo() { } public Cargo(int codCar, String titCar, String codCbo, String desCar) { super(); this.codCar = codCar; this.titCar = titCar; this.codCbo = codCbo; this.desCar = desCar;
  • 102. 101 public int getCodCar() { return codCar; } public void setCodCar(int codCar) { this.codCar = codCar; } public String getTitCar() { return titCar; } public void setTitCar(String titCar) { this.titCar = titCar; } public String getCodCbo() { return codCbo; } public void setCodCbo(String codCbo) { this.codCbo = codCbo; } public String getDesCar() { return desCar; } public void setDesCar(String desCar) { this.desCar = desCar; } }
  • 103. 102 APÊNDICE D: EXEMPLO DE TELAS DO SISTEMA Cadastro de Riscos Cadastro de Colaborador
  • 104. 103 Cadastro de Exames Montagem do PPRA (Local Cargo)
  • 105. 104 ANEXO A: PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO (PPP) I SEÇÃO DE DADOS ADMINISTRATIVOS 1- CNPJ do Domicílio Tributário/CEI 2-Nome Empresarial 3- CNAE 4- Nome do Trabalhador 5- BR/PDH 6- NIT 7- Data do Nascimento 8- Sexo (F/M) 9- CTPS (Nº, Série e UF) 10- Data de Admissão 11- Regime Revezamento 12 CAT REGISTRADA 12.1- Data do Registro 12.2- Número da CAT 12.1- Data do Registro 12.2- Número da CAT 13 LOTAÇÃO E ATRIBUIÇÃO 13.1- Período 13.2- CNPJ/CEI 13.3- Setor 13.4- Cargo 13.5- Função 13.6- CBO 13.7- Cód. GFIP __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___ 14 PROFISSIOGRAFIA 14.1- Período 14.2- Descrição das Atividades __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___ II SEÇÃO DE REGISTROS AMBIENTAIS 15 EXPOSIÇÃO A FATORES DE RISCOS 15.1- Período 15.2- Tipo 15.3- Fator de Risco 15.4- Intens./Conc. 15.5- Técnica Utilizada 15.6- EPC Eficaz (S/N) 15.7- EPI Eficaz (S/N) 15.8- CA EPI __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___ 16 RESPONSÁVEL PELOS REGISTROS AMBIENTAIS 16.1- Período 16.2- NIT 16.3- Registro Conselho de Classe 16.4- Nome do Profisssional Legalmente Habilitado __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___
  • 106. 105 __/__/___ ( ) Normal ( ) Alterado ( ) Estável ( ) Agravamento ( ) Ocupacional ( ) Não Ocupacional __/__/___ ( ) Normal ( ) Alterado ( ) Estável ( ) Agravamento ( ) Ocupacional ( ) Não Ocupacional __/__/___ ( ) Normal ( ) Alterado ( ) Estável ( ) Agravamento ( ) Ocupacional ( ) Não Ocupacional __/__/___ ( ) Normal ( ) Alterado ( ) Estável ( ) Agravamento ( ) Ocupacional ( ) Não Ocupacional 18 RESPONSÁVEL PELA MONITORAÇÃO BIOLÓGICA 18.1- Período 18.2- NIT 18.3- Registro Conselho de Classe 18.4- Nome do Profissional Legalmente Habilitado __/__/___ a __/__/___ __/__/___ a __/__/___ __/__/___ a __/__/___ III SEÇÃO DE RESULTADOS DE MONITORAÇÃO BIOLÓGICA 17 EXAMES MÉDICOS CLÍNICOS E COMPLEMENTARES (Quadros I e II, da NR-07) 17.1- Data 17.2- Tipo 17.3- Natureza 17.4- Exame (R/S) 17.5- Indicação de Resultados IV RESPONSÁVEIS PELAS INFORMAÇÕES Declaramos, para todos os fins de direito, que as informações prestadas neste documento são verídicas e foram transcritas fielmente dos registros administrativos, das demonstrações ambientais e dos programas médicos de responsabilidade da empresa. É de nosso conhecimento que a prestação de informações falsas neste documento constitui crime de falsificação de documento público, nos termos do artigo 297 do Código Penal e, também, que tais informações são de caráter privativo do trabalhador, constituindo crime, nos termos da Lei nº 9.029/95, práticas discriminatórias decorrentes de sua exigibilidade por outrem, bem como de sua divulgação para terceiros, ressalvado quando exigida pelos órgãos públicos competentes. 19- Data Emissão PPP 20 REPRESENTANTE LEGAL DA EMPRESA __/__/___ 20.1-NIT 20.2- Nome (Carimbo) __________________________________ (Assinatura) OBSERVAÇÕES
  • 107. 106 INSTRUÇÕES DE PREENCHIMENTO CAMPO DESCRIÇÃO INSTRUÇÃO DE PREENCHIMENTO SEÇÃO I SEÇÃO DE DADOS ADMINISTRATIVOS 1 CNPJ do Domicílio Tributário/CEI CNPJ relativo ao estabelecimento escolhido como domicílio tributário, nos termos do art. 127 do CTN, no formato XXXXXXXX/XXXX-XX; ou Matrícula no Cadastro Específico do INSS (Matrícula CEI) relativa à obra realizada por Contribuinte Individual ou ao estabelecimento escolhido como domicílio tributário que não possua CNPJ, no formato XX.XXX.XXXXX/XX, ambos compostos por caracteres numéricos. 2 Nome Empresarial Até 40 (quarenta) caracteres alfanuméricos. 3 CNAE Classificação Nacional de Atividades Econômicas da empresa, completo, com 7 (sete) caracteres numéricos, no formato XXXXXX-X, instituído pelo IBGE através da Resolução CONCLA nº 07, de 16/12/2002. A tabela de códigos CNAE-Fiscal pode ser consultada na Internet, no site www.cnae.ibge.gov.br. 4 Nome do Trabalhador Até 40 (quarenta) caracteres alfabéticos. 5 BR/PDH BR – Beneficiário Reabilitado; PDH – Portador de Deficiência Habilitado; NA – Não Aplicável. Preencher com base no art. 93, da Lei nº 8.213, de 1991, que estabelece a obrigatoriedade do preenchimento dos cargos de empresas com 100 (cem) ou mais empregados com beneficiários reabilitados ou pessoas portadoras de deficiência, habilitadas, na seguinte proporção: I - ATÉ 200 EMPREGADOS..........................................................................................2%; II - de 201 a 500.....................................................................................................3%; III - de 501 a 1.000................................................................................................4%; IV - de 1.001 em diante. .......................................................................................5%. 6 NIT NÚMERO DE IDENTIFICAÇÃO DO TRABALHADOR COM 11 (ONZE) CARACTERES NUMÉRICOS, NO FORMATO XXX.XXXXX.XX-X. O NIT corresponde ao número do PIS/PASEP/CI sendo que, no caso de Contribuinte Individual (CI), pode ser utilizado o número de inscrição no Sistema Único de Saúde (SUS) ou na Previdência Social. 7 Data do Nascimento No formato DD/MM/AAAA. 8 Sexo (F/M) F – Feminino; M – Masculino. 9 CTPS (Nº, Série e UF) Número, com 7 (sete) caracteres numéricos, Série, com 5 (cinco) caracteres numéricos e UF, com 2 (dois) caracteres alfabéticos, da Carteira de Trabalho e Previdência Social. 10 Data de Admissão No formato DD/MM/AAAA. 11 Regime de Revezamento Regime de Revezamento de trabalho, para trabalhos em turnos ou escala, especificando tempo trabalhado e tempo de descanso, com até 15 (quinze) caracteres alfanuméricos. Exemplo: 24 x 72 horas; 14 x 21 dias; 2 x 1 meses. Se inexistente, preencher com NA – Não Aplicável. 12 CAT REGISTRADA Informações sobre as Comunicações de Acidente do Trabalho registradas pela empresa na Previdência Social, nos termos do art. 22 da Lei nº 8.213, de 1991, do art. 169 da CLT, do art. 336 do RPS, aprovado pelo Dec. nº 3.048, de 1999, do item 7.4.8, alínea “a” da NR-07 do MTE e dos itens 4.3.1 e 6.1.2 do Anexo 13-A da NR-15 do MTE, disciplinado pela Portaria MPAS nº 5.051, de 1999, que aprova o Manual de Instruções para Preenchimento da CAT. 12.1 Data do Registro No formato DD/MM/AAAA. 12.2 Número da CAT Com 13 (treze) caracteres numéricos, com formato XXXXXXXXXX-X/XX. Os dois últimos caracteres correspondem a um número seqüencial relativo ao mesmo acidente, identificado por NIT, CNPJ e data do acidente. 13 LOTAÇÃO E ATRIBUIÇÃO Informações sobre o histórico de lotação e atribuições do trabalhador, por período. A alteração de qualquer um dos campos - 13.2 a 13.7 - implica, obrigatoriamente, a criação de nova linha, com discriminação do período, repetindo as informações que não foram alteradas. 13.1 Período Data de início e data de fim do período, ambas no formato DD/MM/AAAA. No caso de trabalhador ativo, a data de fim do último período não deverá ser preenchida. 13.2 CNPJ/CEI Local onde efetivamente o trabalhador exerce suas atividades. Deverá ser informado o CNPJ do estabelecimento de lotação do trabalhador ou da empresa tomadora de serviços, no formato XXXXXXXX/XXXX-XX; ou Matrícula CEI da obra ou do estabelecimento que não possua CNPJ, no formato XX.XXX.XXXXX/XX, ambos compostos por caracteres numéricos. 13.3 Setor Lugar administrativo na estrutura organizacional da empresa, onde o trabalhador exerce suas atividades laborais, com até 15 (quinze) caracteres alfanuméricos. 13.4 Cargo Cargo do trabalhador, constante na CTPS, se empregado ou trabalhador avulso, ou constante no Recibo de Produção e Livro de Matrícula, se cooperado, com até 30 (trinta) caracteres alfanuméricos. 13.5 Função Lugar administrativo na estrutura organizacional da empresa, onde o trabalhador tenha atribuição de comando, chefia, coordenação, supervisão ou gerência. Quando inexistente a função, preencher com NA – Não Aplicável, com até 30 (trinta) caracteres alfanuméricos. 13.6 CBO Classificação Brasileira de Ocupação vigente à época, com 6 (seis) caracteres numéricos: 1- No caso de utilização da tabela CBO relativa a 1994, utilizar a CBO completa com 5 (cinco) caracteres, completando com “0” (zero) a primeira posição; 2- No caso de utilização da tabela CBO relativa a 2002, utilizar a CBO completa com 6
  • 108. 107 (seis) caracteres. Alternativamente, pode ser utilizada a CBO, com 5 (cinco) caracteres numéricos, conforme Manual da GFIP para usuários do SEFIP, publicado por Instrução Normativa da Diretoria Colegiada do INSS: 1- No caso de utilização da tabela CBO relativa a 1994, utilizar a CBO completa com 5 (cinco) caracteres; 2- No caso de utilização da tabela CBO relativa a 2002, utilizar a família do CBO com 4 (quatro) caracteres, completando com “0” (zero) a primeira posição. A tabela de CBO pode ser consultada na Internet, no site www.mtecbo.gov.br. OBS: Após a alteração da GFIP, somente será aceita a CBO completa, com 6 (seis) caracteres numéricos, conforme a nova tabela CBO relativa a 2002. 13.7 Código Ocorrência da GFIP Código Ocorrência da GFIP para o trabalhador, com 2 (dois) caracteres numéricos, conforme Manual da GFIP para usuários do SEFIP, publicado por Instrução Normativa da Diretoria Colegiada do INSS. 14 PROFISSIOGRAFIA Informações sobre a profissiografia do trabalhador, por período. A alteração do campo 14.2 implica, obrigatoriamente, a criação de nova linha, com discriminação do período. 14.1 Período Data de início e data de fim do período, ambas no formato DD/MM/AAAA. No caso de trabalhador ativo, a data de fim do último período não deverá ser preenchida. 14.2 Descrição das Atividades Descrição das atividades, físicas ou mentais, realizadas pelo trabalhador, por força do poder de comando a que se submete, com até 400 (quatrocentos) caracteres alfanuméricos. As atividades deverão ser descritas com exatidão, e de forma sucinta, com a utilização de verbos no infinitivo impessoal. SEÇÃO II SEÇÃO DE REGISTROS AMBIENTAIS 15 EXPOSIÇÃO A FATORES DE RISCOS Informações sobre a exposição do trabalhador a fatores de riscos ambientais, por período, ainda que estejam neutralizados, atenuados ou exista proteção eficaz. Facultativamente, também poderão ser indicados os fatores de riscos ergonômicos e mecânicos. A alteração de qualquer um dos campos - 15.2 a 15.8 - implica, obrigatoriamente, a criação de nova linha, com discriminação do período, repetindo as informações que não foram alteradas. OBS.: Após a implantação da migração dos dados do PPP em meio magnético pela Previdência Social, as informações relativas aos fatores de riscos ergonômicos e mecânicos passarão a ser obrigatórias. 15.1 Período Data de início e data de fim do período, ambas no formato DD/MM/AAAA. No caso de trabalhador ativo, a data de fim do último período não deverá ser preenchida. 15.2 Tipo F – Físico; Q – Químico; B – Biológico; E – Ergonômico/Psicossocial, M – Mecânico/de Acidente, conforme classificação adotada pelo Ministério da Saúde, em “Doenças Relacionadas ao Trabalho: Manual de Procedimentos para os Serviços de Saúde”, de 2001. A indicação do Tipo “E” e “M” é facultativa. O que determina a associação de agentes é a superposição de períodos com fatores de risco diferentes. 15.3 Fator de Risco Descrição do fator de risco, com até 40 (quarenta) caracteres alfanuméricos. Em se tratando do Tipo “Q”, deverá ser informado o nome da substância ativa, não sendo aceitas citações de nomes comerciais. 15.4 Intensidade / Concentração Intensidade ou Concentração, dependendo do tipo de agente, com até 15 (quinze) caracteres alfanuméricos. Caso o fator de risco não seja passível de mensuração, preencher com NA – Não Aplicável. 15.5 Técnica Utilizada Técnica utilizada para apuração do item 15.4, com até 40 (quarenta) caracteres alfanuméricos. Caso o fator de risco não seja passível de mensuração, preencher com NA – Não Aplicável. 15.6 EPC Eficaz (S/N) S – Sim; N – Não, considerando se houve ou não a eliminação ou a neutralização, com base no informado nos itens 15.2 a 15.5, assegurada as condições de funcionamento do EPC ao longo do tempo, conforme especificação técnica do fabricante e respectivo plano de manutenção. 15.7 EPI Eficaz (S/N) S – Sim; N – Não, considerando se houve ou não a atenuação, com base no informado nos itens 15.2 a 15.5, observado o disposto na NR-06 do MTE, assegurada a observância: 1- da hierarquia estabelecida no item 9.3.5.4 da NR-09 do MTE (medidas de proteção coletiva, medidas de caráter administrativo ou de organização do trabalho e utilização de EPI, nesta ordem, admitindo-se a utilização de EPI somente em situações de inviabilidade técnica, insuficiência ou interinidade à implementação do EPC, ou ainda em caráter complementar ou emergencial); 2- das condições de funcionamento do EPI ao longo do tempo, conforme especificação técnica do fabricante ajustada às condições de campo; 3- do prazo de validade, conforme Certificado de Aprovação do MTE; 4- da periodicidade de troca definida pelos programas ambientais, devendo esta ser comprovada mediante recibo; e 5- dos meios de higienização. 15.8 C.A. EPI Número do Certificado de Aprovação do MTE para o Equipamento de Proteção Individual referido no campo 154.7, com 5 (cinco) caracteres numéricos. Caso não seja utilizado EPI, preencher com NA – Não Aplicável. 16 RESPONSÁVEL PELOS REGISTROS AMBIENTAIS Informações sobre os responsáveis pelos registros ambientais, por período. 16.1 Período Data de início e data de fim do período, ambas no formato DD/MM/AAAA. No caso de
  • 109. 108 trabalhador ativo sem alteração do responsável, a data de fim do último período não deverá ser preenchida. 16.2 NIT Número de Identificação do Trabalhador com 11 (onze) caracteres numéricos, no formato XXX.XXXXX.XX-X. O NIT corresponde ao número do PIS/PASEP/CI sendo que, no caso de Contribuinte Individual (CI), pode ser utilizado o número de inscrição no Sistema Único de Saúde (SUS) ou na Previdência Social. 16.3 Registro Conselho de Classe Número do registro profissional no Conselho de Classe, com 9 (nove) caracteres alfanuméricos, no formato XXXXXX-X/XX ou XXXXXXX/XX. A parte “-X” corresponde à D – Definitivo ou P – Provisório. A parte “/XX” deve ser preenchida com a UF, com 2 (dois) caracteres alfabéticos. A parte numérica deverá ser completada com zeros à esquerda. 16.4 Nome do Profissional Legalmente Habilitado Até 40 (quarenta) caracteres alfabéticos. SEÇÃO III SEÇÃO DE RESULTADOS DE MONITORAÇÃO BIOLÓGICA 17 EXAMES MÉDICOS CLÍNICOS E COMPLEMENTARES Informações sobre os exames médicos obrigatórios, clínicos e complementares, realizados para o trabalhador, constantes nos Quadros I e II, da NR-07 do MTE. 17.1 Data No formato DD/MM/AAAA. 17.2 Tipo A – Admissional; P – Periódico; R – Retorno ao Trabalho; M – Mudança de Função; D – Demissional. 17.3 Natureza Natureza do exame realizado, com até 50 (cinqüenta) caracteres alfanuméricos. No caso dos exames relacionados no Quadro I da NR-07, do MTE, deverá ser especificada a análise realizada, além do material biológico coletado. 17.4 Exame (R/S) R – Referencial; S – Seqüencial. 17.5 Indicação de Resultados Preencher Normal ou Alterado. Só deve ser preenchido Estável ou Agravamento no caso de Alterado em exame Seqüencial. Só deve ser preenchido Ocupacional ou Não Ocupacional no caso de Agravamento. OBS: No caso de Natureza do Exame “Audiometria”, a alteração unilateral poderá ser classificada como ocupacional, apesar de a maioria das alterações ocupacionais serem constatadas bilateralmente. 18 RESPONSÁVEL PELA MONITORAÇÃO BIOLÓGICA Informações sobre os responsáveis pela monitoração biológica, por período. 18.1 Período Data de início e data de fim do período, ambas no formato DD/MM/AAAA. No caso de trabalhador ativo sem alteração do responsável, a data de fim do último período não deverá ser preenchida. 18.2 NIT Número de Identificação do Trabalhador com 11 (onze) caracteres numéricos, no formato XXX.XXXXX.XX-X. O NIT corresponde ao número do PIS/PASEP/CI sendo que, no caso de Contribuinte Individual (CI), pode ser utilizado o número de inscrição no Sistema Único de Saúde (SUS) ou na Previdência Social. 18.3 Registro Conselho de Classe Número do registro profissional no Conselho de Classe, com 9 (nove) caracteres alfanuméricos, no formato XXXXXX-X/XX ou XXXXXXX/XX. A parte “-X” corresponde à D – Definitivo ou P – Provisório. A parte “/XX” deve ser preenchida com a UF, com 2 (dois) caracteres alfabéticos. A parte numérica deverá ser completada com zeros à esquerda. 18.4 Nome do Profissional Legalmente Habilitado Até 40 (quarenta) caracteres alfabéticos. SEÇÃO IV RESPONSÁVEIS PELAS INFORMAÇÕES 19 Data de Emissão do PPP Data em que o PPP é impresso e assinado pelos responsáveis, no formato DD/MM/AAAA. 20 REPRESENTANTE LEGAL DA EMPRESA Informações sobre o Representante Legal da empresa, com poderes específicos outorgados por procuração. 20.1 NIT Número de Identificação do Trabalhador com 11 (onze) caracteres numéricos, no formato XXX.XXXXX.XX-X. O NIT corresponde ao número do PIS/PASEP/CI sendo que, no caso de contribuinte individual (CI), pode ser utilizado o número de inscrição no Sistema Único de Saúde (SUS) ou na Previdência Social. 20.2 Nome Até 40 caracteres alfabéticos. Carimbo e Assinatura Carimbo da Empresa e Assinatura do Representante Legal. 1.1 OBSERVAÇÕES Devem ser incluídas neste campo, informações necessárias à análise do PPP, bem como facilitadoras do requerimento do benefício, como por exemplo, esclarecimento sobre alteração de razão social da empresa, no caso de sucessora ou indicador de empresa pertencente a grupo econômico. OBS: É facultada a inclusão de informações complementares ou adicionais ao PPP.

×