CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SOFTWARE
DÁVISSON HÚDSON CHAVES BERNADETE
ELIEZER DUTRA GONÇALVES
RICARDO LUIZ D...
DÁVISSON HÚDSON CHAVES BERNADETE
ELIEZER DUTRA GONÇALVES
RICARDO LUIZ DA SILVA CHAGAS
APLICANDO A ENGENHARIA DE DOMÍNIO NA...
DÁVISSON HÚDSON CHAVES BERNADETE
ELIEZER DUTRA GONÇALVES
RICARDO LUIZ DA SILVA CHAGAS
APLICANDO A ENGENHARIA DE DOMÍNIO NA...
Dados de Catalogação na Publicação (CIP)
B517a Bernadete, Dávisson Húdson Chaves.
Aplicando a engenharia de domínio na con...
AGRADECIMENTOS
Dávisson:
Primeiramente, agradeço a Deus pelas minhas conquistas baseada em esforço e dedicação, por
ter ab...
RESUMO
Este projeto visa a aplicação de técnicas de reutilização de software para a construção de um
framework para a emis...
ABSTRACT
This project involves the application of software reuse techniques aiming at the construction
of a framework for ...
LISTA DE FIGURAS
Figura 2.1 Ciclo de Vida da Engenharia de Domínio (OLIVEIRA, 2006) ...................... 19
Figura 2.2 F...
Figura 4.2 Retorno do Servlet para a página local.jsp .................................................... 69
Figura 4.3 P...
LISTA DE TABELAS
Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006) ....... 27
Tabela 2.2 Tipos d...
LISTA DE SIGLAS
AD Análise de Domínio
API Application Programming Interface
ASO Atestado de Saúde Ocupacional
BD Banco de ...
SUMÁRIO
LISTA DE FIGURAS.....................................................................................................
3.2.5.1 Características de PCMSO ............................................... 53
3.2.5.2 Características dos Exames ......
CAPÍTULO 1: INTRODUÇÃO
1.1 Motivação
A sociedade atualmente está diante dos avanços tecnológicos impostos pelo mundo, e
nã...
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...
15
1.2 Objetivos
O objetivo desse projeto é explorar o desenvolvimento de software voltado à
reutilização, explorando algu...
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 ...
CAPÍTULO 2: REFERENCIAL TEÓRICO
2.1 Introdução
Atualmente, grande parte do software já está sendo criado a partir de outro...
18
classes cooperantes que constroem um projeto reutilizável para uma específica classe de
software (GAMMA et al, 2000). E...
19
são catalogados e armazenados de forma que possam ser utilizados a qualquer momento por
outra aplicação que esteja no m...
20
seguintes fases ou macro-atividades que sistematizam a construção do modelo de domínio:
Planejamento, Análise, Projeto ...
21
Dentre as atividades que são realizadas nesta etapa, podemos destacar o estudo de
mercado do domínio, para saber a exis...
22
Após a etapa de Projeto, a última etapa que a ED engloba, como foi descrito
anteriormente, é a Implementação do Domínio...
23
especificação dos requisitos do domínio, assim como a Análise de Requisitos de um software
envolve a sua especificação ...
24
2.2.2 O Ambiente de Reutilização de Software Odyssey
Todo software está continuamente sujeito a modificações, motivadas...
25
é feito o recorte do domínio, determinando-se as características que devem
compor as aplicações (a ressalva se faz para...
26
O ambiente Odyssey está disponível para download, em sua versão light, na página
http://reuse.cos.ufrj.br/odyssey, onde...
27
Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006)
Como já dito, essas características devem s...
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 amb...
29
Característica Definição
Pontos de Variação Determinados pontos em um sistema de software onde
decisões são tomadas a r...
30
Figura 2.6 Classificações das características
Além da variabilidade, as características também podem apresentar a propr...
31
generalização e assossiação. A tabela 2.3 demonstra os relacionamentos específicos na
notação Odyssey-FEX:
Representaçã...
32
através de um projeto de software genérico, proporcionando uma melhoria na qualidade do
sistema, através da reutilizaçã...
33
2.3.1 Tipos de Frameworks
De acordo com a forma de reutilização, os frameworks podem ser classificados, como:
caixa bra...
34
Durante o projeto do domínio, uma arquitetura de software genérica que atenda aos
requisitos do domínio é desenvolvida....
35
CAPÍTULO 3: ANÁLISE E PROJETO DE DOMÍNIO PARA A CONSTRUÇÃO DO
FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO
PREVIDENC...
36
Um dos pontos inerentes ao PPP é que trabalhadores que estejam sujeitos a condições
especiais que prejudiquem a sua saú...
37
maioria dos casos, pela Consolidação das Leis do Trabalho (CLT) e várias outras leis, como:
Instruções Normativas (IN),...
38
funcionalidade do subdomínio de Administração de Pessoal, só é realizada
após as seleções. Dessa forma, esse subdomínio...
39
Dessa forma, devido à obrigatoriedade de emissão do PPP e da sua importância, pois a
empresa que não mantiver o PPP atu...
40
• Agente de RH
Responsável pelo controle das rotinas de admissão, férias, rescisões, cadastros
de locais, funções, cola...
41
Nas seções a seguir, são analisadas as características desses subdomínios necessárias à
implementação e emissão do PPP....
42
fator importante é a descrição do cargo, que segundo a Instrução Normativa (IN) 99/2003, em
seu Anexo XV (MPS, 2003) de...
43
essas movimentações são registradas nos Históricos. Os relacionamentos do colaborador com
os históricos, mostram que é ...
44
controle Médico e Saúde Ocupacional (PCMSO) e Programa de Prevenção dos Riscos
Ambientais (PPRA) (MPS, 2003).
A empresa...
45
Essa característica é representa no campo 13.2 do PPP, onde é apresentado através do
CNPJ/CEI da filial ou da tomadora ...
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, ...
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
s...
48
Ambientais) é feito para um risco somente, mas um risco pode ter de zero a vários PPRAs
associados a ele.
Tabela 3.2 Li...
49
risco, este limite varia de acordo com risco a que ele é exposto e, portanto, varia de risco para
risco. No diagrama de...
50
3.2.4.3 Características do PPRA
O PPRA tem a finalidade de aplicar técnicas de higiene e segurança ocupacional,
definin...
51
Figura 3.7 Diagrama de Características Conceituais do PPRA
A característica conceitual PPRA, apresenta na figura 3.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...
53
estando mais voltado para os Exames Médicos Clínicos, Complementares e Monitoração
Biológica que são regidos através de...
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Aplicação da Engenharia de Domínio em um software para PPP
Upcoming SlideShare
Loading in …5
×

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

1,635 views

Published on

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

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

