RefatoracaodeModelos-Fernandes-2018

Prévia do material em texto

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE ENSINO SUPERIOR DO SERIDÓ
DEPARTAMENTO DE COMPUTAÇÃO E TECNOLOGIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
REFATORAÇÃO DE MODELOS DE SOFTWARE DE UM SISTEMA PARA
APOIO AO PROCESSO DE MONTAGEM DE EQUIPES DE AVALIAÇÃO
DAS UNIDADES DE ENSINO DO PRONATEC
VIRGÍNIA MAIA DE BRITO FERNANDES
Caicó-RN
2018
VIRGÍNIA MAIA DE BRITO FERNANDES
REFATORAÇÃO DE MODELOS DE SOFTWARE DE UM SISTEMA PARA
APOIO AO PROCESSO DE MONTAGEM DE EQUIPES DE AVALIAÇÃO
DAS UNIDADES DE ENSINO DO PRONATEC
Trabalho de conclusão de curso apresentado ao curso
de graduação em Sistemas de Informação, como
parte dos requisitos para obtenção do título de Ba-
charel em Sistemas de Informação da Universidade
Federal do Rio Grande do Norte.
Orientador(a): Taciano de Morais Silva, MSc.
Co-orientador(a): Flavius da Luz e Gorgônio, DSc.
Caicó-RN
2018
Agradecimentos
A Deus, em primeiro lugar, por minha vida. A minha mãe, Benúbia Maia de Brito
Fernandes por ser mãe e pai, na ausência do meu pai. A meu pai, Antonildo dos Santos Fernandes,
por me auxiliar quando precisei. Obrigada por tudo!
Aos meus amigos e amigas que estiveram presentes no decorrer da minha graduação,
pelo apoio e companheirismo. Vocês para sempre serão lembrados. Aos meus orientadores,
Taciano de Morais Silva e Flavius da Luz e Gorgônio pelos incentivos e conselhos.
A François Dantas de Oliveira, pelo o auxílio no projeto vinculado a este trabalho, como
aos vários ensinamentos durante o projeto. Aos alunos que participaram do projeto, componentes
da Empresa Júnior Beta Seridó, meu muito obrigada pelo apoio.
Aos meus colegas de curso, aos que estiveram mais próximos a mim, me ajudando
quando precisei, nos momentos de alegria e de tristeza, agradeço a todos.
Resumo
Durante o processo de desenvolvimento de um software é comum ocorrerem alguns deslizes.
Em qualquer fase deste processo, quase sempre haverá algo a ser modificado, seja, por exem-
plo, por código duplicado, modelagem que precisa ser remodelada ou motivada por problemas
identificados no sistema. Por meio da utilização da refatoração, torna-se possível a modificação
de qualquer uma das fases no processo de desenvolvimento de um sistema a fim de se obter
melhorias. Nessa circunstância, este trabalho apresenta uma proposta de refatoração na fase
de documentação/modelagem do Sistema de Agrupamento Baseado em Inteligência Artificial
(SABIA), realizado pelo Laboratório de Inteligência Computacional Aplicada a Negócios (LA-
BICAN), do curso de Sistemas de Informação (SI) da Universidade Federal do Rio Grande do
Norte (UFRN), com o intuito de modificar ou corrigir problemas na modelagem de software.
Além disso, da documentação do Sistema SABIA, foi feita uma análise de características que
influenciaram positiva e negativamente no desenvolvimento do projeto, que justificam às neces-
sidades de refatoração e demonstram o ganho de qualidade na modelagem do sistema. Ainda,
por meio da análise de melhoria, feita através de um formulário com questões direcionadas
aos interessados, verificou-se que, de fato, há uma melhoria significante ao utilizar técnicas de
refatoração nos modelos de software, tornando os diagramas mais fáceis de serem interpretados.
Palavras-chave: Modelagem. Refatoração. UML. SABIA. PRONATEC.
Abstract
During the software development process some slips are common. At any stage of this process,
there will almost always be something to be modified, for example, by duplicate code, modeling
that needs to be reshaped or motivated by problems identified in the system. Through the use of
refactoring, it becomes possible to modify any of the phases in the development process of a
system in order to obtain improvements. In this circumstance, this work presents a refactoring
proposal in the documentation / modeling phase of the System Grouping Based Intelligence
Artificial (SABIA), carried out by the Laboratory of Intelligence Computational Applied to
Business (LABICAN) of University Federal the Rio Grande do Norte (UFRN), in order to modify
or correct problems in software modeling. In addition, from the documentation of the SABIA
System, an analysis was made of characteristics that influenced positively and negatively in the
development of the project, which justify the needs of refactoring and demonstrate the quality
gain in the system modeling. Also, through the improvement analysis, done through a form
with questions directed to the interested parties, it was verified that, in fact, there is a significant
improvement when using refactoring techniques in software models, making the diagrams easier
to interpret.
Keywords: Modeling. Refactoring. UML. SABIA. PRONATEC.
LISTA DE FIGURAS
Figura 1 – Exemplo de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figura 2 – Nomes simples e Nomes qualificados . . . . . . . . . . . . . . . . . . . . . 17
Figura 3 – Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figura 4 – Operações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 5 – Exemplo de Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 6 – Ator e Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 7 – Tipos de Nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figura 8 – Arquitetura em Camadas do DDD . . . . . . . . . . . . . . . . . . . . . . 21
Figura 9 – Ilustração da Proposta do Trabalho . . . . . . . . . . . . . . . . . . . . . . 28
Figura 10 – Processo de Montagem das Equipes de Avaliadores . . . . . . . . . . . . . 29
Figura 11 – Diagrama de Casos de Uso (Inicial) . . . . . . . . . . . . . . . . . . . . . . 31
Figura 12 – Diagrama de Casos de Uso (Refatorado) . . . . . . . . . . . . . . . . . . . 32
Figura 13 – Uma parte do Diagrama de Classes - Sabia (Inicial) . . . . . . . . . . . . . 33
Figura 14 – Diagrama de Classes - Avaliação (Refatorado) . . . . . . . . . . . . . . . . 34
Figura 15 – Diagrama de Classes - Cadastros IBGE (Inicial) . . . . . . . . . . . . . . . 35
Figura 16 – Diagrama de Classes - Localidade (Refatorado) . . . . . . . . . . . . . . . 36
Figura 17 – Diagrama de Classes - Dados Pessoais (Inicial) . . . . . . . . . . . . . . . . 37
Figura 18 – Diagrama de Classes - Parceiro (Refatorado) . . . . . . . . . . . . . . . . . 38
Figura 19 – Resultado da pergunta 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 20 – Resultado da pergunta 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 21 – Resultado da pergunta 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 22 – Resultado da pergunta 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 23 – Resultado da pergunta 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 24 – Resultado da pergunta 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 25 – Resultado da pergunta 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 26 – Resultado da pergunta 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 27 – Resultado da pergunta 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 28 – Resultado da pergunta 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 29 – Resultado da pergunta 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 30 – Resultado da pergunta 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 31 – Resultado da pergunta 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 32 – Diagrama de Classes - Sabia (Inicial) . . . . . . . . . . . . . . . . . . . . . 50
Figura 33 – Questão 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 34 – Questão 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 35 – Questão 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 36 – Questão 4 . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 53
Figura 37 – Questão 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 38 – Questão 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 39 – Questão 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 40 – Questão 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 41 – Questão 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 42 – Questão 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 43 – Questão 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 44 – Questão 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 45 – Questão 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
LISTA DE TABELAS
Tabela 1 – Diagramas, verificação e refatoração . . . . . . . . . . . . . . . . . . . . . 14
Tabela 2 – Utilização das Técnicas de Refatoração . . . . . . . . . . . . . . . . . . . . 30
Tabela 3 – Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
LISTA DE ABREVIATURAS E SIGLAS
SABIA Sistema de Agrupamento Baseado em Inteligência Artificial
LABICAN Tecnologia da Informação
UFRN Laboratório de Inteligência Computacional Aplicada a Negócios
SI Sistemas de Informação
UFRN Universidade Federal do Rio Grande do Norte
UML Unified Modeling Language
PRONATEC Programa Nacional de Acesso ao Ensino Técnico e Emprego
SETEC Secretaria de Educação Profissional e Tecnológica
EPT Educação Profissional e Tecnológica
UE Unidades de Ensino
MEC Ministério da Educação
BA Banco de Avaliadores
SCDP Sistema de Concessão de Diárias e Passagens
PCD Proposta de Concessão de Diárias
IDE Integrated Development Environment
HTML 5 Hypertext Markup Language, versão 5
CSS 3 Cascading Style Sheets
ER Diagrama Entidade-Relacionamento
DDD Domain-Driven Design
OOSE Object Oriented Software Engineering
OMT Object Modeling Technique
MDD Model Driven Design
OMG Object Management Group
IU Interface de Usuário
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Contextualização e Problema . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Motivação e Justificativa de Estudo . . . . . . . . . . . . . . . . . . 13
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . 15
2.1 Modelagem de Software com Unified Modeling Language (UML) . 15
2.1.1 Diagramas da UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1.1 Diagrama de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1.2 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Domain-Driven Design (DDD) . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Refatoração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Regras de Negócio do SABIA . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Arquitetura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Modelagem Inicial Versus Refatorada . . . . . . . . . . . . . . . . . 30
4.2 Questionário Avaliativo . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
APÊNDICE A – MODELO DO SABIA . . . . . . . . . . . . . . . . . 50
APÊNDICE B – FORMULÁRIO DE QUESTÕES . . . . . . . . . . . 51
11
1 Introdução
1.1 Contextualização e Problema
O Programa Nacional de Acesso ao Ensino Técnico e Emprego (PRONATEC) foi
criado pelo Governo Federal, em 2011, com o objetivo de ampliar a oferta de cursos de educação
profissional e tecnológica no país. O PRONATEC é composto por cinco iniciativas, que são:
Expansão da Rede Federal de Educação Profissional, Científica e Tecnológica; Programa Brasil
Profissionalizado; Rede e-Tec Brasil; Acordo de Gratuidade com o Sistema S; e Bolsa-Formação
(LIMA; PACHECO, 2017).
Estas iniciativas são ofertadas, especialmente, aos estudantes do ensino médio da rede
pública, incluindo os da educação de jovens e adultos, trabalhadores, beneficiários dos programas
federais de transferência de renda, e estudantes que tenham cursado o ensino médio completo
em escola da rede pública ou em instituições privadas na condição de bolsista integral (LIMA;
PACHECO, 2017).
Contudo, para que se tenha um controle sob tais iniciativas, o PRONATEC é avaliado
pela Secretaria de Educação Profissional e Tecnológica (SETEC) que é a coordenadora nacional
da política de Educação Profissional e Tecnológica (EPT) no Brasil. A SETEC realiza uma série
de procedimentos de monitoramento e avaliação do desempenho das Unidades de Ensino (UE)
que ofertam cursos do PRONATEC, com a finalidade de analisar as condições de oferta dos
cursos financiados pelo programa. Participam deste programa as instituições da Rede Federal
de Educação Profissional, Científica e Tecnológica, unidades de ensino dos Serviços Nacionais
de Aprendizagem (SENAI, SENAC, SENAR e SENAT) e instituições de educação profissional
vinculadas aos sistemas estaduais de ensino (CASSIOLATO; GARCIA, 2014).
Entretanto, essa avaliação nas UE ocorre pela SETEC, que desenvolve manualmente
um processo de montagem das equipes (composta por professores e/ou técnicos educacionais).
Este processo é desempenhado pelos Coordenadores de Equipes (CE), que são os responsáveis
por realizar todas as operações referentes as equipes e avaliações, bem como a situação das
instituições a serem visitadas. No entanto, a montagem das equipes tende a ser lento para se
realizar todas as etapas necessárias para a sua efetivação, tendo em vista a dificuldade que há na
tomada de decisão devido aos vários aspectos que existem.
Estes aspectos são descritos como: o processo de avaliação é realizado em ciclos, onde
cada ciclo tem sua duração determinada por um período. O processo se inicia no momento em
que a SETEC libera uma planilha contendo uma lista de instituições e seus respectivos locais
que serão avaliados em um determinado período. De posse desse documento, os avaliadores que
fazem parte deste programa são questionados sobre sua disponibilidade para a realização dessas
Capítulo 1. Introdução 12
avaliações no período estipulado pelo MEC. Assim, cada avaliador deverá informar as semanas
em que têm disponibilidade para participar do programa.
Com o objetivo de automatizar os aspectos falados anteriormente, foi desenvolvido um
Sistema de Agrupamento Baseado em Inteligência Artificial (SABIA), fazendo com que fossem
“sistematizadas” todas as funções abrangidas no processo de avaliação citado. O sistema proposto
foi idealizado para facilitar e automatizar o processo que é manual. Sendo o alvo principal o
uso dos algoritmos genéticos por serem uma técnica de busca adequada para o processo de
monitoramento e avaliação das instituições (SABIA, 2018).
Os algoritmos genéticos são técnicas de busca heurísticas baseado na teoria da evolução
de Charles Darwin que consistem na aplicação de métodos bio-inspirados como o cruzamento
entre indivíduos para gerar um novo, assim como a mutação, que consiste na mudança de uma
característica genética do indivíduo, fazendo com que este seja mais adaptado ou menos adaptado
ao ambiente (LINDEN, 2012).
O SABIA deu-se início em meados de 2014, como projeto de iniciação científica
iniciado no Laboratório de InteligênciaComputacional Aplicada a Negócios (LABICAN), no
qual foram criados a modelagem de software com Unified Modeling Language (UML), em
que foram elaborados o diagrama de classes, diagrama de casos de uso, diagrama entidade-
relacionamento, projeto arquitetural e manual de desenvolvimento. Além disso, foi desenvolvido
algumas partes da interface do sistema (SABIA, 2018).
Para que o projeto fosse desenvolvido de forma simples e rápida, a metodologia ágil
Scrum foi utilizada durante todo o processo de desenvolvimento, tendo uma abordagem iterativa
e incremental, propondo, de acordo com (TANIGUCHI K., 2009), uma possível entrega do
software com maior qualidade e rapidez, assim como, por se tratar de uma metodologia bastante
utilizada no mercado de trabalho por seu ótimo desempenho em auxiliar os processos de
desenvolvimento de softwares.
O sistema mesmo com todo seu planejamento e sua modelagem e parte de sua im-
plementação, acabou sendo descontinuado pelo surgimento de algumas dificuldades, como:
falta de conhecimento técnico por parte de alguns componentes do projeto, disponibilidade dos
alunos e suspensão das ações de avaliação e monitoramento por parte do governo. Estes fatores
resultaram em atrasos na execução de determinadas tarefas, o que influenciou negativamente no
cumprimento do cronograma de atividades, impossibilitando a conclusão do sistema proposto
(SABIA, 2018).
Após a descontinuidade, em meados do ano de 2017 as ações de avaliação e monito-
ramento por parte do governo foram retomadas. Assim, viu-se a oportunidade de retomar o
projeto, sendo conversado entre os alunos e professores envolvidos que o SABIA deveria ser
refatorado para melhor entendimento e aproveitamento das informações antes obtidas, auxiliando
todos os incluídos no projeto a fim de se obter a conclusão do mesmo. Em análise à modelagem
Capítulo 1. Introdução 13
do SABIA, foi possível identificar a necessidade de melhorias, com o intuito de proporcionar
qualidade no processo de desenvolvimento do sistema, tendo-se como consequências: maior
agilidade e melhor organização da documentação/modelagem.
Diante de todo este contexto, o presente trabalho consiste na proposta de refatorar os
modelos que contemplam a documentação/modelagem que antecedem o processo de imple-
mentação do sistema, de modo a, não apenas reparar os modelos existentes, mas também a
identificação de problemas e em propor novos modelos.
1.2 Objetivos
Os objetivos deste trabalho são divididos em objetivo geral e específicos.
1.2.1 Objetivo Geral
Desenvolver uma refatoração de modelos do sistema, usando modelagem de software
com UML, que corrija problemas no sistema SABIA, melhorando o entendimento lógico e a
organização arquitetural do software.
1.2.2 Objetivos Específicos
• Analisar a modelagem de software proposta para o sistema SABIA identificando os
problemas nos modelos e falta de modelos;
• Propor mudanças na modelagem para corrigir as falhas utilizando técnicas de refatoração;
• Efetuar uma análise comparativa entre a proposta anterior dos modelos e a proposta
refatorada.
1.3 Motivação e Justificativa de Estudo
É sabido que com o passar dos tempos as informações vão ficando desatualizadas e
posteriormente vão sendo modificadas ou esquecidas. No caso do SABIA, como o sistema foi
descontinuado pelos motivos já listados (Seção 1.1), as informações contidas no sistema ficaram
desatualizadas.
Considerando a desatualização das informações do sistema, foi realizada uma nova abor-
dagem dos requisitos do sistema, sendo incluídas/excluídas algumas informações atuais/antigas.
Marinescu e Avram (2007) fala que a reestruturação do sistema é de suma importância para que
se tenha uma melhor qualidade do software.
De acordo com Koscianski e Soares (2007), o critério de refatoração é realizado quando
uma nova funcionalidade é adicionada para encontrar e corrigir defeitos (imperfeições de um
Capítulo 1. Introdução 14
produto) e falhas (resultado ocasionado pelos defeitos). A reestruturação será feita ao artefato de
modelos, sendo atribuído os diagramas UML desenvolvidos no SABIA.
Após a análise feita na modelagem do SABIA, foi identificado que o diagrama de casos
de uso, no qual são listados pontos irrelevantes para o referido modelo, bem como, os diagramas
de classes que abordam atributos onde podem ser simplificados, e o diagrama de Entidade-
Relacionamento (ER) não precisará ser utilizado, pois, a critério da equipe de desenvolvimento
do software será utilizada uma ferramenta que faz o mapeamento de forma automatizada.
Baseando-se nas informações reconhecidas no SABIA, juntamente com a análise feita
em todos os artefatos e pela falta de atualização ocorrida com a descontinuidade do sistema,
algumas funcionalidades utilizadas nos diagramas com o tempo foram ficando ultrapassados.
Para que se tenha maior visibilidade das correções que serão feitas nos modelos, a Tabela 1 lista
os diagramas e o que foi refatorado na modelagem do SABIA.
Tabela 1 – Diagramas, verificação e refatoração
Diagrama Verificação Refatoração
Diagrama de Casos de Uso Atores Casos de uso “Manter...”
Diagrama de Classes Diagrama “Sabia” Todo o diagrama
Diagrama de Classes Diagrama “Cadastros IBGE” Classes “País” e “Macrorregião”
Diagrama de Classes Diagrama “Dados Pessoais” Classes “RG” e “Usuario”
Fonte: A Autora (2018)
No diagrama de casos de uso, a refatoração feita é a de excluir os casos de uso “Man-
ter...”, a fim de simplificar o diagrama, o tornando menos “poluído” visualmente e mais fácil de
ser entendido, atribuindo o caso de uso a uma simples anotação no diagrama.
O diagrama de classes descrito como “Cadastros IBGE”, houve a mudança nas classes
de “País” e “Macrorregiao”, no qual são excluídas do diagrama por motivos de não haver
necessidade em tê-las. O “País” fica subentendido ser o Brasil, por o processo de avaliação ser
totalmente realizado no Brasil e “Macrorregiao” se refere a região.
Já no diagrama “DadosPessoais”, as classes “RG” e “Usuário” são também excluídas.
A classe “RG” não tem funcionalidade e só aumenta ainda mais o diagrama, por isso é refatorada
para um atributo pertencente a outra classe.
Assim, de acordo com os problemas listados anteriormente, para que o processo seja
melhor entendido, sem diagramas confusos ou com muitas informações desnecessárias, a re-
fatoração é necessária, podendo evitar vários problemas, tais como: atraso na produção, alto
acoplamento e baixa coesão.
15
2 Fundamentação Teórica
Nesta seção será descrita o conceito da modelagem de software com ênfase na Unified
Modeling Language (UML) contemplando a descrição de todos os modelos utilizados neste
trabalho. Também será abordado o método de modelagem “Domain-Driven Design (DDD)”,
onde é explicado a criação de um determinado processo de como será feito até sua finalização e
a linguagem ubíqua. Além disso, como principal fator deste trabalho, será retratado o que se diz
respeito a refatoração, descrevendo algumas técnicas. Por fim, serão apresentados os trabalhos
relacionados a este.
2.1 Modelagem de Software com Unified Modeling Lan-
guage (UML)
Modelo é uma abstração com o intuito de entender algo antes mesmo de ser construído.
Mas, para que isso ocorra, é preciso montar vários tipos de modelos com a finalidade de testar
antes de construir, ter uma melhor comunicação com o cliente o ajudando a visualizar melhor
como será construído o projeto e tentar diminuir a complexidade que há em alguns projetos,
chegando a reduzir uma quantidade maior de informações que seria absorvida (RUMBAUGH,
2006).
Para haver uma melhor adequação da modelagem, foi criada uma linguagem padrão
chamada Unified Modeling Language (UML), desenvolvida pela união de vários outros métodos
orientados a objetos, a partir de 1967. Visto a necessidade de possuir um método completo, que
fornecesse um excelente suporte a análise de projetos, foi por volta de 1990 que Grady Booch,
Ivar Jacobson e James Rumbaugh começaram a usar ideias retiradas de cada um dos métodos
já criados e pensaram na possibilidadede unificar todos os métodos, assim tendo uma maior
estabilidade ao mercado orientado a objetos (BOOCH; RUMBAUGH; JACOBSON, 2012).
Tendo em vista este acontecimento, Booch, Rumbaugh e Jacobson (2012), criadores
dos métodos: “método de Booch”, “Object Oriented Software Engineering” (OOSE) e “Object
Modeling Technique (OMT)”, estabeleceram três objetivos para que houvesse essa unificação,
que foram: fazer a modelagem de sistemas, do conceito ao executável, utilizando as técnicas de
OO; Incluir questões de escala, característico de sistemas complexos; Criar uma linguagem de
modelagem a ser utilizada por humanos e por máquinas.
Desta forma, Booch, Rumbaugh e Jacobson (2012) retratam que ao decorrer dos
esforços feitos para que houvesse oficialmente a criação da UML, o método foi iniciado em
1994, onde Rumbaugh e Booch se uniram para que isso acontecesse. Com o passar do tempo, a
Capítulo 2. Fundamentação Teórica 16
UML foi sendo reconhecida e tomando seu espaço na comunidade de engenharia de software em
geral. Logo após o lançamento da primeira versão, Guedes (2014) diz que, foram aparecendo
sugestões de empresas com o intuito de melhorar a linguagem, assim, a UML foi adotada pela
OMG (Object Management Group), ou melhor, Grupo de Gerenciamento de Objetos, levando o
título de “linguagem padrão de modelagem”.
Por ter sido titulada como linguagem padrão para a elaboração da estrutura de projetos
de software, a UML pode ser utilizada para a visualização, para especificar melhor todos os
detalhes do projeto e para construí-lo. Assim, a utilização desta vai muito além de ser “a padrão”,
foi escolhida por ser de fácil compreensão, centrada na arquitetura, iterativa e incremental.
2.1.1 Diagramas da UML
Na estruturação de diagramas, Booch, Rumbaugh e Jacobson (2012) argumentam que,
um diagrama é a apresentação gráfica de vários elementos constituídos por itens e relacionamen-
tos. São feitos para permitir uma melhor visualização de todos os aspectos de um sistema. Onde,
na UML são incluídos os diagramas de classes, diagrama de objetos, diagrama de componentes,
diagrama de estruturas compostas, diagrama de casos de uso, diagrama de sequências, dia-
grama de comunicações, diagrama de estados, diagrama de atividades, diagrama de implantação,
diagrama de pacote, diagrama de temporização e o diagrama de visão geral da interação.
No qual, na pesquisa, inicialmente são abordados os diagramas de classes e o de casos
de uso. Para justificar o uso desses diagramas, Guedes (2014) diz que, o diagrama de classes é
um dos diagramas mais utilizados e um dos mais importantes da UML, pois possui uma estrutura
em que compreende todas as classes utilizadas pelo sistema, juntamente com seus atributos,
métodos e relacionamentos entre si, além do mais, todos os outros diagramas se apoiam a sua
estrutura. Ele ainda afirma, que o diagrama de casos de uso é tão importante e utilizado quanto o
diagrama de classes, pois auxilia no levantamento e análise dos requisitos, no qual compreende
todas as precisões dos usuários.
2.1.1.1 Diagrama de Classe
Dentre os diagramas citados na seção anterior, é utilizado o diagrama de classes, onde,
costumam abranger classes, interfaces e relacionamentos de dependência, de generalização e de
associação. São úteis para a visão estática da estrutura de um sistema, como também, são fáceis
de serem entendidos (BOOCH; RUMBAUGH; JACOBSON, 2012).
Segundo Booch, Rumbaugh e Jacobson (2012), as classes são descrições de conjuntos de
objetos que contém atributos, operações, relacionamentos e semântica. Assim, para exemplificar
um exemplo de classe, a Figura 1 mostra uma classe contendo atributos e operações:
Capítulo 2. Fundamentação Teórica 17
Figura 1 – Exemplo de Classe
Fonte: A Autora (2018)
Cada classe terá que ter um nome para que seja possível ser diferenciada das outras
classes, no qual o nome pode ser “simples” ou “nome qualificado”, como representados na
Figura 2:
Figura 2 – Nomes simples e Nomes qualificados
Fonte: Elaborado pela autora, com base em Booch, Rumbaugh e Jacobson, 2012.
Como citado anteriormente, no diagrama existem os atributos que descrevem as quali-
dades da classe. A classe pode ter qualquer número de atributos ou nenhum atributo. Na Figura 3
é possível representar os atributos:
Figura 3 – Atributos
Fonte: Elaborado pela autora, com base em Booch, Rumbaugh e Jacobson, 2012.
Capítulo 2. Fundamentação Teórica 18
No gráfico de atributos, o principal objetivo é listar todos os substantivos que represen-
tam alguma propriedade da classe a que se refere. Os atributos listados na Figura 3, expressam
com nomes, o que uma classe com o nome “Pessoa” deve contemplar, que no caso são: “nome,
cpf, endereço e telefone” (BOOCH; RUMBAUGH; JACOBSON, 2012).
Além de nome da classe e atributos, Booch, Rumbaugh e Jacobson (2012) afirmam que
existem as operações, que são a execução de uma atividade que pode ser solicitada por algum
objeto da classe para modificar o comportamento. As operações podem ser representadas da
seguinte forma:
Figura 4 – Operações
Fonte: Elaborado pela autora, com base em Booch, Rumbaugh e Jacobson, 2012.
Contudo, apesar de que existem poucas classes que trabalham sozinhas, dependendo
do caso, para que se tenha um diagrama de classes propriamente dito, precisa-se haver um
relacionamento entre as classes. Estes relacionamentos são nomeados como: generalização,
dependência e associação Booch, Rumbaugh e Jacobson (2012). Na Figura 5, podem ser
representados tais relacionamentos:
Figura 5 – Exemplo de Relacionamentos
Fonte: Booch, Rumbaugh e Jacobson, 2012, p. 70.
O relacionamento de dependência é utilizado quando, de acordo com a Figura 5, a
classe “Janela” usa as informações da classe “Evento”. A dependência pode ser percebida
Capítulo 2. Fundamentação Teórica 19
também através da sua linha tracejada indicando que “Janela” depende de “Evento”, porém,
deve-se salientar que em caso contrário, a dependência não é recíproca (BOOCH; RUMBAUGH;
JACOBSON, 2012).
O relacionamento de generalização é utilizado quando, como exemplificado na Figura 5,
existe uma classe “pai”, titulada como “Janela” e seus “filhos” titulados como “JanelaConsole” e
“CaixaDeDiálogo”. A relação ocorre pelo motivo das classes “filhos” herdarem os atributos da
classe “pai” (BOOCH; RUMBAUGH; JACOBSON, 2012).
Já o relacionamento de associação, ocorre quando, como mostrado na Figura 5, acontece
uma agregação das classes “CaixaDeDiálogo” com “Controle”, ou seja, objetos de uma classe se
conectam a outra classe. A associação é representada graficamente com uma linha sólida sendo
conectada à mesma classe ou classes diferentes (BOOCH; RUMBAUGH; JACOBSON, 2012).
Diante do que foi descrito sobre o diagrama de classes, o uso deste é de extrema
importância para o projeto, pois, na antiga modelagem do sistema SABIA, foi identificado, neste
diagrama, algumas falhas de comunicação entre as classes, onde será aplicada uma refatoração
fazendo com que se torne possível uma melhor visualização do que poderá vir a ser o sistema.
2.1.1.2 Diagrama de Casos de Uso
Como foi descrito na seção de diagramas da UML, outro diagrama que será utilizado
neste trabalho é o de casos de uso, que segundo Guedes (2014), aborda as necessidades do
usuário. Nele, são inseridas as informações de como o sistema irá se comportar. Mesmo sendo
considerado o diagrama mais informal da UML, ele sempre será consultado durante todo o
processo de modelagem.
Este diagrama identifica o cenário, os casos de uso, os atores e os relacionamentos de
dependência, generalização e associação. A Figura 6, exemplifica o ator e caso de uso:
Figura 6 – Ator e Caso de Uso
Fonte: Elaborado pela autora, com base em Booch, Rumbaugh e Jacobson, 2012.
Como mostrado na Figura 6, o ator representa o papel desempenhado por quem irá
utilizar/interagir dentro do sistema. O caso de uso se refere a funcionalidades, serviços ou tarefas
contidas no sistema. Além disso, todo caso de uso tem um nome (textual ou numérico) para
Capítulo 2. FundamentaçãoTeórica 20
que seja diferenciado dos demais. O nome pode ser “nome simples” ou “nome de caminho”
(GUEDES, 2014). Na Figura 7, os tipos de nomes são ilustrados:
Figura 7 – Tipos de Nomes
Fonte: Elaborado pela autora, com base em Booch, Rumbaugh e Jacobson, 2012.
Em relação a seus relacionamentos, o diagrama de casos de uso também se comporta
da mesma maneira que o diagrama de classes.
Em suma, a proposta aqui apresentada sugere a modelagem de um novo diagrama
de caso de uso com a finalidade de reparar falhas encontradas nos casos de uso, que seriam
irrelevantes para o projeto, na versão anterior realizada no SABIA.
2.2 Domain-Driven Design (DDD)
Vernon (2016) diz que, Domain-Driven Design (DDD) significa “Projeto Orientado a
Domínio” e que um dos pilares do DDD é a linguagem ubíqua, que se refere a uma linguagem
comum entre todos que estão fazendo parte do desenvolvimento de um sistema de software.
Evans (2009) declara que, cada sistema de software está relacionado sob algum interesse
de quem for utilizá-lo. É justamente essa área de interesse que o usuário aplica o sistema, que é
chamado de domínio do software. A modelagem de domínios não está relacionada a criar um
modelo mais real, mas sim, a criação de um determinado processo de como será feito até como
foi feito o processo.
Assim, existem utilidades básicas que determinam a escolha de um modelo: A ligação
entre o modelo e a implementação ajuda na compreensão do modelo, o uso de modelos tem a
capacidade de se transformar numa linguagem em que tanto o desenvolvedor, quanto o cliente,
podem se comunicar sem a necessidade de explicar o que é que está sendo feito, o modelo
trata de estruturar o conhecimento do domínio e aplicar suas diferenças. A ligação do modelo
com a implementação faz com que se utilize às versões anteriores do projeto e as aplique como
feedback na modelagem (EVANS, 2009).
A linguagem ubíqua deve ser compreendida por todos, sem haver ambiguidade. A
respeito disto, se um cliente de um determinado projeto de sistema, solicitar a emissão de uma
fatura para o cliente antes da data limite, na implementação do código deverá constar uma classe
Capítulo 2. Fundamentação Teórica 21
para a entidade “Cliente”, uma classe para a entidade “Fatura”, algum serviço que tenha um
método “emitir” e algum atributo com o nome de “data limite” (CUKIER, 2010).
Para que isso aconteça, utilizando a linguagem ubíqua, foi criado o projeto dirigido
pelo modelo (Model Driven Design - MDD). O MDD é um modelo abstrato que deve ser uma
representação do seu domínio, onde tudo que existe no seu objetivo de sistema deve aparecer no
modelo (CUKIER, 2010).
Entretanto, Evans (2009) afirma que para se dar início a criação deste modelo, inici-
almente, tem-se de isolar o modelo de domínio das demais partes que constituem o sistema.
Cukier (2010), diz que essa separação pode ser feita utilizando-se uma arquitetura em camadas,
dividida em quatro partes: Interface de Usuário (IU), onde acontece a exibição de informações
do sistema ao usuário e interpretação dos comandos do usuário; Aplicação que condiz a camada
fina, responsável por conectar a IU às camadas inferiores; O domínio que representa os conceitos,
regras e lógicas de negócio; e A infraestrutura que fornece recursos técnicos que darão suporte
às camadas superiores.
Na Figura 8, a arquitetura do DDD é representada:
Figura 8 – Arquitetura em Camadas do DDD
Fonte: http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/, 2010.
Capítulo 2. Fundamentação Teórica 22
Evans (2009) diz que após a divisão do sistema em camadas, o que mais importa é
a camada de domínio. Para modelar essa parte, utiliza-se alguns padrões propostos em DDD.
Estes padrões são chamados de blocos de construção e são utilizados para representar o modelo
abstrato. Onde os blocos podem ser entidades, onde são classes de objetos que necessitam de
uma identidade; e Objetos de Valores, por exemplo: strings, números ou cores.
Contudo, Vernon (2016) afirma que o uso da linguagem ubíqua e do MDD, não são
suficientes para a aplicação do DDD. Evans (2009) fala que, ao se tratar de sistemas complexos
é preciso dividir o software em várias partes, no qual é chamada de “contexto delimitado”. Cada
contexto deve ser bem claro para que todos possam entender o código existente.
E assim, a parte mais importante, de acordo com Cukier (2010) é o processo chamado
de “Destilação do Domínio”, onde o objetivo final é atingido quando não há mais nada para tirar
do Núcleo do Domínio. Devido a criação de um sistema ser definido em “blocos”, que mistura
código de várias camadas, classes com especialidades bem diversas, o processo principal se
refere a separação em módulos, extraindo métodos, classes, conceitos, etc., visando a organização
de tudo, onde possa ser bem claro quais são os conceitos centrais (núcleo) do sistema proposto.
Portanto, o uso do DDD neste trabalho, se aplica ao uso da linguagem ubíqua, podendo
tornar toda a documentação/modelagem do sistema mais fácil de ser entendido, sem haver
duplicidade de código e estranheza em determinados significados.
2.3 Refatoração
Segundo Fowler (2009), refatorar é “reestruturar” um software, ou seja, fazer variadas
alterações para tornar o sistema mais fácil de ser entendido, sem alterar seu comportamento
observável. Sendo assim, deve-se salientar que, refatoração é um procedimento que pode e deve
ser usada para qualquer circunstância.
Ainda de acordo com Fowler (2009), há vezes em que não se deve refatorar, pois
algumas vezes é melhor reescrever a partir da “estaca zero”.
Na primeira vez em que faz algo, você apenas faz. Na segunda vez em que
faz algo parecido, você estremece diante da duplicação, mas a faz de qualquer
forma. Na terceira vez em que faz algo parecido, você refatora. (FOWLER,
2004, p. 56).
Entretanto, a refatoração é mais utilizada na programação de sistemas, para melhorar a
estrutura interna do código e não em modelagens. Assim como, também pode ser utilizada para
analisar o que já foi feito em algum projeto.
No SABIA, ver o que tem de ser mudado, o que não precisa ser mudado e o que pode
ser feito tudo novamente, podendo começar da estaca zero. Fazer a refatoração poderá tornar o
Capítulo 2. Fundamentação Teórica 23
código de um sistema de software mais fácil de ser entendido pelo cliente e por todas as outras
pessoas envolvidas.
Para que aconteça a refatoração, existem algumas técnicas que Fowler (2009) abrange,
são elas: Extrair Método, Mover Método, Mover Atributo, Extrair Classe e Renomear Método.
Estas técnicas utilizam o princípio da Orientação a Objetos (OO), que de acordo com Furgeri
(2013), é o paradigma de desenvolvimento de software mais utilizado no mercado. A OO abrange
toda a complexidade que há diante do objeto de software, tendo duas características principais:
possuem suas propriedades (estado) e suas ações (comportamento).
Na técnica de extrair método, Fowler (2009) também diz que sua refatoração ocorre
quando sua principal motivação for eliminar métodos grandes que realizam duas ou mais tarefas,
possuindo também muitos comentários. Sua refatoração ocorre movendo as partes dos códigos
duplicados para um novo método.
A técnica de refatoração “mover método” se dá também de forma simples. Ao possuir
um método que será utilizado muitas vezes por outra classe, é passível de copiar o método usado
pela classe “a” e colar para a classe “b” (FOWLER, 2009).
Muito parecida com a técnica anterior, também pode ser aplicada a técnica “mover
atributo”. Fowler (2009) fala que pode-se aplicá-la quando uma classe “b” utiliza muito um
atributo que foi definido em uma classe “a”, assim, deve-se apenas copiar o atributo da classe
definida para a classe que o utiliza muitas vezes.
Mais uma técnica utilizada: extrair classe. Esta deve ser usada quando existe uma classe
“a” que execute o trabalho que deveria ser feito em duas classes. Então, vista a necessidade, os
atributos da classe “a” podem ser extraídos para uma classe “b”. Quando um método possuium
nome estranho, que não dá pra entender o que realmente ele faz, a técnica a se utilizar é a de
“renomear método”. O nome do método deve ser o mais claro possível, fazendo com que haja
melhor entendimento da real função do método (FOWLER, 2009).
Com isso, por meio das técnicas de refatoração descritas anteriormente, juntamente com
novas maneiras de se refatorar, poderá ser possível corrigir os problemas encontradas no SABIA,
tornando a modelagem do sistema mais fácil de ser entendida e auxiliando mais rapidamente
no processo de implementação do código a ser feito pelos desenvolvedores de software. Das
técnicas descritas por Fowler (2009), a refatoração dos modelos UML do SABIA usará todas as
listadas anteriormente.
2.4 Trabalhos Relacionados
Algumas propostas foram elaboradas e desenvolvidas a fim de se utilizar a refatoração
e modelagem de software, assim como, a refatoração de modelagens.
Em Sunyé (2001), são abordadas refatorações que projetam e preservam o comporta-
Capítulo 2. Fundamentação Teórica 24
mento de um modelo UML. Foram apresentados um conjunto de refatorações de projeto para
melhorar a modelagem de programas orientados a objetos sem adicionar novas funcionalidades.
A refatoração a nível de modelagem se mostrou ser muito complexa, pois a busca e elaboração
de algumas refatorações foram bem difíceis, se tratando do impacto em diferentes visões da
UML. Ainda assim, os autores viram como perspectiva para este trabalho o uso extensivo da
ação semântica, podendo tornar os modelos mais precisos e comprovados.
Correa e Werner (2004) falam em seu trabalho sobre a aplicação de técnicas de refa-
toração para modelos UML/OCL. Eles descrevem que a Linguagem de Restrição de Objetos
(OCL) contém expressões complexas, podendo ser de difícil entendimento. Assim, as técnicas de
refatoração permitem o melhoramento e compreendimento de um modelo UML/OCL. Por fim,
foi visto que as técnicas de refatoração utilizadas pelos autores, obtiveram grandes contribuições,
permitindo que muitos problemas ocasionados pelas especificações em OCL fossem resolvidos.
Baseando-se na proposta de refatoração, pode ser citado o trabalho de Silva e Nunes
(2007), em que aborda um estudo sobre a refatoração de modelos orientados a aspectos. É
possível identificar que a utilização da refatoração possibilitou uma visão mais abrangente para
saber quais refatorações seriam implementadas através da transformação de modelos orientados
a aspectos.
Piveta (2009) escreveu um estudo sobre a melhora na busca por oportunidades de
refatoração em software orientado a objetos e orientado a aspectos. O principal objetivo do
trabalho é o de prover um processo detalhado para refatoração. Foi avaliado os efeitos na
qualidade de software e analisado as vantagens e desvantagens na aplicação de padrões de
refatoração. Os resultados do trabalho mostraram que o uso da refatoração pode ajudar o
desenvolvedor a se concentrar nos padrões que trazem mais benefícios e a implementar o código
mais adequadamente.
Já o trabalho de Junior (2015) apresenta uma pesquisa realizada para efeito do estudo
de métodos e processos de refatoração de banco de dados. Neste trabalho, o autor conclui que o
objetivo do tema em questão era o de apresentar os conceitos de refatoração de banco de dados,
aplicando as respectivas técnicas de refatoração de banco de dados, no qual atingiu o objetivo de
corrigir erros nos esquemas de banco de dados, melhorando a estrutura e o modelo dos mesmos.
Barros (2015) fala em seu trabalho sobre um método para a refatoração de software
baseado em frameworks de domínio. Muller (2014) fala que framework são ferramentas que
facilitam o trabalho dos desenvolvedores. O autor criou um método de refatoração usando como
referência os métodos da literatura, sendo capaz de ajudar os desenvolvedores na refatoração de
aplicações construídas com os conceitos de frameworks de domínio. Os resultados da aplicação
do método foram: melhoria na complexidade do código, diminuição da quantidade de duplicação
de código, tornando-o assim um código mais reutilizável e flexível.
Mognon (2017) utilizou uma abordagem diferente de modelagem de software, chamada
Capítulo 2. Fundamentação Teórica 25
Object-Process Methodology (OPM). Em seu trabalho descreveu que a modelagem é uma
das atividades metodológicas presentes em processos de desenvolvimento de software, sendo
bastante relevante na fase de análise do produto. Preferiu trocar a linguagem usual UML pelo uso
da OPM, que representa a estrutura e comportamento de um sistema em um mesmo diagrama. O
trabalho objetivou que a modelagem utilizada foi eficaz, pois se mostrou ser de fácil execução e
interpretação, tendo como principal objetivo a característica iterativa.
Sendo assim, diante dos trabalhos apresentados, verifica-se que existem algumas téc-
nicas de refatoração, sendo a proposta de Sunyé et al. (2001) e a de Correa e Werner (2004)
aplicadas diretamente a modelagem de software com UML, especificamente dita. As técnicas
utilizadas neste trabalho foram baseadas em Fowler (2009). Os estudos apontam que a refatora-
ção é realmente eficaz no que se diz respeito ao melhor entendimento do produto em questão,
sendo extremamente eficiente para que haja um melhor entendimento e melhoramento no futuro
processo de desenvolvimento do software que poderá ser feito.
26
3 Metodologia
Este capítulo apresenta de forma detalhada o funcionamento do sistema SABIA, envol-
vendo todas suas regras de negócio. A seção subsequente esclarece cada etapa metodológica
para seu processo de execução de acordo com toda sua particularidade em questão.
3.1 Regras de Negócio do SABIA
Avaliadores cadastrados no Banco de Avaliadores da SETEC devem pertencer obriga-
toriamente a um dos seguintes grupos: ativos ou inativos. Avaliadores ativos estão disponíveis
para realizar avaliações normalmente, enquanto que avaliadores inativos estão temporariamente
indisponíveis (por estar de férias, afastado para capacitação, ou outro motivo que o impeça de
receber diárias e/ou passagens) e não serão questionados sobre sua disponibilidade.
Após os avaliadores informarem sua disponibilidade, será feita a lista de equipes que
farão as avaliações. Cada equipe é composta por dois ou mais avaliadores. Para cada UE
a ser avaliada, o CE deve criar uma equipe de acordo com as seguintes regras: pelo menos
um avaliador que mora na mesma região da UE a ser avaliada e o restante dos avaliadores de
diferentes regiões. Não devem fazer parte da equipe avaliadores que residam no mesmo estado
da UE a ser avaliada. A equipe deve conter pelo menos um avaliador experiente, ou seja, que
já tenha feito pelo menos uma avaliação. Não podem fazer parte da equipe avaliadores que já
tenham avaliado a mesma UE anteriormente.
Depois das equipes definidas, os avaliadores são notificados e deverão num prazo de até
quarenta e oito horas para informar as preferências de vôo no Sistema de Concessão de Diárias
e Passagens (SCDP). Cada avaliador terá de enviar a sua Proposta de Concessão de Diárias
(PCD) que constará: origem e destino das viagens, horários e número dos vôos. Caso um dos
avaliadores não informe os dados necessários no PCD, o mesmo será substituído por um novo
avaliador, que logo será alocado na equipe em que está sendo formada.
Quando todos os avaliadores da mesma equipe informarem os dados no PCD, a SETEC
irá aprovar ou cancelar a avaliação, confirmando ou não se os custos estão condizentes se
baseando num teto de gastos propostos por eles mesmos. Após a confirmação, serão emitidos
os ofícios (contendo designações para efeito de comprovação junto a UE) das visitas e dos
avaliadores.
Conseguinte a emissão dos ofícios, o avaliador entrará em contato com as UE para ser
feito o detalhamento de agenda para consequentemente ser realizada a visita à unidade. Depois
de ser realizada a visita, o avaliador é obrigado a entregar o formulário de avaliação e prestar
contas das passagens informadas no PCD. Qualquer problema referente ao avaliador será descritoCapítulo 3. Metodologia 27
nos relatórios. Assim, o SETEC encerra as avaliações.
Contudo, a utilização da metodologia ágil Scrum não foi totalmente empregada durante
o processo de desenvolvimento, pelo motivo de não disponibilidade total da equipe de desen-
volvimento, em que faziam parte alunos que tinham dedicação parcial ao projeto, ocasionando
assim, falta de tempo para se ter reuniões diárias, resultando em reuniões somente em três dias
na semana (SABIA, 2018).
No que se diz respeito a implementação do código, foi utilizada a linguagem de
programação Java, juntamente com a IDE (Integrated Development Environment) Eclipse,
atrelando a linguagem de marcação de textos HTML 5 (Hypertext Markup Language, versão
5), sendo também integrada a linguagem de folhas de estilos CSS 3 (Cascading Style Sheets).
Ambas tecnologias só foram utilizadas devido a familiaridade da equipe com tais (SABIA, 2018).
Ainda se tratando de tecnologias, foi utilizado pela equipe de desenvolvimento o sistema
web Github para a ferramenta de controle de versão. Pozzebom (2015) fala que o GitHub serve
tanto para auxiliar no controle de versões e no compartilhamento das partes implementadas pelos
membros da equipe deste projeto, quanto a ferramenta permite que todas as versões do projeto
sejam salvas em um repositório web, o que possibilita retroceder algumas versões do projeto
em caso de possíveis problemas na versão atual não serem passíveis de resolução pela equipe
(SABIA, 2018).
Assim, as regras descritas foram estabelecidas tanto pela SETEC, quanto pelos alu-
nos e professores envolvidos no projeto, promovendo uma melhor organização dos requisitos
necessários a se desenvolver o sistema.
3.2 Arquitetura do Trabalho
O processo de refatoração do SABIA se dá principalmente a modificação de toda
modelagem, tornando-a como a principal proposta do trabalho (Figura 9). O principal fator
utilizado para a coleta, análise e execução do processo caracteriza-se pela documentação feita
desde o ano de 2014, se estendendo aos anos de 2015, 2017 e 2018, abordando todos os aspectos
utilizados em todo o desenvolvimento do projeto.
Capítulo 3. Metodologia 28
Figura 9 – Ilustração da Proposta do Trabalho
Fonte: A Autora (2018)
Inicialmente, é feita a coleta e análise das informações apurados através de toda a
documentação do SABIA. Para que ocorra a refatoração, se fez necessário o seguimento das
etapas apresentadas na Figura 9, no qual se dá, inicialmente, a coleta e análise dos processos de
formação das equipes e avaliação das UE, citado neste capítulo (Seção 3.1).
O processo de formação das equipes que irão avaliar as UE se dá como as equipes serão
articuladas, tendo como principal requisito um avaliador ser do mesmo estado e o(s) outro(s)
de diferentes estados (Seção 3.1). A formação de equipes se dá, simplificadamente, da seguinte
forma ilustrada na Figura 10.
Capítulo 3. Metodologia 29
Figura 10 – Processo de Montagem das Equipes de Avaliadores
Fonte: A Autora (2018)
Seguidamente, após a coleta e análise dos processos que envolvem o SABIA, são
analisados mais uma vez o processo de formação das equipes que avaliarão as instituições. A
Figura 10 é dada como:
• A SETEC disponibiliza uma planilha que contém todas as informações sobre as Unidades
de Ensino;
• Os Coordenadores de Equipes questionam aos Avaliadores ativos qual a disponibilidade
deles;
• Os Avaliadores escolhidos pelos CE’s informam a preferência de horário de vôos já
pesquisada para o local também escolhido pelos CE’S;
• Propor mudanças na modelagem para corrigir as falhas utilizando técnicas de refatoração;
• Se a SETEC aprovar os custos, o avaliador emitirá um ofício, entrará em contato com a
UE e fará a avaliação;
• Após a avaliação realizada, o avaliador envia o formulário de avaliação feito na UE.
Após a coleta e análise dos dados descritos na seção 3.1, também foi feita a verificação
dos modelos de software do SABIA. A Tabela 1 (Seção 1.3) ilustra o que é verificado e quais
são as modificações.
30
4 Resultados
4.1 Modelagem Inicial Versus Refatorada
Utilizando a UML como linguagem para a modelagem do SABIA, juntamente com as
técnicas de refatoração abrangidas por Fowler (2009), a Tabela 2 lista as técnicas utilizadas nos
diagramas deste trabalho.
Tabela 2 – Utilização das Técnicas de Refatoração
Diagrama Técnica utilizada
Diagrama de casos de uso Extrair classe (Extrair caso de uso)
Diagrama de classes “Dados Pessoais” Extrair classe, mover método, mover atributo e
renomear método.
Diagrama de classes “Cadastros IBGE” Extrair classe e mover atributo
Diagrama de classes “Sabia” Extrair método, mover método, mover atributo,
extrair classe e renomear método
Fonte: A Autora (2018)
No diagrama de casos de uso houve a utilização da técnica de extrair classe, sendo
propriamente utilizado a extração de alguns casos de uso que tornavam o diagrama mais difícil
de ser entendido, tais como no ator “Operador” foram extraídos os casos de uso: manter projeto,
manter estado, manter cidade, manter microrregião, manter mesorregião, manter instituição,
importar instituições, manter equipes, manter demanda (atividades), alterar perfil e alterar status
do usuário. Já no ator “Administrador” foram extraídos os casos de uso: manter usuário, convidar
usuário e alterar senha. E no ator “Avaliador”, o único caso de uso excluído foi o de manter
disponibilidade.
Nos diagramas de classes titulados como “Dados Pessoais”, “Cadastros IBGE” e
“Sabia”, foram utilizadas as técnicas de extrair classe, mover método, mover atributo, extrair
método, mover método, mover atributo, extrair classe e renomear método. Ambos com suas
particularidades podendo ser vistas mais adiante.
Os diagramas que foram feitos inicialmente (Inicial) e os refatorados (Refatorado) serão
listados nas figuras a seguir:
Capítulo 4. Resultados 31
Figura 11 – Diagrama de Casos de Uso (Inicial)
Fonte: SABIA (2018)
No diagrama de casos de uso feito e refeito nos anos de 2014/2015, nota-se muitas
informações atribuídas a três atores (Administrador, Operador e Avaliador). O diagrama, além
de conter muita informação, está desorganizado, o que torna o diagrama complicado de ser
entendido ao visualizá-lo. Uma das falhas mais frequentes, é o da insistência em repetir os casos
de uso “Manter...”, fazendo com que o diagrama seja repetitivo nas ideias. Assim, ao estudar o
diagrama e suas ideias, um novo modelo foi proposto, retirando todos os casos de uso “Manter...”
e refatorando alguns demais.
Capítulo 4. Resultados 32
Figura 12 – Diagrama de Casos de Uso (Refatorado)
Fonte: A Autora (2018)
Visualmente, o diagrama de casos de uso está bem melhor, podendo ser mais fácil
de ser entendido. As informações foram simplificadas e os casos de uso “Manter. . . ” foram
retirados, pelo motivo de ser subentendido no sistema que cada usuário (ator) deverá cadastrar,
alterar, excluir e fazer suas devidas consultas em determinadas funcionalidades. Em relação aos
nomes dos atores, foi modificado o de “Operador”, passando a ser chamado de “Coordenador de
Equipes”, pois se torna mais fácil de entender o papel deste ator, no qual é o responsável por
todas operações referentes as avaliações e avaliadores.
Além disso, foram alterados os casos de uso “alterar perfil”, para “alterar dados”, sendo
um caso de uso com sua funcionalidade estendida aos outros atores. “Alterar status do usuário”
foi alterado para “Atualizar usuários” para simplificar e minimizar a quantidade de casos de uso
sobre atualização de dados.
Capítulo 4. Resultados 33
Figura 13 – Uma parte do Diagrama de Classes - Sabia (Inicial)
Fonte: SABIA (2018)
Na Figura 13 pode ser visualizada uma parte relevante do diagrama de classes “Sabia”,
onde são ilustrados o processo de avaliação do SABIA. O diagrama inteiro pode ser visto no
Apêndice A.
O diagrama tem uma grande e principal falha que é o de ser muito extenso. Nele, estão
ilustrados todas as classes inclusas no processo de avaliação do PRONATEC.
Capítulo 4. Resultados 34
Figura 14 – Diagramade Classes - Avaliação (Refatorado)
Fonte: A Autora (2018)
Antes chamado de “Sabia”, o diagrama com o nome refatorado para “Avaliação” torna
melhor visível o processo de avaliação feito pelos avaliadores. A classe “Avaliacao” teve
composição formada em “AvaliacaoUE” reaproveitada da classe “UnidadeEnsino” do diagrama
“Parceiro”. Além disso, foram reutilizados atributos e métodos de outras classes, tais como os
dados do “Avaliador” reaproveitados da classe “Parceiro” vinda de outro diagrama. A classe
“Ciclo” também foi reaproveitada, sendo copiado os atributos da classe “Período”.
Capítulo 4. Resultados 35
Figura 15 – Diagrama de Classes - Cadastros IBGE (Inicial)
Fonte: SABIA (2018)
O diagrama “Cadastros IBGE” contém sete classes, onde a classe “País” está separada
das demais, por se tratar de uma classe única e específica, porém, sem necessidade. As outras
classes podem ser renomeadas, buscando um melhor entendimento. Ambas as classes possuem
um relacionamento de
Capítulo 4. Resultados 36
Figura 16 – Diagrama de Classes - Localidade (Refatorado)
Fonte: A Autora (2018)
O diagrama “Localidade” (inicialmente com o nome de “CadastroIBGE”), teve a classe
de “Macrorregiao” refatorada para “Regiao”, por motivos de melhor entendimento de significado
da palavra. A classe “Pais” foi excluída pelo fato de ficar subentendido que o nome do país
seja “Brasil” e que todo o processo do SABIA ocorre unicamente neste mesmo país. A classe
“Cidade” foi substituída por “Municipio”, sendo adicionado o atributo de “cep”. Além dessas
mudanças, ocorreu a renomeação da classe “Estado” para “UF”.
Capítulo 4. Resultados 37
Figura 17 – Diagrama de Classes - Dados Pessoais (Inicial)
Fonte: SABIA (2018)
O diagrama “Dados Pessoais” não é de difícil entendimento, porém, possui classes
que poderiam ser renomeadas ou realocadas com determinados atributos mais específicos. A
classe “RG” não se torna necessária, pois contém ligação com a classe “Pessoa”, podendo incluir
os atributos de “RG” para tal. A classe “Usuario” também pode ser realocada, incluindo seus
atributos em outra classe mais específica. Para isso, o diagrama foi refatorado e pode ser ilustrado
na Figura 18.
Capítulo 4. Resultados 38
Figura 18 – Diagrama de Classes - Parceiro (Refatorado)
Fonte: A Autora (2018)
Além do nome do diagrama ter sido modificado, as classes tiveram algumas alterações:
classe “Pessoa” foi refatorada para “Avaliador” possuindo os mesmos atributos, somente havendo
mudança em relação ao relacionamento de generalização vindo da classe “Parceiro”. A classe
“Parceiro” foi criada com o intuito de unificar os atributos e métodos principais das classes
“Avaliador” e “UnidadeEnsino”, possuindo também interligação com qualquer outro tipo de
contato.
Assim, pode-se notar que em todos os diagramas apresentados foram utilizadas as
técnicas de refatoração (Seção 2.3) abrangidas por Fowler (2009) e exibidas na Tabela 2
(Seção 4.1). Ainda, é perceptivelmente capaz de se observar, que houve uma grande diminuição
na quantidade de classes criadas, assim como diagramas bem melhores de serem associados
visivelmente. Na Tabela 3, ilustrada a seguir, os resultados foram listados.
Capítulo 4. Resultados 39
Tabela 3 – Resultados
Diagrama Resultados
Diagrama de casos de uso Um ator renomeado para “Coordenador de Equi-
pes”; Menos casos de uso;
Diagrama de classes “Cadastros IBGE” Renomeio do nome do diagrama para “Locali-
dade”; Exclusão de uma classe; Renomeio de
duas classes; Adição de um atributo em duas
classes diferentes;
Diagrama de classes “Dados Pessoais” Renomeio do nome do diagrama para “Par-
ceiro”;Exclusão de uma classe; Adição de duas
classes;Adição de atributos;Renomeação de atri-
butos;
Diagrama de classes “Sabia” Renomeio do nome do diagrama para “Avalia-
ção”; Exclusão de mais de dez classes;
Fonte: A Autora (2018)
Como melhor forma de validar os resultados, foi feito um formulário de questões
(Apêndice B e seus resultados 4.2) direcionado especialmente aos desenvolvedores do SABIA,
que participaram do projeto nos anos de 2017/2018, para que todos respondessem a algumas
perguntas referentes aos diagramas (iniciais e refatorados) e contribuíssem com a opinião de
comparação entre tais.
4.2 Questionário Avaliativo
Para que as refatorações fossem avaliadas e realmente comparadas, foi feito um ques-
tionário, no qual contém 13 perguntas. O questionário foi enviado a três desenvolvedores e
uma analista, no qual todos responderam as questões. As Figuras a seguir ilustram as perguntas
e o gráfico obtido referente as respostas dos 4 componentes do projeto que responderam ao
formulário.
Capítulo 4. Resultados 40
Figura 19 – Resultado da pergunta 1
Fonte: A Autora (2018)
Na primeira pergunta, seu resultado foi empate. O diagrama em questão era o diagrama
de casos de uso antes de ser refatorado.
Figura 20 – Resultado da pergunta 2
Fonte: A Autora (2018)
Na segunda pergunta, seu resultado foi bem satisfatório. O diagrama de casos de uso
refatorado teve um nível maior de entendimento.
Capítulo 4. Resultados 41
Figura 21 – Resultado da pergunta 3
Fonte: A Autora (2018)
Como já ilustrado, o diagrama de casos de uso que obteve melhor compreensão perante
visualização, foi o refatorado.
Figura 22 – Resultado da pergunta 4
Fonte: A Autora (2018)
A pergunta 4 se dá ao entendimento quando visualiza o diagrama de classes “Sabia”.
As respostas foram na média. Três de quatro respostas foram na média 3. Podendo-se notar uma
certa confusão no entendimento.
Capítulo 4. Resultados 42
Figura 23 – Resultado da pergunta 5
Fonte: A Autora (2018)
Já o resultado da refatoração do diagrama de classes “Avaliação” mostrou que a maioria
das respostas foram para um ótimo entendimento.
Figura 24 – Resultado da pergunta 6
Fonte: A Autora (2018)
De acordo com o gráfico, o resultado obtido foi de meio termo para os dois diagramas,
no qual o entendimento foi igualitário para ambos.
Capítulo 4. Resultados 43
Figura 25 – Resultado da pergunta 7
Fonte: A Autora (2018)
A pergunta 7 consiste em saber qual o nível de entendimento na visualização do
diagrama de classes “Dados Pessoais”. O resultado foi bem dividido, tendo como interpretação
um entendimento não tão bom.
Figura 26 – Resultado da pergunta 8
Fonte: A Autora (2018)
Já o entendimento do diagrama de classes “Parceiro” foi melhor do que o anterior
“Dados Pessoais”, tendo um resultado mais satisfatório.
Capítulo 4. Resultados 44
Figura 27 – Resultado da pergunta 9
Fonte: A Autora (2018)
O resultado entre os diagramas “Dados Pessoais” e “Parceiro” foi de melhor entendi-
mento para o diagrama que foi refatorado.
Figura 28 – Resultado da pergunta 10
Fonte: A Autora (2018)
A pergunta 10 consiste em saber qual o nível de entendimento ao visualizar o diagrama
de classes “Cadastros IBGE”. O resultado foi idêntico entre os diagramas.
Capítulo 4. Resultados 45
Figura 29 – Resultado da pergunta 11
Fonte: A Autora (2018)
Já as respostas para o nível de entendimento do diagrama de classes “Localidade”, que
é o refatorado, também foi idêntico, tendo o mesmo nível de entendimento para ambos.
Figura 30 – Resultado da pergunta 12
Fonte: A Autora (2018)
O resultado final entre os diagramas “Cadastros IBGE” e “Localidade” foi que o
diagrama refatorado, apesar de terem sido idênticos em resultados nas perguntas 10 e 11, foi
melhor entendido visualmente.
Capítulo 4. Resultados 46
Figura 31 – Resultado da pergunta 13
Fonte: A Autora (2018)
Como resultado final do formulário de questões, é possível visualizar que as refatorações
realizadas foram totalmente compreendidas, sendo capaz de fazer com que os envolvidos no
projeto tenham um maior/melhor entendimento na análise da documentação/modelagem do
sistema SABIA.
47
5 Conclusão
Como explicitado ao longo do trabalho, os desenvolvedores de software passam a
maior parte do tempo modificando e fazendo a manutenção de softwares existentes. Isso ocorre
porque os sistemas e, consequentemente, seu design, estão em perpétuaevolução antes de
serem “abandonados”. Antes de evoluir um sistema, modificações estruturais são frequentemente
necessárias. O objetivo da refatoração é tornar certos elementos mais extensíveis, permitindo
adição de novos recursos e simplificação dos mesmos.
Tal qual destacado pela literatura, os resultados deste estudo demonstraram que as
técnicas comumente empregadas para a realização da refatoração nos modelos do SABIA foram
realmente visíveis. As comparações dos diagramas constataram que com o uso de algumas
técnicas de refatoração, o SABIA é capaz de ser melhor entendido, causando menos confusão
ao tentar entender a lógica que há entre os processos de alocação de equipes e de avaliação.
Além disso, as técnicas utilizadas (Tabela 2, Seção 4.1) possibilitaram boas soluções, capazes de
minimizar os problemas encontrados na Seção 1.1 e Seção 3.1.
A contribuição feita através deste trabalho foi a de promover uma documentação
aprimorada e uma modelagem atualizada sobre o projeto SABIA, excluindo qualquer confusão
que possa acontecer. Além de que, a refatoração promove uma visualização melhor dos modelos.
Entretanto, durante a refatoração dos modelos de software, houve a descontinuação
do projeto novamente. Apesar disso, este trabalho foi finalizado com o intuito de auxiliar aos
futuros desenvolvedores e analistas vinculados ao projeto.
Assim sendo, outros fatores não contemplados neste trabalho são sugeridos como
possíveis soluções ainda melhores. A consideração da refatoração da implementação do código
do SABIA, poderão garantir uma refatoração completa e satisfatória, concluindo um estudo
complexo que abrange desde seus requisitos até suas funcionalidades automatizadas.
48
Referências
BARROS, V. P. A. Um método para a refatoração de software baseado em frameworks de
domínio. Dissertação (B.S. thesis) — Universidade Tecnológica Federal do Paraná, 2015. Citado
na página 24.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. [S.l.]: Elsevier Brasil,
2012. Citado 12 vezes nas páginas 15, 16, 18 e 19.
CASSIOLATO, M. M.; GARCIA, R. C. Pronatec: múltiplos arranjos e ações para ampliar o
acesso à educação profissional. [S.l.], 2014. Citado na página 11.
CORREA, A.; WERNER, C. Applying refactoring techniques to uml/ocl models. In: SPRINGER.
International Conference on the Unified Modeling Language. [S.l.], 2004. p. 173–187. Citado
na página 24.
CUKIER, D. Ddd–introdução a domain driven design. AgileAndArt. jul/ago, 2010. Citado 4
vezes nas páginas 21 e 22.
EVANS, E. Domain-driven design: atacando as complexidades no coração do software. [S.l.]:
Alta Books, 2009. Citado 5 vezes nas páginas 20, 21 e 22.
FOWLER, M. Refatoração: Aperfeiçoamento e Projeto. [S.l.]: Bookman Editora, 2009. Citado
10 vezes nas páginas 22, 23, 30 e 38.
FURGERI, S. Modelagem de Sistemas Orientados a Objetos – Ensino Didático. [S.l.]: Editora
Érica, 2013. Citado na página 23.
GUEDES, G. T. UML 2–Guia Prático - 2 Edição. [S.l.]: Novatec Editora, 2014. Citado 4 vezes
nas páginas 16, 19 e 20.
JUNIOR, J. M. Estudo de métodos e processos de refatoração de banco de dados. 2015. Citado
na página 24.
KOSCIANSKI, A.; SOARES, M. d. S. Qualidade de software. São Paulo, SP. Editora: Novatec,
2007. Citado na página 13.
LIMA, M.; PACHECO, Z. S. Teixeira de A. As políticas públicas e o direito à educação:
programa nacional de acesso ao ensino técnico e emprego versus plano nacional de educação.
Educação & Sociedade, SciELO Brasil, v. 38, n. 139, 2017. Citado na página 11.
LINDEN, R. Algoritmos Genéticos. [S.l.]: Editora Ciência Moderna, 2012. Citado na página 12.
MARINESCU, F.; AVRAM, A. Domain-driven design Quickly. [S.l.]: Lulu.com, 2007. Citado
na página 13.
MOGNON, F. e. a. Uma abordagem para modelagem de software utilizando a OPM para
desenvolvimento iterativo, incremental e ágil. [S.l.]: Dissertação de Mestrado, 2017. Citado na
página 24.
Referências 49
MULLER, N. Framework, o que é e para que serve. Acessado em 3 de ago. 2018, 2014.
Disponível em: <https://www.oficinadanet.com.br/artigo/1294/framework_o_que_e_e_para_
que_serve>. Citado na página 24.
PIVETA, E. K. Improving the search for refactoring opportunities on object-oriented and aspect-
oriented software. 2009. Citado na página 24.
POZZEBOM, R. O que é GitHub. 2015. Disponível em: <https://www.oficinadanet.com.br/post/
14791-o-que-github>. Acesso em: 24 de agosto de 2018. Citado na página 27.
RUMBAUGH, J. Braha, Michael, Modelagem e Projetos Baseados em Objetos com UML. [S.l.]:
Segunda, 2006. Citado na página 15.
SABIA. Sistema de Agrupamento Baseado em Inteligência Arti-
ficial. 2018. Disponível em: <https://docs.google.com/document/d/
1S6BZwCDegCoN5H-jKbG39PCQKsmQN1Bhk0xislP4_kw/edit?usp=sharing>. Acesso em:
24 de agosto de 2018. Citado 6 vezes nas páginas 12 e 27.
SILVA, B. C. da; NUNES, D. J. Refatoração de modelos orientados a aspectos. XII Workshop de
Teses e Dissertações em Engenharia de Software - WTES 2007, 2007. Citado na página 24.
SUNYÉ, G. e. a. Refactoring uml models. International Conference on the Unified Modeling
Language Springer, Berlin, Heidelberg, 2001. Citado na página 23.
TANIGUCHI K., C. F. Metodologia ágeis e a motivação de pessoas em projetos de desenvolvi-
mento de software: Aplicando práticas de scrum e xp para promover a motivação de equipes de
projetos de desenvolvimento de software. Revista de ciências exatas e tecnologia, São Paulo,
2009. Citado na página 12.
VERNON, V. Implementing domain-driven design. [S.l.]: Addison-Wesley, 2016. Citado 2
vezes nas páginas 20 e 22.
https://www.oficinadanet.com.br/artigo/1294/framework_o_que_e_e_para_que_serve
https://www.oficinadanet.com.br/artigo/1294/framework_o_que_e_e_para_que_serve
https://www.oficinadanet.com.br/post/14791-o-que-github
https://www.oficinadanet.com.br/post/14791-o-que-github
https://docs.google.com/document/d/1S6BZwCDegCoN5H-jKbG39PCQKsmQN1Bhk0xislP4_kw/edit?usp=sharing
https://docs.google.com/document/d/1S6BZwCDegCoN5H-jKbG39PCQKsmQN1Bhk0xislP4_kw/edit?usp=sharing
50
APÊNDICE A – Modelo do Sabia
O diagrama de classes “Sabia” foi refatorado para “Avaliação”, ilustrado na Figura 14.
Figura 32 – Diagrama de Classes - Sabia (Inicial)
Fonte: SABIA (2018)
51
APÊNDICE B – Formulário de
Questões
Figura 33 – Questão 1
Fonte: A Autora (2018)
APÊNDICE B. Formulário de Questões 52
Figura 34 – Questão 2
Fonte: A Autora (2018)
Figura 35 – Questão 3
Fonte: A Autora (2018)
APÊNDICE B. Formulário de Questões 53
Figura 36 – Questão 4
Fonte: A Autora (2018)
APÊNDICE B. Formulário de Questões 54
Figura 37 – Questão 5
Fonte: A Autora (2018)
Figura 38 – Questão 6
Fonte: A Autora (2018)
APÊNDICE B. Formulário de Questões 55
Figura 39 – Questão 7
Fonte: A Autora (2018)
APÊNDICE B. Formulário de Questões 56
Figura 40 – Questão 8
Fonte: A Autora (2018)
Figura 41 – Questão 9
Fonte: A Autora (2018)
APÊNDICE B. Formulário de Questões 57
Figura 42 – Questão 10
Fonte: A Autora (2018)
APÊNDICE B. Formulário de Questões 58
Figura 43 – Questão 11
Fonte: A Autora (2018)
Figura 44 – Questão 12
Fonte: A Autora (2018)
Figura 45 – Questão 13
Fonte: A Autora (2018)
	Agradecimentos
	Resumo
	Abstract
	Introdução
	Contextualização e Problema
	Objetivos
	Objetivo Geral
	Objetivos Específicos
	Motivação e Justificativa de Estudo
	Fundamentação Teórica
	Modelagem de Software com Unified Modeling Language (UML)
	Diagramas da UML
	Diagrama de Classe
	Diagrama de Casos de Uso
	Domain-Driven Design (DDD)
	Refatoração
	Trabalhos Relacionados
	Metodologia
	Regras de Negócio do SABIA
	Arquitetura do Trabalho
	Resultados
	Modelagem Inicial Versus Refatorada
	Questionário Avaliativo
	Conclusão
	Referências
	Modelo do Sabia
	Formulário de Questões