Null

CENTRO UNIVERSITÁRIO DA FEI
ANDREY ARAUJO MASIERO

FAGNER CRISTIANO DONADON
GUILHERME ALBERTO WACHS LOPES
MATHEUS HENRIQUE PEREIRA GONÇALVES
TOM MIX MARTINI PETRECA
SIGEPAPP: PATTERNS E ANTI-PATTERNS ASSOCIADOS À

PERSONAS
São Bernardo do Campo

2009
SIGEPAPP: PATTERNS E ANTI-PATTERNS ASSOCIADOS À

PERSONAS
Trabalho de Conclusão de curso, apresentado no

Centro Universitário da FEI, como parte dos
requisitos necessários para obtenção do título de
Bacharel em Ciências da Computação, orientado
pelo professor Dr. Plínio T. Aquino Junior.
São Bernardo do Campo

2009
SiGePAPP: Patterns E Anti-Patterns Associados À Personas
Trabalho de Conclusão de Curso – Centro Universitário da FEI.
Comissão julgadora
_________________________________
Orientador e Presidente
_________________________________
Examinador (1)
_________________________________
Examinador (2)
SÃO BERNARDO DO CAMPO

25 de Junho de 2009
ii
AGRADECIMENTOS
A Deus, por nos ter dado força e coragem para enfrentar os problemas durante este
trabalho.
Aos nossos pais, por nos acompanhar pacientemente, entender os obstáculos por nós
superados durante todo o curso e ensinar que a desistência não é uma opção.
Ao nosso orientador Prof o. Dr o. Plinio Thomaz Aquino Junior pela amizade, pelo
incentivo e por acreditar em nosso potencial.
Aos nossos mestres pela paciência nas aulas ministradas e todo o conhecimento
passado.
Aos colegas que vivenciaram esta luta em conjunto.
iii
RESUMO
Este projeto tem por objetivo trabalhar uma técnica de apoio ao desenvolvedor de
software. Ela utiliza três conceitos já existentes no mercado: Patterns, Anti-Patterns e
Personas – documentações denominadas neste trabalho como APPP. Embora os três
conceitos citados já sejam conhecidos e aplicados por profissionais da área, a técnica
explorada por este trabalho destaca o relacionamento entre elas, ou seja, a agregação dos
benefícios de cada conceito em prol de outro. A técnica visa atender os desenvolvedores
através da documentação de boas e más práticas no desenvolvimento de software. Por meio da
documentação de problemas e soluções recorrentes, minimiza-se o tempo de esforço
empregado em um problema já resolvido. É de conhecimento comum que soluções diversas,
bem como boas e más práticas podem ser apropriadamente documentadas – tal como é feito
atualmente por meio de Patterns e Anti-Patterns – porém, por meio desta técnica a
documentação poderá ainda ser orientada a um ou mais perfis de usuários: as Personas.
Visando sustentar a viabilidade e eficácia desta proposta, o trabalho apresenta uma ferramenta
que possibilita aos projetistas e desenvolvedores gerirem todo o processo de criação,
armazenamento, pesquisa, aplicação e validação das estruturas APPP e seus respectivos
relacionamentos. A ferramenta poderá ainda, no futuro, ser adaptada para receber as estruturas
APPP automaticamente, por exemplo, através de técnicas de inteligência artificial visando
uma melhor autonomia na disponibilização de recursos para um bom desenvolvimento de
software.
Palavras Chaves: Patterns, Anti-Patterns, Personas, Picaps, Relacionamento.
iv
ABSTRACT
This project intends to work a technique in order to support software developers. It

uses three concepts already existing in the market: Patterns, Anti-Patterns and Personas -
documentations called in this work as APPP. While the three mentioned concepts are already
known and even implemented by professionals in the area, the technique used by this work
highlights the relationship between them, an aggregation of the benefits of each concept in
favor of another one. The technique aims to support the developers through the
documentation of good and bad practices in software development. Through the
documentation of recurring problems and solutions, it is possible to minimize the time spent
on already resolved issues. It is common knowledge that many solutions as well as good and
bad practices can be properly documented - as it‟s currently done through Patterns and Anti-
Patterns - however, this technique, through the documentation, may be directed to one or
more user profiles: Personas. Seeking to sustain the viability and effectiveness of this
proposal, the work also presents a tool that enables designers and developers to manage the
whole process of creation, storage, research, application and validation of APPP structures
and the relationships among them. In the future, the tool can also be adapted to receive the
structures APPP automatically, for example, through techniques of artificial intelligence for a
better autonomy in the provision of resources for a good software development.
Key-words: Patterns, Anti-Patterns, Personas, Picaps, Relationship.
v
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................... 12
1.1 Objetivo .......................................................................................................................... 13
2 TRABALHOS RELACIONADOS ................................................................................ 14
3 CONCEITOS FUNDAMENTAIS ................................................................................. 17
3.1 Patterns ou Padrões ....................................................................................................... 17
3.1.1 Origem ......................................................................................................................... 17
3.1.2 Definição ...................................................................................................................... 18
3.1.3 Criação de Patterns ..................................................................................................... 20
3.1.4 Linguagem de Patterns ............................................................................................... 20
3.2 Anti-Patterns ................................................................................................................... 22
3.2.1 Definição ...................................................................................................................... 22
3.2.2 Formato ....................................................................................................................... 22
3.2.3 Criação de Anti-Patterns ............................................................................................ 23
3.3 Personagens Fictícios ou Personas ............................................................................... 24
3.3.1 Definição ...................................................................................................................... 24
3.3.2 O processo de criação ................................................................................................. 24
3.4 Busca por Similaridade ................................................................................................. 27
3.4.1 Definição ...................................................................................................................... 28
3.4.2 Similaridade local ....................................................................................................... 28
3.4.3 Similaridade Global.................................................................................................... 29
4 METODOLOGIA ........................................................................................................... 30
4.1 Entrada / Início .............................................................................................................. 32
4.2 Definição da Estrutura .................................................................................................. 32
4.3 Inserção de APPP no SiGePAPP .................................................................................. 33
4.4 Relacionamento entre APPP......................................................................................... 34
4.4.1 PICAPs – Relacionamento entre Patterns e Personas ............................................. 34
4.4.2 Anti-PICAPs – Relacionamento entre Anti-Patterns e Personas ............................ 34
4.4.3 Relacionamento entre Anti-Patterns e Patterns ........................................................ 34
4.4.4 APPP – Relacionamento entre Anti-Pattern, Pattern e Personas. ........................... 35
4.5 Utilização ........................................................................................................................ 35
4.6 Avaliação ........................................................................................................................ 36
vi
4.7 Análise da Avaliação / Ações de Bloqueio ................................................................... 36
4.7.1 Cálculo da média: ....................................................................................................... 37
4.7.2 Análise do resultado: .................................................................................................. 37
4.8 Processo da Busca por Similaridade ............................................................................ 37
4.8.1 O algoritmo ................................................................................................................. 38
4.8.2 Melhoria de Desempenho........................................................................................... 44
5 MODELAGEM ............................................................................................................... 46
5.1 Requisitos ....................................................................................................................... 46
5.1.1 Requisitos Funcionais ................................................................................................. 46
5.1.2 Não Funcionais............................................................................................................ 49
5.2 Diagramas de Caso de Uso............................................................................................ 50
5.2.1 Caso de Uso: Login ..................................................................................................... 50
5.2.2 Caso de Uso: Cadastro ............................................................................................... 50
5.2.3 Caso de Uso: Consulta................................................................................................ 51
5.2.4 Caso de Uso: Relacionamento ................................................................................... 52
5.2.5 Caso de Uso: Avaliação .............................................................................................. 53
5.3 Diagrama de Classe ....................................................................................................... 54
5.3.1 Classe Usuário ............................................................................................................. 56
5.3.2 Classe Login ................................................................................................................ 56
5.3.3 Classe Estrutura ......................................................................................................... 56
5.3.4 Classe Objeto .............................................................................................................. 57
5.3.5 Classe Pattern .............................................................................................................. 57
5.3.6 Classe Anti-Pattern...................................................................................................... 58
5.3.7 Classe Persona ............................................................................................................. 58
5.3.8 Classe Atributo ........................................................................................................... 59
5.3.9 Classe RelacObjetos ................................................................................................... 59
5.4 Diagramas de Seqüência ............................................................................................... 60
5.4.1 Login ............................................................................................................................ 60
5.4.2 Cadastro de Usuário ................................................................................................... 60
5.4.3 Cadastro de Estrutura ............................................................................................... 61
5.4.4 Cadastro de Atributos ................................................................................................ 62
5.4.5 Cadastro de Tipos ....................................................................................................... 63
5.4.6 Cadastro de documento: Pattern ............................................................................... 64
5.4.7 Cadastro de documento: Anti-Pattern ...................................................................... 65
vii
5.4.8 Cadastro de documento: Persona.............................................................................. 66
5.4.9 Cadastro de documento: APPP Personalizado ......................................................... 66
5.4.10 Relacionamento ........................................................................................................... 67
5.4.11 Busca ............................................................................................................................ 68
5.4.12 Avaliação ..................................................................................................................... 68
5.4.13 Ações de Bloqueio ....................................................................................................... 69
5.5 banco de dados ............................................................................................................... 71
5.5.1 Modelo Entidade Relacionamento ............................................................................ 71
5.6 Tecnologias utilizadas ................................................................................................... 73
5.6.1 Oracle........................................................................................................................... 73
5.6.2 Java – JSP ................................................................................................................... 73
6 AVALIAÇÃO DO SISTEMA ........................................................................................ 74
6.1 Avaliação da Interface .................................................................................................. 74
6.1.1 Avaliação Heurística .................................................................................................. 74
6.1.2 Testes com o Usuário baseado em Personas ............................................................. 75
6.1.3 Metodologia de Teste .................................................................................................. 76
6.2 Resultados ...................................................................................................................... 78
6.2.1 Usuários por meio das Personas ................................................................................ 78
6.2.2 Conclusão dos testes com Usuários ........................................................................... 81
6.2.3 Melhorias no sistema com o resultado dos testes com Usuários............................. 81
6.2.4 Heurísticas ................................................................................................................... 82
6.2.5 Conclusão dos testes Heurísticos ............................................................................... 83
7 RESULTADOS OBTIDOS ............................................................................................ 85
8 CONCLUSÃO ................................................................................................................. 86
9 TRABALHOS FUTUROS ............................................................................................. 87
REFERÊNCIAS ..................................................................................................................... 88
ANEXO I – TELAS PRINCIPAIS ........................................................................................ 91
viii
LISTA DE FIGURAS
Figura 1. Grafo da relação entre os padrões Fonte: (GERBER, 1999) .................................... 21
Figura 2. Diagrama de processo para criação de um Anti-Patterns Fonte: Os Autores ........... 23
Figura 3. Metodologia do SiGePAPP Fonte: os autores. ......................................................... 31
Figura 4. Exemplo de PICAP. Fonte: (AQUINO JR., 2008) ................................................... 35
Figura 5. Similaridade Letra a Letra Fonte: Os autores ........................................................... 38
Figura 6. Exemplo Fonte: Os autores ....................................................................................... 39
Figura 7. Quantidade de palavras Fonte: Os autores. ............................................................... 40
Figura 8. Vetor A Fonte: Os autores ........................................................................................ 40
Figura 9. Vetor B Fonte: Os autores ......................................................................................... 41
Figura 10. Ciclo de Busca Fonte: Os autores ........................................................................... 42
Figura 11. Algoritmo Fonte: Os autores ................................................................................... 43
Figura 12. Matriz B, obtida a partir da varredura no Vetor B. Fonte: Os autores .................... 44
Figura 13. Texto 01 vs Texto 02 vs tempo(seg) ....................................................................... 45
Figura 14. Diagrama de Caso de Uso: Login Fonte: os autores. .............................................. 50
Figura 15. Diagrama de Caso de Uso: Cadastro Fonte: os autores. ......................................... 51
Figura 16. Diagrama de Caso de Uso: Consulta Fonte: os autores. ......................................... 52
Figura 17. Diagrama de Caso de Uso: Relacionamento Fonte: os autores............................... 52
Figura 18. Diagrama de Caso de Uso: Avaliação Fonte: os autores ........................................ 53
Figura 19. Digrama de Classes SiGePAPP Fonte: os autores .................................................. 55
Figura 20. Diagrama de Seqüencia: Login Fonte: os autores. .................................................. 60
Figura 21. Diagrama de Seqüência: Cadastro de Usuário Fonte: os autores. ........................... 61
Figura 22. Diagrama de Seqüência: Cadastro de Estrutura Fonte: os autores. ......................... 62
Figura 23. Diagrama de Seqüência: Cadastro de Atributos ..................................................... 63
Figura 24. Diagrama de Seqüência: Cadastro de Tipos ........................................................... 64
Figura 25. Diagrama de Seqüência: Cadastro de documento Pattern Fonte: os autores. ........ 65
Figura 26. Diagrama de Seqüência: Cadastro de documento Anti-Pattern .............................. 65
Figura 27. Diagrama de Seqüência: Cadastro de documento Persona .................................... 66
Figura 28. Diagrama de Seqüência: Cadastro de documento APPP Personalizado ................. 67
Figura 29. Diagrama de Seqüência: Relacionamento Fonte: os autores. ................................. 67
Figura 30. Diagrama de Seqüência: Busca Fonte: os autores. ................................................. 68
Figura 31. Diagrama de Seqüência: Avaliação Fonte: Os autores. .......................................... 69
Figura 32. Diagrama de Seqüência: Ações de Bloqueio Fonte: os autores. ............................. 70
ix
Figura 33. Modelo Entidade Relacionamento .......................................................................... 72
Figura 34. Média de Notas da Avaliação no Teste de Usuário. Fonte os Autores. .................. 79
Figura 35. Erro Heurística 1 e 2 ............................................................................................... 82
Figura 38. Tela: Inicial ............................................................................................................. 91
Figura 39. Tela: Cadastro de Usuário ....................................................................................... 92
Figura 40. Tela: Cadastro de Estrutura ..................................................................................... 93
Figura 41. Tela: Cadastro de Conteúdo .................................................................................... 94
Figura 42. Tela: Busca APPP ................................................................................................... 95
Figura 43. Tela: Resultado da Busca ........................................................................................ 95
x
LISTA DE TABELAS
Tabela 1. Atributos fundamentais de um Pattern (GAMMA, et al., 1995) .............................. 18
Tabela 2. Modelo de atributos opcionais para Pattern(GAMMA, et al., 1995) ....................... 19
Tabela 3. Exemplo de Pattern .................................................................................................. 19
Tabela 4. Atributos fundamentais de um Anti-Pattern ............................................................. 22
Tabela 5. Tabela de exemplos de Personas .............................................................................. 26
Tabela 6. Classificação de Grau de Severidade ........................................................................ 75
Tabela 7. Usuários .................................................................................................................... 76
Tabela 8. Lista de Tarefas......................................................................................................... 77
Tabela 9. Questionário .............................................................................................................. 78
Tabela 10. Melhorias reportadas pelos Usuários ...................................................................... 81
xi
1 INTRODUÇÃO
Nos dias atuais existem softwares controlando boa parte de tudo que nos cerca, desde
um aparelho eletrônico até as grandes corporações. A qualidade do desenvolvimento de um
software tornou-se algo fundamental para o sucesso do produto e, de forma significativa, vê-
se intensificar esse quadro nos últimos anos. A demanda por sistemas desenvolvidos de forma
mais rápida, o inevitável aumento da dependência das empresas de softwares que atendam aos
seus negócios e a enorme diversidade de perfis de usuários acabam impactando diretamente a
maneira como os sistemas computacionais são planejados, desenvolvidos e finalmente
implementados. Por outro lado, o dinamismo, a necessidade de processamento, transformação
de informações e a flexibilidade do mercado pressionam os desenvolvedores de tal forma que
o tempo entre a solicitação do software e sua entrega final tem sido significativamente
minimizado. Como conseqüência, a relação custo, qualidade e prazo têm sido seriamente
desafiados e/ou comprometidos. Soma-se ainda a este quadro o crescimento exponencial de
usuários com seus mais variados perfis, características e conhecimentos, trazendo com eles a
natural necessidade de que os sistemas envolvidos atendam de alguma forma as
particularidades de cada perfil. Assim, os desenvolvedores carecem cada vez mais de técnicas
e recursos que efetivamente os auxiliem a maximizar o tempo, minimizar o retrabalho e
atender às crescentes necessidades de seus clientes. Tudo isso sem comprometer a qualidade
do produto final.
Esse equilíbrio exigido pelo mercado – custo, qualidade e prazo – faz com que a
criação, compartilhamento e a gerência adequada de documentos se tornem ainda mais
necessários.
Muitos são os itens a serem documentados: boas e más práticas, perfis de usuários,
problemas e também possíveis soluções. Todas essas informações, quando disponíveis de
forma padronizada e completa, auxiliam os desenvolvedores a, por exemplo, entenderem a
maneira como um determinando componente foi desenvolvido, qual a melhor prática para
resolução de um determinado problema e como essas soluções podem ser aplicadas a perfis
específicos de usuários. Atualmente, os conceitos de Patterns e Anti-Patterns atendem
parcialmente estas necessidades relacionadas ao desenvolvimento de software.
Em (AQUINO JR., 2008) o autor descreve os Patterns, ou Padrões, como soluções de
problemas que se repetem em diferentes contextos. Ele esclarece que a idéia de padrões é
capturar conhecimento do bom projeto e documentá-lo de forma que possa ser compartilhado
pela comunidade.
12
Por outro lado os Anti-Patterns descrevem soluções ineficientes ou que resultam em
conseqüências negativas (KOTZÉ, et al., 2006).
Essas duas estruturas – Patterns e Anti-Patterns – são ótimas técnicas de
documentação durante o desenvolvimento de software, contudo poucas levam em
consideração o perfil do usuário final e suas mais diversas características. Tal deficiência
pode ser resolvida através da técnica de Personas.
De acordo com (COOPER, 1999) as Personas são um conjunto de informações
realísticas e representativas que incluem detalhes fictícios para caracterização mais completa
de um grupo de usuários. Isso possibilita o planejamento do sistema focando um pequeno
conjunto de perfis, porém atendendo uma grande quantidade de usuários e suas respectivas
características (AQUINO JR., 2008).
1.1 Objetivo
Este trabalho explora e relaciona os conceitos de Anti-Patterns, Patterns e Personas
(APPP) promovendo uma técnica para apoio ao desenvolvimento de software. Também
apresenta uma ferramenta, intitulada SiGePAPP (Sistema de Gerenciamento de Patterns,
Anti-Patterns e Personas), que possibilita o compartilhamento, busca e gerenciamento das
documentações.
13
2 TRABALHOS RELACIONADOS
Os conceitos relacionados a este projeto de formatura são utilizados em diversos

