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

(1)

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

(2)

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

(3)

(4)

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.

(5)

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.

(6)

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.

(7)

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 32 – Diagrama de Classes - Sabia (Inicial) . . . 50

Figura 33 – Questão 1 . . . 51

(8)

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

(9)

LISTA DE TABELAS

Tabela 1 – Diagramas, verificação e refatoração . . . 14

Tabela 2 – Utilização das Técnicas de Refatoração . . . 30

(10)

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

(11)

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

(12)

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

(13)

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ência Computacional 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

(14)

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ção1.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 comKoscianski e Soares(2007), o critério de refatoração é realizado quando uma nova funcionalidade é adicionada para encontrar e corrigir defeitos (imperfeições de um

(15)

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 Tabela1lista 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.

(16)

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 possibilidade de 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

(17)

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, diadia-grama de estados, diadia-grama de atividades, diadia-grama 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).

SegundoBooch, 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 Figura1mostra uma classe contendo atributos e operações:

(18)

Figura 1 – Exemplo de Classe

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 Figura2:

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 Figura3

é possível representar os atributos:

Figura 3 – Atributos

(19)

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 Figura3, 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

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

(20)

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 Figura5, 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 Figura5, 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 segundoGuedes (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 Figura6, exemplifica o ator e caso de uso:

Figura 6 – Ator e Caso de Uso

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

(21)

que seja diferenciado dos demais. O nome pode ser “nome simples” ou “nome de caminho” (GUEDES,2014). Na Figura7, os tipos de nomes são ilustrados:

Figura 7 – Tipos de Nomes

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

(22)

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 Figura8, a arquitetura do DDD é representada:

Figura 8 – Arquitetura em Camadas do DDD

(23)

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 comCukier(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

SegundoFowler(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

(24)

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 queFowler(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 comFurgeri

(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 possui um 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 porFowler(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.

(25)

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 deSilva 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 deJunior(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.

(26)

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.

(27)

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á descrito

(28)

Capí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 (Figura9). 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.

(29)

Figura 9 – Ilustração da Proposta do Trabalho

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 Figura9, 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ção3.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ção3.1). A formação de equipes se dá, simplificadamente, da seguinte forma ilustrada na Figura10.

(30)

Figura 10 – Processo de Montagem das Equipes de Avaliadores

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 Figura10é 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 Tabela1(Seção1.3) ilustra o que é verificado e quais são as modificações.

(31)

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 porFowler(2009), a Tabela2lista 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

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:

(32)

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.

(33)

Figura 12 – Diagrama de Casos de Uso (Refatorado)

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.

(34)

Figura 13 – Uma parte do Diagrama de Classes - Sabia (Inicial)

Fonte: SABIA (2018)

Na Figura13pode 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êndiceA.

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.

(35)

Figura 14 – Diagrama de Classes - Avaliação (Refatorado)

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”.

(36)

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

(37)

Figura 16 – Diagrama de Classes - Localidade (Refatorado)

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

(38)

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 Figura18.

(39)

Figura 18 – Diagrama de Classes - Parceiro (Refatorado)

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ção4.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 Tabela3, ilustrada a seguir, os resultados foram listados.

(40)

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;

Como melhor forma de validar os resultados, foi feito um formulário de questões (ApêndiceBe seus resultados4.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.

(41)

Figura 19 – Resultado da pergunta 1

Na primeira pergunta, seu resultado foi empate. O diagrama em questão era o diagrama de casos de uso antes de ser refatorado.

Na segunda pergunta, seu resultado foi bem satisfatório. O diagrama de casos de uso refatorado teve um nível maior de entendimento.

(42)

Como já ilustrado, o diagrama de casos de uso que obteve melhor compreensão perante visualização, foi o refatorado.

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.

(43)

Já o resultado da refatoração do diagrama de classes “Avaliação” mostrou que a maioria das respostas foram para um ótimo entendimento.

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.

(44)

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.

Já o entendimento do diagrama de classes “Parceiro” foi melhor do que o anterior “Dados Pessoais”, tendo um resultado mais satisfatório.

(45)

O resultado entre os diagramas “Dados Pessoais” e “Parceiro” foi de melhor entendi-mento para o diagrama que foi refatorado.

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.

(46)

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.

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.

(47)

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.

(48)

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étua evoluçã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 (Tabela2, Seção4.1) possibilitaram boas soluções, capazes de minimizar os problemas encontrados na Seção1.1e Seção3.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.

(49)

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ágina24.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. [S.l.]: Elsevier Brasil, 2012. Citado 12 vezes nas páginas15,16,18e19.

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ágina11.

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ágina24.

CUKIER, D. Ddd–introdução a domain driven design. AgileAndArt. jul/ago, 2010. Citado 4 vezes nas páginas21e22.

EVANS, E. Domain-driven design: atacando as complexidades no coração do software. [S.l.]: Alta Books, 2009. Citado 5 vezes nas páginas20,21e22.

FOWLER, M. Refatoração: Aperfeiçoamento e Projeto. [S.l.]: Bookman Editora, 2009. Citado 10 vezes nas páginas22,23,30e38.

FURGERI, S. Modelagem de Sistemas Orientados a Objetos – Ensino Didático. [S.l.]: Editora Érica, 2013. Citado na página23.

GUEDES, G. T. UML 2–Guia Prático - 2 Edição. [S.l.]: Novatec Editora, 2014. Citado 4 vezes nas páginas16,19e20.

JUNIOR, J. M. Estudo de métodos e processos de refatoração de banco de dados. 2015. Citado na página24.

KOSCIANSKI, A.; SOARES, M. d. S. Qualidade de software. São Paulo, SP. Editora: Novatec, 2007. Citado na página13.

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ágina11.

LINDEN, R. Algoritmos Genéticos. [S.l.]: Editora Ciência Moderna, 2012. Citado na página12. MARINESCU, F.; AVRAM, A. Domain-driven design Quickly. [S.l.]: Lulu.com, 2007. Citado na página13.

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ágina24.

(50)

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ágina24.

PIVETA, E. K. Improving the search for refactoring opportunities on object-oriented and aspect-oriented software. 2009. Citado na página24.

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ágina27.

RUMBAUGH, J. Braha, Michael, Modelagem e Projetos Baseados em Objetos com UML. [S.l.]: Segunda, 2006. Citado na página15.

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áginas12e27.

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ágina24. SUNYÉ, G. e. a. Refactoring uml models. International Conference on the Unified Modeling Language Springer, Berlin, Heidelberg, 2001. Citado na página23.

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ágina12.

VERNON, V. Implementing domain-driven design. [S.l.]: Addison-Wesley, 2016. Citado 2 vezes nas páginas20e22.

(51)

50

APÊNDICE A – Modelo do Sabia

O diagrama de classes “Sabia” foi refatorado para “Avaliação”, ilustrado na Figura14. Figura 32 – Diagrama de Classes - Sabia (Inicial)

(52)

51

APÊNDICE B – Formulário de

Questões

Figura 33 – Questão 1

(53)

APÊNDICE B. Formulário de Questões 52

(54)

(55)

(56)

(57)

(58)

(59)

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)