aplicação da engenharia de domínio em um software para ppp
DESCRIPTION
Estudo e aplicação da Engenharia de Domínio em um software para emissão do PPP.TRANSCRIPT
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
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
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.
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
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.
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.
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.
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
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
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
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
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
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
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
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..
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.
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.
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.
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
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
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.
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.
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
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.
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
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.
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.
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.
Car
acte
ríst
icas
de
Aná
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.
Car
acte
ríst
icas
de
Pro
jeto
(T
ecno
lógi
cas)
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.
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.
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.
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,
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.
Rel
acio
nam
ento
s E
spec
ífic
os
na O
dyss
ey-F
EX
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,
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).
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.
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.
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.
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
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,
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)
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.
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.
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
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
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
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.
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.
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.
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
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
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.
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.
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.
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,
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
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).
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.
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,
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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
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:
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
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
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.
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).
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.
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.
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.
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.
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.
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.
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
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
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.
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
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
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
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
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.
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
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.
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
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.
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.
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
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.
94
APÊNDICE B: DIAGRAMA DE CLASSE PARA EMISSÃO E CONTROLE DO
PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO
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á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> </p> <p> </p></td> <td height="58" nowrap="nowrap" colspan="2" id="logo" valign="bottom">PPP</td> <td width="45"> </td> </tr> <tr bgcolor="02021E"> <td height="57" nowrap="nowrap" colspan="2" id="tagline" valign="top">PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO </td> <td width="45"> </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"> <br /> <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órico de Local </a></td> </tr> <tr> <td width="155" height="40"><a>Histórico de Cargo </a></td>
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ó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í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ó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> </td> </tr> <tr> <td> </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>
97
<td> </td> <td> </td> </tr> </table></td> </tr> </table> </form> <p> </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"> </td> </tr> <tr> <td width="155"> </td> <td width="1"></td> <td width="50"> </td> <td width="24"> </td> <td width="2767"> </td> <td width="4"> </td> <td width="45"> </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)) {
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; }
}
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); }
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;
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; }
}
102
APÊNDICE D: EXEMPLO DE TELAS DO SISTEMA
Cadastro de Riscos
Cadastro de Colaborador
103
Cadastro de Exames
Montagem do PPRA (Local Cargo)
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 __/__/___
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
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
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
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.