documentos, artigos e ferramentas existentes. Foram pesquisados trabalhos relacionados ao
tema proposto, bem como publicações que possam embasar o uso das técnicas citadas.
Dentre esta busca, destaca-se o trabalho chamado SAMOA (SILVA, et al., 2004), que
descreve um assistente automatizado para detecção de padrões em Diagramas UML, na WEB.
O grupo defende a idéia de que a tarefa de encontrar padrões em um projeto de software
qualquer se caracteriza por ser extremamente tediosa para o engenheiro de software, pois,
segundo eles, requer encontrar todas as realizações possíveis desses padrões. Explica também
que a busca por estes padrões força os profissionais a analisar todos os diagramas existentes
no projeto, e em seguida, aplicar regras para aprimorá-las.
O SAMOA proporciona justamente a facilidade da automação desta tarefa, viabilizando o
trabalho dos desenvolvedores. Este sistema pode receber dois tipos de entradas: a primeira é
um diagrama de classes UML exportado no formato XMI e a segunda, o código fonte para
realizar o processo de engenharia reversa (SILVA, et al., 2004). O sistema trabalha numa
interação com o profissional de software e propõe criticas a padrões específicos, sugerindo
melhorias baseadas em regras pré-definidas, como por exemplo (SILVA, et al., 2004):
 Nome para as classes: o nome de um factory method no padrão Factory Method deverá ter o
sufixo Factory.
 Escopo para operações: Métodos hook no padrão Template Method devem ser declarados
como protected.
A ferramenta proposta por este grupo poderá ser utilizada em conjunto com este
projeto de formatura. Uma vez que ele objetiva justamente a análise de um padrão, o conteúdo
do SiGePAPP (Sistema de Gerenciamento de Patterns, Anti-Patterns e Personas) pode servir
como fonte para o SAMOA. Embora este projeto apresente uma avaliação prévia das
estruturas APPP, não se pretende gerar críticas ou sugerir melhorias como o faz o SAMOA.
Devido à necessidade de facilitar a busca e aplicação de padrões, (MARINHO, et al., 2003)
desenvolveram um repositório de padrões de software. Este repositório possui a característica
de integrar o modelo de processo de desenvolvimento de software - RUP (Rational Unified
Process), tendo como objetivo oferecer um conjunto amplo e abrangente de padrões, de forma
que possa ser consultado e utilizado durante as diversas fases de desenvolvimento. O
repositório, portanto, tem a tarefa de catalogar os padrões que servirão de entrada para o RUP
e contém significativas semelhanças com este projeto de formatura, contudo, não apresenta
nenhuma relação com Anti-Patterns e/ou soluções voltadas para perfis de usuários.
14
Este repositório proposto é referenciado em outro trabalho chamado IIMPaR, “Uma
Interface de Integração de Modelos de Padrões de Software para o Rose” (ANDRADE, et al.,
2005).
O IIMPaR é uma ferramenta que tem por finalidade reutilizar modelos de padrões a
partir de um formato aberto, construindo para a ferramenta Rational Rose uma biblioteca de
padrões que podem ser aplicados automaticamente. O grupo lembra que o Rose é uma
ferramenta de modelagem de software, baseada na linguagem UML, que tem sido usada com
sucesso, tanto no meio acadêmico quanto no comercial. O IIMPaR apresenta uma interface de
integração para o Rose, de forma a viabilizar a utilização de modelos de padrões no ambiente
de modelagem do próprio Rose. A referência do IIMPaR com o repositório apresentado
anteriormente vem justamente do fato de que os modelos de padrões utilizados por esta
interface, podem estar armazenados em qualquer repositório, evidenciando a eficácia de uma
base apropriadamente catalogada de padrões de software.
A ferramenta proposta neste projeto de formatura embora mais detalhada em termos
de conteúdo e relacionamento com outras estruturas, como as Personas, poderá também servir
de fonte e proporcionar um ambiente completo para o armazenamento, busca e aplicação
desses padrões, trabalhando em conjunto com o IIMPaR.
A utilização dos Patterns pode ir além dos domínios da programação em
computadores ou até mesmo da Engenharia de Software propriamente dita. A implantação de
suas recomendações contribui beneficamente para o sucesso de qualquer trabalho, mostrando
que a utilização dessa documentação como conceito – e não meramente algo inerente à
computação – pode sim ser considerada em todos os contextos onde as boas práticas e
soluções são compartilhadas e a experiência valorizada. Um trabalho que evidencia o
parágrafo anterior é o Cognitor (ANACLETO, et al., 2007). No trabalho propõem-se a
utilização de padrões, contudo, aplicando-os à melhoria no desenvolvimento de materiais de
aprendizagem para Educação à Longa Distância (EAD). O Cognitor é um framework baseado
na Linguagem de Padrões Cog-Learn. O trabalho contextualiza a idéia de que projetar
material de aprendizagem estruturado na forma de objetos de aprendizagem para Educação à
Distância (EAD), em ambiente Web, é uma tarefa difícil para os professores – especialmente
aqueles com pouca experiência em projeto de atividades de aprendizagem num ambiente
computacional – além de exigir tempo e recursos muitas vezes não disponíveis. Os padrões
criados pela equipe têm como finalidade gerar um vocabulário comum que possa ser utilizado
por diversos participantes (ANACLETO, et al., 2007). O artigo divulgado pela equipe explica
15
que esses padrões são documentados em uma Linguagem de Padrões (LP) chamada Cog-
Learn, que são, por sua vez, instanciados na ferramenta Cognitor que funciona como um
framework para facilitar a utilização pelos professores – nesta ferramenta, os professores são
auxiliados em suas tarefas de projetar e editar o material de aprendizagem.
Em contra partida, a diversificação de usuários quando não considerada, altera a
eficácia na implantação de uma determinada solução. Em (COSTA, et al., 2008) foi
desenvolvido um trabalho nomeado DEAN que, através de pesquisas de campo e utilização
do algoritmo K-Means para mineração de dados, compõe personagens fictícios - Personas.
Embora esta ferramenta crie as Personas, ela não faz nenhuma relação com Patterns e/ou
Anti-Patterns.
Em (AQUINO JR., 2008), foi desenvolvido um trabalho chamado “PICaP: Padrões e
Personas para expressão da diversidade de usuários no Projeto de Interação”. A técnica criada
por ele – as PICaPs – é a junção de um Pattern a uma ou mais Personas. O autor explica que
a falta de conhecimento de quem são os usuários, por parte daqueles que desenvolvem o
software, é tão grave quanto à ausência de boas práticas no decorrer do desenvolvimento. No
entanto, as PICaPs não abrangem o conceito de Anti-Patterns.
16
3 CONCEITOS FUNDAMENTAIS
Nesta sessão, são apresentados os conceitos de Patterns, Anti-Patterns, Personas e

Raciocínio Baseado em Caso, que são utilizados na composição da metodologia apresentada
na sessão 4 deste projeto de formatura.
3.1 Patterns ou Padrões

O processo de desenvolvimento de software apresenta problemas, dúvidas e desafios,
muitas vezes reincidentes, cuja resolução já foi encontrada. Através dessa recorrência de
problemas, soluções e melhores práticas surgem os Patterns, uma documentação que emerge
através da experiência de diversos profissionais e que pode ser compartilhada e recomendada
a fim de se produzir software com resultado previsível, menor custo, minimização de
retrabalho, ganhos de produtividade, desempenho e escalabilidade (GAMMA, et al., 1995).
Em (AQUINO JR., 2008), o autor esclarece que um padrão deve conter uma solução
comprovada para um problema recorrente de projeto cujo formato seja genérico, fácil de
entender e legível. Os padrões devem prover soluções genéricas, documentadas em um
formato tal que não seja necessariamente amarrado a um problema particular. É importante
considerar que, da mesma forma, um padrão não é uma modelagem ou um componente
pronto de forma a viabilizar a codificação final.
Os padrões são de extrema importância no caso de profissionais com pouca
experiência. A documentação pode ser utilizada como uma leitura geral, ajudando o
profissional na composição de idéias, resolução de problemas específicos, contribuindo em
projetos de sistemas de forma a viabilizar e enriquecer a comunicação e discussão entre os
desenvolvedores (AQUINO JR., 2008).
Neste projeto de formatura, os Padrões são comumente referenciados conforme a
língua inglesa: Patterns. É de conhecimento geral que a palavra Padrão pode ser traduzida,
compreendida e/ou aplicada de diversas maneiras. Dentre elas, destaca-se o uso da palavra
Standard, representando normas ou regras que devem ser seguidas com precisão
(WEHMEIER, 2000). Portanto, idéias ou conceitos provenientes das diversas traduções
existentes para Padrões – como o abordado por Standards - não serão utilizadas.
3.1.1 Origem
Os Patterns foram inicialmente definidos como aplicação do conhecimento ao
trabalho (TAYLOR, 1911). Em 1977, um arquiteto chamado Christopher Alexander
17
(ALEXANDER, 1977) percebeu que, com o passar do tempo, seu trabalho resumia-se a
resolver problemas que de alguma forma já haviam sido tratados em algum momento.
Alexander percebeu que os problemas eram relativamente parecidos e que, em muitos casos, a
solução era genérica e que poderia, sem muitas dificuldades, ser aplicada a diversos
problemas específicos em seus mais variados contextos. A partir da disponibilização dessas
soluções, um arquiteto sem experiência poderia alcançar um excelente resultado por meio da
implementação dessas regras de projeto, compartilhando um conjunto de padrões de forma
que possa ser utilizado pela comunidade em geral.
O conceito de Pattern definido por Alexander tem, como referência, portanto,
problemas e soluções relacionadas com a construção civil. Contudo, este conceito pode ser
aplicado em quaisquer áreas de trabalho, inclusive em computação.
3.1.2 Definição
Christopher Alexander definiu um padrão como: “Cada Pattern descreve um
problema que ocorre várias e várias vezes em nosso meio, descrevendo, portanto, a solução
para este problema, de tal forma que possa ser utilizada milhares de vezes, sem que haja o
retrabalho desta.”(ALEXANDER, 1977).
Embora a aplicação prática de um Pattern seja um processo relativamente claro e
simples, a definição exata de sua estrutura não é algo único. Existem diversas estruturas que
contém atributos diferentes que podem ser atribuídos.
Em (GAMMA, et al., 1995) os autores explicam que, embora notações gráficas sejam
importantes e úteis, elas por si só não são suficientes para se documentar um padrão. Essas
notações simplesmente capturam o produto final do processo de modelagem, seus
relacionamentos entre as classes e objetos. Para que uma solução possa ser reutilizada torna-
se também necessário documentar decisões, alternativas e até mesmo exemplificar com casos
concretos.
Um Pattern possui basicamente quatro atributos fundamentais. A Tabela 1 apresenta
estes atributos:
Tabela 1. Atributos fundamentais de um Pattern (GAMMA, et al., 1995)
Nome  O nome de um Pattern deve representá-lo de maneira abrangente.

Contexto  Descrição da situação onde ocorre o problema.
Problema  Descreve o problema propriamente dito.
Solução  Descreve os elementos que compõem sua solução.
18
 Nunca deve ser descrito uma solução específica, como por exemplo, um
código que implementa um algoritmo. A solução é como um modelo que
deve ser aplicado a qualquer projeto.
Além dos atributos fundamentais ainda podem ser inseridos diversos outros atributos
que ajudem a compreender melhor o padrão descrito. Gamma (GAMMA, et al., 1995) cita
ainda outros atributos opcionais que podem compor um padrão. A Tabela 2 apresenta alguns
destes atributos.
Tabela 2. Modelo de atributos opcionais para Pattern(GAMMA, et al., 1995)
Conseqüências  Descrevem quais são as vantagens, os resultados esperados na utilização

deste Pattern.
 Uma declaração curta que responda as seguintes perguntas: O que
Intento exatamente esse Pattern faz? Qual é seu racional e objetivo/intento? Qual
problema ou prática especificamente ele trata?
Também conhecido  Outros nomes pelos quais o Pattern é conhecido.
como
Exemplo de Código  Uma exemplificação literal de como o Pattern pode ser codificado. Essa
codificação pode ser feita em qualquer linguagem.
Patterns  Quais Patterns estão associados com este? Quais são as principais
diferenças e semelhanças? Com quais outros Patterns este deveria ser
Relacionados
utilizado?
A Tabela 3 apresenta um exemplo prático de um Pattern. Descreve uma boa maneira

de visualização das informações como estrutura de árvores. Os atributos utilizados neste
padrão envolvem uma imagem, a descrição do problema, o contexto e sua solução.
Tabela 3. Exemplo de Pattern
Tree-Table
From Outlook Express's news reader

Problema: A interface do usuário apresenta diversas informações, de tal forma que a tabela
torna-se completamente funcional (ou permite que os dados sejam ordenados). No
entanto, os itens são inicialmente organizados de forma hierárquica, sendo
apresentados em formato de árvore ou outline.
Contexto: A combinação das duas abordagens de apresentação de dados fornece o melhor
resultado, a um custo que se resume em programação e design. É possível mostrar a
19
hierarquia dos itens, além de uma matriz com dados adicionais ou atributos de cada
item, tudo em uma estrutura unificada.
Solução: Os exemplos mostram o que deve ser feito: coloca-se a árvore na primeira coluna e
os atributos dos itens nas colunas subseqüentes. As linhas – um item por linha – são
normalmente selecionáveis. Naturalmente, pode ser combinada numa tabela
ordenada com o objetivo de produzir uma estrutura mais usável e interativa.
Esta técnica tornou-se comumente utilizada em clientes de e-mail e noticias.
Fonte: (TIDWELL, 2006)
3.1.3 Criação de Patterns