No Downloads
Views
Total views
1,635
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SOFTWARE DÁVISSON HÚDSON CHAVES BERNADETE ELIEZER DUTRA GONÇALVES RICARDO LUIZ DA SILVA CHAGAS APLICANDO A ENGENHARIA DE DOMÍNIO NA CONSTRUÇÃO DE UM FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO Campos dos Goytacazes/RJ 2007
  2. 2. DÁVISSON HÚDSON CHAVES BERNADETE ELIEZER DUTRA GONÇALVES RICARDO LUIZ DA SILVA CHAGAS APLICANDO A ENGENHARIA DE DOMÍNIO NA CONSTRUÇÃO DE UM FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO Trabalho de Conclusão de Curso apresentado ao Centro Federal de Educação Tecnológica de Campos como requisito parcial para conclusão do Curso de Tecnologia em Desenvolvimento de Software. Orientadora: Profª. Aline Pires Vieira de Vasconcelos, D.Sc. Campos dos Goytacazes/RJ 2007
  3. 3. DÁVISSON HÚDSON CHAVES BERNADETE ELIEZER DUTRA GONÇALVES RICARDO LUIZ DA SILVA CHAGAS APLICANDO A ENGENHARIA DE DOMÍNIO NA CONSTRUÇÃO DE UM FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO Trabalho de Conclusão de Curso apresentada ao Centro Federal de Educação Tecnológica de Campos como requisito parcial para conclusão do Curso de Tecnologia em Desenvolvimento de Software. Aprovados em 20 de setembro de 2007. Banca Avaliadora: ________________________________________________________ Profª. Aline Pires Vieira de Vasconcelos, D.Sc. (Orientadora) ______________________________________________ Profª. Ana Sílvia R. Santiago, M.Sc. ______________________________________________ Prof. Marcelo Machado Feres, M.Sc.
  4. 4. Dados de Catalogação na Publicação (CIP) B517a Bernadete, Dávisson Húdson Chaves. Aplicando a engenharia de domínio na construção de um framework de emissão do perfil profissiográfico previdenciário / Dávisson Húdson Chaves Bernadete, Eliezer Dutra Gonçalves, Ricardo Luiz da Silva Chagas. – Campos dos Goytacazes, RJ : [s.n.], 2007. 109 f. ; il. Orientadora: Aline Pires Vieira de Vasconcelos. Monografia (Tecnologia de Desenvolvimento de Software). Centro Federal de Educação Tecnológica de Campos. Campos dos Goytacazes, RJ, 2007. Bibliografia: f. 79-84. 1. Framework – Programa de computador. 2. Software - Desenvolvimento. 3. Sistema de informação gerencial. 4. Sistema de recuperação da informação. I. Gonçalves, Eliezer Dutra. II. Chagas, Ricardo Luiz da Silva. III. Vasconcelos, Aline Pires Vieira de , orient. IV. Título. CDD – 005.3
  5. 5. AGRADECIMENTOS Dávisson: Primeiramente, agradeço a Deus pelas minhas conquistas baseada em esforço e dedicação, por ter aberto portas em meu caminho que levam à vitória sobre todas as coisas. Sua força é maior em todos os sentidos, e por isso me ajudaram nos momentos de dificuldade. Agradeço à Aline, nossa orientadora, por ajudar e compreender nossos erros no projeto, e incentivar a busca por novas áreas de conhecimento. Agradeço aos meus amigos por me darem força e incentivo, em especial aos companheiros da minha cidade Conceição de Macabu, que viajam constantemente comigo na busca do ensino que o CEFET proporciona, e aos meus colegas de classe, pessoas capazes e que se ajudam mutuamente na busca do saber. Agradeço também ao meu amigo Eliezer, que além de ser um dos membros do projeto, me ajudou num momento no qual estava desempregado, quase trancando a matrícula, e ele me conseguiu uma bolsa de inicialização cientifica na UENF. Isso se explica devido à dependência do emprego para manter os meus estudos, já que moro em outra cidade . E por último, mas não menos importante, a minha família e amigos de trabalho, por ter compreendido meus momentos de ausência dedicados ao estudo. Eliezer: Primeiramente agradeço ao meu Senhor e Salvador Jesus Cristo por ter morrido em uma cruz para me salvar. A Minha esposa, Michele, que teve paciência e amor para comigo. NEOQUEAV. Aos meus pais, Devanil e Marlene, por cuidarem de mim e sempre me apoiarem em todos os momentos. Agradeço aos professores do CEFET Campos pelo conhecimento proporcionado, em especial a orientadora do projeto Profª. Drª. Aline Pires que incansavelmente corrigiu esse trabalho e ajudou em todo o seu desenvolvimento. Ao colega de classe, Alamir Rodrigues pelo apoio durante o curso. Aos amigos Dávisson e Ricardo pelos esforços na elaboração desse trabalho. Aos amigos da UENF: Alexandre pela a ajuda na implementação do Framework; André Luiz, Maritza e Vanuzia por terem me recebido de braços abertos e terem se tornardo meus amigos. Ricardo: Quero agradecer primeiro a Deus por ter me dado forças para chegar até o fim desta jornada, pois sem ele nada seria possível. Também a toda minha família, e principalmente a minha esposa, que entendeu todas as minhas dificuldades, falhas, e me ajudou e incentivou para que eu continuasse. Agradeço também à nossa orientadora Aline, que soube entender as limitações e dificuldades na elaboração do trabalho, e também a todos os professores do CEFET por transmitir o conhecimento que adquiri nesse tempo. Por fim queria agradecer a todos os colegas da turma, que estiveram sempre unidos e se ajudando, principalmente o Eliezer que num momento de dificuldade após meu casamento me ajudou muito com a matéria acumulada. Enfim, a todos que nesta etapa da minha vida contribuíram de alguma forma para que eu alcançasse o sucesso, obrigado.
  6. 6. RESUMO Este projeto visa a aplicação de técnicas de reutilização de software para a construção de um framework para a emissão do Perfil Profissiográfico Previdenciário (PPP). As técnicas empregadas englobam a Engenharia de Domínio, envolvendo principalmente a Análise de Domínio (AD), e princípios de frameworks, como a determinação de seus pontos configuráveis (i.e. hot-spots). O PPP representa um documento histórico-laboral dos trabalhadores, que deve ser entregue ao Instituto Nacional de Seguro Social (INSS) por ocasião de encerramento de contrato ou término da prestação de serviço, aposentadoria especial ou afastamento do trabalho por fatores de segurança, saúde ou incapacidade. Ele deve conter todo o histórico-laboral do trabalhador, abrangendo, cronologicamente por período, informações administrativas (setor, cargo, função etc.), ambientais e biológicas relacionadas ao trabalhador, para fins de comprovação e controle, e minimização de fraudes. O PPP está integrado à gestão de pessoal, permitindo o monitoramento e registro dos fatores de risco que afetem a saúde do trabalhador e a sua segurança, de modo a organizar e individualizar as informações contidas em diversos setores da empresa. Com isso, o INSS comprova as condições para habilitação de benefícios e serviços previdenciários. Através da AD, visa-se determinar aspectos comuns e variáveis entre empresas no que diz respeito à administração de pessoal e emissão do PPP, permitindo, dessa forma, o desenvolvimento de artefatos reutilizáveis de software. É utilizado o ambiente Odyssey, desenvolvido pela COPPE/UFRJ, para apoiar o processo, pois o desenvolvimento voltado à reutilização envolve maior esforço do que aquele voltado a uma aplicação específica. Palavras-chave: Engenharia de Domínio (ED), Perfil Profissiográfico Previdenciário (PPP), Frameworks, Gestão de Recursos Humanos (GRH), Análise de Domínio (AD), Variabilidade e Opcionalidade.
  7. 7. ABSTRACT This project involves the application of software reuse techniques aiming at the construction of a framework for the emission of the Providenciary Profissiographic Profile (PPP). The employed techniques encompass Domain Engineering, mainly involving Domain Analysis (DA), and principles of frameworks, as the determination of its configuration points (i.e. hot- spots). The PPP represents a historical-labor document of the workers, that must be delivered to the National Institute of Social Security (INSS) in the occurrence of contract or provision of services ending, special retirement, or removal of the work for security factors, health problems or incapacity. It must contain all the description-labor of the worker, enclosing, chronologically by period, administrative information (department, post, function etc.), biological and environmental information, allowing the INSS to get evidences and to control the worker conditions, minimizing frauds. The PPP is integrated to the staff management, allowing the monitoring and recording of risk factors that affect the health and security of the worker. Therefore, it is possible to organize and individualize the information contained in the diverse set of company departments. Through the PPP, the INSS can prove the conditions to give benefits and providence services. Through the DA, it is possible to determine common and variable aspects among companies in respect to the staff administration and emission of the PPP, allowing, the development of reusable software artifacts. The Odyssey environment, developed by COPPE/UFRJ, is used to support the process, since the development for reuse requires a greater effort than the one involving a specific application. Keywords: Domain Engineering (DE), Providenciary Profissiographic Profile (PPP), Frameworks, Staff Management, Domain Analysis (DA), Variabilities and Optionalities.
  8. 8. LISTA DE FIGURAS Figura 2.1 Ciclo de Vida da Engenharia de Domínio (OLIVEIRA, 2006) ...................... 19 Figura 2.2 Fases da Engenharia de Domínio (UFPE, 2007a) .......................................... 20 Figura 2.3 Um modelo genérico de desenvolvimento para/com reuso ............................ 22 Figura 2.4 Modelos de domínio (i.e. características, casos de uso e classes) e suas ligações de rastreabilidade no ambiente Odyssey ............................................................ 25 Figura 2.5 Características conceituais e funcionais da notação Odyssey-FEX ............... 28 Figura 2.6 Classificações das características ................................................................... 30 Figura 2.7 Propriedades ortogonais da notação Odyssey-FEX ........................................ 30 Figura 2.8 Classificação ortogonal das características na notação Odyssey-FEX ........... 31 Figura 3.1 Diagrama de Contextos do Domínio de Gestão de Recursos Humanos ......... 40 Figura 3.2 Diagrama de Características Conceituas de Cargo ......................................... 41 Figura 3.3 Diagrama de Característica Conceituas de Local ........................................... 42 Figura 3.4 Diagrama de Características Conceituas do Colaborador .............................. 43 Figura 3.5 Diagrama de Características Conceituas dos Históricos do Colaborador ...... 44 Figura 3.6 Diagrama de Características Conceituais de Risco ........................................ 47 Figura 3.7 Diagrama de Características Conceituais do PPRA .................................... 51 Figura 3.8 Diagrama de Características Funcionais da montagem do PPRA .................. 52 Figura 3.9 Diagrama de características conceituais de PCMSO .................................... 53 Figura 3.10 Diagrama de características conceituais de Exame ...................................... 55 Figura 3.11 Diagrama de características conceituais de Histórico de Exame .................. 56 Figura 3.12 Diagrama de Classes de parte do subdomínio de Administração de Pessoal – Características de Colaborador ..................................................................................... 57 Figura 3.13 Diagrama de Classe do subdomínio de Administração de Pessoal – Históricos ......................................................................................................................... 58 Figura 3.14 Diagrama de Classe do subdomínio de Segurança – Montagem do PPRA .. 59 Figura 3.15 Opções de Mapeamentos no Odyssey .......................................................... 59 Figura 3.16 Diagrama de Classe do subdomínio de Medicina – Históricos .................... 60 Figura 3.17 Diagrama de Casos de Uso ........................................................................... 61 Figura 3.18 Wizard de mapeamento de características funcionais para casos de uso no ambiente Odyssey ............................................................................................................ 61 Figura 4.1 Arquitetura Lógica do Java EE 5 (SILVA e MOREIRA, 2006) .................... 65
  9. 9. Figura 4.2 Retorno do Servlet para a página local.jsp .................................................... 69 Figura 4.3 Página local.jsp interagindo com o Servlet ................................................... 69 Figura 4.4 Cadastro de Cargo em JSP que mostra a tela de cargo ................................... 70 Figura 4.5 Exemplo de código do arquivo persistence.xml ............................................. 71 Figura 4.6 Mapeamento de persistência da Classe Cargo ................................................ 72 Figura 4.7 Exemplo de código do relacionamento muitos para um unidirecinal ............. 73 Figura 4.8 Implentação de persitência na classe Cargo ................................................... 74
  10. 10. LISTA DE TABELAS Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006) ....... 27 Tabela 2.2 Tipos de Características no ambiente Odyssey .............................................. 29 Tabela 2.3 Relacionamentos da notação Odyssey-FEX .................................................. 31 Tabela 3.1 Obrigatoriedade de Emissão do Perfil Profissiográfico Previdenciário ......... 38 Tabela 3.2 Limites de tolerância para ruído contínuo ou intermitente ............................ 48
  11. 11. LISTA DE SIGLAS AD Análise de Domínio API Application Programming Interface ASO Atestado de Saúde Ocupacional BD Banco de dados CAT Comunicação de Acidente do Trabalho CLT Consolidação das Leis do Trabalho CNPJ Cadastro Nacional de Pessoa Jurídica CRUD Create, Read, Update e Delete EA Engenharia de Aplicação ED Engenharia de Domínio EJB Enterprise JavaBeans EPC Euipamento de Proteção Coletiva EPI Equipamento de Proteção Individual GRH Gestão de Recursos Humanos GUJ Grupo de Usuários Java HH Homem Hora HTML HyperText Markup Language IN Instruções Normativas JEE Java Enterprise Edition JMS Java Message Service JMX Java Management Extensions JPA Java Persistência API JSF JavaServer Faces JSP JavaServer Pages JSTL JSP Standard Tag Library MP Medidas Provisórias MTE Ministério do Trabalho e Emprego MVC Model View Control NR Normas Regulamentadoras OMG Object Management Group OO Orientação a Objeto PCMSO Programa de Controle Médico de Saúde Ocupacional POJO Plain Old Java Objects PPP Perfil Profissiográfico Previdenciário PPRA Programa de Prevenção a Riscos Ambientais SESMT Serviço Especializado em Engenharia e Segurança em Medicina do Trabalho SGBD Sistema Gerenciadores de Bando de Dados UML Unified Modeling Language
  12. 12. SUMÁRIO LISTA DE FIGURAS....................................................................................................... 7 LISTA DE TABELAS .................................................................................................... 8 LISTA DE SIGLAS ......................................................................................................... 9 CAPÍTULO 1: INTRODUÇÃO ................................................................................... 13 1.1 Motivação ....................................................................................................... 13 1.2 Objetivos ........................................................................................................ 15 1.3 Organização da Monografia 15 CAPÍTULO 2: REFERENCIAL TEÓRICO .............................................................. 17 2.1 Introdução ....................................................................................................... 17 2.2 Engenharia de Domínio .................................................................................. 18 2.2.1 Análise de Domínio.......................................................................... 22 2.2.2 O Ambiente de Reutilização de Software Odyssey ......................... 24 2.2.2.1 A Notação Odyssey-FEX ................................................. 26 2.3 Frameworks .................................................................................................... 31 2.3.1 Tipos de Frameworks ...................................................................... 33 2.4 Considerações Finais ...................................................................................... 33 CAPÍTULO 3: ANÁLISE DE DOMÍNIO PARA A CONSTRUÇÃO DO FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO ...................................................................................................... 35 3.1 Introdução ....................................................................................................... 35 3.2 Análise de Domínio ....................................................................................... 35 3.2.1 Descrição do Domínio ..................................................................... 36 3.2.2 Contextos ......................................................................................... 39 3.2.3 Subdomínio de Administração de Pessoal ...................................... 41 3.2.3.1 Características de Cargos e Locais ................................... 41 3.2.3.2 Características de Colaborador e seus Históricos ............. 42 3.2.4 Subdomínio de Segurança ............................................................... 46 3.2.4.1 Características dos Riscos ................................................ 47 3.2.4.2 Características dos Equipamentos de Proteção ................ 49 3.2.4.3 Características do PPRA ................................................... 50 3.2.5 Subdomínio Medicina ..................................................................... 52
  13. 13. 3.2.5.1 Características de PCMSO ............................................... 53 3.2.5.2 Características dos Exames .............................................. 54 3.2.5.3 Histórico de Exames.......................................................... 55 3.3 Mapeamento do Modelo de Características para o Modelo de Classes ......... 56 3.4 Mapeamento do Modelo de Características para o modelo de Casos de Uso 60 CAPITULO 4: TECNOLOGIAS EMPREGADAS NO FRAMEWORK ................ 63 4.1 Introdução ....................................................................................................... 63 4.2 Java Enterprise Edition ................................................................................... 64 4.2.1 Arquiteturas Multicamadas ............................................................. 64 4.2.2 Servidor de Aplicação ..................................................................... 65 4.2.3 Enterprise JavaBeans ....................................................................... 67 4.2.4 Servlets ............................................................................................ 68 4.2.5 JavaServer Pages ............................................................................. 69 4.2.6 Java Persistência API ...................................................................... 70 4.2.6.1 Mapeamento de Entidades ................................................ 72 4.2.4.2 Persistência a Entidades .................................................... 73 4.4 Considerações Finais ...................................................................................... 74 CAPITULO 5: CONCLUSÕES E TRABALHOS FUTUROS .................................. 76 5.1 Conclusões ................................................................................................ 76 5.2 Contribuições e Benefícios do Trabalho .................................................. 77 5.3 Dificuldades Encontradas ......................................................................... 77 5.4 Trabalhos Futuros ..................................................................................... 78 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................... 79 Apêndice A: Casos de Uso para o Controle e Emissão do Perfil Profissiográfico Previdenciário ............................................................................................................................... 85 Apêndice B: Diagrama de Classe para Emissão e Controle do Perfil Profissiográfico Previdenciário ............................................................................................................................... 96 Apêndice C: Exemplo de Listagem dos Códigos ......................................................................... 97 Apêndice D: Exemplo de Telas do Sistema ..................................................................... 102 Anexo A: Perfil Profissiográfico Previdenciário (PPP) ................................................................ 104
  14. 14. CAPÍTULO 1: INTRODUÇÃO 1.1 Motivação A sociedade atualmente está diante dos avanços tecnológicos impostos pelo mundo, e não dispõem de muito tempo. Nesse contexto, o software é extremamente necessário ao atendimento desses ideais. Porém, não basta apenas que os softwares sejam disponibilizados, é preciso que estes tenham qualidade e que sejam produzidos com eficiência para atendimento ao seu cliente. Assim, percebe-se que a sociedade necessita de sistemas que utilizem técnicas sistemáticas com tempo de desenvolvimento menor possível, mas com toda qualidade que possa apresentar. Baseando-se no que foi citado, é apresentado o fator da reutilização de software, que consiste basicamente no processo de criação de sistemas de software a partir de outros que já existiam antes, o que diminui o custo do software em si e minimiza pesquisas extensas de trabalhos posteriores em cima de um mesmo projeto ou idéia. Para que a reutilização seja efetiva, uma vez que o desenvolvimento voltado à reutilização envolve grande esforço, a idéia é que se crie um projeto utilizando-se métodos e ferramentas de análise e modelagem de software, como a Engenharia de Domínio (ED), Análise de Domínio (AD), Engenharia de Aplicação (EA) etc., dando base para projetos futuros que venham a reutilizar a estrutura do sistema. Isso possibilita a criação ou expansão para sistemas mais complexos em menos tempo. Para aplicar a reutilização de software, uma das técnicas possíveis de ser adotada é a Engenharia de Domínio, que oferece um apoio sistemático à reutilização desde o início do seu ciclo de vida, apoiando a reutilização também de artefatos de análise e de projeto, ao invés de somente a reutilização de código. A ED trabalha na criação de soluções genéricas que venham a ser reutilizadas pelas aplicações do domínio, ressaltando as suas variabilidades, que, por sua vez, se mostram bastante importantes, pois deixam claro os pontos onde os sistemas se assemelham para serem reutilizados e os pontos onde se diferem para serem avaliados mais cautelosamente e estudados para implementação. A Análise de Domínio (AD) oferece suporte para o reuso sistemático e em larga escala, através da captura das características comuns e das variabilidades entre os sistemas do
  15. 15. 14 domínio. A AD é inicializada logo após a conclusão do seu planejamento na ED, ou seja, a AD, uma das etapas da ED, cria um arcabouço propício de reuso para a implementação dentro de um escopo bem definido. Aplicando os conhecimentos adquiridos em reutilização focada na ED, pode-se desenvolver um projeto voltado para a implementação de um domínio estruturado dentro de um framework. O domínio escolhido foi a emissão do Perfil Profissiográfico Previdenciário (PPP). Um framework é um conjunto de classes que cooperam para construir um sistema reutilizável para uma classe específica de software (GAMMA, HELM, JOHNSON e VLISSIDES, 2000). Isso permite que seja construído uma estrutura genérica para um domínio específico, com divisão de classes e objetos, ou seja, os frameworks definem a arquitetura do domínio. O PPP deve ser entendido como uma monitoração histórico-laboral de um colaborador de uma determinada empresa. Esse domínio trata especificamente de toda a vida de um colaborador (um colaborador pode ser um trabalhador próprio da empresa, um contratado ou prestador de serviços terceirizado) dentro da empresa, como níveis de segurança a que foi submetido, riscos a saúde a que foi exposto, e tudo que foi causado por esses fatores individualmente ou coletivamente. O INSS pode solicitar o PPP quando da necessidade de envio do mesmo, ou seja, pode ser por motivo de algum acidente em que o colaborador necessite se aposentar, ou permanecer inativo por tempo indeterminado, ou ainda contraia alguma doença relativa ao seu trabalho onde se expõe a fatores prejudiciais apontados ou relacionados pelo Programa de Prevenção a Riscos Ambientais (PPRA) ou pelo Programa de Controle Médico e Saúde Ocupacional (PCMSO), abrangendo, cronologicamente por período, as informações administrativas (setor, cargo, função etc.), ambientais e biológicas relacionadas ao trabalhador, para fins de comprovação e controle, e minimização de fraudes. A comprovação do direito a aposentadoria especial será feita mediante Perfil Profissiográfico Previdenciário (PPP). Esse domínio foi escolhido por apresentar características que demonstram claramente a necessidade de implementação por framework, pois ele é obrigatório a toda administração de recursos humanos, uma vez que é exigido pelo INSS, além de variar de uma empresa para outra como em divisões de setores, nomenclaturas, especificações etc. Dessa forma, apresenta variabilidades. Devido ao fato de ser um domínio complexo e pouco trivial, implica em um desafio alcançável com esforço e dedicação, mas, que na verdade, se demonstra propício para a representação da ED aliada aos conceitos de framework..
  16. 16. 15 1.2 Objetivos O objetivo desse projeto é explorar o desenvolvimento de software voltado à reutilização, explorando algumas técnicas baseadas em reutilização, como Engenharia de Domínio (ED), Frameworks e Análise de Domínio (AD), tendo sido escolhido como estudo de caso o domínio de emissão do Perfil Profissiográfico Previdenciário (PPP). Visa-se ainda conhecer um ambiente de modelagem baseado em reutilização, aprimorando o conhecimento adquirido, e assim sendo possível a construção de um framework para o referido domínio. O ambiente adotado é o Odyssey (ODYSSEY, 2007), que apóia as atividades da ED e se encontra disponível para uso, provendo suporte à reutilização com base em modelos de domínio. Como tecnologia de implementação, utilizou-se a linguagem JEE (Java Enterprise Edition) e tecnologias adjacentes como Enterprise Java Bean, Jboss etc., por ser a linguagem que hoje está presente no mercado e que também beneficia o desenvolvimento para reutilização através da idéia de componentes de software dos Java Beans. Mas vale ressaltar que a base da modelagem é independente da linguagem, ou seja, o projeto pode ser implementado em qualquer linguagem de programação orientada a objeto. O principal objetivo aqui, entretanto, é contribuir para trabalhos futuros, apresentando a base do sistema para reutilização, deixando assim o framework pronto para ser instanciado por diferentes aplicações para diferentes empresas. 1.3 Organização da Monografia Este projeto está organizado em mais 4 capítulos, além desta Introdução. No capítulo 2, é apresentado um referencial teórico, onde observa-se mais detalhadamente o conceito de Engenharia de Domínio (ED), Análise de Domínio (AD), conceitos de reutilização de software no ambiente Odyssey (ODYSSEY, 2007) e Frameworks. Este capítulo busca referenciar a abordagem de cada um desses fatores nos artefatos do domínio. Aqui também são destacados os conceitos de variabilidades no ambiente e os tipos de frameworks destacados na literatura.
  17. 17. 16 O capítulo 3 apresenta a aplicação das técnicas descritas no capítulo 2 para a construção de um modelo de domínio para a emissão do Perfil Profissiográfico Previdenciário (PPP), representando um conjunto de classes que podem ser reutilizados para implementar ou criar aplicações. No capítulo 4, demonstram-se as tecnologias empregadas para a implementação do framework, como: Java, o servidor de aplicação Jboss, EJB (Enterprise Java Bean), Servlets, JSP (JavaServer Pages) e o JPA (Java Persistence API), utilizando o Hibernate como framework de persistência. No capítulo 5, e último, são apresentadas algumas conclusões obtidas durante o desenvolvimento do projeto. Fala-se das possibilidades para trabalhos futuros, além de benefícios obtidos e dificuldades encontradas pelo grupo no desenvolvimento baseado em reutilização e no uso de um ambiente de desenvolvimento para apoio a essas atividades.
  18. 18. CAPÍTULO 2: REFERENCIAL TEÓRICO 2.1 Introdução Atualmente, grande parte do software já está sendo criado a partir de outros, ou de partes já existentes, pois a cada dia o software está ficando mais complexo e a demanda por ele só aumenta. Com isso, a reutilização é uma atividade que está sendo muito disseminada pela comunidade de desenvolvimento de software. Ela pode ser definida como o processo de criação de sistemas de software a partir de software preexistente (KRUEGER, 1992), trazendo consigo a promessa de aumentar a produtividade e diminuir custos do desenvolvimento, além de melhorar a qualidade do produto, através da reutilização de artefatos de software já testados e utilizados em outros contextos (FRAKES e KANG, 2005). Ela representa uma sub-área da Engenharia de Software que cresce cada vez mais. No contexto da Engenharia de Software, diferentes abordagens buscam melhorar a qualidade dos artefatos1 de software, bem como diminuir o tempo e o esforço necessários para produzi-los, assim como abordagens de reutilização. A reutilização não é uma técnica nova, ela já vem sendo realizada desde o início da Engenharia de Software, porém, anteriormente, se reutilizava apenas bibliotecas de rotinas ou partes de código em ambientes de programação. Com o passar do tempo e o surgimento do paradigma de desenvolvimento de sistemas orientado a objetos (OO), a reutilização ganhou mais força, pois as classes passaram a encapsular dados e funções, e então a parte reutilizável aumentou a sua granularidade, o que ajudou a alcançar ainda mais os objetivos da reutilização. Percebeu-se que era muito vantajoso, principalmente se isto fosse feito desde o início do ciclo de vida do software e com o avanço das pesquisas passou-se a se fazer não apenas a reutilização de código, mas também a de outros artefatos, como artefatos de análise e de projeto. O uso de técnicas de reutilização desde as fases iniciais do desenvolvimento de aplicações facilita a reutilização de componentes em fases mais avançadas do desenvolvimento (ODYSSEY, 2007). Uma das abordagens da Engenharia de Software que busca a melhora no desenvolvimento através da reutilização são os frameworks. Um framework é um conjunto de 1 Artefato é o termo usado para qualquer produto do trabalho de desenvolvimento de software.
  19. 19. 18 classes cooperantes que constroem um projeto reutilizável para uma específica classe de software (GAMMA et al, 2000). Estas estruturas de classes quando estendidas e adaptadas permitem produzir aplicações específicas. Produzir uma especificação adequada a uma família de aplicações com características similares (i.e. um domínio) e reutilizar esta especificação no desenvolvimento de aplicações específicas são preocupações no desenvolvimento de frameworks. Sua grande vantagem é o reuso não apenas de código, mas também de projeto. A fim de apoiar a especificação de um conjunto de aplicações, a Engenharia de Domínio representa uma outra abordagem de reutilização de software que pode ser adotada em conjunto com os frameworks. Ela também visa a criação de artefatos para um determinado domínio com o objetivo de serem reutilizados e será discutida com mais detalhes a seguir. Partindo desta Introdução, o restante do capítulo está organizado da seguinte forma: a a Seção 2.2 aborda conceitos inerentes à Engenharia de Domínio; a Seção 2.3 trata do assunto frameworks; e a Seção 2.4 apresenta algumas considerações finais. 2.2 Engenharia de Domínio A Engenharia de Domínio (ED) pode ser definida como: "o processo de identificação e organização do conhecimento sobre uma classe de problemas, i.e. o domínio do problema, para apoiar a sua descrição e solução" (PRIETO-DIAZ e ARANGO, 1991). Ela é responsável pela criação de artefatos para aplicações que compartilhem características em comum, definindo uma família de aplicações ou domínio. Com isso, ao se identificar as semelhanças e as diferenças de um domínio, ou seja, as suas variabilidades e opcionalidades, pode-se tornar viável a reutilização dos artefatos produzidos tanto para sistemas em desenvolvimento como para sistemas futuros do mesmo domínio. A ED se preocupa em produzir artefatos de software reutilizáveis com princípios que norteiam a modularidade, como: a criação de módulos com interfaces pequenas, explícitas e em pequena quantidade, e o uso do princípio da ocultação de informação (UFSC, 2007). Este tem sido o principal elemento de orientação para a produção de bibliotecas de artefatos reutilizáveis. O objetivo da ED é identificar, construir, catalogar e disseminar um conjunto de componentes de software que têm aplicabilidade a software existente e futuro, em um particular domínio de aplicação (PRESSMAN, 2006). Na ED, todos os artefatos produzidos
  20. 20. 19 são catalogados e armazenados de forma que possam ser utilizados a qualquer momento por outra aplicação que esteja no mesmo domínio. A Engenharia de Domínio envolve o processo de busca, análise, manipulação e formalização das informações do domínio relevantes para a implementação de um programa de reutilização. O resultado final de um processo de ED são os modelos de domínio. Enquanto a ED é voltada à construção de artefatos reutilizáveis para várias aplicações, ou seja, é voltada ao desenvolvimento para reutilização, a Engenharia de Aplicação (EA) é responsável por implementar aplicações através da instanciação dos artefatos que foram produzidos pela ED, conforme mostra a Figura 2.1. A Engenharia de Aplicações se dedica ao estudo das melhores técnicas, processos e métodos para a produção de aplicações, no contexto do desenvolvimento com reutilização. A EA se utiliza da ED buscando componentes de software que estejam disponíveis para a reutilização como em uma biblioteca. As duas trabalham em conjunto fazendo com que os artefatos produzidos sejam reutilizados em qualquer aplicação que se encontre no mesmo domínio. A EA pode produzir feedback para a ED, no sentido da descoberta de novos artefatos reutilizáveis durante o desenvolvimento de novas aplicações no domínio. Figura 2.1 Ciclo de Vida da Engenharia de Domínio (OLIVEIRA, 2006) O objetivo da ED é que a reutilização de software seja realizada desde o início do ciclo de vida para que o software alcance o sucesso, sendo que os artefatos produzidos são ao mesmo tempo específicos para o domínio em questão e genéricos o suficiente para atender a toda a variedade de aplicações possíveis àquele domínio. Dessa forma, a ED propõe as
  21. 21. 20 seguintes fases ou macro-atividades que sistematizam a construção do modelo de domínio: Planejamento, Análise, Projeto e Implementação do domínio. A Figura 2.2 mostra uma visão geral das fases da ED. A Análise de Domínio (AD) deve ter início assim que é concluído o seu planejamento, envolvendo um estudo de viabilidade. Durante esta fase são originados alguns documentos, como o glossário do domínio, onde estão documentados todos os conceitos encontrados no domínio que servem como entrada para a fase de Projeto do Domínio, conforme apresenta a figura. Figura 2.2 Fases da Engenharia de Domínio (UFPE, 2007a) A fase de Planejamento é o início do processo e tem o objetivo de fazer as estimativas de recursos utilizados na ED, de custos, cronogramas e, principalmente, a Análise de Viabilidade do domínio (veja Figura 2.2). Como em qualquer outro ramo de atividade, o desenvolvimento de um software, ou de um modelo de domínio, não deve ser feito sem que antes se tenha uma visão geral de custo, mercado, e prazo de retorno do investimento, que não costuma ser curto, ainda mais em se tratando de desenvolvimento baseado em reutilização. No desenvolvimento baseado em reutilização, um grande investimento inicial deve ser feito no desenvolvimento dos artefatos reutilizáveis antes mesmo que qualquer aplicação do domínio possa ser desenvolvida. Neste contexto, para que não ocorra nenhuma surpresa no futuro, é necessário que antes de tudo se faça uma Análise da Viabilidade do domínio.
  22. 22. 21 Dentre as atividades que são realizadas nesta etapa, podemos destacar o estudo de mercado do domínio, para saber a existência de clientes e possíveis concorrentes, e a partir daí se for constatado o potencial econômico, faz-se um estudo do domínio para identificar superficialmente suas variabilidades. Com base nestas informações, o passo seguinte é verificar se a documentação disponível sobre o domínio é suficiente para o seu estudo e a extração de seus conceitos (Figura 2.2). Deve-se verificar a maturidade do domínio, ou seja, o quanto de documentação, sistemas existentes e informação disponível este possui, e ainda se os requisitos em comum são estáveis para justificar o desenvolvimento para reutilização. A partir daí, estima-se o esforço e recursos necessários ao desenvolvimento e o tempo de retorno do investimento, sendo possível dar um parecer sobre a viabilidade do domínio. Após o planejamento e o parecer final dando um sinal verde, ou seja, constatando a viabilidade do domínio, inicia-se então a Análise de Domínio (AD). Nesta fase, o objetivo principal é entender os conceitos gerais do domínio, e produzir modelos de requisitos que mostrem as semelhanças e diferenças do domínio, as quais podem ser representadas através de opcionalidades e variabilidades nos artefatos do domínio. A Análise de Domínio é a atividade onde é delimitado o escopo do domínio e também onde são determinadas as características comuns e variáveis de uma família de aplicações (OLIVEIRA, 2006). O modelo mais comumente utilizado para a modelagem de variabilidades e opcionalidades é o modelo de características (features). Uma característica, segundo Kang et al. (1990), pode ser definida como “um aspecto, uma qualidade, ou uma característica visível ao usuário, proeminente ou distinta, de um sistema (ou sistemas) de software”. O modelo de características representa as características de uma família de sistemas em um domínio, suas semelhanças e diferenças e as relações entre elas (KANG et al., 1990). A etapa de Projeto de Domínio visa, principalmente, a especificação de arquiteturas de software específicas de domínio (DSSAs – Domain Specific Software Architectures) com base nos requisitos, variabilidades e opcionalidades levantados para o domínio. Uma DSSA representa uma coleção de componentes especializados para um determinado tipo de tarefa (domínio), generalizados para que seja possível seu uso efetivo através do domínio e compostos em uma estrutura padronizada (topologia) efetiva para a construção de aplicações (HAYES, 1994). Uma DSSA deve atender aos requisitos de referência, i.e. funcionais e não- funcionais do domínio. Arquiteturas de referência são criadas para serem configuradas e estendidas durante o processo de instanciação de aplicações, representando um framework para o domínio.
  23. 23. 22 Após a etapa de Projeto, a última etapa que a ED engloba, como foi descrito anteriormente, é a Implementação do Domínio. Nesta etapa, as oportunidades de reutilização do modelo, que foram identificadas nas fases de Análise e de Projeto, serão implementadas na forma de componentes ou classes de objetos reutilizáveis. Pode-se realizar também a extração desses artefatos de sistemas legados existentes no domínio ou a busca desses componentes em bibliotecas de software, sendo então reaproveitados para a construção de novas aplicações no mesmo domínio. Figura 2.3 Um modelo genérico de desenvolvimento para/com reuso (GUIZZARDI, 2007) Podemos concluir, conforme mostra a Figura 2.3, que o objetivo da Engenharia de Domínio é, durante o processo de conversão do conhecimento de desenvolvedores acerca do domínio, criar um repositório de componentes, produzindo um conjunto de artefatos passíveis de reutilização na Engenharia de Aplicação (denominada de Engenharia de Software na Figura). Dessa forma, como mostrado na figura 2.3, um projeto de domínio da ED pode ser reutilizado para várias aplicações específicas na Engenharia de Software ou EA. 2.2.1 Análise de Domínio Uma vez que a etapa de Análise de Domínio é a mais explorada neste trabalho, por ser a base para uma abordagem de ED de sucesso, ela é detalhada nesta seção. Ela envolve a
  24. 24. 23 especificação dos requisitos do domínio, assim como a Análise de Requisitos de um software envolve a sua especificação de requisitos. Requisitos adequadamente compreendidos e especificados são a base para um desenvolvimento de software com sucesso. O estudo e o entendimento dos problemas e requisitos de um domínio é a principal atividade da Análise de Domínio. PRIETO-DIAZ e ARANGO (1991) definem a AD como “o processo de identificar e organizar o conhecimento a respeito de uma classe de problemas, i.e. o domínio do problema, de maneira a apoiar a descrição e solução de tais problemas”. Isto é fundamental para que os artefatos próprios, que serão gerados desse estudo, possam ser reutilizados em aplicações ou outros softwares que pertençam ao mesmo domínio. Além disso, nesta fase são identificadas as variabilidades do domínio, ou seja, os pontos dentro deste domínio onde existirão semelhanças e diferenças, definindo-se os aspectos comuns entre as aplicações que poderão ser instanciadas a partir deste modelo de domínio. Alguns métodos conhecidos e utilizados para especificar as variabilidades do domínio são: o FODA (KANG et al., 1990), FORM (KANG et al., 2002), FODACom (VICI e ARGENTIERI, 1998), FeatuRSEB (GRISS et al., 1998), ODM (SIMOS e ANTHONY,1998), Odyssey-DE (BRAGA, 2000) e CBD-Arch-DE (BLOIS, 2006). O método CBD-Arch-DE é suportado pelo ambiente de reutilização Odyssey da COPPE/UFRJ (ODYSSEY, 2007) e emprega a notação Odyssey-FEX, que é adotada neste trabalho e explicada na seção a seguir. Para facilitar a Análise de Domínio é recomendável que se defina o escopo do domínio, pois sabendo o que se está analisando, evita-se que a análise se torne uma atividade interminável e às vezes sem nenhum objetivo real e específico. Por outro lado, tem que se tomar cuidado para não restringir muito este domínio a ponto de, ao final, não se gerar nenhum artefato útil às aplicações do domínio. Após definido o escopo do domínio, deve-se extrair as suas características (features). A partir do modelo de características, devem ser derivados os demais modelos do domínio, com o objetivo de refletir os conceitos, funcionalidades e aspectos tecnológicos do domínio. Tanto requisitos funcionais quanto não-funcionais são analisados como features, as quais representam as partes comuns e variáveis dos sistemas. O modelo de características é o modelo de mais alto nível de abstração na ED e identifica o que é opcional ou mandatório em um domínio, e também o que pode variar. A seção 2.2.2, a seguir, descreve a importância dos ambientes de reutilização para apoiar o desenvolvimento baseado em reutilização, destacando o ambiente Odyssey (ODYSSEY, 2007). Este ambiente está disponível para uso e adota a notação Odyssey-FEX para a modelagem de características.
  25. 25. 24 2.2.2 O Ambiente de Reutilização de Software Odyssey Todo software está continuamente sujeito a modificações, motivadas por diversos fatores. Como exemplo, temos: a correção de erros encontrados por desenvolvedores e usuários, o surgimento de novas tecnologias, as alterações no ambiente de operação e o desenvolvimento incremental. Dessa forma, o desenvolvimento de software deve ser realizado com o apoio de ambientes que permitam a sua contínua evolução. O mesmo vale para modelos desenvolvidos para um domínio. A fim de que a reutilização de software possa se tornar efetiva, uma vez que envolve grande esforço, ela deve ser realizada com o apoio de um ambiente de desenvolvimento de software baseado em reutilização (MOURA, CARVALHO e SILVA, 2006). Não só um ambiente que permita acompanhar a evolução dos modelos desenvolvidos, mas também que apóie a própria especificação dos modelos de análise e projeto do domínio e geração do código, além da reutilização dos artefatos desenvolvidos através da Engenharia de Aplicação. Uma infra-estrutura de suporte à reutilização baseada em modelos de domínio pode ajudar na utilização efetiva da reutilização durante o desenvolvimento de software, fornecendo métodos, ferramentas e procedimentos que são adequados para a especificação de modelos e aplicações do domínio. Um ambiente de desenvolvimento baseado em reutilização, disponível para utilização e desenvolvido em nível nacional é o ODYSSEY (ODYSSEY, 2007). Trata-se de um protótipo acadêmico, desenvolvido pela equipe de reutilização da COPPE/UFRJ. O principal objetivo do Odyssey é prover mecanismos, baseados em reutilização, para o desenvolvimento de software, servindo como um arcabouço onde modelos conceituais, arquiteturas de software, e modelos implementacionais são especificados para domínios de aplicação previamente selecionados. O Odyssey implementa a notação Odyssey-FEX (OLIVEIRA, 2006) para a modelagem de características do domínio e suas variabilidades. Não foi encontrado um ambiente comercial com as funcionalidades para apoio à reutilização que o Odyssey oferece, como: • Desenvolvimento para reutilização, através de processos de Engenharia de Domínio, permitindo o desenvolvimento de modelos reutilizáveis de domínio. • Desenvolvimento com reutilização, através da Engenharia de Aplicação, permitindo a instanciação de aplicações a partir dos modelos de domínio, onde
  26. 26. 25 é feito o recorte do domínio, determinando-se as características que devem compor as aplicações (a ressalva se faz para as características obrigatórias do domínio, que devem ser sempre selecionadas). • Mapeamentos e ligações de rastreabilidade entre modelos em diferentes níveis de abstração, como mostra a Figura 2.4, permitindo a reutilização dos diferentes modelos de domínio que devem compor as aplicações (BLOIS, 2006). • Instanciação de padrões de projeto e arquiteturais em modelos de domínio e de aplicações. • Engenharia reversa dinâmica e estática (VASCONCELOS, 2007). • Desenvolvimento orientado a modelos (i.e. MDA – Model-Driven- Architecture), permitindo a geração de modelos de componentes específicos para uma plataforma a partir de modelos independentes de plataforma (MAIA, 2006). Figura 2.4 Modelos de domínio (i.e. características, casos de uso e classes) e suas ligações de rastreabilidade no ambiente Odyssey (VASCONCELOS, 2007). A figura 2.4 mostra um modelo de características construído utilizando a notação Odyssey-FEX. Neste exemplo, é considerado o domínio de Software para Controle Escolar.
  27. 27. 26 O ambiente Odyssey está disponível para download, em sua versão light, na página http://reuse.cos.ufrj.br/odyssey, onde também podem ser obtidos artigos, dissertações e teses que descrevem as suas funcionalidades. Ele possui funcionalidades essenciais e secundárias para a ED e a EA. As funcionalidades essenciais compõem o núcleo (kernel) do ambiente, sendo baixadas com ele, e as funcionalidades secundárias estão disponíveis na forma de plugins, sendo baixadas de dentro do próprio Odyssey sob demanda. Dessa forma, em função das funcionalidades oferecidas, o ambiente Odyssey é adotado neste trabalho para apoiar o processo de Engenharia de Domínio e construção de um framework para o domínio. A seguir, é apresentada a notação Odyssey- FEX para a modelagem de características e variabilidades do domínio. 2.2.2.1 A Notação Odyssey-FEX A notação Odyssey-FEX foi elaborada a partir do refinamento da notação proposta por MILER (2000), que vem a ser uma extensão do método FODA de (KANG et al., 1990). Ela permite a representação de variabilidades no modelo de características do domínio. O modelo de características da Odyssey-FEX incorpora além dos relacionamentos triviais entre características (i.e. alternativo , implementador por etc.), relacionamentos da UML. A representação de variabilidades deve estar o mais coerente possível na mesma família de sistemas. Para tanto, é de suma importância que essa variabilidade expressa no modelo de características seja também estendida para outros modelos de nível mais baixo de abstração, como o modelo de classes, de casos de uso e de componentes. Neste sentido, Oliveira (2006) propõe regras de mapeamento para a propagação das variabilidades para os demais modelos de domínio, através do estabelecimento de correspondências semânticas entre os elementos do metamodelo de características (OLIVEIRA, 2006) e os elementos do metamodelo da UML (OMG, 2005). As características definidas na notação Odyssey-FEX e disponíveis no ambiente Odyssey devem ser utilizadas em fases distintas do desenvolvimento de um software. A Tabela 2.1 apresenta a taxonomia de características na notação Odyssey-FEX.
  28. 28. 27 Tabela 2.1 Tipos de Características na notação Odyssey-FEX (OLIVEIRA, 2006) Como já dito, essas características devem ser mapeadas para os demais artefatos do domínio, como classes e casos de uso, e as características tecnológicas mapeadas para artefatos da fase de projeto de domínio, como classes ou componentes utilitários e de infra- estrutura. Ainda podemos subdividir as características de domínio em funcionais e conceituais. As características funcionais estão ligadas aos casos de uso e as conceituais aos conceitos ou classes de um domínio. Para efeito de demonstração, é apresentado na figura 2.6 Ícone Tipo de Característica Características de Domínio – Características intimamente ligadas à essência do domínio. Representam as funcionalidades e/ou os conceitos do modelo e correspondem a casos de uso e componentes estruturais concretos. CaracterísticasdeAnálise Características de Entidade – São os atores do modelo. Entidades do mundo real que atuam sobre o domínio. Podem, por exemplo, expor a necessidade de uma interface com o usuário ou de procedimentos de controle. Características de Ambiente Operacional - Características que representam atributos de um ambiente que uma aplicação do domínio pode usar e operar. Ex: tipo de terminal, sistemas operacionais, bibliotecas etc. CaracterísticasdeProjeto(Tecnológicas) Características de Tecnologia de Domínio - Características que representam tecnologias utilizadas para modelar ou implementar questões específicas de um domínio. Ex: métodos de navegação em um domínio de aviões. Características de Técnicas de Implementação – Características que representam tecnologias utilizadas para implementar outras características, podendo ser compartilhadas por diversos domínios. Ex: técnicas de sincronização.
  29. 29. 28 um exemplo desse modelo referente a um domínio de matrícula e transferência em uma instituição de nível superior no ambiente Odyssey. Figura 2.5 Características conceituais e funcionais da notação Odyssey-FEX (VASCONCELOS, 2007) Na Figura 2.5, a Secretária representa uma Característica de Entidade, ou seja, um usuário do domínio. Matricular Aluno e Realizar Transferência de Instituição são Características de Domínio funcionais que darão origem a casos de uso ou métodos/operações do domínio. Por outro lado, Escola, Curso, Graduação, Pos-Graduação e Ensino a Distância são Características de Domínio conceituais que darão origem às classes ou atributos no domínio. Na notação Odyssey-FEX a variabilidade pode ser classificada como pontos de variação, variantes ou invariantes. A descrição da variabilidade encontra-se na tabela 2.2.
  30. 30. 29 Característica Definição Pontos de Variação Determinados pontos em um sistema de software onde decisões são tomadas a respeito, por exemplo, de qual variante será utilizada. Em outras palavras, pontos de variação refletem a parametrização no domínio de uma maneira abstrata e são configuráveis através das variantes. De acordo com a descrição encontrada em (SCHMID, 1997), que considera o uso de frameworks como técnica de reutilização de software, os pontos de variação dão origem aos hot-spots no Projeto do Domínio. Tais hot-spots podem ter diferentes alternativas de configuração, que distinguem as aplicações que serão construídas a partir do framework. Variantes Alternativas de implementação disponíveis para um ponto de variação são denominados Variantes. Em outras palavras, são elementos necessariamente ligados a um ponto de variação, que atuam como alternativas para se configurar aquele ponto de variação. Invariantes Os elementos “fixos”, que não são configuráveis no domínio. Considerando o uso de frameworks como técnica de Projeto de Domínio, tais elementos invariantes são denominados frozen-spots (SCHMID, 1997). Tabela 2.2 Tipos de Características no ambiente Odyssey Seguindo esse princípio podemos verificar que essa classificação é de extrema importância para o desenvolvimento de um projeto baseado em reutilização, pois se identifica quais pontos podem ser configuráveis na aplicação, mais especificamente em seu domínio. Assim demonstramos na figura 2.6 a característica de Transmissão classificada como ponto de variação, e Manual e Automático classificadas como variantes de Transmissão, conforme a notação Odyssey-FEX. Os pontos de variação podem ser mapeados para herança ou implementação de interface em modelos de classes.
  31. 31. 30 Figura 2.6 Classificações das características Além da variabilidade, as características também podem apresentar a propriedade da opcionalidade. Esta faz referência à obrigatoriedade de uma característica, ou seja, aqui ela pode ser classificada como mandatória ou opcional. São mandatórias quando necessárias a qualquer aplicação do domínio ou opcionais quando não são necessárias em pelo menos uma das aplicações instanciadas a partir do domínio que a deu origem. Uma característica na notação Odyssey-FEX pode possuir propriedades ortogonais de variabilidade e opcionalidade como demonstrado na figura 2.7. Figura 2.7 Propriedades ortogonais da notação Odyssey-FEX Na notação Odyssey-FEX as características mandatórias têm contorno cheio e as opcionais têm contorno tracejado. No exemplo da Figura 2.5 tem-se Realizar Transferência e Ensino Distância como opcional e Matricular Alunos, Escola e Curso como mandatórios por exemplo, vale lembrar que o conceito dessas características será explicado mais adiante. Em relação aos relacionamentos possíveis entre características, segundo OLIVEIRA (2006), na notação Odyssey-FEX relacionamentos são utilizados para ajudar a expressar o domínio, muitos deles importados da UML (OMG, 2005) como composição, agregação,
  32. 32. 31 generalização e assossiação. A tabela 2.3 demonstra os relacionamentos específicos na notação Odyssey-FEX: Representação Descrição Alternativo (Alternative) - Relacionamento entre um ponto de variação e suas variantes, denota a pertinência de uma variante a um determinado ponto de variação. RelacionamentosEspecíficos naOdyssey-FEX Implementado por (Implemented By) - Relacionamento entre Características de Domínio e Características Tecnológicas, ou entre Características Tecnológicas que se encontram em camadas diferentes. Ligação de Comunicação (Communication Link) - Relacionamento existente entre Características de Entidade e Características de Domínio. Cumpre o mesmo papel do relacionamento de associação entre atores e casos de uso na UML (OMG, 2004) Tabela 2.3 Relacionamentos da notação Odyssey-FEX A figura 2.8 representa um exemplo um exemplo de relacionamento: Figura 2.8 Exemplo de relacionamento da notação Odyssey-FEX 2.3 Frameworks A reutilização de software, conforme já mencionado, deve ser utilizada com o propósito de facilitar o trabalho do desenvolvedor de aplicações. Isso se dá, por exemplo,
  33. 33. 32 através de um projeto de software genérico, proporcionando uma melhoria na qualidade do sistema, através da reutilização constante do projeto e redução no tempo de desenvolvimento. Com isso, o desenvolvedor que cria aplicações se concentra nos aspectos específicos da sua aplicação. Os frameworks têm esse objetivo de fornecer soluções genéricas e reutilizáveis para variados problemas de projeto de software. Um framework é um conjunto de classes cooperantes que constroem um projeto reutilizável para uma classe específica de software (GAMMA et al, 2000). Essa especificação pode ser utilizada para a construção de diferentes domínios, definindo a estrutura geral, divisão de classes e objetos e suas responsabilidades. Os frameworks definem a arquitetura do domínio. De acordo com (GAMMA et al, 2000), os frameworks estão se tornando cada vez mais comuns e importantes. Eles representam a maneira pela qual os sistemas orientados a objetos conseguem maior reutilização. Com os frameworks, é possível criar um software mais rapidamente. Porém, isso reduz a possibilidade de decisões estruturais, pois quase toda a infra-estrutura já foi definida e validada. Além disso, é importante perceber que não se deve criar um framework muito específico para abordar somente um determinado problema de uma aplicação em particular, mas sim visando um domínio como um todo (MOURA, CARVALHO e SILVA, 2006). A arquitetura deve funcionar para todas as aplicações do domínio e conforme uma aplicação evolui, o framework também devem evoluir. Isso mostra que o processo para construir um framework, assim como todo processo de software voltado à reutilização, é muito complexo, pois ele não deve ser encarado como uma aplicação tradicional, e sim permitir uma variação de suas características. Dentro de qualquer domínio, existem as características i.e. (features) que permitem identificar suas funcionalidades e conceitos, assim como as suas variabilidades e opcionalidades. As características comuns a todas as aplicações do domínio e invariáveis dão origem aos frozen-spots (pontos fixos) dos frameworks. Esses pontos fixos são representados por características invariantes e mandatórias e estão definidos no framework de forma inalterável para todas as aplicações do domínio, por exemplo, através de classes concretas. Existem também os hot-spots (pontos variáveis), que representam as características variáveis nas diferentes aplicações de um domínio, ou seja, os pontos de variação e opcionais. Essas características devem ser genéricas, pois devem ser adaptadas às necessidades da aplicação, sendo representadas, por exemplo, através de classes abstratas, métodos abstratos, métodos template e outros padrões de projeto do GAMMA et al (2000).
  34. 34. 33 2.3.1 Tipos de Frameworks De acordo com a forma de reutilização, os frameworks podem ser classificados, como: caixa branca (white box); caixa preta (black box) ou caixa cinza (gray box). Nos frameworks caixa branca, o reuso acontece por herança ou extensão, sendo necessário conhecer os detalhes de como o framework trabalha. É importante que o desenvolvedor domine o funcionamento, para a partir disso, criar novas classes que deverão implementar ou estender as classes abstratas. O framework caixa preta não exige que o desenvolvedor conheça os detalhes da implementação do framework, exigindo apenas que a classe use a composição de objetos e delegação em vez de herança. Já nos frameworks caixa cinza, existe uma mistura dos outros dois tipos de frameworks, caixa branca e caixa preta, ou seja, o reuso pode ocorrer por herança e composição simultaneamente. Os frameworks podem ainda ser classificados de acordo com o seu escopo, da seguinte forma: • Frameworks de Infra-estrutura: apóiam a infra-estrutura de sistemas em diferentes domínios de aplicação, oferecendo serviços como persistência, segurança, busca, interfaces gráficas etc. • Frameworks de Integração: são utilizados para integrar aplicações e componentes distribuídos (ex: middleware, como Corba). • Frameworks de Aplicação: são dirigidos a um domínio específico de aplicações, ou seja, a uma família de aplicações em uma determinada área. 2.4 Considerações Finais Este capítulo abordou técnicas de reutilização de software, destacando a importância dessa sub-área na Engenharia de Software. A Engenharia de Domínio, uma das técnicas apresentadas, cria um modelo de domínio de aplicação, que é utilizado como base para a instanciação de aplicações específicas. A Análise de Domínio é uma das principais atividades da ED, pois permite estabelecer o escopo e requisitos do domínio, bem como as suas variabilidades e opcionalidades. As aplicações do domínio são instanciadas com base nessas variabilidades e opcionalidades do domínio.
  35. 35. 34 Durante o projeto do domínio, uma arquitetura de software genérica que atenda aos requisitos do domínio é desenvolvida. Ela fornece a entrada para o projeto das aplicações, podendo ser representada como um framework do domínio. As aplicações devem estender e adaptar os hot-spots durante a instanciação do framework. De um modo geral, a principal motivação para a reutilização está relacionada ao aumento dos níveis de qualidade e produtividade no desenvolvimento de software. O aumento de qualidade é uma conseqüência da reutilização de componentes que foram previamente documentados, testados e aprovados. O aumento da produtividade é resultado de uma redução no tempo de desenvolvimento, evitando a reconstrução de partes do sistema que já existem. A partir da Análise de Domínio utilizando a notação Odyssey-FEX, esse trabalho de conclusão de curso tem o objetivo de construir um framework de aplicação para a emissão e controle do Perfil Profissiográfico Previdenciário. Esse framework será analisado e projetado nos capítulos 3 e 4, seguindo os princípios de reutilização de software apresentados neste capítulo.
  36. 36. 35 CAPÍTULO 3: ANÁLISE E PROJETO DE DOMÍNIO PARA A CONSTRUÇÃO DO FRAMEWORK DE EMISSÃO DO PERFIL PROFISSIOGRÁFICO PREVIDENCIÁRIO 3.1 Introdução Neste capítulo, as técnicas de reutilização apresentadas no capítulo 2 são aplicadas para a especificação do domínio que envolve a Emissão do Perfil Profissiográfico Previdenciário (PPP). O PPP, como já mencionado, é o documento histórico-laboral do trabalhador, que tem por objetivo informar ao Instituto Nacional do Seguro Social (INSS) as informações administrativas (documentação, cargos exercidos, locais de trabalho etc.), ambientais (riscos no ambiente, concentração etc.), biológicas (exames médicos) e a efetiva exposição do trabalhador a agentes nocivos. O modelo do PPP encontra-se no Anexo A. O ambiente de reutilização Odyssey (ODYSSEY, 2007) é utilizado para apoiar o processo. Esse ambiente aplica a notação Odyssey-FEX (OLIVEIRA, 2006) para a modelagem das opcionalidades e variabilidades do domínio, apresentada no capítulo 2, que define a semântica dos elementos funcionais, conceituais e tecnológicos utilizados na modelagem de domínio, incluindo seus relacionamentos. O capítulo está organizado da seguinte forma: a seção 3.2 apresenta a Análise de Domínio realizada para a determinação dos conceitos e funcionalidades inerentes à emissão do PPP. Na seção 3.2.2 são apresentados os Contextos ou subdomínios com seus respectivos atores. As características dos subdomínios Administração de Pessoal, Segurança e Medicina são apresentadas nas respectivas seções: 3.2.3; 3.2.4 e 3.2.5. A seção 3.3 apresenta o mapeamento do modelo de características para o modelo de classes e por último a seção 3.4 que mostra o mapeamento do modelo de características para o modelo de casos de uso. 3.2 Análise de Domínio Nesse ponto do trabalho, é apresentado o domínio analisado através de descrição textual e modelos.
  37. 37. 36 Um dos pontos inerentes ao PPP é que trabalhadores que estejam sujeitos a condições especiais que prejudiquem a sua saúde ou integridade física possuem o direito a Aposentadoria Especial (PR, 1999a). A comprovação do direito a aposentadoria especial será feita mediante Perfil Profissiográfico Previdenciário (PPP), no padrão estabelecido pelo Instituto Nacional do Seguro Social (INSS), como já mencionado pode ser encontrado no Anexo A. Além disso, de acordo com o risco de acidente de trabalho, cada empresa contribui com um percentual diferente, incidindo sobre o total da remuneração paga, a saber: 1 % para risco leve; 2% risco médio; e 3% caso o risco de acidente seja grave. Por exemplo, um trabalhador que exerce a atividade de cultivo de arroz terá 2% do salário recolhido para o INSS, já a atividade de produção de tubos de aço tem recolhimento de 3% (vide site PR, 1999a). É importante destacar que essa contribuição é devida à empresa e não ao funcionário. Uma vez que o domínio que envolve a Emissão do Perfil Profissiográfico Previdenciário é bastante amplo e complexo, optou-se pela sua divisão em subdomínios que são apresentados em diagramas de contextos, de acordo com a notação Odyssey-FEX, onde é possível verificar a interdependência dos mesmos. Para cada subdomínio, são apresentas suas características, relacionamentos, opcionalidades e variabilidades. A partir desse modelo de características, é gerado o modelo de classes, que representa o framework para o PPP, e o modelo de casos de uso, através de regras de mapeamento definidas pela notação Odyssey- FEX. Esse mapeamento é realizado pelo ambiente Odyssey, seguindo as regras propostas por OLIVEIRA (2006), que realiza a consistência Inter-Modelos para possibilitar uma representação coerente dos requisitos de domínio, suas opcionalidades e variabilidades, em diferentes níveis de abstração. Dessa forma, através da proposta da Odyssey-FEX, o domínio do PPP é modelado no ambiente de reutilização Odyssey, onde toda a análise de requisitos é representada, mantendo a opcionalidade e variabilidade das características nos diferentes níveis de abstração do domínio. 3.2.1 Descrição do domínio A Gestão de Recursos Humanos (GRH) tem como objetivo administrar, descobrir talentos, cuidar da saúde e segurança do capital humano. Essa gestão é fundamentada, na
  38. 38. 37 maioria dos casos, pela Consolidação das Leis do Trabalho (CLT) e várias outras leis, como: Instruções Normativas (IN), Normas Regulamentadoras (NR), Medidas Provisórias (MP) e acordos coletivos da categoria (vide site do MTE, 2007). Esta Consolidação estatui as normas que regulam as relações individuais e coletivas de trabalho nela previstas (CLT, Art.1º). Essas leis, ou atos administrativos, norteiam as relações do trabalho para os aspectos jurídicos. O domínio de GRH requer adaptações gerencias para atender plenamente as necessidades de cada empresa. Novos problemas organizacionais e gerenciais devem ser tratados para cada caso particular. Dessa forma, apresenta requisitos em comum e requisitos que variam de uma aplicação para outra, justificando a realização de uma Análise de Domínio. Além disso, trata-se de um domínio muito abrangente, pois envolve vários subdomínios, como: Administração de Pessoal; Segurança e Medicina no Trabalho; Recrutamento; Treinamento; Cargos e Salários; e Apontamentos de Horário de Trabalho. Para cada subdomínio, devem ser observadas as leis e os aspectos gerenciais que norteiam o seu funcionamento. Os subdomínios do GRH podem ser definidos da seguinte forma: Administração de Pessoal: envolve a administração de cadastros básicos, como empresas (i.e. filiais), locais de trabalho (i.e. departamentos, setores), cargos, funções, horários de trabalho, salário etc., e seus respectivos históricos, necessários a uma adequada gestão de pessoal. Trata a emissão de uma folha de pagamento, controlando a admissão, férias e rescisões. Segurança: fundamentado pela Norma Regulamentadora da Saúde e Segurança no Trabalho (NR 18) e pelo Programa de Prevenção dos Riscos Ambientais (PPRA - NR 9) (MTE, 2007), o objetivo desse subdomínio é controlar e prevenir acidentes e sinistros, garantindo a integridade física do colaborador em face aos riscos existentes no ambiente de trabalho. Medicina: é regulamentada pelo Programa de controle Médico e Saúde Ocupacional (PCMSO -NR 7) (MTE, 2007). Tem por objetivo manter a prevenção e a promoção da saúde do colaborador e também é norteada pela Instrução normativa 99 de 05/12/2003 (MPS, 2003). Mantém a ficha médica, controla atendimentos, resultados de exames e suas periodicidades etc. Treinamento: envolve o controle da gestão do conhecimento, controle de cursos, instrutores, participantes, alocação de salas, aplicação e correção de avaliações. Recrutamento: administra requisições para aberturas de vagas, vagas em aberto, cadastramento de currículos e triagens para seleções. A admissão,
  39. 39. 38 funcionalidade do subdomínio de Administração de Pessoal, só é realizada após as seleções. Dessa forma, esse subdomínio é responsável pela administração dos testes, currículos etc. Cargos e Salários: implementa e controla a política salarial com base nos descritivos dos cargos, requisitos de formação e habilidades, avaliações, carreiras e competências. Apontamentos de Horário de Trabalho: controla os horários de trabalho, escalas de revezamento, realizando o cálculo de horas extras, faltas, atrasos, saídas intermediárias. O objetivo desse subdomínio é controlar e gerenciar os horários, realizando apenas a referência de Homem Hora (HH) trabalhadas, extras e faltas. Já com as quantidades referências lançadas, o subdomínio de Administração de pessoal realiza os cálculos dos valores dessas horas com seus respectivos percentuais. Apesar da abrangência do domínio exposto, o foco do presente trabalho se restringe à emissão do PPP e a todas as funcionalidades e conceitos necessários para embasar esta emissão. A seleção deste recorte do domínio e, conseqüentemente, do estabelecimento deste foco para o presente projeto, se deve ao fato da Instrução Normativa Nº 99 de 5/12/2003 (MPS, 2003) estabelecer a obrigatoriedade desse relatório para todos os trabalhadores a partir de 01/01/2004, dependendo do ramo de atividade da empresa e da exposição a agentes nocivos. Segue na Tabela 3.1 a descrição das situações em que o PPP deve ser emitido pela empresa. Rescisão Por ocasião da rescisão do contrato de trabalho ou da desfiliação da cooperativa, ou do sindicato, o PPP deve ser emitido em duas vias, com fornecimento de uma das vias para o trabalhador, mediante recibo. Simples conferência Para simples conferência por parte do trabalhador, pelo menos uma vez ao ano, quando da avaliação global anual do Programa de Prevenção de Riscos Ambientais - PPRA. Com isso, o trabalhador poderá acompanhar os riscos ambientais a que está submetido e verificar o resultado dos exames médicos. Na requisição da aposentadoria Para fins de requerimento de reconhecimento de períodos laborados em condições especiais. Para fins de análise de benefícios por incapacidade, a partir de 1º de janeiro de 2004, quando solicitado pelo INSS. Por solicitação das autoridades Quando solicitado pelas autoridades competentes. Tabela 3.1 Situações de Obrigatoriedade de Emissão do Perfil Profissiográfico Previdenciário (IN 99, Art. 148 § 8º) (MPS, 2003)
  40. 40. 39 Dessa forma, devido à obrigatoriedade de emissão do PPP e da sua importância, pois a empresa que não mantiver o PPP atualizado, ou emitir documentos em desacordo com os respectivos laudos técnicos, estará sujeita à penalidade prevista no Art. 133 da Lei Nº 8.213 de 1991 (PR, 1991b), e ainda devido ao fato do controle da emissão desse relatório ser mais incomum que o controle sobre outras atividades da GRH, ele foi escolhido como foco do presente projeto. A análise de domínio e o desenvolvimento do projeto estão baseados apenas nas características básicas de Segurança, Medicina e de Administração de Pessoal necessárias à emissão e controle do PPP. 3.2.2 Contextos Conforme mencionado, o domínio de GRH está dividido nos seguintes subdomínios: Administração de Pessoal, Treinamento, Recrutamento, Cargos e Salários, Segurança, Apontamentos de Horário de Trabalho e Medicina. Na Figura. 3.1, são apresentados os subdomínios, no ambiente Odyssey, que são representados em diagrama através de contextos (OLIVEIRA, 2006). Através deste diagrama, observamos as ligações dos atores, i.e. usuários do domínio, com seus respectivos subdomínios. Os atores deste domínio são: Profissional de Segurança, Profissional de Medicina e Agente de RH. Na notação Odyssey-FEX, atores são denominados entidades. Abaixo segue uma descrição sucinta dos atores e suas respectivas atribuições. • Profissional de Segurança Responsável pela definição e implantação de rotinas de segurança e no trabalho, analisando riscos por locais e/ou cargos, funções etc. Responsável também pelas definições de distribuição de Equipamento de Proteção Individual (EPI) e Equipamento de Proteção Coletiva (EPC) e acompanhamento/treinamento de rotinas de segurança. • Profissional de Medicina Define e controla o Programa de Controle Médico de Saúde Ocupacional (PCMSO), realiza exames periódicos e laboratoriais. Responsável pela saúde ocupacional da empresa. Realiza atendimentos de emergência.
  41. 41. 40 • Agente de RH Responsável pelo controle das rotinas de admissão, férias, rescisões, cadastros de locais, funções, colaboradores, admissões, férias e seus respectivos históricos. Figura 3.1 Diagrama de Contextos do Domínio de Gestão de Recursos Humanos no ambiente Odyssey É possível observar no diagrama de contextos (figura 3.1) a dependência dos subdomínios de Medicina, Segurança, Treinamento, Recrutamento, Cargos e Salários com relação ao de Administração de Pessoal, que contém empresas, colaboradores, cargos, locais, funções e várias outras características que são utilizadas por todos os outros subdomínios. A dependência do subdomínio Medicina com Segurança, observada na figura 3.1 através da seta indicativa, existe devido ao fato das definições do Programa de Prevenção dos Riscos Ambientais (PPRA) serem analisadas primeiramente, sendo possível somente após esta análise de riscos, realizar a montagem do Programa de Controle Médico de Saúde Ocupacional (PCMSO), que irá definir os exames clínicos e laboratoriais de acordo com os riscos, assim como suas respectivas periodicidades.
  42. 42. 41 Nas seções a seguir, são analisadas as características desses subdomínios necessárias à implementação e emissão do PPP. 3.2.3 Subdomínio de Administração de Pessoal Esse subdomínio gerencia cadastros básicos do GRH, além de controlar a admissão, emissão da Folha de Pagamento e rescisões de contrato. O Objetivo é manter todas as informações funcionais sobre o funcionário, como, por exemplo, alocação legal do trabalhador na empresa (histórico de filial), alocação gerencial (locais do componente organizacional), muitas vezes denominado departamento ou seção, o cargo ocupado com seus descritivos e suas funções. A seguir, são apresentadas as características desse subdomínio. 3.2.3.1 Características de Cargos e Locais O Cargo é a nomenclatura utilizada para o conjunto de atribuições e a posição hierárquica na empresa, devendo ser registrado no contrato de trabalho e na Carteira de Trabalho e Previdência Social (CTPS). Figura 3.2 Diagrama de Características Conceituas de Cargo Cada cargo possui um código que é a sua Classificação Brasileira de Ocupação (CBO), essa classificação foi construída pelo Ministério do Trabalho e Emprego (MTE) e tem o objetivo de organizar os diferentes programas de políticas no trabalho, facilitando assim o estudo e a geração de informações estatísticas. Sua presença é obrigatória no PPP. Um outro
  43. 43. 42 fator importante é a descrição do cargo, que segundo a Instrução Normativa (IN) 99/2003, em seu Anexo XV (MPS, 2003) deve informar a descrição das atividades, físicas ou mentais, realizadas pelo trabalhador, por força do poder de comando a que se submete. O CBO e a descrição representam, dessa forma, características pertencentes a Cargo, conforme mostra a Figura 3.2. No momento do mapeamento para o diagrama conceitual, a característica Descrição irá se transformar em atributo de Cargo, já a característica CBO será mapeada como uma classe. A característica Cargo é um Ponto de Variação (VP) que poderá ser estendido de acordo com a estrutura de cargos existente em cada empresa. A característica de Local tem o objetivo de definir a forma que a empresa utiliza para gerenciar seus componentes organizacionais. Por exemplo, em locais pode ser definido um organograma com dois dígitos por quebra, com a seguinte máscara de divisão: 00 – Gerência 00.00 – Departamento 00.00.00 – Seção Para montar essa estrutura é necessário que cada local tenha uma referência do seu nível hierárquico superior, essa definição pode ser observada na figura 3.3 com o auto- relacionamento de local. A característica de Local é uma estrutura que permite a criação dos componentes que organizam os locais de trabalho em departamentos e/ou seções, gerência ou de qualquer forma que retrata a organização lógica da empresa. Dessa forma, a característica Local representa um Ponto de Variação (VP) que deverá ser estendida através de suas variantes que representam seus departamentos, setores etc. Figura 3.3 Diagrama de Característica Conceituas de Local 3.2.3.2 Características de Colaborador e seus Históricos Outras responsabilidades do subdomínio Administração de Pessoal é manter atualizado todas as movimentações do colaborador, como a mudança de cargo e local. Todas
  44. 44. 43 essas movimentações são registradas nos Históricos. Os relacionamentos do colaborador com os históricos, mostram que é possível um colaborador ter vários históricos, como mostra a figura 3.5. Todo aquele que participa de alguma atividade direta ou indireta na prestação de serviço para uma empresa é chamado de colaborador. O diagrama de características apresentado na figura 3.4 apresenta o característica Colaborador como mandatória, pois o colaborador é a principal característica do domínio de GRH e é um ponto de variação, tendo o Empregado e Terceiro como suas variantes opcionais, devido à possibilidade uma empresa possuir somente Terceiros ou somente Empregados. Conforme apresentado no capítulo 2, os pontos de variação são mapeados para hot-spots. Tais hot-spots podem ter diferentes alternativas de configuração, que distinguem as aplicações que serão construídas a partir do framework. Apesar da característica conceitual Colaborador na figura 3.4, não demonstrar graficamente a opção de Ponto de Variação (VP), o relacionamento de Colaborador para Empregado/Terceiro representa essa definição, tendo o Colaborador como (VP) e Terceiro/Empregado como suas variantes. Figura 3.4 Diagrama de Características Conceituas do Colaborador O empregado é todo aquele que tem um vínculo empregatício com a empresa, onde essa instituição é responsável pelo pagamento de salário, recolhimento de impostos e emissão de documentos legais exigidos pelo MTE. O Terceiro, por sua vez, é todo profissional que atua sem vínculo empregatício com a empresa na qual está prestando serviço, porém existem vários aspectos legais que a empresa tomadora de serviço é obrigada a administrar, por exemplo, a estrutura do PPRA. Segundo a legislação, a empresa contratante de serviços de terceiros deverá informar à contratada os riscos ambientais relacionados à atividade que desempenha e auxiliá-la na elaboração e na implementação dos respectivos do Programa de
  45. 45. 44 controle Médico e Saúde Ocupacional (PCMSO) e Programa de Prevenção dos Riscos Ambientais (PPRA) (MPS, 2003). A empresa deve manter toda a estrutura funcional de seus colaboradores atualizada em históricos de cargos pelos quais cada um deles já passou, locais de trabalho e funções, registrando a data da mudança. Esses históricos estão presentes na seção de dados administrativos, nos campos lotação e atribuição do PPP, como mostra o Anexo A. Os relacionamentos do colaborador com os históricos, mostram que é possível um colaborador ter vários históricos, como mostra a Figura 3.5. Cada histórico deve conter a data início e a data fim do colaborador no cargo, local, função etc. Figura 3.5 Diagrama de Características Conceituas dos Históricos do Colaborador O relacionamento de associação de Empresa com relação ao Colaborador, identifica para qual empresa o colaborador possui vínculo. As características Colaborador e Empresa são mandatórias. Para empresas que possuem várias filiais, a característica HisLotacao, que representa as trocas de entre filiais da mesma empresa ou para empresa tomadoras de serviço.
  46. 46. 45 Essa característica é representa no campo 13.2 do PPP, onde é apresentado através do CNPJ/CEI da filial ou da tomadora de serviço. O Histórico de Local (HisLocal) representa o campo 13.3 do PPP, onde deverá ser indicada todas as trocas de locais, i.e. setores ou departamentos no qual o trabalhador atuou. A diferença do Histórico de Local (HisLocal) para o Histórico de Filial (HisLotacao) é devido o histórico de local representar, apenas, a estrutura organizacional gerencial da empresa, já o Histórico de Filial representa uma característica opcional que demonstra a alocação legal do trabalhador. A Função muitas vezes é confundida com cargo, porém ela indica um conjunto de tarefas utilizadas para implementar a departamentalização. A Instrução Normativa 99/2003, em seu Anexo XV (MPS, 2003) revela que a função é o lugar administrativo na estrutura organizacional da empresa, onde o trabalhador tenha atribuição de comando, chefia, coordenação, supervisão ou gerência. Função é uma característica de opcional, como mostra a Figura 3.5, todas as trocas de funções devem ser realizadas nos históricos de função HisFunção. Diferentemente de cargos, funções não apresentam a CBO. O Histórico de Registro Ambiental e Biológico (HisRegAmbBio), característica mandatória que registra os colaboradores responsáveis pelas informações ambientais e biológicas. Segundo Instrução Normativa 99/2003, em seu Anexo XV (MPS, 2003), o PPP deve apresentar informações sobre os responsáveis pelos registros ambientais e biológicos, por período. No diagrama de Classes (Apêndice B), é possível verificar a presença de um atributo denominado tipReg, na classe HisRegAmbBio Esse atributo é responsável por classificar o histórico como registro ambiental ou biológico. Por isso, cada característica HisRegAmbBio (figura 3.5) possui apenas o relacionamento para 1 (um) colaborador. A Comunicação de Acidente de Trabalho (CAT), característica apresentada na figura 3.5, deve ser emitida e apresentada a Previdência Social no máximo em 24 horas, após o acidente. Essa notificação é realizada através do formulário chamado (CAT). Esse formulário apresenta informações de dados sobre a documentação do empregador, colaborador, informações sobre o acidente e atendimentos médicos. Para a emissão do PPP, de acordo com a Instrução Normativa 99/2003, em seu Anexo XV (MPS, 2003), só são necessárias as seguintes informações: Registro da CAT na Previdência Social; Data do Acidente e o Número da CAT. De acordo com o relacionamento de Colaborador para a CAT, um colaborador pode ter se acidentado várias vezes ou nenhuma.
  47. 47. 46 3.2.4 Subdomínio de Segurança Este subdomínio trata da parte de Segurança do Trabalho. Com o conceito de reutilização, um software pode ser usado tanto para uma indústria como para uma loja. Com isso, o conceito de segurança se torna totalmente diferente, pois os riscos que existem em uma indústria são muito diferentes dos riscos existentes em uma loja, e até mesmo os riscos de uma loja podem ser diferentes dos riscos de outra. Portanto, a segurança é definida de um modo genérico, para que cada empresa possa ajustar a sua realidade, de acordo com os seus riscos. A segurança em um ambiente de trabalho, na verdade, representa um conjunto de medidas que visam extinguir, ou pelo menos minimizar, qualquer risco que venha a causar algum acidente ou doença ocupacional no setor de trabalho, buscando proteger a integridade do trabalhador bem como a sua capacidade de trabalho. A Segurança do Trabalho estuda diversas disciplinas como Introdução à Segurança, Higiene e Medicina do Trabalho, Prevenção e Controle de Riscos em Máquinas, Equipamentos e Instalações, Psicologia na Engenharia de Segurança, Gerência de Riscos etc. No entanto, é dada ênfase apenas à parte de segurança, prevenção e doenças causadas por más condições do ambiente de trabalho, pois é o que interessa para o propósito do projeto, que é a emissão do PPP. De acordo com a Norma Regulamentadora 9 - Riscos Ambientais (NR9) da Secretaria de Segurança e Saúde no Trabalho do Ministério do Trabalho e Emprego (MTE, 2007), todo empregador ou instituição que admite trabalhador e mantém algum vínculo empregatício é obrigado por lei a implantar um Programa de Prevenção a Riscos Ambientais (PPRA), que tem por objetivo a prevenção da saúde dos trabalhadores através da antecipação e do reconhecimento das condições e dos riscos no ambiente de trabalho, tanto aqueles que já existem quanto aqueles que ainda surgirão, para que após reconhecidos, eles possam ser controlados. Esses riscos podem ser físicos, químicos ou biológicos. Por isso o reconhecimento antecipado é tão importante, pois sendo conhecido pode-se então estudar o risco e se descobrir formas de controlá-lo. O objetivo principal da segurança é evitar a ocorrência de acidentes, ou a presença de agentes causadores de danos à saúde. Além de visar evitar também a exposição do trabalhador a estes agentes ou a condições adversas que possam vir a causar algum tipo de dano a sua saúde. Segue a descrição das características deste subdomínio.
  48. 48. 47 3.2.4.1 Características dos Riscos De acordo com cada ambiente de trabalho, os riscos são diferentes. A legislação de segurança do trabalho brasileira considera como riscos ambientais, aqueles relacionados a agentes físicos, químicos e biológicos. Os agentes físicos são aqueles decorrentes de processos e equipamentos produtivos e podem ser: • ruídos e vibrações; • pressões anormais em relação a pressão atmosférica; • temperaturas extremamente altas ou baixas e; • radiações ionizantes e não-ionizantes. Os agentes químicos são aqueles decorrentes de manipulação e processamento de matérias primas, onde se destacam: • poeiras; • fumos, névoas e neblina; • gases e vapores. Os agentes biológicos são aqueles oriundos da manipulação, transformação e modificação de seres vivos microscópicos, como: • genes; • bactérias; • fungos; • bacilos; • parasitas; • protozoários; • vírus e outros. Figura 3.6 Diagrama de Características Conceituais de Risco A figura 3.6 mostra que um risco tem um tipo e um tipo pode ter de zero a vários riscos associados a ele e também o PPRA (Programa de Prevenção a Riscos
  49. 49. 48 Ambientais) é feito para um risco somente, mas um risco pode ter de zero a vários PPRAs associados a ele. Tabela 3.2 Limites de tolerância para ruído contínuo ou intermitente Para que sejam considerados fatores de riscos ambientais, os agentes físicos, químicos ou biológicos precisam estar presentes no ambiente de trabalho em determinadas concentrações e intensidades e o tempo máximo de exposição do trabalhador a eles é determinado por limites pré-estabelecidos. Na NR15 denominada Atividades e Operações Insalubres, revelado que: entende-se por Limite de Tolerância, para os fins desta Norma, a concentração ou intensidade máxima ou mínima, relacionada com a natureza e o tempo de exposição ao agente, que não causará dano à saúde do trabalhador, durante a sua vida laboral (MTE, 2007). Isto significa que deve existir um limite para que o trabalhador fique exposto ao Nível de ruído dB (A) Máxima exposição diária PERMISSÍVEL 85 8 horas 86 7 horas 87 6 horas 88 5 horas 89 4 horas e 30 minutos 90 4 horas 91 3 horas e trinta minutos 92 3 horas 93 2 horas e 40 minutos 94 2 horas e 15 minutos 95 2 horas 96 1 hora e 45 minutos 98 1 hora e 15 minutos 100 1 hora 102 45 minutos 104 35 minutos 105 30 minutos 106 25 minutos 108 20 minutos 110 15 minutos 112 10 minutos 114 8 minutos 115 7 minutos
  50. 50. 49 risco, este limite varia de acordo com risco a que ele é exposto e, portanto, varia de risco para risco. No diagrama de classe (Apêndice B), é possível perceber isto, através da classe PPRA que tem associada a ela o risco, que por sua vez tem associada a si o tipo de risco, onde é definido a que grupo este risco pertence. Com isso, é possível analisar este risco e aferir sua intensidade para determinar o tipo de PPRA que será montado. Como exemplo, veja a tabela 3.2, dos limites estabelecidos para nível de ruído medidos em decibéis (dB). A função do departamento de Segurança de uma empresa é justamente a identificação de todos os riscos existentes, e que poderão vir a existir em função da alteração de um processo produtivo, da troca de uma máquina, da mudança de um ambiente de trabalho etc., que possa vir a causar danos aos trabalhadores daquele setor. 3.2.4.2 Características dos Equipamentos de Proteção Os equipamentos de proteção individual (EPIs) e equipamentos de proteção coletiva (EPCs) são equipamentos destinados à proteção dos trabalhadores a riscos que ameacem a sua segurança e que não foram eliminados por meio de métodos organizacionais. O EPI é todo meio ou dispositivo de uso pessoal destinado a proteger a integridade física do trabalhador durante a sua atividade laboral. Ele visa neutralizar a ação do agente causador de acidente contra o corpo da pessoa que usa o equipamento. Como exemplo, tem-se: luvas, óculos de proteção, capacetes, botas etc. Os EPCs, por sua vez, representam equipamentos de proteção coletiva, devendo proteger todos os trabalhadores expostos a determinado risco. Como exemplo, podemos citar o enclausuramento acústico de fontes de ruído, a ventilação dos locais de trabalho, a proteção de partes móveis de máquinas e equipamentos, a sinalização de segurança, a cabine de segurança biológica, capelas químicas, cabine para manipulação de radioisótopos, extintores de incêndio, dentre outros. Os EPIs e os EPCs entram na montagem do PPRA como um meio de proteção ao trabalhador, caso o risco não tenha sido amenizado por outra forma qualquer. Eles estão associados ao PPRA, figura 3.7 (vide também diagrama de classe no Apêndice B), e será utilizado aquele que for mais conveniente ao tipo de risco à que ele se destina.
  51. 51. 50 3.2.4.3 Características do PPRA O PPRA tem a finalidade de aplicar técnicas de higiene e segurança ocupacional, definindo assim uma política com a direção da empresa e atribuindo responsabilidades, integrando toda a organização e envolvendo e comprometendo empregados e empregadores. A responsabilidade pela elaboração e implementação do Programa é total do empregador, que deve cuidar de sua eficácia, sua abrangência e intensidade, que será diferenciada em cada local, cargo ou função, dependendo do risco e da necessidade de controle. O objetivo principal do PPRA é evitar a ocorrência de acidentes, ou a presença de agentes causadores de danos à saúde, assim também como a exposição do trabalhador a estes agentes ou a condições adversas que podem vir a causar algum tipo de dano à sua saúde. Para a montagem de um PPRA, geralmente uma firma especializada é contratada para fazer o levantamento dos riscos, ou caso a empresa possua o SESMT (Serviço Especializado em Segurança e Medicina no Trabalho) este setor é responsável por este levantamento, que serve para descobrir a existência ou não dos riscos presentes no ambiente de trabalho através de medições das concentrações dos contaminantes (substâncias e compostos químicos) ou das intensidades dos agentes físicos (ruído, vibrações, calor, etc), para posterior comparação com os respectivos limites de tolerância da NR 15 (MTE, 2007) ou American Conference of Governamental Industrial Hygienists (ACGIH) (PRESTOMED, 2007). No caso de existir um risco que sua intensidade seja nociva à saúde (vide tabela 3.2, por exemplo), é emitido o Laudo Técnico de Condições Ambientais do Trabalho (LTCAT), que é um parecer circunstanciado e conclusivo das condições ambientais a que o funcionário foi exposto, devendo, contudo, refletir a realidade no momento da consecução da vistoria (PRESTOMED, 2007). Após a emissão do LTCAT é função do engenheiro do trabalho identificar quem está submetido ao risco, em quais cargos, locais, funções etc. estarão sujeitos à ação nociva do risco e tentar amenizar esta ação através do PPRA. Caso o risco não seja amenizado ao ponto de não causar danos à saúde são utilizados EPIs, ou EPCs para se tentar atenuar ou reduzir a nocividade do agente de modo a neutralizar seus efeitos no colaborador daquele cargo, local ou função.
  52. 52. 51 Figura 3.7 Diagrama de Características Conceituais do PPRA A característica conceitual PPRA, apresenta na figura 3.7, é mandatória, sendo um Ponto de Variação (VP) e tem como suas variantes: PPRACargo, PPRACargoLocal, PPRALocal, PPRAColaborador e PPRAFuncão que são características opcionais. Portanto, numa implementação específica do framework serão pontos variáveis do PPRA. O risco também é uma característica conceitual mandatória, e será selecionado de acordo com o PPRA, cada PPRA apresenta um único Risco. A montagem de um PPRA poderá ser feita pela combinação de um cargo, local, por um cargo em um determinado local ou função. O PPRA deve ser montado para um risco específico, após isso o engenheiro de segurança no trabalho irá analisar se o risco está associado a um colaborador, uma função, cargo ou local. Estas características se relacionam com seus determinantes, por exemplo, o PPRACargo se relaciona com o Cargo, e assim por diante. A figura 3.8 apresenta as características funcionais do PPRA. Essas características, de acordo com a notação Odyssey-FEX (OLIVEIRA, 2006), podem ser mapeadas para casos de uso ou métodos das classes. Esse mapeamento será realizado na seção 3.2.7.
  53. 53. 52 Figura 3.8 Diagrama de Características Funcionais da montagem do PPRA 3.2.5 Subdomínio Medicina A base do subdomínio de Medicina está no Programa de Controle Médico de Saúde Ocupacional (PCMSO) de que trata a Norma Regulamentadora 7 – Exames Médicos (NR7), previsto pelo MTE, sob o número 3214 de 08/06/1978 (MTE, 2007). O PCMSO tem o objetivo de promoção e preservação da saúde do conjunto dos seus trabalhadores. A NR7 estabelece os parâmetros mínimos e diretrizes gerais, norteada com a Instrução Normativa Nº 99 de 5/12/2003 (MPS, 2003), a serem observados na execução do PCMSO, podendo os mesmos serem ampliados mediante negociação coletiva de trabalho. Os riscos existentes devem ser estudados e informados a comissão responsável para implementação do PCMSO. O PCMSO deve considerar aspectos individuais e coletivos dentro de um ambiente de trabalho, relacionando a saúde e o trabalho. Um médico só estará apto para elaborar o PCMSO, após ser realizado o levantamento de riscos ou quando o próprio cargo exige um PCMSO (MPS, 2003). O subdomínio de medicina está voltado para referenciar a parte de controle médico dentro de uma empresa, como por exemplo: ficha médica, atendimentos, exames etc., porém na próxima seção serão aborados somente os dados do PPP em seus pontos relevantes,
  54. 54. 53 estando mais voltado para os Exames Médicos Clínicos, Complementares e Monitoração Biológica que são regidos através de quadros específicos a serem seguidos para complemento do PPP. Segue a descrição das características deste subdomínio. 3.2.5.1 Características do PCMSO O Programa de Controle Médico de Saúde Ocupacional (PCMSO) deve ser aplicado em caráter de prevenção, rastreamento e diagnóstico precoce dos agravos à saúde relacionados ao trabalho, inclusive de natureza subclínica, além da constatação da existência de casos de doenças profissionais ou danos irreversíveis à saúde dos trabalhadores. Esse recurso deve estar presente em todas as empresas, não só as que possuem uma quantidade considerável de funcionários, mas todas, principalmente as que têm possibilidades de riscos maiores. Figura 3.9 Diagrama de características conceituais de PCMSO Como mostra a Figura 3.9, o PCMSO é abordado como um ponto de variação, pois pode-se observar que existem as características opcionais que estão ligadas a ele, ou seja, que

×