Um Pattern é criado a partir de uma solução encontrada para problemas recorrentes
durante o desenvolvimento de um determinado um projeto. Depois de encontrada a solução,
inicia-se o processo de adequação do Pattern, através do estabelecimento de seus atributos.
Um Pattern pode ser descrito através dos atributos (vide item 3.1.2) ou o usuário poderá
acrescentar outros conforme sua necessidade. (AQUINO JR., 2008)
Em (BORCHERS, 2008) o autor sugere que a descrição de um Pattern não pode ser
genérica, ela deve ser detalhada, porém de forma concisa para não torná-la extensa, ambígua
ou de difícil leitura. Caso o Pattern se torne muito extenso, deve ser considerada a hipótese de
dividi-lo em um ou mais Patterns menores, referenciando-os sempre que possível.
A descrição do problema deve ser bem elaborada. Afinal, ela indicará o escopo de sua
solução. Detalhes de onde a solução se aplica ou, até mesmo, onde ela não se aplica ajuda o
leitor a reconhecer o problema / solução e aplicá-los à sua própria necessidade.
A utilização de uma linguagem de fácil entendimento contribui para o sucesso na
documentação de um Pattern. Considere que mais importante do que documentar um
conhecimento ou experiência, é poder compartilhá-los com pessoas de diversas áreas,
possibilitando que profissionais sem experiência tirem proveito de suas vantagens através do
Pattern criado (BORCHERS, 2008).
3.1.4 Linguagem de Patterns

Um repositório de Patterns, ou catalogo de padrões é um conjunto de padrões que
podem ser utilizados isoladamente. Um conjunto de padrões, que pertencem a um mesmo
contexto, quando combinados, gera uma linguagem de padrões. Essa linguagem torna a
utilização dos padrões mais eficiente.
Uma linguagem de padrões é composta pelos seguintes elementos (AQUINO JR.,
2008):
20
 Padrões individuais;
 Título;
 Descrição do argumento de aplicação;
 Grafo ilustrando o relacionamento;
 Etc.
Para que seja construído este grafo, é necessário saber alguns tipos possíveis de
relacionamento. Exemplo de possíveis relacionamentos entre o padrão A (PA) e o padrão B
(PB) (MARINHO, et al., 2003):
 Se PA usa PB, então a solução de PA é gerada utilizando PB;
 Se PA refina PB, então o problema de PA é uma especialização de PB;
 Se PA requer PB, então a aplicação de PB é exigida na aplicação de PA;
 Se PA é alternativo a PB, então ambos os padrões oferecem, apesar de
diferentes, soluções a um problema.
A Figura 1 ilustra um grafo gerado para representar uma linguagem de Patterns. Cada
Pattern é representado por um retângulo e estes se relacionam entre si através das setas, sendo
que estas descrevem ainda o tipo de cada relacionamento.
Figura 1. Grafo da relação entre os padrões

Fonte: (GERBER, 1999)
Portanto, uma linguagem de padrões é um conjunto de padrões estruturado

hierarquicamente conduzindo o projetista a uma abstração e ligação entre eles. Caso não
21
exista tal estrutura hierárquica entre eles, isso é considerado apenas como um conjunto ou
catálogo de padrões.
3.2 Anti-Patterns
É senso comum que dificilmente um projeto seja entregue sem que erros aconteçam
durante sua concepção. Naturalmente, os projetistas tencionam buscar melhores soluções
gerando experiência e aprendizado, porém algumas dessas resoluções podem conter falhas.
Um meio de documentação para os problemas existentes que descreve erros ou
procedimentos ineficientes é conhecido como Anti-Patterns(LONG, 2001). Em (AKROYD,
1996) foi apresentado este conceito, que tem como objetivo completar e agregar valor a idéia
já existente de Patterns.
Anti-Pattern mostra inclusive o caminho seguido para tentar chegar ao resultado,
evitando assim que outros profissionais cometam os mesmos equívocos.
3.2.1 Definição
Pesquisas comprovam que cinco entre seis projetos de software falham (BROWN, et
al., 2000). Essas falhas podem ser aproveitadas para documentar o domínio de soluções
insatisfatórias por meio de Anti-Patterns, que permitem uma comunicação entre os projetistas.
Podem ser destacados dois tipos de Anti-Patterns (KOTZÉ, et al., 2006):
 Simple Anti-Pattern: Apresenta soluções negativas.
 Amelioration Anti-Pattern: Descreve os passos de uma solução ineficiente na
tentativa de encontrar uma solução positiva.
3.2.2 Formato
A Tabela 4 apresenta os atributos fundamentais de um Anti-Pattern (MICROSOFT
CORPORATION, 2005) (LONG, 2001):
Tabela 4. Atributos fundamentais de um Anti-Pattern
Nome: O nome de um Anti-Pattern deve representá-lo de maneira abrangente.

Contexto: Descrição da situação onde ocorre o problema.
Problema: Descrição do problema.
Barreiras: Considerações adicionais que auxiliam o reconhecimento da situação
Sintomas: Descreve quais foram os erros encontrados que motivaram os
especialistas a criá-los.
Consequências: Descreve o que pode acontecer caso o Anti-Pattern seja seguido.
22
Recomendações: Como a solução pode ser alcançada, podendo ser direcionada há um
Pattern. Este atributo está presente apenas em Anti-Patterns de
Melhoria.
Fonte: os autores
Outros atributos como: Anti-Patterns relacionados e palavras-chave podem ser

considerados para orientar o leitor sobre problemas relacionados.
3.2.3 Criação de Anti-Patterns

A partir de pesquisas realizadas junto ao Laboratório de Engenharia de Usabilidade da
FEI (LEU-FEI), foi observado que o processo de criação de um Anti-Pattern depende,
significativamente, do componente humano (MASIERO, et al., 2008). Esse processo é
constituído, basicamente, por três etapas fundamentais, conforme descrito na seqüência:
 Análise e Estudo de Caso: Levantamento dos problemas

 Agrupamento dos Erros: Abstrair problemas semelhantes e encontrar erros em
comum.
 Criação de Anti-Patterns: Documentar os problemas encontrados nos atributos
dos Anti-Patterns.
A Figura 2 apresenta as etapas do processo para a documentação:
Figura 2. Diagrama de processo para criação de um Anti-Patterns

Fonte: Os Autores
23
3.3 Personagens Fictícios ou Personas
Devido ao crescimento da diversidade de usuários, torna-se evidente as suas diferenças
de comportamento, necessidade, habilidade e experiência computacional. Essa variedade de
características e perfis impõe aos projetistas um grande desafio, que é o de desenvolver um
produto acessível a todos os perfis de usuários que o utilizarão (AQUINO JR., 2008). Uma
resposta para este problema é unir as características dos usuários envolvidos e representá-los
na forma de personagens fictícios, chamados Personas.
É sabido por meio de pesquisas e pela prática comum entre os projetistas, que estes
possuem a tendência de desenvolver sistemas tendo como base o seu próprio perfil ao invés
do perfil do usuário. As Personas, portanto, auxiliam a romper esta tendência, contribuindo
para que estes profissionais desenvolvam o sistema focando nos perfis dos usuários(AQUINO
JR., 2008).
3.3.1 Definição
De acordo com (COOPER, et al., 2003), as Personas são personagens fictícios que
caracterizam de forma mais completa um grupo de usuários finais. Elas devem possuir um
nome, características e imagem para agregar realismo e facilitar sua aplicação, comunicação e
reconhecimento entre os profissionais que irão utilizá-las (ver exemplo na Tabela 5). Através
deste conceito, é possível desenvolver um sistema baseado em poucos perfis, mas que, na
verdade, abrange uma quantidade maior de usuários (AQUINO JR., 2008).
3.3.2 O processo de criação

Dentre as muitas razões pelas quais um projeto não obtém sucesso – e partindo do
pressuposto que este sucesso nada mais é do que aquilo que o cliente deseja – destaca-se,
conforme já mencionado, a falta de conhecimento do projetista quanto às características dos
usuários do sistema. Conhecer os usuários, saber exatamente quem eles são, como trabalham,
quais são suas habilidades e experiências, quais seus reais perfis e atributos - todos esses itens
devem ser considerados como fatores determinantes e de peso considerável em uma avaliação
final por parte daqueles que efetivamente pagarão pelo produto.
Segundo o próprio criador de Personas, Cooper (COOPER, 1999) explica que os
passos necessários para a criação de uma Persona são:
 Coleta de dados: Para conhecer o usuário, as equipes de projeto devem

realizar pesquisas, entrevistas e atividades correlatas. Esse estudo de campo,
24
corpo a corpo com o usuário, é parte fundamental para a elaboração das
Personas. Os projetistas são até mesmo aconselhados a recolher fotos dos
usuários, descrever seus hábitos, experiências, como e quais tarefas
desempenham e quem as executa. Qual a freqüência e nível de destreza
necessária para cada tarefa, quais os caminhos que as pessoas normalmente
utilizam para realizar essa ou aquela função em específico, dentre outros. Ao
término da coleta de dados, os desenvolvedores estarão munidos de um
volume enorme de informações que, embora ainda passível de refinamento, já
os dará uma visão inicial dos tipos de usuários com quem estarão
efetivamente trabalhando.
 Definir variáveis de Comportamento: Esta etapa inicia o processo de

mineração e tratamento dos dados obtidos por meio da coleta. O objetivo
deste passo consiste na distribuição das pessoas em variáveis que definem o
comportamento dos usuários, variáveis estas que são resultados das
entrevistas e atividades explicadas no passo anterior. Em resumo, o produto
final é agrupar as pessoas que possuem comportamentos próximos.
 Identificar padrões de comportamento significantes: Este passo consiste

numa análise mais profunda dos grupos formados pelo passo anterior
identificando padrões de comportamento que se destacam. Segundo
(COOPER, 1999), uma provável Persona é identificada com o agrupamento
de seis a oito variáveis diferentes.
 Sintetizar características e metas relevantes: Toda Persona necessita de

um nome, sobrenome e até mesmo uma ilustração. Embora fictício, a
Persona deve ser personificada em todos os sentidos possíveis. Isso facilitará
a comunicação entre os projetistas. Esta parte do processo responsabiliza-se
justamente por essa personificação, descreve o ambiente de uso potencial, dia
de trabalho típico, soluções e relacionamentos, etc.
 Verificar redundâncias: Devido ao grande volume de informações

coletadas, as redundâncias podem ser removidas. Por meio de pesquisas
adicionais direcionadas a comportamentos em particular, torna-se possível
25
descartar redundâncias, agrupar Personas, descartar atributos irrelevantes,
etc.
 Descrição expandida: A descrição expandida consiste na melhor maneira de

literalmente estreitar e personificar o relacionamento entre os projetistas e as
Personas. Essa descrição consiste na narrativa em terceira pessoa do usuário
ou grupo de usuários representados pelas Personas. Nesta parte do processo
descreve-se de maneira mais contextualizada as características do usuário
representado.
Com base nesse processo, é apresentado na Tabela 5 três Personas como exemplos.
Aqui, assume-se que a coleta de dados já foi feita e o processo encontra-se completo, os dados
já foram filtrados, os atributos relevantes escolhidos, os redundantes descartados e o grupo de
usuário foi representado nessas três Personas. Seguindo ainda a metodologia de Cooper
(COOPER, 1999), cada Persona possui uma descrição expandida visando aumentar a
personificação e contribuir para a viabilização de seu uso entre os projetistas.
Tabela 5. Tabela de exemplos de Personas
Perfil dos Usuários

Nome da Persona: Felipe
Idade: 33 anos
Experiência Computacional: Alta
Profissão: Professor
Escolaridade: Pós-Graduado
Freqüência que utiliza computadores: Diariamente
Característica: Calmo
Descrição: Felipe possui uma agenda bastante ocupada, está freqüentemente

envolvido com projetos de pesquisa e trabalhos acadêmicos. Considera sistemas
em informática extremamente úteis para auxiliá-lo na obtenção de conteúdo e
conhecimento. Felipe aprecia jogos eletrônicos durante as horas vagas, é casado
e pretende ter filhos.
Nome da Persona: Andréia
Idade: 29 anos
Profissão: Gerente de Projetos
Escolaridade: Pós-Graduada
26
Característica: Detalhista
Descrição: Andréia trabalha numa empresa multinacional onde gerencia

projetos de desenvolvimento de sistemas e consultoria. Viaja constantemente
devido as suas muitas responsabilidades. A Andréia lidera grupos de
desenvolvimento, auxiliando-os com treinamento e instruções relacionadas. É
solteira e gosta de passear em shoppings com suas amigas e jogar xadrez.
Nome da Persona: Matheus
Idade: 25 anos
Profissão: Analista de Sistemas
Escolaridade: Superior Incompleto
Característica: Inquieto
Descrição: Matheus trabalha com programação há vários anos, o que o

incentivou a fazer o curso de Ciência da Computação. Atualmente, ele trabalha
numa grande empresa de fábrica de softwares com horário flexível, permitindo-
o até mesmo cumprir suas tarefas em sua própria casa. Não tem paciência para
ler instruções nem manuais alegando que o aprendizado, em sua grande parte,
vem da tentativa e erro. Nos horários vagos assiste a jogos de futebol em
estádios e gosta de música rock.
Fonte: os autores
Vê-se, portanto, que a consolidação dos passos propostos por (COOPER, 1999) para a
fabricação de uma Persona permite ao desenvolvedor personificar em sua mente o usuário
para quem o sistema está sendo desenvolvido. A descrição visual permite aos
desenvolvedores discutirem possíveis soluções para determinada Persona sem que, para isso,
seja necessário listar todos os seus atributos novamente. Por meio da descrição expandida e
seus mais variados atributos, é possível expandir a compreensão de quem realmente é o
usuário, quais são suas dificuldades na realização de suas funções e até mesmo prever qual
será seu comportamento diante de situações impostas naturalmente pelo uso da aplicação
desenvolvida.
3.4 Busca por Similaridade

É comum, nos dias de hoje, encontrarmos grandes bases de dados com todos os tipos
de informações. Tais informações são de suma importância para as empresas efetuarem
consultas, estatísticas, planejamentos e conseqüentemente tomadas de decisões. Por exemplo,
27
uma empresa de help desk pode necessitar de uma base contendo todos os casos de problemas
esperados por parte de seus usuários. Esses problemas devem ser encontrados de uma forma
ágil e com exatidão para direcionar o cliente à solução. Uma base de dados onde não seja
possível obter uma informação específica não cumpre com o propósito para o qual esta foi
originalmente criada.
Para satisfazer essa necessidade, a busca por similaridade utiliza o grau de semelhança
entre objetos para selecionar o mais adequado. (GRESSE, 2003)
3.4.1 Definição
Comumente usado em RBC (Raciocínio Baseado em Casos) e IR (Information
Retrieval), a similaridade é um conceito que extrai um grau de semelhança entre dois
objetos(GRESSE, 2003). Esse grau de semelhança pode ser utilizado para comparar cada
objeto da base de dados com o objeto que se deseja obter.
A busca visa encontrar um grau de similaridade entre 0.0 e 1.0 efetuando uma
comparação de características, com os casos armazenados.
O processo de similaridade, portanto, envolve duas etapas:
3.4.2 Similaridade local

Similaridade referente à comparação de um único atributo dos casos. Os métodos
usados aqui podem ser (GRESSE, 2003):
 Correspondência exata: Caso as strings estejam escritas da mesma
forma. Por exemplo, "e-commerce" e "e-commerce", o algoritmo
retorna 1.0, enquanto "e-business" e "e-commerce", o retorno é 0.0
 Correção ortográfica: Ponderação entre o número de caracteres que
são iguais pelo número total de caracteres. Por exemplo, "menino" e
"menina", a quantidade de caracteres idênticos: 5. Quantidade total de
caracteres: 6. Portanto, a similaridade é dada por: 5/6 = 0,83.
 Contagem de palavras: Utilizado em textos maiores. Faz um contagem
por palavras idênticas nos casos comparados.
 Taxa do maior substring comum: Taxa entre a maior sequência de
caracteres entre os dois casos pelo número total da consulta.
28
3.4.3 Similaridade Global
Similaridade referente à comparação de todos os atributos ou índices dos casos,
analisados anteriormente com a similaridade local. Essas características, ou atributos,
podem ter pesos, classificando-o como maior ou menor relevância no cálculo.
Para ter maior eficiência, a busca pode ser feita em uma base de casos indexada,
ou seja, é possível escolher quais atributos devem ser comparados. A fórmula abaixo
apresenta o cálculo do algoritmo Nearest Neighbour (vizinho mais próximo)(GRESSE,
2003):
𝑊𝑖 ∗ 𝑠𝑖𝑚(𝑞𝑖, 𝑐𝑖)
𝑆𝑖𝑚 𝑋, 𝑌 =
𝑊𝑖
Sendo:
Wi: Peso do Atributo
Sim(X,Y): Similaridade global da consulta X com o caso Y
sim(qi,ci): Similaridade local entre atributo qi de X e ci de Y.
Depois de finalizado o processo de adaptação, o caso é então armazenado na base

de casos. Para tanto, é necessário coletar informações relevantes para a indexação e
colocá-lo na estrutura correta. Usando técnicas de manutenção de base de casos é possível
mantê-la redundante e com um tamanho aceitável(GRESSE, 2003).
Com base nesses conceitos a metodologia do trabalho é definida com objetivo de
guiar e embasar a criação da ferramenta proposta neste projeto de formatura, conforme
segue na sessão 4.
29
4 METODOLOGIA
Nesta seção, é apresentada a metodologia utilizada no sistema. É detalhado o

funcionamento do algoritmo de busca por similaridade através de exemplos e diagramas de
apoio. O fluxograma da Figura 3 detalha todo o processo proposto, desde suas entradas,
definições intermediárias, inserção no sistema, avaliação dos documentos, ações de bloqueio e
disponibilização das estruturas e documentos entre os usuários.
30
Legenda:
Figura 3. Metodologia do SiGePAPP

Fonte: os autores.
31
4.1 Entrada / Início
Como parte inicial da metodologia do SiGePAPP, o processo de entrada resume-se
nos meios pelos quais o usuário poderá iniciar o fluxo de criação ou pesquisa de um APPP:
 Busca: Por conter uma base de documentações inseridas pelos mais diversos
profissionais da área, os usuários do SiGePAPP poderão pesquisar por um
Pattern, Anti-Pattern ou Persona, sendo possível também encontrar outros
documentos relacionados. O processo inicia-se com o preenchimento dos
seguintes campos: Nome, Contexto, Problema e/ou Solução. A partir disso, o
sistema utilizar-se-á das técnicas provenientes da busca por similaridade em
RBC (Raciocínio Baseado em Casos) (conforme descrito no item 3.4.2) para
comparar as informações digitadas com os atributos comuns entre Patterns e
Anti-Pattern. O processo de busca de Personas ocorre pelos seus atributos
nome e descrição.
 Novo Cadastro: Conforme descrito no item 4.3.
4.2 Definição da Estrutura

Uma estrutura bem definida – com seus atributos e características essenciais – é tão
importante quanto o próprio conteúdo que será inserido no sistema. Em (GAMMA, et al.,
1995) os autores explicam que estruturas como os Patterns, por exemplo, devem ser descritos
num formato claro e consistente. Cada estrutura segue um tipo de template (modelo) variando
de acordo com o contexto e necessidades específicas. Gamma (GAMMA, et al., 1995)
enfatiza que uma estrutura bem formatada é essencial para a compreensão e utilização por
parte dos usuários. Seus campos ou atributos devem ser escolhidos de maneira que
efetivamente contribuam para clareza e consistência mencionada pelos autores.
Devido aos mais diversos contextos nos quais uma estrutura APPP poderá vir a ser
enquadrada, o SiGePAPP permitirá ao usuário desfrutar de uma considerável flexibilidade
para determinar, ele próprio, cada atributo que sua estrutura apresentará. Visando manter a
organização e facilitar a associação entre os contextos inseridos no sistema, o SiGePAPP
possui uma propriedade denominada “Estrutura Mínima”, ou seja, a despeito dos atributos
que poderão ser criados pelo usuário, eles sempre partirão de alguns campos que serão
obrigatória e automaticamente inseridos na documentação no momento que o usuário optar
32
pela criação de uma nova estrutura. Os atributos que compõem as estruturas mínimas para
cada componente do APPP são:
 Pattern
o Nome;
o Contexto;
o Descrição do Problema;
o Solução.
 Anti-Pattern
o Nome;
o Contexto;
o Solução;
o Descrição do Problema;
o Barreiras;
o Sintomas;
o Conseqüências;
o Recomendações;
 Personas
o Nome;
o Descrição;
o Link para Foto;
Caso o usuário julgue que os atributos acima não são suficientes para uma boa
descrição de sua documentação, ele terá, portanto, a flexibilidade para criar outros atributos
que irão compor sua estrutura final. Ademais, o usuário poderá ainda usufruir de estruturas
criadas por outros usuários.
4.3 Inserção de APPP no SiGePAPP

O usuário documenta suas próprias experiências no SiGePAPP por meio dos APPPs.
Essa documentação consiste no registro de soluções, boas e más práticas e perfis de usuários
envolvidos no contexto abordado pela documentação. Primeiramente o usuário deve escolher
entre utilizar uma estrutura já existente ou criar uma nova. Caso o usuário escolha criar uma
nova estrutura APPP ele procederá com a definição de seus atributos e esta então será
disponibilizada para uso. Uma vez tendo a estrutura definida é feito o preenchimento.
33
4.4 Relacionamento entre APPP
O sistema permite ao usuário efetuar o relacionamento entre os documentos APPP
gerados. Este relacionamento pode ocorrer entre as três, ou apenas duas das estruturas. Em
(AQUINO JR., 2008) ou autor expõe uma estrutura chamada de PICaP, que é justamente a
relação entre Pattern e Personas (ver Figura 4) . Ele explica que a relação entre as duas
estruturas enriquece a documentação, pois embora o problema seja o mesmo, a solução
abordada pode ser feita tendo como base as características de cada uma das Personas
envolvidas.
A seguir, é detalhado como é possível realizar estes relacionamentos:
4.4.1 PICAPs – Relacionamento entre Patterns e Personas

Conforme apresentado na seção 3.1.2, um Pattern possui diversos atributos. Ao
descrever a solução para um determinado problema, o Pattern apresenta detalhes de como
este problema poderá ser solucionado para esse ou aquele perfil de usuário (conforme Tabela
5), sendo que estes perfis estarão representados pelas Personas anexadas ao Pattern. A grande
vantagem dessa estrutura é que uma solução pode ser extremamente eficaz para um
determinado perfil de usuário, contudo, completamente inútil para outro. O relacionamento,
portanto, do Pattern com as Personas assegura que o usuário final seja realmente considerado
como sendo parte fundamental para uma solução adequada.
4.4.2 Anti-PICAPs – Relacionamento entre Anti-Patterns e Personas

O relacionamento entre um Anti-Pattern e Personas possui objetivo semelhante ao
explicado no item anterior. Contudo, o atributo utilizado como meio de relacionamento entre
as duas estruturas é a “Conseqüência” ou “Sintoma” do Anti-Pattern (atributos explicados no
item 3.2.2 ). Por meio dessas duas documentações relacionadas, é possível documentar
exatamente como cada perfil de usuário é afetado, tornando possível ao desenvolvedor
precaver-se de situações indesejáveis e tomar as ações preventivas de maneira personalizada
para cada perfil de usuário do sistema em desenvolvimento.
4.4.3 Relacionamento entre Anti-Patterns e Patterns

O relacionamento entre essas duas documentações resume-se praticamente no fato de
que uma é conseqüência ou resposta natural da outra. Em um Pattern, o seu atributo
“Problema” pode ser referenciado diretamente a um Anti-Pattern. Da mesma forma, em um
34
Anti-Pattern, o atributo “Recomendações” pode ser referenciado a um Pattern. Isso torna a
documentação muito mais objetiva e direta, características tão claramente defendidas por
diversos autores, como descritas em (GAMMA, et al., 1995).
4.4.4 APPP – Relacionamento entre Anti-Pattern, Pattern e Personas.

Este relacionamento consiste na junção de todas as três descritas acima. Devido à
flexibilidade contida na criação de cada estrutura, o usuário poderá facilmente propor o
relacionamento entre todas elas, usufruindo assim dos benefícios conjuntos de cada uma,
resultando em uma estrutura completa APPP.
Torna-se importante enfatizar a realidade de que existem casos onde um determinado
problema tem características demais primitivas ou abstratas a ponto de não permitir nenhum
vínculo entre as estruturas.
A Figura 4 exemplifica uma estrutura APPP contendo a relação entre um Pattern e
duas Personas.
Figura 4. Exemplo de PICAP.

Fonte: (AQUINO JR., 2008)
4.5 Utilização
Uma vez finalizado o processo de inserção e disponibilização, o usuário tem a
possibilidade de navegar pelo SiGePAPP, verificar estruturas e conteúdos de APPP, com o
intuito de aplicá-los em seus projetos usufruindo de todos os recursos do sistema.
35
4.6 Avaliação
Conforme as documentações são disponibilizadas para uso, os usuários podem avaliá-
las à medida que são aplicados em seus projetos. Essa avaliação é feita através de um
questionário cujas respostas possuem pesos que variam entre 1 (um) e 5 (cinco). O
administrador do sistema possui a flexibilidade para criar um questionário personalizado, criar
as perguntas e suas respectivas respostas, bem como anexar respostas já existentes como:
“Sim”, “Não”, “Sempre”, “Fácil”, entre outras.
Essa avaliação é essencial para a filtragem dos dados inseridos no sistema, pois
somente por meio deste feedback por parte dos usuários é possível classificar a confiabilidade
de cada documento.
A princípio, os autores deste projeto de formatura haviam criado a possibilidade do
usuário avaliar tanto a estrutura do documento (seus atributos, nomes e organização) como o
conteúdo de cada documento, a primeira avaliação denominava-se “Estrutura” e a segunda
“Conceitual”. À medida que o trabalho foi sendo desenvolvido, conclui-se por meio de testes
e experiências que a avaliação da estrutura não agregaria valor suficiente para justificar o
investimento necessário em sua implantação. Para o usuário do SiGePAPP, ter a certeza – por
meio de avaliações – de que o conteúdo de um determinado documento é de fato eficaz, é o
que realmente importa. Saber, por meio da experiência alheia – que será refletida nas
avaliações dos documentos (conteúdo) – que um determinado Pattern, Anti-Pattern ou
Persona realmente atende às suas necessidades é indubitavelmente o maior retorno esperado
pelos usuários.
A experiência de uso aliada às avaliações freqüentes procura fazer com que somente
os melhores documentos sejam destacados, contribuindo para o sucesso no compartilhamento
de conhecimento e experiências. O resultado desta avaliação alimenta o processo de análise
descrito no item 4.7.
4.7 Análise da Avaliação / Ações de Bloqueio

Após todo evento de avaliação por parte dos usuários, será executada uma análise para
verificar se o documento avaliado deve continuar disponível para uso ou não. Essa rotina e
executada a cada avaliação. Esse procedimento é importante para tentar garantir que os
APPP’s mantidos pelo sistema sejam confiáveis.
De acordo com etapas específicas, listadas a seguir, é verificado se os itens são
considerados adequados para permanecerem no sistema:
36
4.7.1 Cálculo da média:
Através da Equação 1, é possível obter a média dos usuários que avaliaram um
documento:
n i
N x =
i
Equação 1. Equação para o cálculo de média da avaliação
Onde:
N(x) = Nota da análise
n(i) = Nota de um usuário i
Sendo:
i ≥ 10
Para efetuar este cálculo foi utilizado uma função do banco de dados Oracle. O nome
desta função é AVG, que executa exatamente a fórmula apresentada na Equação 1.
4.7.2 Análise do resultado:

De posse da média das avaliações, o sistema irá analisar o resultado seguindo duas
regras:
 Se 𝑁 𝑥 > 50%: Documento ou estrutura continua habilitado para uso.
 Se 𝑁 𝑥 ≤ 50%: Neste caso, o sistema bloqueia e oculta dos usuários o
documento.
Em caso de bloqueio o autor recebe uma mensagem que informa essa ocorrência.
4.8 Processo da Busca por Similaridade

Conforme citado no item 3.4.2, a similaridade local pode ser calculada por meio de
diversos métodos. Dentre aqueles descritos por (GRESSE, 2003), os autores deste projeto de
formatura optaram pelo método conhecido como “Taxa de maior substring comum”. Este
método foi selecionado porque sua lógica leva em consideração a similaridade da palavra letra
a letra – partindo da primeira – e não somente a palavra como um todo. Sendo assim, ao
analisar a similaridade de duas palavras como “pode” e “podendo” o algoritmo valoriza ao
máximo suas semelhanças. Até mesmo os prefixos das palavras podem ser considerados
como semelhantes através da utilização deste algoritmo.
37
Figura 5. Similaridade Letra a Letra
Fonte: Os autores
No exemplo da Figura 5, as letras “P”, “O”, “D” e “E” são encontradas em ambas as
palavras, resultando, portanto, em uma similaridade de 4 / 7, ou seja, 57% - de sete letras,
quatro são semelhantes. Um algoritmo que não levasse em consideração a busca letra a letra
simplesmente encerraria sua lógica alegando similaridade zero. O passo a passo deste
algoritmo será discutido posteriormente. Por agora é necessário enfatizar que, devido à
vantagem apresentada acima, o grupo julgou o algoritmo “Taxa de maior substring comum” –
doravante denominada apenas TMSC – como sendo aquele que melhor atende às
necessidades deste trabalho, justificando, portanto, sua implantação.
4.8.1 O algoritmo
A TMSC foi implantada com base em alguns conceitos já existentes (GRESSE, 2003)
e outros julgados necessários pelo próprio grupo, são eles:
 Similaridade(A, B) = Similaridade(B, A);

 Similaridade(A, A) = 1,0 ou 100%;
 Palavras com quantidade de letras menor ou igual a três são descartadas;
 A verificação não é Case Sensitive (não considera a caixa de texto);
 Caracteres estranhos são retirados dos textos;
Para facilitar a compreensão do processo, deste ponto em diante as duas frases da

Figura 6 serão utilizadas como exemplo à medida que o passo a passo do algoritmo é descrito.
38
Figura 6. Exemplo
Fonte: Os autores
Tendo em mãos os textos que serão comparados, o algoritmo executará os seguintes

passos:
4.8.1.1 Passo 1 – Verifica a quantidade de palavras de cada texto

Este primeiro passo é feito por meio de uma função denominada
Quantidade_de_Palavras(A), onde o parâmetro “A” é o texto cujo número de palavras deseja
se obter. Conforme descrito nos conceitos pré-definidos pelo grupo as palavras com menos de
quatro letras são descartadas da análise. O principal objetivo desta varredura inicial é
descobrir qual dos dois textos apresenta a menor quantidade de palavras. A lógica do TMSC
consiste em um laço onde a primeira palavra do texto base é comparada com todas as palavras
do outro texto, portanto, quanto menor for este último melhor o desempenho, uma vez que o
número de “loops” será menor. No exemplo trabalhado, teríamos o resultado demonstrado na
Figura 7.
39
Figura 7. Quantidade de palavras
Fonte: Os autores.
Sendo assim, o Texto A será o texto base e o Texto B o comparado, uma vez que este
último possui sete palavras, uma a menos do que o primeiro.
4.8.1.2 Passo 2 – Preenchendo os vetores

O segundo passo consiste em alocar todas as palavras dos textos em vetores de forma
que cada palavra seja armazena em uma posição do vetor. A função responsável por esta
tarefa chama-se Preenche_lista(A, B), sendo o parâmetro A o texto à ser vetorizado e o
parâmetro B o vetor propriamente dito. Em nosso exemplo, o procedimento retornaria os dois
textos conforme a Figura 8 e Figura 9, onde o Texto A foi alocado no Vetor A e o Texto B no
Vetor B.
Figura 8. Vetor A
Fonte: Os autores
40
Figura 9. Vetor B
Fonte: Os autores
4.8.1.3 Passo 3 – Comparando palavra por palavra, letra por letra

Nesta etapa do processo, o TMSC encontra-se com os textos completamente prontos
para iniciar o clico de comparações e buscas entre os dois. O algoritmo responsável por esta
etapa, a mais importante de todo processo, chama-se Maior_substring(A, B, C, D). O
parâmetro “A” é uma palavra do vetor, o “B” é o vetor comparado, o “C” e o “D” são os
parâmetros de retorno da função, tecnicamente chamados de Max_Caracter e Max_Comum.
Os parâmetros de saída são dois inteiros que formarão a fração que, por sua vez, representa a
similaridade da palavra no texto comparado. O primeiro forma o numerador e o segundo o
denominador da fração.
A lógica consiste na construção de dois loops, um dentro do outro. O primeiro loop
percorre o texto base, em nosso exemplo, o Texto A armazenado no Vetor A. Ao encontrar a
palavra “Interface” armazenada na posição zero do Vetor A o TMSC armazena a primeira
letra “I” em uma variável e parte então diretamente para o Vetor B percorrendo todas as suas
palavras em busca daquelas que se iniciam com a mesma letra “I”. Todas as palavras do Vetor
B que não constarem a letra “I” na primeira posição são descartadas de forma que no segundo
loop estas não precisem fazer parte da varredura. Ao chegar ao fim do Vetor B, este conterá
apenas palavras que se iniciam com a letra “I”.
Em seguida, o TMSC move o ponteiro do Vetor A – posicionado na palavra
“Interface” – para a sua segunda letra, ou seja, “n”, e novamente parte para o Vetor B
buscando em todas as suas palavras aquelas que contém a segunda letra igual a “n”. Nota-se
que as letras são comparadas levando em consideração sua posição na palavra do Vetor A, ou
seja, posição 1 no Vetor A com posição 1 no Vetor B, 2 com 2 e assim por diante. O loop que
percorre a palavra do Vetor A se encerrará quando:
41
 A palavra percorrida (no Vetor A) chegar ao fim, no exemplo aplicado aqui após a
letra “e” de “interface”;
 Encontrar uma palavra no Vetor B cuja similaridade seja igual a 1, ou seja, 100% -
palavra idêntica;
A cada iteração do segundo loop a função Maior_substring() retorna os parâmetros C e D

atualizados de acordo com a similaridade atual de cada palavra até a posição da letra
percorrida. O objetivo é finalizar a busca de forma que cada palavra do Vetor B tenha uma
fração representada por C / D. O numerador C representa o número de caracteres semelhantes
e o D, por sua vez, a base pela qual este será divido. Por definição, a base será sempre o
número de letras da maior palavra entre as duas que estão sendo comparadas. Ao término dos
ciclos efetuados na primeira palavra do Vetor A, o TMSC assume a maior similaridade de
todas as palavras como sendo a final.
A Figura 10 demonstra o ciclo de busca da primeira palavra do Vetor A e o retorno final
de sua similaridade.
Figura 10. Ciclo de Busca

Fonte: Os autores
Logo após o término do ciclo demonstrado pela figura acima o TMSC inicia todo o
processo novamente agora tendo como base a próxima palavra do Vetor A: “devera”. A
42
função retornará a fração de similaridade desta palavra e repetirá o processo até o término do
vetor base. No exemplo demonstrado na figura acima, todas as outras palavras do Texto B -
além da “interface” – foram descartadas logo no primeiro ciclo, já que nenhuma delas possui
a letra “i” na primeira posição. Caso houvesse alguma palavra iniciando com “i” além da
“interface” esta seria percorrida até que encontrasse a primeira discrepância, ao término do
processo o algoritmo teria duas palavras cujas frações de similaridades seriam maior do que
zero, nesta situação, o TMSC retorna sempre aquela de maior similaridade.
Na Figura 11, encontra-se delineado a codificação do algoritmo Maior_substring() em
pseudo-código, conforme lógica anteriormente descrita.
Figura 11. Algoritmo

Fonte: Os autores
A função Maior_substring() retorna, contudo, a similaridade das palavras

individualmente e não do texto como um todo. Para obter a similaridade de todo o texto a
função é inserida em um laço de forma que seus retornos (frações de similaridade) são
acumulados uns com os outros. Ao término do loop principal, a rotina terá duas variáveis
denominadas Comuns_car e Totais_car com a similaridade total do texto em questão.
43
4.8.1.4 Passo 4 – A similaridade Global
Uma vez que todo o processo destina-se a informar ao usuário qual a similaridade de
todo o APPP, o SiGePAPP utiliza da similaridade local para calcular a global. Esta é feita
através de pesos que são atribuídos a cada atributo do APPP. No final do processo, a
similaridade de cada atributo é multiplicada por seu respectivo peso de forma que a soma
destes formarão a similaridade global entre os APPP‟s analisados.
4.8.2 Melhoria de Desempenho
Conforme o TMSC foi implementado, estudado e testado, o grupo, com a ajuda do

corpo docente da FEI, preocupou-se em melhorar o desempenho do mesmo. A preocupação
com o desempenho do processo de busca e resposta do sistema tornou-se prioridade para os
autores deste projeto de formatura.
Após estudos, reuniões e debates, foi implementada uma mudança no processo de
vetorização dos textos comparados, de tal forma que o desempenho melhorou
consideravelmente.
A mudança consistiu em organizar as palavras dos textos em matrizes e não mais
vetores. O TMSC faz então uma matriz cujas posições são marcadas de “A” a “Z”. Cada
palavra do texto é colocada em sua devida posição de acordo com a letra que esta se inicia.
Fazendo uso do exemplo em questão, a distribuição das palavras do texto comparado
na matriz seria conforme a Figura 12.
Figura 12. Matriz B, obtida a partir da varredura no Vetor B.

Fonte: Os autores
A vantagem desta mudança no sistema de vetorização é que procurar uma determinada

palavra iniciada com “i”, por exemplo, o cursor já vai diretamente para a posição “I” da
44
matriz, onde terá que percorrer um número muito menor de palavras do que faria caso
estivesse trabalhando com a vetorização tradicional. Ademais, quando uma palavra é utilizada
esta é excluída da matriz, tornando-a ainda mais enxuta para o próximo ciclo de busca.
O gráfico da Figura 13 demonstra que a busca por similaridade comporta-se como
uma função exponencial. O eixo x e y do gráfico representam o tamanho em caracteres de
cada um dos textos comparados. O eixo z, por sua vez, representa o tempo em segundos do
início até o fim de toda a execução do algoritmo. Conclui-se, portanto, que o tempo de
resposta do algoritmo é diretamente proporcional ao tamanho dos textos comparados.
t (seg)
1,5
1 t (seg)
1-1,5
0,5 0,5-1
1838
0-0,5
0 152
1281 Texto 01
640 62
320
Texto 02 62
Figura 13. Texto 01 vs Texto 02 vs tempo(seg)

Fonte: Os autores
45
5 MODELAGEM
Nesta sessão serão abordados os seguintes itens:

 Requisitos
 Diagramas de Casos de Uso
 Diagramas de Classes
 Diagramas de Seqüência
5.1 Requisitos
5.1.1 Requisitos Funcionais
Identificação: RF-1
Requisito: Cadastro de Pattern
Descrição: Possibilidade de cadastrar um Pattern baseado em uma
estrutura definida. A estrutura poderá ser a mínima ou
personalizada pelo usuário por meio da inclusão de novos
atributos.
Requisito: Cadastro de Anti-Pattern
Descrição: Possibilidade de cadastrar um Anti-Pattern baseado em uma
atributos.
Requisito: Cadastro de Persona
Descrição: Possibilidade de cadastrar uma Persona baseada em uma
atributos.
46
Requisito: Cadastro da Estrutura de Pattern
Descrição: Caso não exista uma estrutura que descreva eficientemente
um Pattern, o usuário poderá criar uma nova estrutura a
partir da mínima com atributos personalizados.
Requisito: Cadastro de Estrutura de Anti-Pattern
um Anti-Pattern, o usuário poderá criar uma nova estrutura a
Requisito: Cadastro de Estrutura de Persona.
uma Persona, o usuário poderá criar uma nova estrutura a
Requisito: Busca de APPP
Descrição: Encontrar outros APPP a partir de atributos específicos
digitados pelo usuário, tais como nome, contexto etc. O
usuário poderá escolher se deseja uma “Busca por Estrutura”
ou uma “Busca por Conteúdo ou Documento”. Ademais, ele
poderá ainda desejar uma busca por similaridade, digitando
parte do texto ou palavras aleatórias.
Requisito: Associações entre os APPP
Descrição: Há quatro tipos de relacionamentos entre os APPPs:
 Relacionar um Pattern à Personas(PiCAPS)
 Relacionar um Anti-Pattern à Personas(Anti-
PiCAPS)
 Relacionar Pattern com Anti-Pattern.
47
 Relacionar Pattern com Anti-Pattern e Personas.
O usuário poderá ter a flexibilidade para associar

documentos na ordem de 1 para “n”, ou seja, um Pattern,
por exemplo, poderá estar relacionado com diversas
Personas, sendo que cada uma delas conterá uma descrição
do seu relacionamento.
Requisito: Cadastro de Usuários
Descrição: Os usuários devem estar cadastrados previamente de acordo
com seu perfil, podendo ser:
 Administrador
 Usuário
O sistema deverá conter uma verificação para assegurar a

integridade dos dados inseridos, impedindo a inserção de
usuários repetidos, etc.
Requisito: Avaliação dos documentos
Descrição: Usuários podem atribuir notas aos documentos. As respostas
possuem pesos que variam de 1 (um) a 5 (cinco) sendo 1
(um) o menor peso e 5 (cinco) o maior. As perguntas e
respostas poderão ser cadastradas pelo administrador, tendo
este flexibilidade total para criar respostas relacioná-las às
perguntas que desejar.
Requisito: Ação de bloqueio
Descrição: De acordo com dados obtidos com a avaliação (RF-11), o
sistema bloqueará o documento, avisando o autor desse
bloqueio.
48
Requisito: Exibir APPP relacionado
Descrição: O usuário poderá visualizar quais documentos estão
relacionados uns com os outros.
5.1.2 Não Funcionais
Identificação: RNF-1
Requisito: Estrutura Client-Server
Descrição: Estrutura que contém computadores clientes e
computadores servidores onde existe uma comunicação em
rede.
Requisito: Usabilidade
Descrição: Proporcionar ao usuário uma interface de fácil navegação,
clara e objetiva. Conceder botões, atalhos e seqüência de
telas objetivando a agilidade por parte do usuário.
Requisito: Uso de SGBD
Descrição: Sistema de gerenciamento de banco de dados para criação
de banco de dados relacional.
Requisito: Segurança
Descrição: Controle de usuários por meio de Login, podendo este ter o
perfil de administrador ou usuário convencional.
Requisito: Ambiente WEB
49
Descrição: Sistema deverá ser projetado em plataforma WEB.
Requisito: Manutebilidade
Descrição: Código estruturado para prover manutenção facilitada.
5.2 Diagramas de Caso de Uso

Nesta seção serão apresentados os diagramas de casos de uso para os cenários
levantados.
5.2.1 Caso de Uso: Login

Na Figura 14 é apresentado o diagrama de caso de uso para o cenário login, onde o
usuário realizará sua autenticação para acessar e utilizar o sistema.
Ao acessar o caso de uso “Efetuar Login”, o usuário informará ao sistema seu nome de
usuário e senha, com estes dados o sistema iniciará o processo de validação de login e este
sendo aceito abrirá a tela inicial do sistema.
Figura 14. Diagrama de Caso de Uso: Login

Fonte: os autores.
5.2.2 Caso de Uso: Cadastro

Na Figura 15 é apresentado o diagrama de caso de uso para o cenário de cadastro,
onde o usuário poderá efetuar o seu próprio cadastro de acesso ao sistema, cadastro das
estruturas envolvidas no APPP, bem como o conteúdo de cada APPP.
50
Ao realizar o acesso ao caso de uso “Cadastro de Usuário”, o usuário poderá efetuar o
cadastro de seu acesso e alterações de seu perfil no sistema. Para realizar o cadastro de uma
nova estrutura APPP, o acesso é feito pelo caso de uso “Cadastro de Estrutura”, se não existir
os atributos desejados pelo usuário este deverá inseri-lo através do caso de uso “Criação e/ou
Alteração de atributos”. Por fim, o cadastro dos APPP será realizado através do caso de uso
“Cadastro de Conteúdo”.
Figura 15. Diagrama de Caso de Uso: Cadastro

Fonte: os autores.
5.2.3 Caso de Uso: Consulta

Na Figura 16 é apresentado o diagrama de caso de uso para o cenário de pesquisa onde
o usuário conseguirá realizar suas pesquisas por problemas e soluções apresentadas através
das estruturas APPP.
51
Figura 16. Diagrama de Caso de Uso: Consulta
Fonte: os autores.
5.2.4 Caso de Uso: Relacionamento

Na Figura 17 é apresentado o diagrama de caso de uso para o cenário de
relacionamento entre as APPP. Através do caso de uso ”Relacionar / Associar”, o usuário
poderá realizar os relacionamentos descritos na item 4.4, realizados manualmente pelo usuário
Figura 17. Diagrama de Caso de Uso: Relacionamento

Fonte: os autores.
52
5.2.5 Caso de Uso: Avaliação
Na Figura 18 é apresentado o diagrama de caso de uso para o cenário de avaliação dos
APPP pelos usuários do sistema.
Através dessas avaliações o sistema poderá bloquear a exibição, de um determinado
APPP e enviar ao seu criador um informativo sobre o bloqueio.
Figura 18. Diagrama de Caso de Uso: Avaliação

Fonte: os autores
53
5.3 Diagrama de Classe
O Diagrama de Classe tem por finalidade representar as classes utilizadas, de forma
gráfica, de acordo com as regras de UML. A Figura 19 apresenta o diagrama de classe gerado
para este projeto de formatura.
54
Figura 19. Digrama de Classes SiGePAPP
Fonte: os autores
55
5.3.1 Classe Usuário
Essa classe armazena todas as informações necessárias para o sistema funcionar, no
que tange o usuário.
Atributos:
 cd_user: código do usuário no sistema.
 nm_prim_nome: Primeiro nome do usuário no sistema.
 nm_ult_nome: Ultimo ou sobrenome do usuário.
 dt_nasc: data de nascimento do usuário.
 nr_nota: Nota que usuário tem no sistema, de acordo com sua avaliação.
 dt_cadastro: data da criação do cadastro do usuário no sistema.
 ds_área_interesse: Áreas de interesse do usuário.
 nm_msn: username do Microsoft MSN Messenger do Usuário.
 nm_skype: username do Skype usado pelo usuário.
Métodos:
 Construtores, Getters e Setters.
5.3.2 Classe Login

Esta classe contém informações sobre o login do sistema.
 Nm_login: Nome de usuário usado para o login.
 Pw_login:: senha usada para login.
 cd_user: Código do usuário que possui esse login.
Métodos:
Dependências:
 Relação de composição com a classe Usuário.
5.3.3 Classe Estrutura

Atributos:
 nm_estrutura: é o atributo que guarda o nome da estrutura.
 cod_user : atributo que guarda o código do usuário criador.
 dt_criacao: Data da criação da estrutura.
56
 ds_estrutura: Descrição da estrutura.
 cd_estrutura: É o atributo que armazena o código da estrutura.
 tpEstrutura: Tipo da estrutura(„PA‟ – Pattern; „AP‟ – AntiPattern, „PE‟ -
Persona).
Métodos:
Dependências:
 Relação de composição com a classe Usuário.
5.3.4 Classe Objeto

Essa classe é base para as classes Pattern, Anti-Pattern e Persona. Ela representa o
documento propriamente dito.
Atributos:
 cd_objeto: Código do objeto.
 nm_objeto: nome do objeto.
 cd_estrutura: Código da estrutura na qual esse documento será preenchido.
 ds_objeto: Descrição do objeto.
 dt_criação: Data da criação do objeto.
 cd_user_criacao: Código do usuário que criou o objeto.
 fl_ativo: Flag que diz que esse objeto está ativo no sistema.
Métodos:
Dependências:
 Relação de composição com a classe Estrurura.
 Relação de composição com a classe Usuario.
5.3.5 Classe Pattern

Essa classe representa o Pattern no sistema. Todos os atributos e métodos herdados
passam agora a representar itens de um Pattern.
Atributos:
57
 Herda todos os atributos da classe Objeto, com relação entre cd_objeto e
cd_pattern.
 cd_pattern: Representa o código do Pattern no sistema (cd_objeto).
 ds_Pat_problema: descrição do problema que esse Pattern documenta.
 ds_Pat_solução: descrição da solução do problema que esse Pattern
documenta.
Métodos:
 Herda todos os métodos da classe Objeto.
5.3.6 Classe Anti-Pattern

Essa classe representa o Anti-Pattern no sistema. Todos os atributos e métodos
herdados passam agora a representar itens de um Anti-Pattern.
Atributos:
 Herda todos os atributos da classe Objeto, com relação entre cd_objeto e
cd_AntiPattern.
 cd_AntiPattern: Representa o código do AntiPattern no sistema
(cd_objeto).
 ds_Sintomas: descrição dos sintomas que esse AntiPattern documenta.
 ds_Recomendacoes: descrição das recomendações para os sintomas que
esse AntiPattern documenta.
 ds_Consequencias: descrição das conseqüências.
 ds_barreiras: descrição das barreiras.
 ds_problema: descrição do problema, se ele existir.
Métodos:
 Construtores, Getters, Setters.
5.3.7 Classe Persona

Essa classe guarda as informações sobre os perfis usados no sistema, seja na descrição
de uma solução ou no vínculo com outros dos conceitos englobados pelo APPP. Todos os
atributos e métodos herdados da classe Objeto passam agora a representar itens de uma
Persona.
58
Atributos:
 Herda todos os atributos da classe Objeto, com relação entre cd_persona e
cd_Objeto.
 cd_persona: Código da Persona.
 url_foto: link para o local onde se encontra a foto dessa Persona.
Métodos:
5.3.8 Classe Atributo

Classe que representa os possíveis atributos que um documento APPP pode conter.
Atributos:
 cd_atributo_obj: Código do atributo.
 nm_atributo_obj: Nome do atributo.
 ds_atributo_obj: Descrição do atributo
 cd_tipo: tipo do atributo.
 fl_atrib_relac: Flag que diz se esse atributo pode ser relacionável.
Métodos:
5.3.9 Classe RelacObjetos

Essa é a classe responsável pelo relacionamento entre objetos (documentos APPP),
que é um dos objetivos desse trabalho.
Atributos:
 cd_relac: Código do relacionamento.
 cd_objeto_relacionado: Código do objeto A do relacionamento A-B.
 cd_objeto_relacionando: Código do objeto B do relacionamento A-B.
 cd_atributo_obj: Código do atributo pelo qual os objetos se relacionam
 vl_relac: Descrição do relacionamento.
Métodos:
Dependências:
59
 Relação de composição com a classe Objeto.
 Relação de composição com a classe Atributo.
5.4 Diagramas de Seqüência

Nesta seção, serão apresentados os diagramas de seqüência dos principais cenários
identificados durante a construção desta monografia.
5.4.1 Login
Na Figura 20 representa o processo encontrado no cenário para efetuar o login no
sistema.
 O usuário acessa a interface de login – responsável pela obtenção dos dados
necessários – e transmite para a servlet LoginServlet.
 A servlet LoginServlet instancia a classe LoginDAO para validar o login cadastrado no
banco de dados. Se a verificação deste estiver correta, o login será executado, caso
contrário a classe GravarLog irá gerar um log com o erro ocorrido.
 Após a conexão com o banco, esta é fechada.
Figura 20. Diagrama de Seqüencia: Login

Fonte: os autores.
5.4.2 Cadastro de Usuário

Na Figura 21 é apresentado o processo encontrado no cenário para o cadastro de um
novo usuário no sistema.
60
 O usuário acessa a interface de cadastro que, por sua vez, transmite os dados para a
servlet CadUsuarioServlet.
 Em seguida, o banco de dados é acessado para verificar se o usuário cadastrado existe.
 Caso o usuário já exista, o sistema lança uma notificação. Em caso negativo, ou seja, o
usuário ainda não existe no banco de dados, este é acessado e o novo usuário é
inserido pelo método Insere(Usuario usuario)
 Em caso de algum erro durante o processo, um log é gerado.
Figura 21. Diagrama de Seqüência: Cadastro de Usuário

Fonte: os autores.
5.4.3 Cadastro de Estrutura

Na Figura 22 apresenta o processo para a criação de uma nova estrutura de APPP.
 Primeiramente, a servlet ExisteEstruturaServlet chama a DAO Estrutura_objDAO e
certifica-se que a estrutura sendo cadastrada não exista no banco de dados, após isso, a
conexão é fechada.
 Caso a estrutura não exista no banco, o cadastro é autorizado. Por meio da
CadEstruturaServlet, a DAO Estrutura_objDAO acessa o banco e insere a nova
estrutura. A conexão é fechada logo em seguida.
 Em seguida, por meio da mesma servlet, a DAO Atrib_EstruturaDAO acessa o banco
e insere novos atributos à estrutura anteriormente cadastrada, criando em seguida uma
nova tabela no banco de dados que representará essa estrutura com seus atributos.
Novamente, a conexão é fechada, finalizando o processo.
61
Figura 22. Diagrama de Seqüência: Cadastro de Estrutura
Fonte: os autores.
5.4.4 Cadastro de Atributos

Na Figura 23 é apresentado o processo para a criação de um novo atributo de uma
estrutura APPP.
 Primeiramente, a servlet ExisteAtributoServlet chama a DAO AtributoDAO e certifica-
se que o atributo sendo cadastrado não exista no banco de dados, após o que, a
conexão é fechada.
 Caso o atributo não exista no banco, o cadastro é autorizado. Por meio da
CadAtributoServlet, a DAO AtributoDAO acessa o banco e insere o novo atributo. A
conexão é fechada logo em seguida.
62
Figura 23. Diagrama de Seqüência: Cadastro de Atributos
Fonte: Os autores
5.4.5 Cadastro de Tipos

Na Figura 24 é apresentado o processo para a criação de um novo atributo de uma
estrutura APPP.
 Primeiramente, a servlet ExisteTipoServlet chama a DAO TipoDAO e certifica-se que
o Tipo sendo cadastrado não exista no banco de dados, após o que, a conexão é
fechada.
 Caso o Tipo não exista no banco, o cadastro é autorizado. Por meio da
CadTipoServlet, a DAO TipoDAO acessa o banco e insere o novo Tipo. A conexão é
fechada logo em seguida.
63
Figura 24. Diagrama de Seqüência: Cadastro de Tipos
Fonte: Os autores
5.4.6 Cadastro de documento: Pattern

Na Figura 25 é demonstrado o processo de criação de um documento do tipo Pattern.
 Na interface, o usuário informa os dados do documento a ser inserido.
 A interface então chama a servlet CadPatternServlet que, por sua vez, acessa o banco
por meio da DAO PatternDAO, criando o novo documento.
64
Figura 25. Diagrama de Seqüência: Cadastro de documento Pattern
Fonte: os autores.
5.4.7 Cadastro de documento: Anti-Pattern
Na Figura 26 é demonstrado o processo de criação de um documento do tipo Anti-

Pattern.
 A interface então chama a servlet CadAntiPatternServlet que, por sua vez, acessa o
banco por meio da DAO AntiPatternDAO, criando o novo documento.
Figura 26. Diagrama de Seqüência: Cadastro de documento Anti-Pattern

Fonte: Os autores
65
5.4.8 Cadastro de documento: Persona
Na Figura 27 é demonstrado o processo de criação de um documento do tipo Persona.

 A interface então chama a servlet CadPersonaServlet que, por sua vez, acessa o banco
por meio da DAO PersonaDAO, criando o novo documento.
Figura 27. Diagrama de Seqüência: Cadastro de documento Persona

Fonte: Os autores
5.4.9 Cadastro de documento: APPP Personalizado
Na Figura 28 é demonstrado o processo de criação de um documento do tipo APPP

Personalizado, ou seja, um documento que, além dos atributos básicos, possui outros
atributos exclusivos da estrutura.
 A interface então chama a servlet CadAPPPServlet que, por sua vez, acessa o banco
por meio da DAO GenericDAO, criando o novo documento.
66
Figura 28. Diagrama de Seqüência: Cadastro de documento APPP Personalizado
Fonte: Os autores
5.4.10 Relacionamento
Na Figura 29 é apresentado o processo de relacionamento os documentos.
 Através da interface, o usuário relaciona os documentos manualmente.
 A servlet CadRelacAPPPServlet é responsável por instanciar a DAO
RelacObjetoDAO que então efetua o relacionamento entre os documentos.
 Em seguida, a conexão é fechada.
Figura 29. Diagrama de Seqüência: Relacionamento

Fonte: os autores.
67
5.4.11 Busca
Na Figura 30 é apresentado o cenário de busca de um documento.
 O usuário entrará com os dados com os quais o sistema efetuará a busca por
similaridade.
 Em seguida, a servlet BuscaSimilaridadeServlet instancia a DAO GenericDAO que,
através do método buscaSimilaridade, passa os parâmetros necessários para o cálculo
da similaridade e retorno da função.
 A conexão é fechada.
Figura 30. Diagrama de Seqüência: Busca

Fonte: os autores.
5.4.12 Avaliação
Na Figura 31 é apresentado o processo do cenário encontrado para a realização da
avaliação de uma documentação APPP.
 Primeiramente, através da Servlet CadQuestPreenchServlet o questionário é buscado
bem como todas as suas perguntas e respectivas respostas.
 Após o preenchimento do questionário, este é inserido no banco através da DAO
QuestPreenchDAO, armazenando as respostas do questionário que será utilizada para
o cálculo da média final do documento.
68
Figura 31. Diagrama de Seqüência: Avaliação
Fonte: Os autores.
5.4.13 Ações de Bloqueio

Na Figura 32 é apresentado o processo para bloqueio dos documentos APPP com
avaliações negativas.
 Por meio da Servlet CadQuestPreenchServlet é chamado o método que calcula a
média das notas dadas ao documento através da classe AvaliaObjeto.
 A classe AvaliaObjetivo instancia a DAO Aval_Obj_UserDAO que, por sua vez, insere
insere a avaliação no banco.
 Com a média atualizada, o sistema verifica as regras internas estabelecidas para
executar as ações de bloqueio e envio de email ao autor do documento.
69
Figura 32. Diagrama de Seqüência: Ações de Bloqueio
Fonte: os autores.
70
5.5 Banco de Dados
5.5.1 Modelo Entidade Relacionamento

A Figura 33 demonstra o diagrama MER (Modelo Entidade Relacionamento) do banco de
dados do sistema. Ele foi desenhando em cima das entidades principais do banco, seus
relacionamentos e atributos estão claramente delineados.
Como destacado na Figura 33, foi criada uma estrutura de banco de dados capaz de não
somente armazenar as informações com as quais o sistema lida, mas salvá-las de forma
estruturada e organizada, inclusive utilizando um dicionário de dados próprio.
A necessidade de criação de tal organização se deu pelo fato de trabalharmos com tabelas
criadas de forma dinâmica, uma vez que cada usuário pode criar estruturas de APPP usando
diversos atributos diferentes, com tipos diferentes, na ordem que lhe for conveniente.
Para controlar o acesso e manipulação de dados dessas tabelas criadas de forma dinâmica,
usamos um dicionário de dados capaz de armazenar informações como nomes de tabelas,
nomes e tipos de atributos, permitindo assim a criação e utilização inclusive de procedures
dinâmicas.
71
Figura 33. Modelo Entidade Relacionamento
Fonte: Os autores
72
5.6 Tecnologias Utilizadas
5.6.1 Oracle
O grupo optou por utilizar o SGBD da Oracle pois membros do grupo já estavam
familiarizados com a ferramenta, e o Oracle atendia a todas as necessidades do projeto. A
escolha de qualquer outra tecnologia que não Oracle iria impor aos autores deste projeto de
formatura a necessidade de se adequarem a uma nova curva de aprendizado. Tendo em vista o
curto prazo de entrega proposto do projeto, essa escolha poderia inviabilizar sua conclusão.
5.6.2 Java – JSP

Quando o grupo decidiu que o projeto seria uma ferramenta online, as opções
discutidas foram utilizar alguma linguagem orientada a objetos, como C# da Microsoft em seu
pacote .NET, por exemplo, ou desenvolver o software em Java (JSP e Servlets em um
servidor WEB). Fatos como o grupo possuir fácil acesso a materiais de apoio para Java e a
quantidade de frameworks disponíveis na web para esta tecnologia foram os fatores que
levaram o grupo a optar por esta.
73
6 AVALIAÇÃO DO SISTEMA
6.1 Avaliação da Interface
6.1.1 Avaliação Heurística

O método de Avaliação Heurística de Nielsen (NIELSEN, 1993) consiste em avaliar
uma interface ou um produto segundo regras específicas, descobrindo e avaliando o nível de
severidade para cada erro encontrado. As heurísticas são recomendações em formato de
afirmações e/ou premissas que indicam bons procedimentos de construções de interface,
preservando assim a usabilidade do sistema. Com base nestas heurísticas, o método possui a
capacidade de avaliar um sistema de forma a englobar praticamente todos os seus aspectos,
especialmente aqueles com resultado direto no contentamento do usuário. As dez heurísticas
de Nielsen foram posteriormente adaptadas por Waldez Lima (LIMA, 2003)(LIMA, 2003)
para sistemas que visam ambientes colaborativos, como o SiGePAPP. Abaixo, seguem as
heurísticas utilizadas como base para o teste do sistema (NIELSEN, 1993):
 Retorno: É essencial que o sistema mantenha o usuário informado quanto às

tarefas ou processos que este está executando.
 Falar a Língua do Usuário: É essencial que o sistema utilize de uma

linguagem simples e comum a maioria dos usuários, as mensagens de erro,
advertência e instrução, por exemplo, não devem conter termos técnicos e/ou
de difícil compreensão.
 Saídas Claramente Marcadas: Todas as ações de saída ou cancelamento de

ações e telas devem ser claramente especificadas para o usuário.
 Consistência e Padrões: Os padrões de interface devem seguir princípios de

consistência de forma que o aprendizado do usuário seja otimizado. O
objetivo é tornar o usuário o mais produtivo possível.
 Prevenção de Erros: Evitar que o usuário enfrente uma situação de erro.

Caso este ocorra, o sistema deve apoiar o usuário na resolução do problema.
74
 Minimizar a carga de Memória do Usuário: O sistema deve trazer as
informações importantes para a tomada de decisão dos usuários, evitando
navegação desnecessária entre as telas.
 Atalhos: Prover atalhos visando a melhoria na produtividade.
 Diálogo Simples e Natural: A interface com o usuário deve ser simples e

informações confidenciais não devem ser expostas em lugares indevidos.
 Boas Mensagens de Erro: As mensagens de erros devem ser claras, precisas,

construtivas e amigáveis. O usuário deve ser eficazmente auxiliado pela
mensagem.
 Ajuda e Documentação: Os usuários não conhecem o sistema como um

todo. Um mecanismo de ajuda e documentação apropriada deve estar
disponível.
Vários testes foram feitos nas telas do SiGePAPP. Os erros foram documentados e
classificados de acordo com um grau de severidade (0 a 4) conforme Tabela 6:
Tabela 6. Classificação de Grau de Severidade
Grau Descrição
0 O evento documentado não corresponde a um problema de usabilidade.
1 Trata-se de um problema cosmético. Será corrigido caso sobre algum tempo no projeto.
2 Problema de Usabilidade simples. Corrigi-lo deve ser prioridade baixa.
3 Problema de Usabilidade médio: A correção deve ser considerada como prioridade alta.
4 Problema de Usabilidade grave: A sua correção é essencial antes da liberação do

sistema.
Fonte: Os autores
6.1.2 Testes com o Usuário baseado em Personas

O Teste com Usuário consiste basicamente nos resultados obtidos através dos testes feitos
pelo próprio usuário. Este método agiliza a detecção de erros e melhorias em todo o
desenvolvimento do sistema. (BARANAUSKAS, 2003)
Em (BARANAUSKAS, 2003) os autores descrevem a técnica de testes com usuários
baseado em Personas (TUBAP) e explicam que esta visa facilitar a construção ou
75
reformulação de design de interfaces focando os resultados baseados em perfis reais de
usuários, representados pelas Personas.
Para este teste os seguintes procedimentos foram adotados:
 Definição dos perfis reais dos usuários: Com base nos perfis de usuários que
provavelmente utilizarão o sistema proposto por este projeto de formatura, foi
definido um conjunto de três Personas, sendo estas, Felipe (Professor), Andréia
(Gerente de Projetos) e Matheus (Analista de Sistemas). Os atributos de cada
Persona encontram-se descritos no item 3.3.1.
 Criação das Personas: As Personas foram criadas utilizando-se da estrutura
conforme item 3.3.2
6.1.3 Metodologia de Teste

Cada usuário participante do teste se enquadrou em uma Persona de acordo com seu
perfil real, sendo que estes foram determinados através de um questionário respondido por
cada usuário. Os testes foram executados no LEU-FEI – Laboratório de Engenharia de
Usabilidade – localizado no Centro Universitário da FEI, em São Bernardo do Campo, São
Paulo.
Na Tabela 7 encontra-se delineado as características de cada usuário:
Tabela 7. Usuários
Fonte: Os autores
Grau de Experiência Característica Deficiência Conhece
Usuário Sexo Idade
Escolaridade Informática Pessoal Física APPP
Superior Impaciente e
1 Masculino 21 Avançado Não Sim
Incompleto Detalhista
Pós Detalhista e
2 Masculino 33 Avançado Visão Sim
Graduando Insistente
Superior
3 Masculino 31 Intermediário Insistente Não Não
Incompleto
Pós
4 Masculino 46 Intermediário Calmo Não Não
Graduado
Superior Insistente e
5 Feminino 23 Avançado Não Não
Incompleto Dedicada
Superior
6 Feminino 25 Intermediário Calma Não Não
Incompleto
Superior Dedicado e
7 Masculino 22 Avançado Não Sim
Incompleto Calmo
Superior Impaciente e
8 Masculino 21 Avançado Não Não
Incompleto Insistente
76
Os usuários foram instruídos a executarem uma lista pré-determinada de tarefas
conforme Tabela 8, recebendo algumas instruções:
 As tarefas deveriam ser executadas na ordem em que se encontra;
 O usuário deveria ler cada tarefa em voz alta, antes de executá-la;
 Uma vez iniciada, o usuário poderia desistir da tarefa a qualquer momento;
 Foi instruído que o que estaria sendo avaliado são a interface propriamente dita
e sua usabilidade e não o usuário ou seus conhecimentos.
Tabela 8. Lista de Tarefas

Fonte: Os autores
Tarefa Descrição
1 Se cadastrar no SiGePAPP com seus dados pessoais.
2 Fazer o login no sistema com o usuário e senha cadastrados no item anterior. (Se não for possível,
utilizar: Usuário: “teste” e Senha: “teste”
3 Cadastrar uma estrutura do tipo Pattern, onde o “Nome da Estrutura”deverá ser o seu primeiro nome
e no campo “Descrição”escrever uma frase de no máximo 3 linhas, sobre o que você irá fazer
amanhã. Os seguintes atributos adicionais deverão fazer parte dessa estrutura: Faculdade, Curso,
Semestre, CodigoMatric e Área.
4 Cadastrar uma estrutura tipo Pattern, que é derivado da estrutura cadastrada na Tarefa 3. O campo
“Nome da Estrutura” deverá ser o seu sobrenome e o campo “Descrição” deve conter uma frase de
no máximo três linhas sobre o que você fará na próxima segunda-feira. Os seguintes atributos
adicionais deverão compor essa nova estrutura: “Nome do professor” e “Nota”.
5 Cadastrar uma estrutura do tipo Persona, onde o “Nome da Estrutura” deverá ser o seu nome e o
campo “Contexto” deve conter uma frase de no máximo três linhas sobre o que você fará nas férias.
Os seguintes atributos adicionais deverão fazer parte dessa Persona: “Profissão” e “Cor do cabelo”.
6 Cadastrar um Pattern utilizando a estrutura cadastrada na Tarefa 4. (Se não for possível utilizar a
estrutura da Tarefa 4, escolha a estrutura chamada “Teste2”.
7 Cadastrar uma Persona utilizando a inserida na Tarefa 5. O campo Nome deverá ser o seu nome
completo e o campo “Contexto” deverá ser uma frase de duas linhas sobre o que você gosta de fazer
nas férias. Os demais campos da estrutura deverão ser preenchidos normalmente. (Se não for possível
utilizar a estrutura da Tarefa 5, escolher a estrutura chamada “Teste”.
8 Fazer a busca do “Pattern” cadastrado na Tarefa 6. Utilize algumas palavras chaves que foram
utilizadas no seu cadastro.
9 Faça o logoff do sistema.
77
6.2 Resultados
6.2.1 Usuários por meio das Personas

Após os testes, todos os usuários participantes foram convidados a responderem dez
perguntas sobre o sistema. As questões relacionadas na Tabela 9 exploram a opinião e o nível
de satisfação dos usuários quanto a diversos conceitos como, usabilidade, facilidade de
execução das tarefas, qualidade da interface e outros. As respostas são objetivas e suas
respostas seguem um padrão, o extremo 1 (um) tende para o negativo, significando “Muito
difícil”, “Muito insatisfeito”, “Muito ruim”, “Muito confusa” ou “Nunca utilizarei”,
enquanto que o extremo 7 (sete) tende para o positivo, sendo “Muito fácil”, “Muito
satisfeito”, “Muito útil”, “Muito clara” ou “Utilizarei sempre”.
Tabela 9. Questionário
Pergunta
1 Como você avalia a navegação na interface?
2 Qual o seu nível de satisfação quanto ao uso da página?
3 Como você define a interface?
4 Qual sua opinião em relação às tarefas executadas?
5 Você utilizaria o SiGePAPP futuramente?
6 Qual sua opinião a respeito do Cadastro de APPP?
7 Qual a sua opinião a respeito da Criação de Estruturas?
8 Qual a sua opinião a respeito da Busca de APPP?
9 Como você define a Usabilidade do sistema?
10 Dê uma nota geral para a interface do SiGePAPP.
Fonte: Os autores
As notas dadas pelos usuários fora compiladas e uma média final calculada. A Figura
34 demonstra o resultado final da avaliação.
78
Figura 34. Média de Notas da Avaliação no Teste de Usuário.
Fonte os Autores.
6.2.1.1 Conclusões finais por Perfis de Usuários

Após a finalização dos testes e análise dos resultados, foi possível consolidar os
resultados de acordo com as três Personas estabelecidas, cada uma delas evidenciou
conseqüências inerentes ao seu perfil, possibilitando ajustar o sistema para atender às suas
necessidades.
6.2.1.2 Felipe
Felipe obteve êxito em 67% das tarefas que lhe foram designadas, realizando-as em
aproximadamente 17 minutos. Ele é um usuário muito paciente, característica essa que ficou
evidente no teste. O Felipe destacou-se pelo fato de ter despendido um tempo significativo
navegando nas páginas, lendo e familiarizando-se com as instruções da tela, rótulos e campos
em geral antes de iniciar a primeira tarefa. Apresentou dificuldades com relação ao tamanho
da fonte utilizada nas páginas, o que é característico de seu perfil.
O Felipe não teve sucesso na realização das tarefas 6 e 7. Ambas as tarefas tinham
como objetivo comum cadastrar um novo documento do tipo Pattern e Persona. Foi
observado que o usuário ficou confuso quanto ao o que exatamente deveria ser feito. Sua
confusão ficou evidente quando tentou cadastrar uma estrutura, quando na verdade, deveria
cadastrar um documento a partir da estrutura previamente cadastrada em um das tarefas
anteriores. Ao avaliar o sistema no final do teste, Felipe – mais uma vez – evidenciou sua
necessidade por informações claras e detalhadas, reportando, portanto, a deficiência do
sistema neste quesito. Ademais, o Felipe apreciou muito a facilidade de navegação, a
organização da interface, combinação das cores e efeitos envolvidos.
79
6.2.1.3 Andrea
Andrea obteve sucesso em 68% das tarefas designadas. Por ter um perfil
extremamente detalhista e observador, a Andrea destacou-se por ter sido o usuário que levou
mais tempo para executar as tarefas, finalizando-as em aproximadamente 28 minutos.
Observou-se que devido ao seu perfil de liderança, atitude e conhecimento técnico,
Andrea passou grande parte do teste sugerindo melhorias em voz alta e, ao tempo que
navegava nas telas do sistema, percebia-se que despendia mais tempo do que o necessário,
pois estava paralelamente pensando na parte lógica do sistema, ao invés de concentrar-se
unicamente na realização das tarefas propostas.
A Andrea apresentou dificuldade com as tarefas 6 e 7. Para ela, não ficou claro a
diferença entre o cadastro de uma estrutura APPP e o cadastro do documento propriamente
dito. Após uma breve explicação do avaliador, o usuário conseguiu realizar a tarefa sem
dificuldades. Andrea elogiou a navegação e simplicidade das telas, para ela, o SiGePAPP é
uma ferramenta extremamente útil por parte dos desenvolvedores de sistema, atestando
firmemente que utilizaria a ferramenta em seu dia-a-dia.
6.2.1.4 Matheus
Matheus é o usuário mais representativo entre todos os que participaram dos testes.
Seu perfil de programador coincide com o daqueles que mais utilizarão o sistema. O Matheus
teve sucesso em mais de 70% das tarefas designadas, levando em média 20 minutos para sua
realização.
O Matheus demonstrou o tempo todo como sendo um usuário bastante intuitivo, ao
contrário do que aconteceu com o usuário Felipe ou a Andrea, o Matheus navegou pelas telas
do sistema praticamente pela tentativa e erro, não se importando muito com as instruções
contidas no caminho. Mesmo quando encontrava alguma dúvida buscava a resposta por meio
de sua própria intuição. Outra característica bastante marcante do Matheus é o fato dele
utilizar freqüentemente atalhos, procurava constantemente meios de pular passos e/ou
abreviar o processo convencional. Reportou problemas relacionados à agilidade das telas
como o foco do cursor, a posição default após preenchimento de um determinado formulário
de modo que ao pressionar o ENTER o processo seguisse o fluxo padrão.
Devido à sua experiência e agilidade com a utilização de sistemas em geral, o Matheus
não teve muitas dificuldades com as tarefas como um todo, apresentou ligeira confusão na
tarefa 8 onde deveria buscar o Pattern cadastrado em tarefas anteriores.
80
6.2.2 Conclusão dos testes com Usuários
As Personas utilizadas nos testes evidenciaram a real necessidade que tanto o
SiGePAPP quanto qualquer outro sistema possui de levar em consideração as necessidades de
cada perfil de usuário, conforme corroborado durante o desenvolvimento deste trabalho de
conclusão de curso.
Percebeu-se que tarefas que eram simples e até mesmo corriqueiras para um
determinado perfil, foi indubitavelmente um desafio para um outro tipo de usuário. Ficou
evidente que o desejo de instruir o usuário quanto aos passos a serem tomados deve ir além do
que simplesmente colocar textos explicativos na interface, ação amplamente praticada no
início do desenvolvimento. As Personas tiveram dificuldades em realizar tarefas que eram
literalmente óbvias para os autores, o que, mais uma vez, reforçou a necessidade e
importância dos testes literais com o usuário propriamente dito. Por outro lado, algumas
características foram amplamente elogiadas, o que repercutiu numa aplicação ainda mais
vasta pelo sistema como um todo dessas boas práticas.
Como resultado, algumas alterações foram feitas no sistema, conforme item 6.2.3, e
outras foram incluídas como trabalhos futuros. Os testes com as Personas efetivamente
contribuíram para o sucesso do SiGePAPP.
6.2.3 Melhorias no sistema com o resultado dos testes com Usuários

Os testes com os usuários ajudaram os desenvolvedores deste projeto de formatura a
efetuarem diversas melhorias significativas no sistema, especialmente no que diz respeito à
usabilidade. Dentre as melhorias demonstradas na Tabela 10 e qualificadas como resultado
direto de sugestões e solicitações dos usuários participantes dos testes, destaca-se:
Tabela 10. Melhorias reportadas pelos Usuários
1. O menu de opções localizado à esquerda da tela inicial foi modificado, de modo que
o cadastro de estrutura e de documento (conteúdo) ficou claramente definido e
separado.
2. Foi inserida uma opção em que o usuário ajusta o tamanho da fonte utilizada nos
campos, labels e telas, proporcionando mais conforto na utilização do sistema
3. O campo onde o cursor se encontra no momento da navegação sofre mudança da cor

de fundo.
4. O processo de busca por documentações foi aberto de forma que o usuário pode
81
pesquisar diretamente pelo nome de um documento já conhecido, visualizar todas as
documentações a partir de uma estrutura pré-selecionada ou utilizar da busca por
similaridade através da parte de um texto ou palavra digitada.
5. As mensagens de erro serão mostradas sempre na cor vermelha, indicando

claramente que a mensagem trata-se de um erro, exigindo, portanto, a atenção do
usuário quanto aos próximos passos a serem dados.
No ANEXO I – TELAS PRINCIPAIS pode ser observado como ficaram as telas do

sistema após o teste de usuários.
6.2.4 Heurísticas
Após os ajustes dos erros de usuários, o SiGePAPP passou por uma bateria de testes
baseados nas regras heurísticas definidas no item 6.1.1. Os 6 (seis) itens encontrados estão
entre a Figura 35 e Figura 37 como sendo os mais significativos, estão listados e qualificam-
se como ajustes de trabalho futuro.
Problema 1 Problema 2
Método Utilizado Método Utilizado
AH TUBAP AH TUBAP
Heurística Violada Grau de Severidade Heurística Violada Grau de Severidade

Prevenção de erros Número: 3 Atalhos Número: 3
Persona(s) Afetada(s) Persona(s) Afetada(s)
Felipe Andréia Matheus Felipe Andréia Matheus
Interface Interface
Alteração de Senha Ajuda ao usuário
Atividade na Interface Atividade na Interface

Na tela de alterar senha, clique diretamente no botão "Confirmar" No meio de uma atividade, recorrer ao help, sem sair da tela.
sem digitar nenhum dado nos campos de Senha
Detalhamento do Problema Detalhamento do Problema
O SiGePAPP possibilita clicar no botão confirmar, mesmo sem O SiGePAPP não possui atalhos nas suas telas, facilitando o
digitar nenhuma informação nos campos de senha, não fazendo usuário no entendimento dos conceitos envolvidos na sua
nenhuma verificação se estão em branco. O Sistema ainda mostra atividade.
uma mensagem que a senha foi alterada com sucesso.
Recomendações Recomendações
Fazer verificação no campo, para verificar se o mesmo está em O sistema deve possuir links para as âncoras da página do "Help"
branco quando o usuário clica no botão "Confirmar" facilitando o usuário na leitura e entendimento dos conceitos.
Figura 35. Erro Heurística 1 e 2

Fonte: Os autores
82
AH TUBAP AH TUBAP

Consistência e Padrões Número: 3 Boas Mensagens de Erro Número: 2
Interface Interface
Menu lateral do sistema SiGePAPP Cadastro de Estrutura ou Conteúdo

Clicar no link Cadastro de Documento no menu lateral do sistema Tentar cadastrar uma nova estrutura sem estar logado no sistema.
SiGePAPP no navegador Internet Explorer do Windows
Ao mudar de navegador, o efeito do menu que esconde alguns O SiGePAPP mostra uma mensagem de erro informando ao
links, perde a sensibilidade, dificultando o usuário em clicar no usuário que para cadastrar uma nova estrutura ele deve estar
link. logado, porém cita que para logar o usuário deve ir até o canto
superior direito da página, dificultando ao usuário o entendimento.
Ajustar a sensibilidade do menu ou tirar o efeito de esconder os A página deveria ter algum link direto para o usuário se registrar
links. ou logar, facilitando a navegação.

Fonte: Os autores
Problema 5 Problema 6
AH TUBAP AH TUBAP

Retorno Número: 2 Boas Mensagens de Erro Número: 1
Interface Interface
Cadastro de perguntas e cadastro de respostas de um Cadastro de Conteúdo
questionário.
Cadastar uma nova pergunta ou uma nova resposta. Tentar cadastrar um novo conteúdo deixando um atributo da
estrutura em branco e clicar no botão "Cadastrar"
O SiGePAPP não fornece nenhum tipo de retorno ao usuário da O sistema SiGePAPP retorna uma mensagem de erro para o
ação que está executando. usuário, dizendo que existe campos em branco e que todos devem
ser preenchidos, porém não cita qual o campo que está em
branco, isso facilicitaria o usuário na identificação do campo.
Disponibilizar o retorno da ação que o sistema está executando, Criar uma verificação e na mensagem de erro citar qual o campo
para o usuário não tomar decisões precipitadas. que está em branco.

Fonte: Os autores
6.2.5 Conclusão dos testes Heurísticos

Os testes heurísticos confirmam a necessidade que o usuário possui de um sistema
que, por mais complexo que possa ser, efetivamente o ajude a executar as tarefas com
83
facilidade e simplicidade. Percebe-se que dentre as heurísticas estabelecidas no item 6.1.1
aquelas que tratam exclusivamente da comunicação entre o usuário e a interface são as que
mais foram mencionadas. Conclui-se que para o usuário a interface em si é o próprio sistema
e que se esta não estiver bem alinhada com as necessidades do usuário, todo o sistema corre o
risco de perder seu prestígio e aceitação, a despeito de suas funcionalidades e complexidade.
Os testes heurísticos evidenciaram ainda que as Personas efetivamente agem de maneira
diferente umas das outras, corroborando a variedade de perfis como já explorado neste
trabalho de conclusão de curso. O problema 6, por exemplo, não foi reportado para a Persona
Matheus, uma vez que esta representa um conjunto de usuários mais experientes e práticos do
que os outros. Durante os testes, vários outros erros e melhorias foram detectados sendo que a
maior parte destes foi enquadrada em trabalhos futuros.
84
7 RESULTADOS OBTIDOS
O desenvolvimento deste trabalho de conclusão de curso alcançou resultados

extremamente satisfatórios. Através do SiGePAPP, os conceitos de Patterns, Anti-Patterns e
Personas foram explorados, aplicados e fortalecidos durante todo o seu desenvolvimento. O
projeto culminou com uma ferramenta de auxílio aos desenvolvedores de software no
processo de criação e gestão de documentações de boas e más práticas; tais documentações –
feitas a partir dos conceitos APPP – podem ser associados uns aos outros e aos mais diversos
perfis de usuários.
O SiGePAPP possui ainda diversos recursos que auxiliam seus usuários no
manuseio das documentações, como:
 Criação Personalizada de estruturas APPP;
 Associação direta de nível “n” para “n” entre as documentações;
 Pesquisa básica de documentações;
 Pesquisa avançada por meio da Busca por similaridade;
 Avaliação das documentações pelos usuários do sistema;
 Controle de qualidade por meio do bloqueio de documentos;
Através de conceitos envolvendo o Raciocínio Baseado em Casos, o módulo de busca

por similaridade foi, não só implantado com sucesso, como também sofreu melhorias
significativas ao longo do processo. Dentre estas melhorias destaca-se a inserção de matrizes
na alocação das palavras – e não mais vetores como feito anteriormente – o que contribuiu
significativamente para a melhora de desempenho no retorno dos resultados da busca.
O banco de dados foi implantado através da larga utilização de funções e
procedimentos internos ao banco, contribuindo para o desempenho do sistema, seguindo
regras de normalização e baseado em diagramas de Entidade e Relacionamentos.
O SiGePAPP foi submetido a uma bateria de testes reais, tanto heurísticos como testes
feitos com usuários. Através do estabelecimento de Personas que representaram o perfil real
dos usuários do sistema, diversos usuários participaram dos testes tendo que executar tarefas
pré-estabelecidas e avaliação final, os testes resultaram em uma variedade de correções,
melhorias e sugestões, sendo que boa parte delas foram implantadas na versão final do
sistema. Em geral, o SiGePAPP obteve avaliações positivas por parte dos usuários,
destacando-se sua alta aplicabilidade e facilidade de navegação.
85
8 CONCLUSÃO
O projeto atendeu aos objetivos propostos inicialmente: Explorar os conceitos de

Patterns, Anti-Patterns e Personas, promover uma técnica de apoio aos desenvolvedores
através do relacionamento desses três conceitos e disponibilizar uma ferramenta que gerencie
o relacionamento, busca e avaliação dos documentos APPP.
O SiGePAPP obteve resultados positivos nas avaliações de usuários. Dentre aqueles
que participaram dos testes e preencheram os questionários de resultado, 50% afirmaram que
certamente utilizariam o sistema futuramente, os outros 50% foram todos acima da média. A
interface do sistema também obteve plena aceitação por parte dos usuários, corroborando com
os princípios de usabilidade cobertos por este projeto de formatura, conforme notas
registradas no item 6.2.1.
Durante o desenvolvimento, testes e utilização do SiGePAPP, o grupo percebeu que a
aplicação prática do sistema foi além daquele inicialmente esperado, que era somente restrito
aos desenvolvedores de software. Outras aplicações foram consideradas possíveis, dentre elas
destaca-se as pesquisas, ensino, mecânica, logística e até mesmo algo simples como a
documentação de uma receita culinária.
86
9 TRABALHOS FUTUROS
Com a implantação do SiGePAPP, foram levantados alguns trabalhos futuros que

ajudariam em diversos aspectos como: performance, relacionamentos entre documentos,
segurança, portabilidade e acuracidade dos resultados listadas abaixo:
 Devido ao uso de instruções SQL dinâmicas no banco para consultas entre as
diversas estruturas, constatou-se que haveria a possibilidade de variáveis
internas estourarem a memória, dependendo da quantidade de tabelas
dinâmicas criadas no SBGD.
 Utilização de técnicas de I.A. para geração e relacionamento automatizado de
APPPs.
 Portabilidade entre navegadores.
 Controle de versionamento dos documentos por meio de Data Warehouse, por
exemplo.
 Melhoria do método de avaliação dos documentos.
 Correção dos erros de usabilidade documentados na Avaliação Heurística.
87
REFERÊNCIAS
ABEL, MARA. 1996. Um Estudo Sobre Raciocínio Baseado em Casos. 1996.

AKROYD, M. 1996. Anti Patterns Session Notes. Object World West, San Francisco.
1996.
ALEXANDER, C. et al. 1977. A Pattern Language: Towns, Building, Constructions.
Oxford University Press, New York. 1977.
ANACLETO, J. C., et al. 2007. Cognitor: Um Framework Baseado na Linguagem de
Padrões Cog-Learn. Revista Brasileira de Informática na Educação. 2007, Vols. 15, p. 32/3-
43.
ANDRADE, R. M. C., et al. 2005. IIMPaR – Uma Interface de Integração de
Modelos de Padrões de Software para o Rose. 2005.
AQUINO JR., P.T. 2008. PICaP : padrões e personas para expressão da diversidade
de usuários no projeto de interação. Tese (Doutorado) - Escola Politécnica da Universidade
de São Paulo. Departamento de Engenharia de Computação e Sistemas Digitais. Ed. Rev. -
224p, 2008.
BARANAUSKAS, M. C. and ROCHA, H.V. 2003. Design e Avaliação de Interfaces
Humano-Computador. 2003.
BILJON, J. V., et al. 2004. The use of anti-patterns in human computer interaction.
In: Fulfilling the promise of ICT, Proceedings of SAICSIT 2004, edited by G Marsden, P
Kotze & A Adesina-Ojo. ACM Conference Proceedings Series, SAICSIT, Pretoria. 2004.
BORCHERS, J. 2008. The Aachen Media Space: Design Patterns for Augmented
Work Environments. In Saadi Lahlou, editor, Designing User Friendly Augmented Work
Environments: From meeting rooms to digital collaborative spaces. Springer Verlag, 2008.
BROWN, W. e al., et. 2000. What's an Anti-Pattern? AntiPatterns. 2000.
BUDINSKY, F.J., et al. 1996. Automatic Code Generation from Design Patterns.
IBM Systems Journal 35. 1996.
COOPER, A. e REIMANN, R. M. 2003. About Face 2.0 The Essentials of
Interaction Design. John Wiley & Sons. 2nd edition, 2003.
COOPER, A. 1999. The inmates are running the asylum: Why high-tech products
drive us crazy and how to restore the sanity. Indianopolis, Ind.: Sams. 1999.
COSTA, D. M., et al. 2008. DEAN Compositor de Personagens Fictícios.
Apresentação de Trabalho - Tese de Graduação. 2008.
88
GAMMA, E., et al. 1995. Design Patterns: Elements of Reusable Object-Oriented
Software. s.l. : Addison-Wesley Professional, 1995. ISBN-13: 978-0201633610.
GERBER, L. D. 1999. Uma linguagem de padrões para o desenvolvimento de
sistemas de apoio à decisão baseado em frameworks. Tese de Mestrado apresentada na PUC
- RS. 1999.
GILBRETH, F. B. 1911. Motion study: a method for increasing the efficiency of the
workman. Imprenta New York : D. Van Nostrand Company. 1911.
GRESSE, C. W. 2003. Raciocínio Baseado em Casos. s.l. : Editora Manole Ltda.,
2003. ISBN 85-204-1459-1.
HANMER, R. 2003. Introduction to Pattern Languages. SugarLoafPLoP 2003, The
Third Latin American Conference on Pattern Languages of Programming, Porto de Galinhas,
PE. 2003.
KOTZÉ, P., et al. 2006. Patterns, anti-patterns and guidelines – effective aids to
teaching HCI principles? in E T Hvannberg, J C Read, L Bannon, P Kotzé and W Wong
(eds.), Inventivity: Teaching theory, design and innovation in HCI, University of Limerick.
2006, 115-120.
LIMA, W. T. 2003. Avaliação de usabilidade em sistema colaborativo na área
bancária. 2003.
LONG, J. 2001. Software Resuse Antipatterns. IBM. 2001.
MARINHO, F., et al. 2003. Uma Proposta de um Repositório de Padrões de Software
Integrado ao RUP. III Conferência Latino-Americana em Linguagens de Padrões para
Programação. 2003.
MASIERO, A., et al. 2008. Anti-Patterns Apoiando a Documentação dos Problemas
de Usabilidade. Revista Hífen, SIMS - XIII Simpósio de Informática. 2008, Vol. 32, 62 - ISSN
1983-6511.
MICROSOFT CORPORATION. 2005. Principles of Service Design: Service
Patterns and Anti-Patterns. MSDN. Disponível online em msdn.microsoft.com/en-
us/library/ms954638.aspx, 2005, último acesso em julho/2008.
NIELSEN, J. 1993. Usability Engineering. 1993.
RIESBECK, CHRISTOPHER K. e SCHANK, ROGER C. 1989. Inside case-based
reasoning. Hillsdale, New Jersey : Lawrence Erlbaum Associates, 1989.
SHNEIDERMAN, B. 2000. Universal Usability, Pushing human-computer
interaction. COMMUNICATIONS OF THE ACM. 5, 2000, Vols. 43, pp. 85-91.
89
SILVA, E. R. e SCHIEL, U. 2004. SAMOA Uma Ferramenta Para Detecção de
Padrões de Projetos em Diagramas UML, na WEB. Apresentação de Trabalho/Seminário -
Tese de Mestrado. 2004.
TAYLOR, F. W. 1911. The principles of scientific management. Imprenta New York;
London: Harper & brothers. 1911.
TIDWELL, J. 2006. UI Patterns and Techniques. [Online] 2006. [Citado em: 18 de
Novembro de 2008.] http://www.time-tripper.com/uipatterns/Tree-Table.
WEHMEIER, S. 2000. Oxford Advanced Learner's Dictionary. Oxford : Oxford
University Press, 2000. 6.
90
ANEXO I – TELAS PRINCIPAIS
O SiGePAPP possui uma interface bastante simples e de fácil compreensão. As telas

principais do sistema estão sendo explicadas nesta parte do anexo.
A Figura 38 apresenta a tela inicial do sistema. Mesmo sem ter acessado o sistema por
meio do usuário e senha, o usuário poderá visualizar alguns detalhes dos últimos documentos
cadastrados no sistema.
Figura 38. Tela: Inicial

Fonte: Os autores
A Figura 39 apresenta a tela de cadastro de usuário. Através da verificação imediata do

usuário digitada, consistência de CPF, listagem de cidades de acordo com o estado
selecionado, a usabilidade foi respeitada visando facilitar o cadastro.
91
Figura 39. Tela: Cadastro de Usuário
Fonte: Os autores
A Figura 40, por sua vez, demonstra a tela inicial do cadastro de estruturas.
92
Figura 40. Tela: Cadastro de Estrutura
Fonte: Os autores
A Figura 41 mostra a tela de cadastro de um conteúdo APPP, ou seja, a documentação

propriamente dita. O cadastro inicia-se com a escolha de qual estrutura será utilizada para que
nas próximas telas possa então dar entrada nos dados do documento.
93
Figura 41. Tela: Cadastro de Conteúdo
Fonte: Os autores
A tela de busca está sendo demonstrada na Figura 42. O usuário possui a flexibilidade
de buscar seu documento de digitando parte do nome, contexto, problema ou solução,
podendo ainda buscar uma Persona da mesma forma. O resultado da busca é listado de forma
ordenada de acordo com seu grau de similaridade, conforme Figura 43.
94
Figura 42. Tela: Busca APPP
Fonte: Os autores
Figura 43. Tela: Resultado da Busca

Fonte: Os autores
95

Null

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Null

Transféré par

Droits d'auteur :

Formats disponibles

CENTRO UNIVERSITÁRIO DA FEI

ANDREY ARAUJO MASIERO

SIGEPAPP: PATTERNS E ANTI-PATTERNS ASSOCIADOS À

São Bernardo do Campo

SIGEPAPP: PATTERNS E ANTI-PATTERNS ASSOCIADOS À

Trabalho de Conclusão de curso, apresentado no

São Bernardo do Campo

SiGePAPP: Patterns E Anti-Patterns Associados À Personas

Trabalho de Conclusão de Curso – Centro Universitário da FEI.

SÃO BERNARDO DO CAMPO

incentivo e por acreditar em nosso potencial.

Aos colegas que vivenciaram esta luta em conjunto.

Palavras Chaves: Patterns, Anti-Patterns, Personas, Picaps, Relacionamento.

This project intends to work a technique in order to support software developers. It

Key-words: Patterns, Anti-Patterns, Personas, Picaps, Relationship.

Os conceitos relacionados a este projeto de formatura são utilizados em diversos

Nesta sessão, são apresentados os conceitos de Patterns, Anti-Patterns, Personas e

3.1 Patterns ou Padrões

Nome  O nome de um Pattern deve representá-lo de maneira abrangente.

Problema  Descreve o problema propriamente dito.

Solução  Descreve os elementos que compõem sua solução.

Conseqüências  Descrevem quais são as vantagens, os resultados esperados na utilização

A Tabela 3 apresenta um exemplo prático de um Pattern. Descreve uma boa maneira

From Outlook Express's news reader

3.1.3 Criação de Patterns

3.1.4 Linguagem de Patterns

Figura 1. Grafo da relação entre os padrões

Portanto, uma linguagem de padrões é um conjunto de padrões estruturado

Nome: O nome de um Anti-Pattern deve representá-lo de maneira abrangente.

Outros atributos como: Anti-Patterns relacionados e palavras-chave podem ser

3.2.3 Criação de Anti-Patterns

 Análise e Estudo de Caso: Levantamento dos problemas

Figura 2. Diagrama de processo para criação de um Anti-Patterns

3.3.2 O processo de criação

 Coleta de dados: Para conhecer o usuário, as equipes de projeto devem

 Definir variáveis de Comportamento: Esta etapa inicia o processo de

 Identificar padrões de comportamento significantes: Este passo consiste

 Sintetizar características e metas relevantes: Toda Persona necessita de

 Verificar redundâncias: Devido ao grande volume de informações

 Descrição expandida: A descrição expandida consiste na melhor maneira de

Perfil dos Usuários

Descrição: Felipe possui uma agenda bastante ocupada, está freqüentemente

Descrição: Andréia trabalha numa empresa multinacional onde gerencia

Descrição: Matheus trabalha com programação há vários anos, o que o

3.4 Busca por Similaridade

3.4.2 Similaridade local

Depois de finalizado o processo de adaptação, o caso é então armazenado na base

Nesta seção, é apresentada a metodologia utilizada no sistema. É detalhado o

Figura 3. Metodologia do SiGePAPP

 Novo Cadastro: Conforme descrito no item 4.3.

4.2 Definição da Estrutura

4.3 Inserção de APPP no SiGePAPP

4.4.1 PICAPs – Relacionamento entre Patterns e Personas

4.4.2 Anti-PICAPs – Relacionamento entre Anti-Patterns e Personas

4.4.3 Relacionamento entre Anti-Patterns e Patterns

4.4.4 APPP – Relacionamento entre Anti-Pattern, Pattern e Personas.

Figura 4. Exemplo de PICAP.

4.7 Análise da Avaliação / Ações de Bloqueio

4.7.2 Análise do resultado:

4.8 Processo da Busca por Similaridade

 Similaridade(A, B) = Similaridade(B, A);

Para facilitar a compreensão do processo, deste ponto em diante as duas frases da

Tendo em mãos os textos que serão comparados, o algoritmo executará os seguintes