webcase - ferramenta colaborativa para especificação de requisitos emodelagem de diagramas de...
DESCRIPTION
A ferramenta WebCASE foi desenvolvidapara auxiliar as etapas iniciais da engenharia de software através da elaboração de diagramas decasos de uso e permitir a interação e colaboração entre os responsáveis.TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO
WEBCASE – FERRAMENTA COLABORATIVA PARA ESPECIFICAÇÃO DE REQUISITOS E MODELAGEM DE DIAGRAMAS DE ATIVIDADES
Área de Engenharia de Software
por
Haissam Yebahi
Carlos Henrique Bughi, M.Sc. Orientador
Itajaí (SC), novembro de 2008
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
WEBCASE – FERRAMENTA COLABORATIVA PARA ESPECIFICAÇÃO DE REQUISITOS E MODELAGEM DE DIAGRAMAS DE ATIVIDADES
Área de Engenharia de Software
por
Haissam Yebahi Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Carlos Henrique Bughi, M.Sc.
Itajaí (SC), novembro de 2008
ii
AGRADECIMENTOS
Admito que não foi nada fácil chegar até esta fase, diversas foram as barreiras, falta de recursos,
restando como único suporte o apoio de pessoas que sem dúvida foram essenciais ao longo desses
cinco anos.
Em primeiro lugar agradeço a Deus, por ter me guiado diante de tantas dúvidas mesmo quando a
esperança parecia não ser suficiente e hoje fica como uma grande experiência de vida.
Aos meus pais, Abdala Yebahi e Doralina Comelli, por toda educação e ensinamentos que me
tornaram a pessoa que sou.
A professora Adriana Gomes Alves por auxiliar e permitir a realização dos testes durante sua aula
que tiveram grande importância para verificar o funcionamento da nova versão da WebCASE.
Ao professor Rudimar Luis Scaranto Dazzi, a professora Anita Maria Fernandez da Rocha e a
Marlei Salete Antunes, que me ajudaram desde o início da faculdade.
Ao meu orientador Carlos Henrique Bughi, por confiar na minha capacidade e orientar durante este
ano, com diversas contribuições motivações e cobranças que tornam possível a realização deste
projeto.
A família dos meus grandes amigos Jean Rauwers, “Pai João”, Dalva Rauwers, Daniel Hasse,
Janete Hasse e Hari Hasse, que me auxiliaram e que hoje considero parte da minha família, afinal
tiveram que me agüentar por um bom tempo. Ao futuro aluno do curso de Ciência da Computação,
Bruno Hasse, me ajudando em alguns testes e me apoiando nos momentos de loucura, hoje já ciente
de tudo aquilo que irá passar.
Ao meu amigo Rafael Rauber, pelo auxilio na criação de imagens utilizadas no design da
ferramenta WebCASE.
As demais pessoas, amigos professores, avaliadores que apoiaram e contribuíram para a realização
deste projeto com idéias, sugestões e críticas.
iii
SUMÁRIO
1 INTRODUÇÃO.................................................................................... 10 1.1 PROBLEMATIZAÇÃO ................................................................................... 13 1.1.1 Formulação do Problema............................................................................... 13 1.1.2 Solução Proposta ............................................................................................. 13 1.2 OBJETIVOS ...................................................................................................... 13 1.2.1 Objetivo Geral ................................................................................................. 13 1.2.2 Objetivos Específicos ...................................................................................... 14 METODOLOGIA ..................................................................................................... 15 1.3 ESTRUTURA DO TRABALHO ..................................................................... 17
2 FUNDAMENTAÇÃO TEÓRICA...................................................... 19 2.1 ANÁLISE TÉCNICA DA FERRAMENTA WEBCASE .............................. 19 2.1.1 Funcionalidades............................................................................................... 19 2.1.2 Modelo conceitual e estrutura física do banco de dados............................. 25 2.1.3 Tecnologias ...................................................................................................... 33 2.1.4 Considerações sobre a Ferramenta ............................................................... 43 2.2 ENGENHARIA DE SOFTWARE ................................................................... 43 2.2.1 Requisitos de Software ................................................................................... 45 2.2.2 Engenharia de Requisitos............................................................................... 49 2.2.3 Processos da Engenharia de Requisitos ........................................................ 50 2.2.4 Gerenciamento de requisitos.......................................................................... 58 2.3 DIAGRAMA DE ATIVIDADES...................................................................... 63 2.4 ANÁLISE DE FERRAMENTAS SIMILARES ............................................. 67 2.4.1 Enterprise Architect 6.5 ................................................................................. 68 2.4.2 CONTROLA.................................................................................................... 69 2.4.3 ArgoUML......................................................................................................... 71 2.4.4 SPRES – Ferramenta Case para Especificação de Requisitos. .................. 72 2.4.5 Análise comparativa entre as ferramentas................................................... 74
3 PROJETO............................................................................................. 76 3.1 MODELAGEM DE NEGÓCIO E FUNCIONALIDADES .......................... 76 3.1.1 Requisitos......................................................................................................... 76 3.1.2 Casos de uso..................................................................................................... 79 3.1.3 Diagrama de classes ........................................................................................ 81 3.1.4 Diagrama Entidade-Relacionamento............................................................ 83 3.1.5 Diagrama de atividades .................................................................................. 85
4 IMPLEMENTAção.............................................................................. 87 4.1 BANCO DE DADOS ......................................................................................... 87 4.2 DRAW2D............................................................................................................ 87 4.3 EXTJS................................................................................................................. 88 4.4 LAYOUT ............................................................................................................ 88
iv
5 Apresentação da Ferramenta.............................................................. 90 5.1 MÓDULO DIAGRAMA DE ATIVIDADES.................................................. 90 5.2 ESPECIFICAÇÃO DE REQUISITOS E REGRAS DE NEGÓCIO........... 95 5.2.1 Aprovação de Requisitos ................................................................................ 97 5.3 MATRIZ DE RASTREABILIDADE .............................................................. 98 5.4 ALTERAÇÕES REALIZADAS NA VERSÃO 1.0...................................... 100 5.4.1 Casos de Uso .................................................................................................. 100 5.4.2 Pacotes............................................................................................................ 101 5.4.3 Importação XMI ........................................................................................... 101
6 TESTES E VALIDAÇÃO .................................................................104 6.1 RESULTADOS DE USABILIDADE............................................................. 105 6.2 CONFORMIDADE DOS REQUISITOS E REGRAS DE NEGÓCIO ..... 106 6.3 TESTE DE COMPATIBILIDADE COM NAVEGADORES .................... 108
7 CONCLUSÕES ..................................................................................109 7.1 TRABALHOS FUTUROS.............................................................................. 110
REFERÊNCIAS BIBLIOGRÁFICAS .................................................112
A DETALHAMENTO DE CASOS DE USO......................................118
B DICIONÁRIO DE DADOS...............................................................123
C REQUISITOS DA VERSÃO 1.0 ......................................................131
v
LISTA DE ABREVIATURAS
AJAX Asynchronous JavaScript And XML API Application Programming Interface CASE Computer Aided Software Engineering CGI Common Gateway Interface CSS Cascading Style Sheets DOM Document Object Model ER Entidade Relacionamento DER Diagrama Entidade Relacionamento ERS Especificação de Requisitos de Software FTP File Transfer Protocol HTML Hyper Text Markup Language HTTP Hyper Text Transfer Protocol IEEE Institute of Electrical and Electronics Engineers IIS Internet Information Service JSON JavaScript Object Notation JSP Java Server Pages LGPL Lesser General Public License ODBC Open Database Connectivity OMG Object Management Group PDF Portable Document Format PHP Hypertext Preprocessor POP Post Office Protocol RAD Rapid Application Development RF Requisitos Funcionais RIA Rich Internet Applications RN Regras de Negócio RUP Rational Unified Process RNF Requisitos Não-funcionais SAX Simple API for XML SGBD Sistema Gerenciador de Banco de Dados SQL Structured Query Language SMTP Simple Mail Transfer Protocol TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí W3C World Wide Web Consortium XHTML eXtensible Hyper Text Markup Language XMI XML Metadata Interchange XML Extensive Markup Language
vi
LISTA DE FIGURAS
Figura 1. Cadastro de administradores/analistas. ...............................................................................21 Figura 2. Exemplo de um diagrama de casos de uso. ........................................................................21 Figura 3. Tela de detalhamento de um caso de uso............................................................................22 Figura 4. Gerenciamento de projetos. ................................................................................................23 Figura 5. Chat agregado a ferramenta WebCASE. ............................................................................24 Figura 6. Aprovação de Casos de Uso pelo cliente............................................................................25 Figura 7. Modelo de classes original da ferramenta WebCASE........................................................26 Figura 8. Exemplo de código para inserir informações no banco de dados.......................................27 Figura 9. Framework para conexão ao banco de dados da ferramenta WebCASE. ..........................30 Figura 10. Modelo ER da ferramenta WebCASE. .............................................................................31 Figura 11. Comunicação entre cliente servidor através de um navegador Web.................................34 Figura 12. Exemplo de comunicação utilizando AJAX.....................................................................39 Figura 13. Tabela de dados criada com a biblioteca ExtJS................................................................40 Figura 14. Código para a geração de uma tabela utilizando a biblioteca ExtJS. ...............................41 Figura 15. Pontes entre diferentes ferramentas e empresas. ..............................................................42 Figura 16. Distribuição dos custos envolvidos em projetos de Software...........................................44 Figura 17. Etapas presentes no processo de engenharia de requisitos. ..............................................50 Figura 18. Exemplo de um diagrama de caso de uso. ........................................................................53 Figura 19. Cobertura do gerenciamento de requisitos nas etapas da engenharia de requisitos..........59 Figura 20. Exemplo de matriz de rastreabilidade entre requisitos. ....................................................63 Figura 21. Diagrama de atividades representando uma pesquisa em um sistema de buscas. ............64 Figura 22. Representação de uma atividade ou ação. ........................................................................65 Figura 23. Representação de um estado inicial (esquerda) e um estado final (direita). .....................65 Figura 24. Representação de uma transição por uma seta..................................................................65 Figura 25. Elemento de decisão com dois fluxos (sim/não). .............................................................66 Figura 26. Bifurcação em um diagrama de atividades. ......................................................................66 Figura 27. Particionamento separando as atividades de acordo com o tipo de usuário. ....................67 Figura 28. Especificação de requisitos no Enterprise Architect 6.5...................................................68 Figura 29. Exemplo de diagrama de atividades gerado no Enterprise Architect 6.5. ........................69 Figura 30. Tela principal da ferramenta CONTROLA. .....................................................................70 Figura 31. Matriz de rastreabilidade criada pela ferramenta CONTROLA. ......................................71 Figura 32. Ferramenta Colaborativa ArgoUML. ...............................................................................72 Figura 33. ERS modelada na Ferramenta SPRES..............................................................................73 Figura 34. Modelo de classes modificado da ferramenta WebCASE. ...............................................82 Figura 35. Modelo ER modificado da ferramenta WebCASE...........................................................84 Figura 36. Diagrama de atividades com as novas funcionalidades integradas. .................................86 Figura 37. Novo menu da WebCASE em comparação com o menu da versão anterior. ..................89 Figura 38. Diferentes formas de representação de relacionamento no diagrama de atividades.........91 Figura 39. Menu popup com opções para facilitar a manipulação dos elementos.............................91 Figura 40. Separação de responsabilidades através do particionamento de atividades......................92 Figura 41. Relacionamento entre dois elementos conectando entre duas portas. ..............................93 Figura 42. Cadastro de informações de relacionamento do diagrama de atividades. ........................94 Figura 43. Tela para edição de elemento do diagrama de atividades.................................................95 Figura 44. Diversas opções de filtros em um pacote de requisitos. ...................................................95 Figura 45. Tela de cadastro de requisito. ...........................................................................................96 Figura 46. Cadastro de categorias de requisitos. ................................................................................97
vii
Figura 47. Tela para aprovação/reprovação de requisitos pelo cliente. .............................................97 Figura 48. Comparacão entre a matriz de rastreabilidade da Enterprise Architect (esquerda) e
WebCASE (direita). ...................................................................................................................98 Figura 49. Visualização entre relacionamentos na matriz de rastreabilidade. ...................................99 Figura 50. Relacionamento de um caso de uso com outros elementos. ...........................................100 Figura 51. Nova tela do cadastro de Pacotes....................................................................................101 Figura 52.Gráfico apresentando a relação de eficácia e erros dos módulos desenvolvidos.............105 Figura 53.Gráfico apresentando a conformidade dos requisitos funcionais. ...................................107 Figura 54.Gráfico apresentando a conformidade das regras de negócio..........................................107 Figura 55.Comparação da taxa de transferência com a ativação do modulo deflate no Apache. ....108 Figura 56. Casos de uso do módulo administrador. .........................................................................118 Figura 57. Casos de uso do módulo analista. ...................................................................................119 Figura 58. Casos de uso do módulo cliente......................................................................................122
viii
RESUMO
YEBAHI, Haissam. WebCASE - Ferramenta Colaborativa para Especificação de Requisitos e Modelagem de Diagramas de Atividades. Itajaí, 2008. 149 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2008. O ciclo de vida de um software é formado por diversas atividades que permitem avaliar seu progresso e garantir a realização das tarefas envolvidas na solução de um problema. Manter as informações organizadas em um ambiente de trabalho compartilhado facilitam o gerenciamento e rastreamento das mudanças em um projeto. Como resultados é possível negociar compromissos, melhorar estimativas de prazo, além de diminuir falhas, aumentando a satisfação do cliente e da empresa responsável pelo projeto. Através das ferramentas CASE (Computer Aided Software
Engineering – Engenharia de Software Auxiliada por Computador), é possível realizar as atividades envolvidas nos processos de engenharia de software em um nível de especificação maior, com ênfase na análise, qualidade e produtividade de um projeto. Sua utilização permite facilitar o entendimento humano e a comunicação, onde a técnica empregada para a representação deve ser capaz de expor e simplificar as etapas envolvidas no processo, incluindo informações para seu aprimoramento e real utilização. Seguindo este conceito, a ferramenta WebCASE foi desenvolvida para auxiliar as etapas iniciais da engenharia de software através da elaboração de diagramas de casos de uso e permitir a interação e colaboração entre os responsáveis. Tendo em vista que a versão inicial da WebCASE contemplava uma parte dos processos existentes durante a modelagem de um software, este projeto apresenta a extensão e evolução da ferramenta através da inclusão e integração de três novas funcionalidades: (i) permitir a especificação de requisitos (requisitos funcionais, não-funcionais e regras de negócio), (ii) elaboração de diagramas de atividades e (iii) a geração de matrizes de rastreabilidade entre requisitos funcionais, casos de uso e regras de negócio. A ferramenta conta ainda com um módulo para importação de arquivos XMI (XML-based Metadata
Interchange – Intercâmbio de metadados baseado em XML) gerados pela ferramenta Enterprise Architect 6.5, tornando rápida a migração de informações entre estas aplicações. Entre os diferenciais da ferramenta WebCASE pode-se citar a utilização de recursos open-source que reduzem custos tanto no desenvolvimento, utilização e principalmente pelo fato de ser uma ferramenta desenvolvida para a plataforma Web. A execução e desenvolvimento deste projeto de pesquisa justificam-se por contemplar diversas áreas da Ciência da Computação (e.g., Programação, Engenharia de Software, Banco de Dados) e por possibilitar a evolução de um projeto acadêmico de grande importância, não somente pela inclusão de conceitos até então ausente em ferramentas CASE, mas também como um instrumento de auxílio à disciplina de Engenharia de Software. Palavras-chave: Requisitos de software. Diagrama de atividades. Matriz de rastreabilidade.
ix
ABSTRACT
A software is composed by many activities that allow assess it progress and guarantee all tasks
involved to solve the main problem. Keep information organized in a shared environment, making it
easier to manage and track changes. As results it’s possible to negotiate compromises, improve
estimates of term and also reduce failures and increase satisfaction both for client and company
responsible for the project. The CASE Tools allow perform the activities involved in the software
process in a higher specification level with emphasis on analysis and project with more quality and
productivity. Using Cases tools facilitates human understanding and communication where the
technique employed for representation must be able to explain and simplify all the steps involved in
the process by stakeholders, including information for their improvement and real use. The
WebCASE tool was developed with the purpose to give support for software engineering through
the construction of use case plus the part of interaction and collaboration among stakeholders, with
communication through chat rooms. Once the WebCASE tool embraces only part of the processes
of software modeling, this paper's proposal is to evolve the tool through the inclusion and
integration of three new features, as means to permit the specification of requirements, activity
diagrams and relationship matrix between requirements and use cases. WebCASE also includes a
module to import XMI (XML-based Metadata Interchange) files, generated by the Enterprise
Architect 6.5 Tool, making fast the import of information between these tools. Among the
differentials of WebCASE can site the use of open source resources that reduce the cost both in
development and use, because it’s a tool developed to the Web platform.The execution and
development of this research project are justified for reaching many Computer Science areas, such
as Programming and Software Engineering, as well as for allowing the evolution of an important
academic project, not only due to the inclusion of concepts as yet absent in CASE tools, but also
because it is a support instrument to the Software Engineering subject.
Keywords: Software requirements. Activities diagram. Traceability matrix.
1 INTRODUÇÃO
O aprimoramento de técnicas relacionadas ao gerenciamento de projetos, tem sido
fortemente discutido nas mais diversas áreas relacionadas à engenharia de software. Segundo
Fernandes (2005), um dos principais fatores para a obtenção de sucesso no desenvolvimento de
software, está em realizar uma boa documentação e especificação dos problemas a serem
solucionados. Para isto é necessário que um software passe por uma análise detalhada, dividindo-o
em subproblemas de forma organizada a fim de encontrar os requisitos necessários para seu pleno
funcionamento.
Para Gustafson (2003), um software possui um ciclo de vida formado por atividades
seqüenciais denominadas milestones, onde são produzidos diversos artefatos (e.g., contratos,
avaliações, códigos fontes, documentação para os usuários) com a finalidade de avaliar o progresso
de desenvolvimento do sistema.
Seguindo estes conceitos é possível analisar sua natureza e complexidade, para mais tarde
sintetizar os módulos definidos com maior clareza e menor probabilidade de reestruturação durante
o desenvolvimento. Como vantagens podem-se citar a redução de custos na gestão dos recursos
necessários e a estimativa de prazos dentro de um limite tolerável de tempo, existindo maior
satisfação para o cliente e equipe responsável pelo projeto (PFLEEGER, 2004).
Pesquisas realizadas nesta área comprovaram que uma boa engenharia e documentação,
resultam em produtos melhor sucedidos e menos propícios a falhas, mesmo existindo um aumento
no tempo necessário para seu planejamento (ibidem).
De acordo com Pfleeger (2004) uma maneira eficiente de determinar os requisitos é
identificar seus casos de uso, já que estes elementos estão fortemente interligados. Para Braude
(2005 apud Rech, 2007) um caso de uso descreve de forma simplificada as variadas ações de uma
tarefa dentro de uma aplicação específica, definindo as ações necessárias com base nas diversas
condições encontradas para sua realização. A etapa de identificação dos casos de uso pode ser
auxiliada pela elaboração de diagramas de atividades, que servem para demonstrar o fluxo dos
processos existentes em sistemas.
Conforme citado por Jacquart (2004), o Standish Group, grupo responsável por realizar
investigações de aplicações críticas, conduziu pesquisas na área de projetos de software em mais de
350 empresas e em mais de 8000 projetos. Estas pesquisas apontaram que cerca de 30% dos
projetos eram abandonados antes mesmo de terem sido concluídos e apenas 16% eram entregues
11
dentro do prazo estipulado. Entre os fatores de insucesso, merecem destaque a má especificação e a
modificação dos requisitos durante a etapa de modelagem.
Quatrani (2000) apresenta um conceito sobre a importância de uma boa definição em um
projeto, denominado de Triângulo do Sucesso. Para que um projeto seja bem sucedido é necessário
definir três pontos que devem estar fortemente atrelados entre si: processo, notação e ferramenta. O
processo define a parte responsável pela correta compreensão do problema, a notação é responsável
pela comunicação entre os envolvidos no processo e a ferramenta atua como um quadro de
comunicação, permitindo analisar e descrever os processos necessários.
Atualmente as empresas e responsáveis por projetos de software adotam o uso de
ferramentas CASE (Computer-Aided Software Engineering – Engenharia de Software Auxiliada por
Computador). Estas ferramentas fazem uso de elementos gráficos e linguagem padrão, normalmente
a UML (Unified Modeling Language – Linguagem de Modelagem Unificada), para projetar
softwares de forma completa (PFLEEGER, 2004).
A utilização de ferramentas CASE tem como característica facilitar a compreensão e a
comunicação, onde a técnica empregada para representação das informações deve ser capaz de
expor e simplificar as etapas envolvidas no processo (SILVA; ROCHA, 1998).
Quatrani (2000) aponta a interação entre os envolvidos (e.g., desenvolvedores, analistas,
clientes) como tarefa fundamental realizada desde o início do projeto, definindo como os problemas
e processos serão resolvidos, transformando-os em operações realizadas pelo computador através de
um software.
Com a internet novos conceitos surgiram para a comunicação e realização de tarefas, de
forma descentralizada e geograficamente distribuída, denominada modelo de comunicação
colaborativa (COLOSSI; QUEIROZ; CONSENTINO, 2001). Este modelo permite que a interação
entre as pessoas continue de forma produtiva, existindo cooperação e coordenação por parte dos
participantes em um espaço de trabalho compartilhado, através da negociação de compromissos e
conhecimento (GEROSA; RAPOSO; FUKS, 2002).
As ferramentas existentes no mercado para modelagem de sistemas, nem sempre possuem
uma maneira simples e flexível de realizar o compartilhamento das informações entre os envolvidos
em um projeto de software. Como alternativa a este cenário, o acadêmico do curso de Ciência da
Computação da Universidade do Vale do Itajaí, Vagner Rech, desenvolveu uma ferramenta CASE
em seu trabalho de conclusão de curso no ano de 2007. Como característica principal, a ferramenta
denominada WebCASE reúne a parte de comunicação e planejamento de projetos de software em
um único ambiente (RECH, 2007).
12
Segundo Rech (2007), o objetivo da ferramenta WebCASE consiste em suprir algumas
necessidades relacionadas à colaboração entre usuários e analistas durante a modelagem de um
sistema através da Internet, para acelerar os processos de correção e aceitação por parte do cliente.
A WebCASE foi desenvolvida com o propósito de auxiliar a engenharia de software através
da documentação de diagramas de casos de uso contendo atores, cenários, pré-condições, pós-
condições, histórico de atualizações, comunicação entre os usuários, através de salas de bate papo
(chats) e aprovação dos casos de uso pelos clientes.
Sua utilização estende-se como uma ferramenta de apoio ao ensino da disciplina de
Engenharia de Software, para permitir uma melhor visão do negócio e facilitar a compreensão dos
diagramas de caso de uso, visto que muitas das ferramentas existentes no mercado possuem alto
custo para aquisição.
Sabendo-se que a versão inicial da ferramenta WebCASE contempla somente uma das
etapas existentes na modelagem de software, a proposta deste trabalho consiste na evolução da
ferramenta através da inclusão de três novos módulos: (i) módulo para especificação de requisitos
(requisitos funcionais, não-funcionais e regras de negócio); (ii) módulo para elaboração de
diagrama de atividades; e (iii) módulo para geração de matriz de rastreabilidade entre: requisitos
funcionais, casos de uso e regras de negócio;
Através da especificação dos requisitos e regras de negócio, é possível descrever as
principais funcionalidades e recursos de um software, definindo o que ele poderá fazer além de
relacionar suas restrições e aspectos pertinentes ao negócio (SOMMERVILLE, 1997 apud
QUIRINO, 2005).
Os requisitos podem ser divididos em dois grupos: (i) os funcionais que descrevem as
funcionalidades do software, o que ele irá executar; e (ii) os não-funcionais, utilizados para
descrever aspectos relacionados às necessidades envolvidas em relação aos usuários e equipamentos
(e.g., usabilidade, desempenho, confiabilidade, hardware, segurança) (CONALLEN, 2003 apud
QUIRINO, 2005).
A elaboração de um diagrama de atividade tem como objetivo demonstrar o fluxo seqüencial
das ações em um processo do sistema, possibilitando de maneira alternativa expressar como,
quando e onde elas acontecem. Sua representação é feita utilizando-se elementos gráficos visuais,
entre os principais podem ser citados os estados iniciais, estados finais, atividades e elementos de
decisão que permitem decidir um fluxo alternativo para uma determinada ação (LIMA et al., 2000).
13
Uma forma de verificar se os requisitos de software encontram-se contemplados pelos casos
de uso é através da rastreabilidade entre estes elementos. Utilizando as matrizes de rastreabilidade é
possível visualizar o relacionamento entre os componentes do projeto (e.g., requisitos funcionais,
não-funcionais, regras de negócio, casos de uso) (KOTONYA; SOMMERVILLE 1997 apud
QUIRINO, 2005).
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Tratando-se de projetos de software, a utilização de ferramentas CASE colaborativa para
auxiliar de forma eficiente a produção de sistemas, possui diversos fatores a favor, já que muitas das
etapas existentes podem ser executadas pelos envolvidos durante o processo.
Existem hoje no mercado, diversas ferramentas disponíveis para a elaboração de diagramas
de atividades e para a especificação de requisitos, porém o acesso descentralizado e em tempo real
permanece um tanto quanto ausente, pois muitas vezes as informações necessitam ser
desmembradas da ferramenta em que foram projetadas, para posteriormente serem avaliadas pelas
equipes envolvidas.
1.1.2 Solução Proposta
A execução e desenvolvimento deste projeto de pesquisa justificam-se por contemplar
diversas áreas da Ciência da Computação, como Programação e Engenharia de Software, bem como
por possibilitar a evolução de um projeto acadêmico de grande importância não somente pela
inclusão de conceitos ausentes na ferramentas, mas também como um instrumento de auxílio à
disciplina de Engenharia de Software.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Integrar novas funcionalidades à ferramenta WebCASE, para permitir a especificação de
requisitos, modelagem de diagramas de atividades e geração de matrizes de rastreabilidade entre os
elementos (requisitos funcionais, regras de negócio e casos de uso).
14
1.2.2 Objetivos Específicos
• Pesquisar e analisar soluções similares de ferramentas de modelagem;
• Analisar e compreender o funcionamento da ferramenta WebCASE;
• Pesquisar os conceitos e tecnologias necessárias à continuidade do projeto;
• Estudar os conceitos relacionados ao gerenciamento, especificação e processos da
engenharia de requisitos;
• Estudar a notação UML com ênfase nos diagramas de atividades;
• Determinar os requisitos exigidos pelo sistema;
• Realizar a modelagem conceitual do sistema;
• Implementar o sistema;
• Módulo para modelagem de Diagrama de Atividades;
• Nó inicial e final;
• Atividades;
• Bifurcação (fork); e
• Nó de decisão.
• Módulo para especificação de requisitos, e regras de negócio;
• Descrição Requisito/Identificadores;
• Status/Prioridade/Estabilidade/Dificuldade;
• Cadastro de tipos de requisito; e
• Aprovação/Rejeição pelo cliente.
• Matriz de Rastreabilidade
• Rastreabilidade entre requisitos funcionais, regras de negócio e casos de uso;
• Importação de informações geradas pela ferramenta Enterprise Architect versão 6.5 através da especificação XMI 2.1 (XML-based Metadata Interchange – Intercâmbio de metadados baseado em XML) para diagramas de atividades e requisitos de software.
• Testar e validar a implementação do sistema através de um caso de teste aplicado aos alunos
da disciplina de engenharia de software do curso de Ciência da Computação da UNIVALI,
para validar a usabilidade de todas as funcionalidades e conformidade dos requisitos e regras
de negócio; e
• Documentar o desenvolvimento e os resultados alcançados.
15
Metodologia
Para a realização do presente projeto, sua estrutura foi dividida em seis grandes etapas
listadas abaixo:
• Levantamento bibliográfico: Estudo das funcionalidades a serem adicionadas na
ferramenta, a fim de contemplar os requisitos propostos. Os conceitos envolvidos no projeto
são documentados nesta etapa, para permitir maior clareza e viabilizar sua conclusão.
• Fundamentação sobre os processos envolvidos na engenharia de requisitos, juntamente
com a relação das funcionalidades já presentes na ferramenta WebCASE e estudo das
características presentes na especificação de software segundo o padrão IEEE 830-1998;
• Fundamentação teórica sobre gerenciamento, mudanças de requisitos e metodologias
aplicadas ao rastreamento de requisitos de software através das matrizes de
rastreabilidade;
• Fundamentação teórica sobre a estrutura e elementos presentes nos diagramas de
atividades definidos pela UML; e
• Pesquisa de ferramentas similares existentes no mercado com as novas funcionalidades
propostas, para permitir melhor comparação e especificação dos requisitos seguindo
características presentes em ferramentas CASE.
• Análise Técnica: Estudo da ferramenta WebCASE com o objetivo de compreender seu
funcionamento, verificando as necessidades para se adaptar ao requisitos deste projeto e
analisando as tecnológicas envolvidas no ambiente proposto, suas particularidades e
compatibilidades.
• Execução da ferramenta, estudo da documentação e códigos fontes disponíveis;
• Estudo das tecnologias utilizadas na ferramenta: JSON (JavaScript Object Notation –
Notação de Objetos em JavaScript), framework Ext JS, JavaScript, PHP e MySQL; e
16
• Pesquisa do padrão para gerenciamento de objetos e troca de informações baseadas no
padrão XML (Extensible Markup Language – Linguagem de Marcação Extendida) em
ferramentas de modelagem UML através da especificação XMI.
• Levantamento de Requisitos e Modelagem: Definição dos requisitos e funcionalidades da
ferramenta proposta.
• Definição dos requisitos e regras de negócio necessário para contemplar o
funcionamento do sistema proposto;
• Modelagem UML do sistema seguindo as metodologias apresentadas em livros. A
análise deverá abranger a especificação e componentes de software necessários para
adicionar os módulos propostos no escopo do trabalho. Para isto serão modelados e
alterados se preciso, os casos de uso, diagramas de classe e diagramas de atividades; e
• Alteração do modelo ER (Entidade Relacionamento) para o banco de dados com o
objetivo de se adaptar às novas funcionalidades da ferramenta.
• Desenvolvimento: Desenvolvimento do sistema, ou seja, alteração da solução existente, que
posteriormente passará por testes e validação.
• Alteração da estrutura do banco de dados, adicionando novas tabelas para suprir as
necessidades do sistema; e
• Implementação dos módulos propostos de acordo com a definição dos requisitos. Todo o
desenvolvimento deve seguir a modelagem realizada e as funcionalidades descritas no
escopo do trabalho.
• Testes e Validação: Realização de testes e validações sobre a solução proposta, verificando
suas funcionalidades e corrigindo-as caso seja necessário.
• Realização de testes das novas funcionalidades com alunos do curso de Ciência da
Computação da UNIVALI, que estejam cursando uma das disciplinas de engenharia de
software. Serão avaliados os novos serviços implementados, analisando se os mesmos
alcançaram os resultados esperados; e
17
• Testes de integração com as funcionalidades existentes, através da definição e aplicação
de um estudo de caso para certificar-se que a ferramenta executa suas funções
inicialmente propostas nesta nova versão.
• Documentação: Ao longo do projeto são registrados os passos executados desde o
levantamento do problema, a fundamentação teórica, a proposta de uma nova solução, o
desenvolvimento, testes, validações, os resultados finais e conclusões. Essa documentação
deve permitir que outros pesquisadores possam compreender a solução, acrescentar novas
funcionalidades em versões futuras e efetuar os mesmos experimentos e testes feitos para
sua validação.
1.3 Estrutura do trabalho
No primeiro capítulo é apresentada uma introdução sobre o projeto, objetivos e a devida
importância na área de Ciência da Computação, como uma ferramenta para facilitar o estudo da
engenharia de software e auxiliar analistas de sistema nas etapas iniciais em projetos de software.
No segundo capítulo (Fundamentação Teórica), são definidos os principais conceitos
relacionados ao projeto, tecnologias e funcionalidades presentes na fase atual da ferramenta
WebCASE, conflitos encontrados entre o modelo teórico e implementação para facilitar a
compreensão das etapas descritas, além de ser realizado um estudo sobre algumas ferramentas
similares disponíveis.
O terceiro capítulo (Projeto) descreve as fases envolvidas no desenvolvimento das novas
funcionalidades à ferramenta WebCASE, sua documentação, diagramas de atividade da UML,
requisitos e regras de negócio, diagrama de classes e modelo ER do banco de dados com a nova
estrutura contendo as modificações realizadas para suprir as necessidades da nova versão.
No quarto (Implementação) e quinto (Apresentação da Ferramenta) capítulo são
apresentados os resultados obtidos durante a implementação dos módulos propostos, descrevendo o
as funcionalidades implementadas.
O sexto capítulo apresenta os resultados dos testes aplicados com alunos do curso de
Ciência da Computação para avaliar a usabilidade e conformidade dos requisitos e verificar o
funcionamento da ferramenta nos principais navegadores.
18
O sétimo e último capítulo apresenta as conclusões, dificuldades encontradas durante o
desenvolvimento e sugestões para trabalhos futuros que possam aprimorar e expandir as
funcionalidades presentes na ferramenta.
19
2 FUNDAMENTAÇÃO TEÓRICA
Neste capitulo são estudados e analisados os conceitos envolvidos no projeto de acordo com
a proposta inicial e assim servir como base para seu desenvolvimento.
A seção 2.1 apresenta um estudo técnico sobre a ferramenta WebCASE, suas
funcionalidades e tecnologias utilizadas.
Na seção 2.2 são apresentados os problemas e motivações da necessidade de gerenciar
projetos de software, a definição de requisitos, a engenharia de requisitos abordando seus quatro
processos, algumas das principais técnicas utilizadas no reconhecimento de requisitos e as
principais características propostas pelo padrão IEEE 830-1998 para especificação de requisitos.
Na seção 2.3 são apresentados os fundamentos sobre diagramas de atividades da UML
juntamente com a notação dos seus elementos.
Por fim, na seção 2.4, são exemplificadas algumas ferramentas CASE disponíveis no
mercado, com as características presentes no foco deste trabalho através de uma tabela comparativa.
2.1 Análise técnica da Ferramenta WebCASE
Com o propósito de analisar e compreender a ferramenta WebCASE, realizou-se um estudo
de seu funcionamento, documentação, funcionalidades presentes na versão inicial, integração dos
novos objetivos com os já existentes, além da modelagem conceitual e tecnologias utilizadas no
desenvolvimento. Esta análise visa verificar as possíveis implicações e modificações necessárias
para atender as necessidades dos novos módulos propostos que estarão presentes ao final deste
projeto.
2.1.1 Funcionalidades
Desenvolvida para auxiliar no processo de modelagem de casos de uso em projetos de
software, a ferramenta WebCASE permite que desenvolvedores, analistas e clientes, interajam de
forma descentralizada e colaborativa em um projeto durante as etapas iniciais de elaboração,
mantendo um histórico de atualizações e permitindo trabalhar de forma concorrente sobre um
mesmo projeto (RECH, 2007).
20
A ferramenta WebCASE possui opções diferenciadas de acordo com o tipo de usuário
autenticado (cliente, analista e administrador). As seções seguintes foram baseadas no trabalho de
conclusão de curso do acadêmico Vagner Rech e apresentam as funcionalidades presentes na
ferramenta em sua versão inicial (RECH, 2007).
2.1.1.1 Perfil de usuário
O controle de acesso e realizado por nível de usuário divididos em três categorias, cada qual
com suas devidas permissões.
• Administrador: É o perfil com maior número de funcionalidades dentro do sistema.
Permite consultar, cadastrar, alterar e excluir administradores e analistas (Figura 1),
gerenciar projetos e definir os analistas responsáveis pelos mesmos. Um administrador
pode executar as funcionalidades presentes no perfil Analista, mas não do perfil Cliente;
• Analista: Grupo de usuários que podem abrir projetos, adicionar e remover pacotes,
cadastrar clientes, modelar e desenhar diagramas de casos de uso com seu respectivo
detalhamento, além de permitir importar diagramas de casos de uso da ferramenta
Enterpise Architect versão 6.5 através de arquivos XMI na versão 2.1; e
• Cliente: Este é o perfil de usuário com o menor número de funcionalidades disponíveis,
entre suas ações estão à aprovação e rejeição de casos de uso, realização de anotações e
participação no sistema de bate papo presente na ferramenta.
21
Figura 1. Cadastro de administradores/analistas.
2.1.1.2 Desenhar e detalhar diagramas de casos de uso
Módulo principal do sistema (Figura 2) permite aos analistas de um projeto criar os
diagramas inserindo casos de uso, atores e realizar a associação entre os elementos (associação,
generalização, inclusão e extensão).
Figura 2. Exemplo de um diagrama de casos de uso.
22
Em relação ao nível de detalhamento (Figura 3), é possível inserir informações sobre cada
caso de uso como cenários, observações, condições e a liberação para aprovação pelo cliente. Existe
na ferramenta um controle que permite a edição de um caso de uso por apenas um analista
simultaneamente até que o mesmo seja liberado.
Figura 3. Tela de detalhamento de um caso de uso.
2.1.1.3 Gerenciar Projetos
Permite aos usuários com perfil administrador adicionar novos projetos ou excluir projetos
existentes. Conforme apresentado na Figura 4, no momento da inclusão de um novo projeto, é
possível definir quais serão os analista já cadastrados, que participarão do projeto, podendo ainda
para um analista participar de diversos projetos.
23
Figura 4. Gerenciamento de projetos.
2.1.1.4 Bate Papo (chat)
A ferramenta conta com um sistema de chat para facilitar a comunicação entre os usuários,
sem a necessidade de utilizar um sistema externo. Este fator é relevante já que a colaboração é uma
das características presentes na WebCASE.
A Figura 5 apresenta a tela do chat que permite aos usuários da ferramenta WebCASE,
acessar o sistema de bate papo, visualizar e trocar mensagens (on-line). As mensagens enviadas
ficam armazenadas mantendo um histórico das conversas realizadas.
24
Figura 5. Chat agregado a ferramenta WebCASE.
2.1.1.5 Importação de arquivos XMI
A importação de diagramas de caso de uso de outras ferramentas é feito através do módulo
de importação utilizando arquivos no padrão XMI 2.1. Atualmente existe apenas suporte para
importação de arquivos gerados pela ferramenta Enterprise Architect na versão 6.5, sendo esta
restrição mantida neste projeto.
2.1.1.6 Aprovação de casos de uso
Após um caso de uso ter sido liberado por um analista, é permitido ao cliente acessar um dos
projetos em que se encontra cadastrado e assim aprovar ou rejeitar o caso de uso, adicionando se
preciso um comentário para o analista (Figura 6).
25
Figura 6. Aprovação de Casos de Uso pelo cliente.
2.1.2 Modelo conceitual e estrutura física do banco de dados
Uma importante etapa na análise da ferramenta consiste no estudo das classes e estrutura do
banco de dados presente na primeira versão ( Figura 7). Na seqüência é apresentado um breve
detalhamento do modelo de diagrama de classes da ferramenta, com o objetivo de identificar sua
utilização.
26
Figura 7. Modelo de classes original da ferramenta WebCASE.
Fonte: Rech (2007).
A seguir são descritas as classes presentes no modelo proposto por Rech (2007)
desenvolvidas tanto do lado cliente utilizando-se a linguagem JavaScript quanto do lado servidor
através da linguagem PHP.
• wcObject: Responsável por definir os atributos e métodos comuns a todas as demais
classes existentes no modelo. Entre as operações possíveis estão: inserir, atualizar,
remover, listar informações de acordo com o objeto. Na Figura 8, um objeto do tipo
wcElement é criado conforme o parâmetro passado ao método setTable na linha 12 e
seus atributos enviados na linha 14 para o método insert da classe wcObject, responsável
por gravar as informações no banco de dados. Isto permite que através de uma única
classe qualquer ação possa ser realizada no meio de persistência. Estas classes
27
encontram-se implementadas tanto do lado servidor através do arquivo
wcObject.class.php quanto do lado cliente através do arquivo object.js;
Figura 8. Exemplo de código para inserir informações no banco de dados.
• wcElement: Para qualquer elemento adicionado a um pacote a classe wcElement
herdada da classe wcObject é responsável por representar as características básicas de
um elemento como descrição, dimensões, posicionamento na tela. Encontra-se
implementada do lado cliente no arquivo package.js, contendo os métodos comuns de
manipulação de elementos do pacote (e.g., caso de uso, atores), permitindo posicionar,
redimensionar e gravar os atributos para cada elemento. No modelo de classes atual
existem apenas duas classes especialistas de wcObject dentro do arquivo package.js já
que somente casos de uso e atores estão presentes na ferramenta e representadas por
wcUseCase e wcActor;
• wcUseCase: Responsável por definir um caso de uso que necessariamente deve estar
presente em um projeto.
• wcActor: Representar um ator dentro de um pacote, onde todas as suas propriedades são
herdadas de wcElement e não possui informações adicionais. Em sua implementação
existem métodos específicos para adicionar e renomear um ator.
• wcUser: Classe herdada da classe wcObject é responsável por definir um usuário do
sistema formada por atributos que definem as principais características presentes nos três
tipos de usuários da ferramenta (administrador, analista e cliente) e os métodos que
28
permitem realizar as funções de acordo com o perfil de acesso de cada usuário.
Encontra-se implementada no lado servidor através do arquivo wcUser.class.php para
permitir pesquisar e controlar as informações de um usuário no banco de dados e no lado
cliente implementada no arquivo user.js, responsável por criar as requisições que serão
encaminhadas para o servidor de aplicação;
• wcAdministrator: Classe especialista de wcUser responsável por definir as operações
de um administrador do sistema como, manter projetos, cadastrar e definir os analistas
do mesmo. Conforme a modelagem inicial, encontra-se implementada somente do lado
cliente no arquivo adm.js, porém ao invés de estender da classe wcAnalyst de acordo
com o modelo esta estendendo da classe wcUser;
• wcAnalyst: Classe especialista de wcUser, é responsável por adicionar funcionalidades
aos analistas de um projeto, permitindo desenhar, detalhar casos de uso e cadastrar
clientes em um projeto. Encontra-se implementada somente no lado cliente no arquivo
analyst.js;
• wcClient: Classe especialista de wcUser responsável por representar um cliente do
sistema, possui a funcionalidade de aprovar, rejeitar e comentar os casos de uso de um
projeto vinculado a este cliente pelo analista. Encontra-se implementada no lado cliente
no arquivo client.js;
• wcProject: Classe responsável por representar um projeto criado na ferramenta, como
também herda da classe wcObject possuindo um único atributo para armazenar a
descrição de um projeto. Permite adicionar pacotes, definir clientes e analistas presentes
em um projeto. Implementada do lado servidor através da classe wcProject.class.php, é
responsável por criar objetos que serão inseridos no banco de dados, já no lado cliente
encontra-se modelada no arquivo project.js, que possui todas as funcionalidades
relacionadas aos projetos;
• wcPackage: Permite representar um pacote ou adicionar novos pacotes e casos de uso a
um projeto. A existência de subpacotes não é necessária, mas para poder inserir casos de
uso e atores é necessário que exista ao menos um pacote. Esta classe encontra-se
implementada do lado cliente através do arquivo package.js que possui todas as
operações possíveis em um pacote. Nesta classe existem diversas funções responsáveis
29
por tratar as operações realizadas em um pacote como movimentação de elementos na
tela (e.g. drag and drop), redimensionamento, relacionamento entre elementos, criação e
remoção do pacote, etc;
• wcConstraint: Classe responsável por representar as pré-condições e pós-condições de
um caso de uso. Encontra-se desenvolvida no lado cliente dentro do arquivo
analyst_dialogs.js, entre seus métodos estão montar e exibir as telas para cadastro de
condições de um caso de uso;
• wcScenario: Representa um cenário presente em um caso de uso, também possui um
atributo para adicionar uma descrição e outro para informar o tipo de cenário (e.g.,
principal, alternativo, exceção) e está implementada dentro do arquivo analyst_dialogs.js
contendo os métodos para exibir e cadastrar a tela de cenários de um caso de uso; e
• wcLink: Classe responsável por representar e definir o tipo de conexão pelo atributo
mode (e.g., associação, inclusão, exceção) entre dois objetos da classe wcElements. Sua
implementação no lado cliente foi realizada dentro do arquivo package.js que possui
como funcionalidades, desenhar, remover, verificar o tipo de conexão entre os elementos
e adicionar um texto informando o tipo de conexão representada.
A classe de importação e tratamento de arquivos XMI encontra-se implementada, porém não
referenciada dentro do modelo de classes da ferramenta WebCASE. Representada pelo arquivo
wcXMI.class.php no lado servidor, é responsável por tratar o arquivo escrito em XML e inserir as
informações no banco de dados para serem acessadas através de um projeto;
Segundo Rech (2007) um framework de persistência de dados foi desenvolvido com o
objetivo de acelerar e facilitar manutenções nos processos de consulta ao banco de dados, utilizando
os conceitos de orientação a objeto, o framework é formado por seis classes, apresentadas no
diagrama da Figura 9 e descritas abaixo:
30
Figura 9. Framework para conexão ao banco de dados da ferramenta WebCASE.
Fonte: Rech (2007).
• wcDBConfig: Classe responsável por armazenar as informações de conexão com o
banco de dados como usuário, senha, host e database;
• wcDBConnection: Classe responsável por realizar a conexão com o banco de dados
utilizado pela ferramenta WebCASE, possui funções para abrir, fechar e selecionar a
conexão ativa com o banco de dados;
• wcFields: Classe que salva os campos retornado de uma consulta ao banco de dados ou
os campos que serão inseridos através de um comando insert ou update;
31
• wcDBQuery: Classe responsável por executar as instruções SQL, é formada por dois
métodos, um para realizar consultas e outro para inserir, remover e editar informações no
banco de dados; e
• wcMySQL: Classe que realiza a conexão com o banco de dados MySQL.
Na Figura 10 é apresentado o DER (Diagrama Entidade Relacionamento) do banco de dados
da ferramenta WebCASE, onde a descrição das tabelas geradas é exemplificada na seqüência.
Figura 10. Modelo ER da ferramenta WebCASE.
Fonte: Rech (2007).
• wcPackage: Armazena os pacotes ou subpacotes existentes em um projeto para permitir
modelar um diagrama de casos de uso na ferramenta. Apesar de não estar presente no
32
modelo lógico, esta entidade conta com um campo identificador (package_ea_id), utilizado
nos caso de importação de um arquivo XMI;
• wcElement: Armazena os elementos da UML (para a fase atual existem os casos de uso e
atores) de um diagrama de caso de uso. O campo identificador (element_ea_id), utilizado
em uma importação de arquivo XMI, encontrava-se presente somente no modelo físico do
banco de dados;
• wcProject: Entidade que armazena os projetos cadastrados na ferramenta, é formado pelo
nome e descrição do projeto;
• wcProjectHasWcUser: Entidade gerada a partir da relação de wcProject e wcUser, permite
relacionar um usuário do sistema a vários projetos;
• wcUser: Entidade responsável por armazenar as informações dos usuários com acesso ao
sistema, como analistas, clientes e administradores;
• wcLink: Armazena o relacionamento e tipos de associação (e.g., associação, inclusão,
extensão) utilizados entre casos de uso e atores;
• wcClientComment: Armazena os comentários realizados pelos clientes em um caso de uso
juntamente com a data da realização do mesmo. No modelo lógico, esta entidade possui uma
chave estrangeira para a entidade wcElement, porém no modelo físico do banco de dados
encontra-se relacionada à entidade wcHistoricalElement;
• wcHistoricalElement: Armazena informações de quem e quando realizou modificações nos
elementos (casos de uso e atores). Quando um caso de uso é aprovado, um novo histórico é
gerado, mantendo um histórico das modificações realizadas no seu escopo.
• wcConstraint: Armazena as pré-condições e pós-condições dos casos de uso. Cada
condição, relaciona-se somente a um caso de uso e é formada pelo tipo da condição e a
respectiva descrição; e
• wcScenario: Define um cenário pertencente a um único caso de uso, armazenando o nome
do cenário, tipo e descrição.
33
2.1.3 Tecnologias
Projetada para ser executada na plataforma web, independente do sistema operacional, a
ferramenta WebCASE foi desenvolvida utilizando-se de tecnologias modernas e conceitos recentes,
(e.g., Web 2.0, RIA (Rich Internet Applications – Aplicações Ricas para Internet)). Para acessar o
sistema é necessário apenas um computador conectado ao servidor de aplicação e um navegador
web como o Firefox (2.0 ou superior) ou Internet Explorer (5.5 ou superior). Navegadores web ou
Web Browsers são aplicações executadas em um computador (cliente), que permitem exibir
conteúdos dinâmicos de páginas disponibilizadas em outros computadores (servidores). Seu acesso
pode ser realizado de duas formas, através de uma rede local ou através de conexões remotas pela
internet, que utilizam como meio de comunicação um protocolo de transferência de hipertexto
(COSTA, [200-?]).
São explicadas, na seqüência, as tecnologias utilizadas no desenvolvimento da ferramenta,
tanto do lado cliente quanto do lado servidor. Vale ressaltar que a maioria das soluções presentes
são open-source1 e de grande utilização e aceitação pelos desenvolvedores com foco em aplicações
web.
2.1.3.1 Servidor Web
Para permitir a comunicação entre cliente e servidor de aplicação (Figura 11), foi utilizado o
servidor Web Apache2, responsável por disponibilizar o sistema através da internet ou intranet. Este
serviço utiliza-se do protocolo HTTP (Hypertext Transfer Protocol – Protocolo de Transferência de
Hipertexto) para responder as requisições dos usuários, além de permitir a execução de aplicações
CGI (Common Gateway Interface - Interface Comum de Saída) e linguagens de scripts, como PHP
(Hypertext Preprocessor) e JSP (Java Server Pages) (ALECRIM, 2006).
1 Software de utilização livre e sem custos com liberdade para adaptação e distribuição de cópias, permitindo também modificar o código-fonte e disponibilizar de forma gratuita para toda a comunidade com o objetivo de beneficiar a todos os usuários e desenvolvedores. (SEABRA, 2007) 2 Disponível em: http://www.apache.org
34
Figura 11. Comunicação entre cliente servidor através de um navegador Web.
Fonte: Adaptado de STREIBEL (2005).
2.1.3.2 Linguagem de programação
A linguagem de programação adotada, o PHP3 (Hypertext Preprocessor) versão 5.0,
consiste em uma linguagem de script interpretada no lado servidor, que permite disponibilizar
conteúdos dinâmicos e interagir com os usuários através de formulários presentes nas páginas web,
conforme o esquema apresentado na Figura 11 (COSTA, [200-?]).
Como diferenciais presentes no PHP em relação a algumas outras linguagens para a Web,
podem-se citar (DEXTRA SISTEMAS, 2008):
• Disponível para os mais diversos sistemas operacionais existentes (e.g., Windows, Mac
OS, Linux, Solaris). Atualmente é suportado pelos principais servidores de aplicação
(e.g., Apache, IIS (Microsoft Internet Information Service), Xitami, Netscape);
3 Disponível em: http://www.php.net/
35
• O suporte a grande variedade de SGBDs (Sistema Gerenciador de Banco de Dados)
permite que o servidor de aplicação comunique-se com os principais e mais diversos
bancos de dados existentes no mercado como PostgreSQL, MySQL, Oracle, Interbase,
SQL Server e suporte ao padrão ODBC (Open Database Connectivity - Padrão Aberto
de Conexões a Bancos de Dados), que permite acessar diferentes tipos de bancos de
dados através de uma interface padrão;
• Possui diversas bibliotecas para facilitar a leitura e escrita de arquivos textos, além de ser
compatível com os principais padrões de interpretadores XML propostos pelo W3C4
(World Wide Web Consortium – Comitê Organizador da Web), como SAX (Simple Api
for XML – API Simples para XML) e DOM (Document Object Model – Modelo de
Documento Objeto);
• A programação pode ser realizada tanto de forma procedural e seqüencial
(procedimentos e funções), ou através da programação orientada a objeto (suportada nas
versões mais recentes a partir do PHP 5.0), que permite desenvolver os mais diversos
frameworks de aplicações RAD (Rapid Application Developlment – Desenvolvimento
Rápido de Aplicações), além de permitir a integração com outras linguagens de
programação como JAVA e .NET;
• A geração de arquivos em PDF (Portable Document Format – Formato de Documento
Portátil), manipulação de imagens, criação de animações dinâmica (i.e., on the fly) em
flash, envio de e-mails e compactação de arquivos, é feita de forma simples com uma
grande quantidade de funcionalidades; e
• Possui suporte a diversos protocolos de comunicação como HTTP, POP (Post Office
Protocol – Protocolo de Transferência de Mensagens), SMTP (Simple Mail Transfer
Protocol – Protocolo de Transferência Simples do Correio), FTP (File Transfer Protocol
– Protocolo de Transferência de Arquivos) até em níveis mais baixos como a abertura
direta de sockets, que permite interagir com qualquer outro protocolo.
4 Disponível em: http://www.w3.org
36
2.1.3.3 Banco de dados
O armazenamento das informações da ferramenta WebCASE é feito utilizando-se o SGBD
relacional MySQL versão 5.0 na versão open-source. Entre os principais motivos para o sucesso
deste banco de dados estão à velocidade, confiabilidade e facilidade de utilização (MySQL
BRASIL, 2008).
Suas principais características são abordadas a seguir (MySQL BRASIL, 2008):
• Todas as consultas realizadas pelo MySQL são feitas utilizando-se a linguagem SQL
(Structured Query Language - Linguagem Estrutural de Consulta) definida pelo
padrão ANSI/ISO SQL;
• Possui grande portabilidade, desenvolvido em C e C++ é composto por diversas APIs
(Application Programming Interface – Interface de Programação de Aplicativos)
disponíveis nas mais diversas linguagens como Java, Eiffel, PHP, Ruby e Python, para
permitir adicionar novas funcionalidades e ferramentas de suporte a este SGBD;
• Suporte a multithreads, fornece mecanismos de armazenamento, controle transacional e
não transacional, integridade referencial através de chaves primárias e estrangeiras,
realização de consultas, atualização de dados, inserção, remoção, criação de índices para
acelerar consultas. Conta ainda com um sistema de privilégios e senhas que podem ser
baseadas em estações e máquinas;
• Suporte a prepared statement, permite realizar consultas mais rapidamente de forma
otimizada, modificando-se apenas os parâmetros. Isto ocorre devido à existência de três
etapas durante a sua preparação: análise, reestruturação e execução. Utilizando-se esta
funcionalidade é possível que as etapas de análise e reestruturação sejam executadas
uma única vez e não sempre que a consulta é executada;
• Completo suporte e ampla biblioteca de operadores, funções para manipulação de
informações e subconsultas, desenvolvida de forma otimizada para se obter grande
ganho em performance. Recursos para criações de views (i.e., tabelas de visualização de
informações, baseadas em campos de uma ou mais tabelas), além de permitir adicionar
funções de agrupamento (e.g., somatório, média, máximo, mínimo); e
37
• Suporte a programação diretamente no SGBD como stored procedures, funções, triggers
(i.e., gatilhos disparados automaticamente após a ocorrência de um evento (e.g., inserção
de dados em uma tabela)).
2.1.3.4 Interface gráfica e comunicação cliente servidor
Como atrativo da ferramenta WebCASE em relação a outros sistemas web, pode-se citar a
adoção do conceito RIA5. Termo utilizado pela primeira vez em 2001 pela Macromedia para definir
aplicações web que seguem o estilo de aplicações stand-alone6, com alto nível de interação com o
usuário (MACROMEDIA, 2003).
Para tal, aplicações RIA extrapolam o padrão tradicional da Web, baseado em simples
formulários HTML (Hyper Text Markup Language - Linguagem de Marcação de Hipertexto),
transferindo para o cliente boa parte da implementação lógica e deixando para o servidor apenas a
tarefa de conexão e manipulação de banco de dados, (MOOCK, 2007; WOOLSTON, 2006).
2.1.3.5 AJAX
Um dos maiores responsáveis pelo aumento da popularidade de aplicações web com
interfaces ricas foi, além da evidente necessidade de diminuir a diferença entre aplicações web e
aplicações stand-alone, a popularização do AJAX (Asynchronous JavaScript And XML - XML e
JavaScript Assíncrono) (BUGHI, 2007).
O AJAX não pode ser considerado uma linguagem de programação, nem uma nova
tecnologia, a melhor maneira de definir AJAX, segundo Mahemoff (2006), é a mistura de
tecnologias providas por navegadores, como JavaScript e XML, através de solicitações assíncronas
de informação. Conforme Perry (2006), as tecnologias necessárias para a utilização do AJAX são:
• JavaScript, linguagem de programação embutida em páginas web que permite a criação
de conteúdo dinâmico interpretada pelo navegador no lado cliente;
• Modelo de representação de XML em forma de objetos manipuláveis por uma
linguagem através da utilização do padrão DOM; 5 Alguns autores adotam o termo Web 2.0 para definir aplicações web com interfaces ricas (WOOLSTON, 2006) 6 Aplicações denominadas auto-suficientes, que não dependem de softwares adicionais ou sistema operacional específico para serem executadas (TECHTERMS, 2008)
38
• Recuperação de dados assíncronos utilizando um objeto JavaScript denominado
XMLHttpRequest; e
• Apresentação dos dados baseadas em padrões utilizando XHTML (eXtensible Hyper
Text Markup Language - Linguagem de Marcação de Hipertexto Extensível) e CSS
(Cascading Style Sheets – Folhas de Estilo em Cascata).
O principal componente do AJAX, o XMLHttpRequest foi implementado pela Microsoft
como um objeto ActiveX do navegador Internet Explorer 5, na seqüência, o projeto Mozilla
implementou uma solução compatível com o ActiveX, porém funcionando de maneira nativa para o
navegador. Com o objetivo de padronizar a forma como os navegadores realizariam requisições
assíncronas, o W3C incluiu o XMLHttpRequest na especificação DOM nível 3 (MAHEMOFF,
2006).
Conforme apresentado na Figura 12, o funcionamento de uma aplicação que faz uso do
AJAX (e conseqüentemente XMLHttpRequest) consiste em:
1. Requisição inicial pelo navegador;
2. A página completa é obtida pelo servidor (incluindo o motor AJAX) e enviada para o
navegador;
3. Todas as requisições seguintes são realizadas através de chamadas de funções ao motor
AJAX;
4. O motor AJAX realiza uma chamada via XmlHttpRequest ao servidor;
5. O servidor processa e envia a resposta em formato XML; e
6. O motor AJAX processa a resposta do servidor, atualiza os elementos necessários ou
realiza operações com os novos dados provenientes do servidor.
39
Umas das formas alternativas presentes para a comunicação por AJAX entre cliente e
servidor na ferramenta WebCASE é a tecnologia JSON, que ao contrário da forma usual onde as
informações são transportadas como texto ou XML, elas são transmitidas e lidas como objetos
JavaScript.
2.1.3.6 Biblioteca ExtJS
Além do AJAX e JSON, a ferramenta WebCASE faz uso de uma biblioteca desenvolvida
em JavaScript denominada ExtJS7. Voltada para a camada de apresentação, a biblioteca ExtJS
permite criar e adicionar diversos componentes semelhantes aos presentes em aplicações stand-
alone (e.g., janelas, árvores, painéis, formulários, botões, arraste de elementos).
7 Disponível em: http://www.extjs.com
Figura 12. Exemplo de comunicação utilizando AJAX
Adaptado de: GARRETT (2005)
40
Atualmente encontra-se na versão 2.1 e está presente na licença comercial ou sob as
condições da licença LGPL (Lesser General Public License – Menor Licença Pública Geral).
Na Figura 13 é apresentada uma tabela (grid) com dados formatados e diversas
propriedades atribuídas de maneira simples utilizando a biblioteca ExtJS. O código utilizado para a
geração desta tabela encontra-se disponível na Figura 14 e é apresentado na seqüência.
Figura 13. Tabela de dados criada com a biblioteca ExtJS
Fonte: VEDOVELLI (2007)
Inicialmente deve ser criado um objeto do tipo Ext.grid.Grid (linha 31), onde todas as
propriedades e atributos são passados como parâmetro na forma de objeto JavaScript no construtor
do GridPanel.
A definição das colunas é feita com um objeto do tipo Ext.grid.ColumnModel (linha 22),
para cada coluna deve-se informar seu título (header), largura (width), se a mesma pode ser
ordenada (sortable), o tipo e formato dos dados que serão apresentados. Para este exemplo foi
utilizada uma estrutura auxiliar para armazenar o tipo de dado (i.e., monetário, datas, textos) de
cada coluna da tabela (linhas 13 a 17).
Alguns atributos adicionais podem ser informados como forçar a apresentação total dos
dados na tela (forceFit), título (title), largura da tabela (width) e se a mesma será renderizada dentro
de um iframe (renderTo).
41
Figura 14. Código para a geração de uma tabela utilizando a biblioteca ExtJS.
Adaptado de: VEDOVELLI (2007)
2.1.3.7 Formato de troca de documentos
Para permitir a integração da ferramenta WebCASE com outras ferramentas CASE
existentes, foi adotado o padrão XMI, desenvolvido pela OMG8(Object Management Group –
Grupo de Gerenciamento de Objetos) com o objetivo de padronizar o transporte de componentes
entre aplicações através do XML.
8 Organização de padrões reconhecida internacionalmente, a estrutura da OMG é baseada em dois aspectos: (1) Domínios que representam diversas áreas tecnológicas, como telecomunicação, comércio eletrônico, simulação e transporte; (2) e as plataformas que trabalham na especificação de tecnologias como a UML, MOF e XMI. (BRODSKY, 1999)
42
Para Brodsky (1999) a diversidade de ferramentas disponíveis para projetos de software é de
extrema importância, pois permite que novas metodologias sejam propostas para facilitar os
negócios. Uma das vantagens em se utilizar o XML se deve a facilidade existente para a
compreensão e leitura humana (RAMOS e STRECHT, [200-?]).
Conforme Ramos e Strecht ([200-?]), XMI é um padrão aberto baseado em XML proposto
para o intercâmbio de informações e representação de metamodelos entre aplicações de modelagem
e desenvolvimento de software (e.g., versão, representação de modelos, relacionamento entre
elementos).
Alguns exemplos incluem: (i) ferramentas de desenvolvimento (e.g., C++, Java); (ii)
ferramentas de modelagem, design, orientação a objetos e UML (e.g., Enterprise Architect,
Rational Rose); e (iii) Bancos de Dados e Data Warehouses (e.g., Oracle 8i,Visual Warehouse),
além de repositórios e geradores de relatórios e documentação (BRODSKY, 1999).
A recomendação da OMG para a utilização do padrão XMI, tem como objetivo permitir as
empresas participantes colaborar e disponibilizar um canal de comunicação, importação e
exportação de informações entre as ferramentas (Figura 15).
Na situação atual da XMI, cada software deve saber a respeito das funções de outras
ferramentas, permitindo criar pontes para clientes que necessitam compartilhar informações entre as
ferramentas.
Figura 15. Pontes entre diferentes ferramentas e empresas.
Fonte: Adaptado de Brodsky (1999).
43
2.1.4 Considerações sobre a Ferramenta
Com o estudo realizado sobre a ferramenta WebCASE foi possível avaliar a forma em que
se encontra sua modelagem e implementação, proporcionando uma melhor visão e identificação de
possíveis limitações que possam existir durante a alteração e adição das novas funcionalidades.
Algumas discrepâncias relacionadas ao modelo ER e ao modelo de classes são apresentadas
e corrigidas no capitulo 3. Como o objetivo principal deste trabalho está relacionado à adição de
novas funcionalidades, só será feita a correção de falhas se ocorrerem problemas na nova versão.
2.2 Engenharia de Software
Engenharia de software é a área de ciência da computação que lida com a construção de
sistemas de software, sejam eles grandes ou complexos que precisam ser construídos por uma
equipe ou equipes de engenheiros. Normalmente, estes sistemas de softwares existem em várias
versões, e são utilizados durante vários anos (GHEZZI; JAZAYERI ; MANDRIOLI, 1991).
Desde a idéia inicial até a entrega para o cliente, um software pode passar por mudanças
para corrigir defeitos, reforçar funcionalidades e retirar recursos obsoletos para se adequar a um
novo ambiente de trabalho (PFLEEGER, 2004).
Um estudo realizado por Davis ([s.d.] apud PETERS; PEDRYCZ, 2001) apresentado na
Figura 16, relata uma distribuição dos principais custos envolvidos para detectar e corrigir erros em
um projeto de software, onde a existência de falhas tende a diminuir de acordo com os esforços
atribuídos às etapas de pré-projeto, ou seja, quanto mais claro for o projeto, menores serão os custos
envolvidos na manutenção e maior será a sua qualidade.
44
Requisitos
3%Projeto
7% Codificação
10%
Testes da
Unidade
23%
Testes de
Aceitação
57%
Figura 16. Distribuição dos custos envolvidos em projetos de Software.
Fonte: Adaptado de Peters; Pedrycz (2001).
Através da engenharia de software, diversas abordagens para o desenvolvimento surgem a
fim de tentar resolver estes problemas, dando origem aos modelos universais de processo de
software (PETERS; PEDRYCZ, 2001). Para Mazzola (2008) os seguintes fatores devem ser
considerados no processo de gerência de projeto:
• O desenvolvimento de software na maioria dos casos não possui um planejamento inicial
das suas funcionalidades, tornando obscuro, possíveis obstáculos que somente seriam
encontrados após o início da execução do projeto. Como conseqüências a remodelagem,
a perda de tempo e o aumento nos custos poderiam estar presentes, impedindo uma
avaliação das metodologias empregadas no desenvolvimento;
• A insatisfação é quase sempre uma das principais características resultantes ao final do
projeto, isto se deve a alguns fatores como a falta de comunicação entre os envolvidos e
o cliente, para definir o escopo do sistema; e
• Como resultado de uma má especificação de software, o aumento no custo total, a falta
de segurança e a alta manutenção, acabam fazendo com que o projeto seja
descontinuado, causando prejuízos tanto para as empresas envolvidas no
desenvolvimento quanto para os clientes.
45
Mesmo não existindo um modelo ideal, é necessário realizar um estudo entre as diferentes
abordagens a fim de encontrar o mais adequado às necessidades de um projeto, onde cada processo
é formado por técnicas e ferramentas que visam facilitar sua compreensão e acelerar o processo de
documentação e análise seguindo seus conceitos (PFLEEGER, 2004). Sommerville (2007) aponta
quatro atividades comuns entre os diversos processos de engenharia de software existentes:
• A especificação de software ou engenharia de requisitos: Tendo descrito as ações do
software, é necessário definir os serviços e restrições para seu funcionamento, tornando
esta atividade uma etapa crítica, já que possibilita influenciar as etapas posteriores de
desenvolvimento;
• O projeto e implementação: Desenvolvimento e codificação do software atendendo as
especificações e requisitos;
• Validação de software: Tanto durante o desenvolvimento quanto na finalização do
projeto, o software deve ser testado a fim de garantir a qualidade do produto
desenvolvido; e
• Evolução de software: Permite que o software seja mutável e adaptável as necessidades
do cliente.
2.2.1 Requisitos de Software
Para Fernandes (2005) os requisitos de software definem propriedades que devem ser
executadas pelo sistema, expressam características e restrições do ponto de vista da satisfação das
necessidades do usuário, a fim de fornecer controle e suporte a uma tarefa específica.
Filho (2001 apud QUIRINO, 2005), afirma que os critérios de aceitação de um produto
estão ligados aos requisitos funcionais do sistema, pois definem as diversas propriedades e funções
realizadas pelo mesmo.
A necessidade de especificar os requisitos é proporcional ao tamanho do sistema, ou seja,
quanto maior à complexidade envolvida, maior a necessidade de realizar uma especificação mais
detalhada, aumentando a dificuldade do processo.
Através dos requisitos, toda funcionalidade comportamental e não comportamental pode ser
descrita e avaliada. Muitas das etapas e técnicas envolvidas são abordadas pela engenharia de
requisitos, onde diversos paradigma e arquiteturas são apresentados a fim de realizar um
46
planejamento minucioso e completo para melhorar o desempenho de um projeto (PETERS;
PEDRYCZ, 2001).
Sommerville (2007) aponta duas formas de especificar requisitos. Diferenciadas pelo nível
de abstração de sua descrição, permite abranger diversos tipos de leitores e assim facilitar a
comunicação em grupo:
• Requisitos de usuário: Utilizam linguagem mais clara e diagramas, exprimindo as
idéias das funcionalidades, restrições a serem desempenhadas e os serviços que serão
executadas pelo software; e
• Requisitos de sistema: São mais formais e possuem menor abstração, descritos através
de uma linguagem mais precisa e com maior detalhamento. São utilizados
principalmente por engenheiros de software, arquitetos de sistema e desenvolvedores de
software.
Entre os principais desafios envolvidos no trabalho de determinar os requisitos, estão os de
encontrar, comunicar e documentar de forma clara, os aspectos necessários às capacidades e
condições do sistema, tanto para o cliente como a equipe envolvida no projeto (LARMAN, 2004).
De forma resumida os requisitos de software podem ser divididos em requisitos funcionais,
não-funcionais e regras de negócio (requisitos de domínio) (CYSNEIROS, 2008).
A distinção entre um requisito funcional e um requisito não-funcional pode não ser simples,
onde um requisito funcional está relacionado a algum tipo de transformação a ser realizada
internamente no software, enquanto que um requisito não-funcional está relacionado à como esta
transformação irá se comportar ou que qualidade deverá possuir (EAGLE, 1995; CHUNG, 2000
apud CYSNEIROS 2008).
Qualquer que seja a classificação, os requisitos são formados por um conjunto de atributos
que definem suas características principais (e.g., prioridade, status, descrição) e demais informações
que possam vir a ser necessárias (SANTOS; VARGAS; ABREU, 2004).
47
2.2.1.1 Requisitos Funcionais
Os requisitos funcionais (RF) descrevem através de uma linguagem clara e escrita às
funções que o sistema deverá realizar, geralmente são específicos a cada software projetado
(SOMMERVILLE, 2007).
Já para Pfleeger (2004) um requisito funcional é responsável por descrever a interação e
comportamento existente entre o sistema e o ambiente, levando em consideração a ocorrência de
uma ação ou estímulo.
Quirino (2005) define um requisito funcional como uma descrição das atividades executadas
de acordo com as entradas e saídas executadas em resposta a uma ação externa ao sistema.
2.2.1.2 Requisitos Não-funcionais
Ao contrário dos requisitos funcionais os requisitos não-funcionais (RNF) estão
relacionados às propriedades de funcionamento (e.g. confiabilidade, tempo de resposta,
portabilidade, desempenho) e não as funções específicas do sistema. A importância de um RNF é
oposta à de um RF onde muitas vezes existe uma maneira alternativa de se executar determinada
tarefa. Já a omissão ou falha de um RNF pode comprometer o funcionamento e tornar o sistema
inútil. (SOMMERVILLE, 2007).
Outros fatores relacionados aos requisitos não-funcionais são as necessidades de software,
hardware, linguagens de programação utilizadas, recursos financeiros e demais características que
não estão relacionadas às funcionalidades do software (ibidem).
Para Pfleeger (2004) um requisito não-funcional representa limitações e restrições que
possam existir e que possam interferir na solução final do sistema. Entre os tipos de RNF propostos
por Sommerville (2007) estão:
• Requisitos de produto: Ligados ao comportamento, geralmente são relacionados ao
desempenho, poder de processamento, confiabilidade, tolerância à falhas, portabilidade e
usabilidade;
• Requisitos organizacionais: Relacionados às políticas impostas pela organização do
cliente, alguns exemplos incluem linguagem de programação e sistema operacional; e
48
• Requisitos externos: Requisitos voltados aos fatores externos do software, como a
interoperabilidade com softwares de outras organizações e interfaces de comunicação.
Com a existência de diversas categorias de RNF, Conallen (2003 apud Quirino, 2005),
classifica os requisitos não-funcionais em:
• Usabilidade: Relacionados principalmente a interação software x usuário. Permite que
sejam definidos, como por exemplo, as telas do sistema que devem ser projetadas a fim
de facilitar sua utilização;
• Desempenho: Descrevem os fatores relacionados ao tempo de resposta do software.
Abrangem tanto a parte de sistemas operacionais, quanto à parte de hardware utilizada
pelo software;
• Confiabilidade: Em sistemas críticos esta é uma característica essencial, define
restrições quanto ao seu total funcionamento e tolerância à falhas, além de definir
questões relacionadas à recuperação de informações;
• Segurança: Definem aspectos necessários à proteção das informações do software como
níveis e políticas internas da empresa para acesso aos dados;
• Hardware: Apontam os requisitos e especificações de hardware, necessários ao
funcionamento do software; e
• Implantação: Definem aspectos a serem verificados durante a instalação e treinamento
do sistema, a fim de garantir seu correto funcionamento.
2.2.1.3 Regras de Negócio
Para a execução de tarefas por um software, é necessário que normas e restrições sejam
definidas para atender corretamente a determinadas necessidades do negócio. Para Sommerville
(2007) as regras de negócio (RN), ou requisitos de domínio, são restrições ou especificações que
serão executados por uma tarefa e não como ela será executada.
Já para Ross (2003 apud BUGHI, 2007) as regras de negócio são como diretivas que
influenciam ou guiam o comportamento dos negócios em um sistema e são formalizadas através de
uma linguagem declarativa.
49
Apesar da importância de definir corretamente as regras de negócio, sua compreensão pode
ser acompanhada de diversos conflitos originados dos processos envolvidos na gerência de negócio
e de sistemas de informação de suporte, principalmente com as mudanças dos processos ao longo
dos anos (ALENQUER, 2002 apud QUIRINO, 2005).
Quirino (2005) aponta o processo de definição das regras de negócio como uma atividade
realizada por um analista de negócios e não pelos responsáveis em mapear os requisitos do sistema
devido ao maior entendimento nos processos envolvidos.
2.2.2 Engenharia de Requisitos
Uma das etapas existente na maioria dos processos da engenharia de software responsável
por definir os objetivos, escopo e descrição dos requisitos é a engenharia de requisitos. Focada na
análise e documentação dos problemas envolvidos em um projeto, permite avaliar o contexto e
viabilidade das necessidades organizacionais do cliente (PETERS; PEDRYCZ, 2001). Para
Sommerville (2007) os seguintes componentes estão envolvidos na parte de análise de requisitos:
• Ambiente: formado por usuários do sistema, máquinas, serviços e operações de
software, possuem a importância de especificar como e de que forma as tarefas serão
executadas;
• Itens produzidos: descrevem as necessidades envolvidas no processamento, consumo e
produção do sistema;
• Funções: descrevem as funções executadas por pessoas e máquinas, necessárias para
realizar um determinado serviço; e
• Modos de operação: métodos utilizados, formas de produção e quando as operações
acontecem.
Rezende (1999) apresenta a comunicação e a capacitação como fatores essenciais durante a
análise de requisitos devido à possibilidade de haver conflitos com exigências apontadas por outros
envolvidos no processo, já que este problema tende a aumentar com a complexidade das tarefas.
Para facilitar e melhorar a capacidade de análise de sistemas, Silva e Rocha (1998) apontam
a necessidade de realizar a interação entre os envolvidos, definindo “o que” e “como” determinada
50
tarefa deverá ser realizada, avaliando suas origens e separando suas características, para permitir
que novas habilidades gerenciais sejam propostas e novos modelos de processos sejam definidos.
2.2.3 Processos da Engenharia de Requisitos
A criação e atualização de um documento contendo a relação de todos os requisitos é parte
fundamental e objetivo principal do processo existente na engenharia de requisitos
(SOMMERVILLE, 2007).
Conforme descrito por Sommerville (2007), o processo de definição de requisitos pode ser
dividido em quatro subprocessos (Figura 17) relacionados à avaliação da utilidade e adequação para
a empresa: (i) estudo de viabilidade; (ii) análise e elicitação de requisitos; (iii) especificação; e (iv)
validação do software.
Figura 17. Etapas presentes no processo de engenharia de requisitos.
Fonte: Adaptado de UNESP (2006).
Estas etapas estão inseridas em um processo evolutivo e contínuo ao longo do ciclo de vida
do software, já que na prática as alterações nos requisitos podem se tornar constantes, necessitando
gerenciar estas mudanças para obter ao final de cada etapa um artefato reunindo as informações
coletadas.
51
2.2.3.1 Estudo de viabilidade
Na maioria dos projetos de software, deve-se inicialmente realizar um estudo das
necessidades e avaliar como o software auxiliará nos processos da empresa através de resultados
obtidos em relatórios. Assim é possível verificar se sua elaboração é capaz de atingir os objetivos
desejados ou se será necessário realizar alterações de orçamentos, escopo e prazos anteriormente
definidos (SOMMERVILLE, 2007).
Ainda como fontes de estudo, é necessário verificar se o sistema poderá ser implementado
utilizando a tecnologia atual, dentro do orçamento existente e se poderá ser integrado a outros
sistemas já em operação (UNESP, 2006).
Para Sommerville (2007), a realização de um estudo de viabilidade é formada basicamente
por perguntas, coleta e avaliação de informações, abordando quais seriam as contribuições
oferecidas à solução proposta, ou seja, se as respostas não forem satisfatórias, deve-se recomendar o
não prosseguimento do desenvolvimento, restando como conclusão que o software não irá agregar
valores reais para a empresa.
Entre as pessoas envolvidas no estudo de viabilidade, podem ser citados, gerentes de
departamento, funcionários, especialistas em tecnologia e demais pessoas familiarizadas com os
processos e regras de negócio.
Alguns questionamentos básicos, segundo UNESP (2006), são:
• Existem problemas nos processos utilizados atualmente? Qual o impacto causado se o
sistema não fosse implementado?
• Como o sistema auxiliará as atividades do cotidiano?
• Que tecnologias e habilidades serão necessárias à implementação do sistema? Estão
dentro das restrições definidas de custo e prazo?
2.2.3.2 Elicitação e análise de requisitos
Como segunda etapa, os engenheiros de software e a equipe técnica realizam reuniões com
os clientes e stakeholders com a finalidade de descobrir maiores detalhes sobre o domínio da
aplicação, desempenho e hardware necessários.
52
Os stakeholders, segundo Sommerville (2007), são todas as pessoas envolvidas que possuem
influência direta ou indireta sobre os requisitos do sistema, com isto diversos problemas são
encontrados devido a várias razões:
• Normalmente os usuários e stakeholders possuem requisitos conflitantes e
freqüentemente não sabem definir exatamente o que desejam que o sistema realize,
expressando as funcionalidades em termos gerais;
• Utilizam linguagem natural e conhecimento implícito do trabalho que dificultam a
identificação dos requisitos, necessitando definir os pontos em comum e avaliar quem
são as potenciais fontes de requisitos; e
• Como o ambiente econômico e negócios são dinâmicos, os requisitos são modificados
naturalmente, além de existirem fatores políticos que podem ser influenciados durante o
processo de análise.
2.2.3.3 Especificação de Requisitos
Parte do processo responsável por definir e traduzir as informações coletadas durante o
levantamento de requisitos, que compreende e define os serviços exigidos para fornecer uma base
estável para o projeto do software (SOMMERVILLE, 2007). Esta etapa pode ser considerada uma
das mais críticas, já que a má especificação pode resultar em erros nos estágios posteriores.
Algumas técnicas podem ser utilizadas para especificar os requisitos de software, que
variam de acordo com a necessidade e com as melhores abordagens para identificar e facilitar sua
obtenção.
2.2.3.3.1 Levantamento baseado em ponto de vista
Através de entrevistas realizadas com diferentes stakeholders, é possível identificar as
perspectivas, classificando e descobrindo os conflitos entre as fontes de requisitos. Estas entrevistas
consistem na formulação de perguntas sobre o sistema utilizado e o sistema a ser desenvolvido
(SOMMERVILLE, 2007).
Ainda para Sommerville (2007), basicamente os pontos de vista podem ser divididos em três
grupos genéricos:
53
• Pontos de vista de iteração: Responsáveis por representar todas as pessoas envolvidas
direta ou indiretamente com o sistema fornecendo detalhes a respeito das características
e interfaces;
• Pontos de vista indiretos: Representam os stakeholders que não utilizam o sistema, mas
acabam por influenciar seus requisitos e restrições organizacionais; e
• Pontos de vista de domínio: Representam características e restrições de domínio que
acabam influenciando os requisitos do sistema.
2.2.3.3.2 Casos de uso
Para Larman (2004), um caso de uso nada mais é que uma forma de aplicar e descrever um
requisito que será realizado pelo software, além de serem mecanismos centrais para a descoberta e
definição de outros requisitos do sistema. Sua finalidade é expressar a maneira com que elementos
externos interagem com as funcionalidades disponíveis no sistema.
Os diagramas de casos de uso são elementos textuais da UML, geralmente representados em
forma de diagramas, para permitir uma melhor visualização e entendimento. Para Medeiros (2004)
um caso de uso é uma atividade responsável por representar a execução de determinada tarefa em
um software através do relacionamento e interação entre os casos de uso e atores.
Figura 18. Exemplo de um diagrama de caso de uso.
54
Na Figura 18 é apresentado um exemplo de diagrama de caso de uso para um sistema de
controle de usuários. Neste modelo existe um ator, o administrador do sistema, que possui acesso a
duas funcionalidades principais representadas pelos casos de uso UC 02.01, para manipular e
cadastrar usuários e o caso de uso UC 02.02, para gerenciar grupos de usuários. O UC 02.03 possui
a funcionalidade de manipular permissões para o grupo de usuários e está relacionado através de
uma extensão ao UC 02.02.
Para Booch, Rumbaugh e Jacobson (2006) um caso de uso define um comportamento
específico esperado pelo sistema, sem levar em consideração as ações e aspectos necessários a sua
implementação dentro do software.
Para Larman (2004), existe uma forte relação entre os requisitos funcionais e os casos de
uso. A principal diferença é que os casos de uso descrevem de forma mais detalhada como uma
ação será executada pelo software durante a implementação, sendo este um dos principais
mecanismos utilizados em diversos processos de software, para a descoberta e definição de
requisitos.
2.2.3.4 Documentação
Durante as fases da engenharia de requisitos, armazenar e organizar as informações são
tarefas extremamente importantes, pois permite utilizá-las como documento oficial da especificação
do sistema para clientes, desenvolvedores e usuários (PETERS; PEDRYCZ, 2001).
Denominada de Especificação de Requisitos de Software (ERS) são escritas utilizando uma
linguagem natural variando o grau de detalhamento de acordo com o público alvo podendo incluir
diagramas, tabelas e demais artefatos para facilitar seu entendimento (SOARES; FARIA, 2008).
Segundo Peters e Pedrycz (2001), a ERS é responsável por descrever as propriedades,
restrições e funções executadas dentro de um produto de software, geralmente são escritas durante
todo o processo de engenharia de requisitos.
Para Soares e Faria (2008) os seguintes tópicos são encontrados em um documento de ERS:
• Visão geral do sistema, benefícios do desenvolvimento, glossário com termos técnicos;
• Definição dos serviços, requisitos, propriedades do sistema; e
55
• Restrições de operação, definição do ambiente em que o sistema será executado e
integração com outros sistemas.
Ao realizar a descrição dos requisitos devem ser observados os seguintes fatores (PETERS;
PEDRYCZ, 2001):
• Funcionalidade: As tarefas que o software deverá realizar, suas funções e estados;
• Interface externa: Interação do software com o ambiente, pessoas, hardware e outros
software;
• Desempenho: Velocidade, disponibilidade, tempo de resposta;
• Atributos: Portabilidade, rastreabilidade, manutenibilidade, qualidade, estabilidade,
segurança; e
• Restrições: Padrões de qualidade, linguagens de codificação, recursos, orçamento,
ambiente.
2.2.3.4.1 Especificação de requisitos de software segundo IEEE 830-1998
Dentre as diversas abordagens e modelos disponíveis para serem utilizados como modelo de
ERS, destaca-se a especificação proposta pelo IEEE (Institute of Electrical and Electronics
Engineers - Instituto dos Engenheiros Elétricos e Eletrônicos), responsável por definir boas práticas
para a especificação de requisitos proveniente de resultados obtidos de diversos processos da
engenharia de software (PETERS; PEDRYCZ, 2001).
Esta subseção foi escrita baseada na recomendação proposta pelo IEEE, foram extraídos do
documento as principais características que devem estar presentes na especificação de requisitos,
para servir como base na modelagem e desenvolvimento desta atividade na ferramenta WebCASE.
Considerando algumas das informações necessárias que devem estar presentes no escopo da
ERS abaixo são detalhadas de maneira sucinta, explicando o porquê de sua utilização (IEEE, 1998).
Característica da ERS
• Correta: Uma ERS está correta se, e somente se, todos os requisitos atendem as
necessidades do software, podendo ser avaliada pelos usuários se ela está correta e
reflete os objetivos (ibidem).
• Sem ambigüidade: Nenhum requisito deve possuir mais de uma interpretação e que no
mínimo cada requisito é descrito utilizando um único termo. Uma forma de representar
os requisitos é através da utilização de ferramentas para auxiliar sua descrição através de
uma linguagem própria onde muitas vezes são utilizados diagramas para auxiliar este
processo (ibidem).
• Completa: Uma especificação somente poderá ser dita completa se todos os seus
requisitos significantes estiverem disponíveis, até mesmo os relacionados à performance,
funcionalidades e interfaces externas (ibidem).
• Consistência: Para que uma ERS seja considerada consistente é necessário que ela não
possua conflito com outros requisitos, por exemplo, um requisito informa que um estado
“a” deve ser seguido por um estado “b”, já em outro requisitos a ocorrência de “a”ou “b”
podem acontecer simultaneamente (ibidem).
• Classificação por importância e estabilidade: Em uma ERS os requisitos devem
conter indicadores particulares de importância e estabilidade. Como nem sempre os
requisitos possuem a mesma importância, alguns podem ser especiais, essenciais ou
críticos, enquanto outros podem ser apenas desejáveis, sendo esta diferença clara e
explícita. Já na classificação por necessidade um requisito pode ser distinguido de três
formas: (i) Essencial: definem implicações que afetam diretamente o sistema e se não
cumpridos podem acarretar na sua não utilização; (ii) Condicional: responsáveis por
melhorar e adicionar características ao software, mas não farão que ele seja rejeitado; e
(iii) Opcional: características que podem não ter tanta importância e servem para
aprimorar ou adicionar funcionalidades presentes na ERS (ibidem).
• Estabilidade: A estabilidade pode ser expressa com base no número de modificações
esperadas, na experiência e conhecimento de eventos que possam afetar a organização
(e.g., funções, pessoas que possam interferir em um requisito) (ibidem).
57
• Verificável: Toda ERS deve ser verificável, ou seja, se um requisito puder ser testado
com um custo efetivo através de uma pessoa ou máquina e não for ambíguo, então ele
estará cumprindo a especificação do produto. Alguns requisitos que não podem ser
verificados incluem “funcionamento adequado”, “boa interface humana”, “deve ocorrer
usualmente” já que teoricamente o teste de qualidade é impossível por existirem fatores
externos (e.g., configuração de software, hardware, rede) que podem afetar seu perfeito
funcionamento (ibidem).
• Modificável: Toda e qualquer modificação deverá ser fácil, completa e consistente
mantendo a estrutura proposta. Para isto é necessário haver coerência e uma maneira
fácil de organizar os requisitos (e.g., índices, tabelas, cruzamentos explícitos), e assim
verificar que não existem requisitos redundantes e em conflito, garantindo a propriedade
modificável a ERS. Vale lembrar que redundâncias nem sempre são erros, mas podem
acarretar erros facilmente (ibidem).
• Rastreável: Para que uma ERS seja rastreável, deverá existir uma maneira clara e fácil
para referenciar cada requisito em futuras modificações e aprimoramentos na
documentação. Basicamente existem duas formas de realizar um rastreamento, uma
através de referências para os requisitos anteriores e outra através da atribuição de um
nome ou identificador único para cada requisito (ibidem).
Preparação conjunta da ERS
Clientes e fornecedores nem sempre estão capacitados a escrever uma especificação de
software sozinhos, assim, é necessário trabalhar em conjunto para definir e concordar com as
funcionalidades propostas pelo software e permitir que uma documentação bem estruturada e
facilmente entendida seja criada (ibidem).
Evolução da ERS
Como nem sempre é possível descobrir completamente os detalhes nas fases iniciais do
projeto, é necessário que a evolução da ERS avance juntamente com o progresso do software,
documentando as modificações e deficiências que possam surgir com os novos requisitos. Duas
considerações importantes nesta etapa devem ser consideradas: (i) os requisitos devem ser
especificados completamente e na hora em que são descobertos, se por algum motivo estiverem
incompletos devem ser marcados para revisões posteriores; e (ii) um processo de modificação
58
formal deve ser iniciado para identificar, controlar e reportar mudanças no projeto, as mudanças
aceitas devem ser incorporadas a ERS. (ibidem).
2.2.3.5 Validação de requisitos
Como etapa final do processo de engenharia de requisitos, a validação permite verificar se
os requisitos não possuem problemas e atendem as definições propostas pelo usuário. O custo de
correção dos requisitos pode ser muito inferior e diminuir o retrabalho se identificados nesta fase, já
que isto normalmente significa mudanças no projeto, na implementação e na realização de novos
testes para avaliar os requisitos necessários.
Algumas das verificações que devem ser realizadas segundo SOMMERVILLE (2007)
incluem:
• Validade: Avaliar se o sistema fornece as funções necessárias para desempenhar os
requisitos propostos pelos stakeholders, isto se torna necessário devido à existência de
diversos pontos de vista.
• Consistência: Responsável por verificar se os requisitos possuem conflitos ou estão em
contradição para a realização de uma tarefa.
• Completeza: Avaliar se os requisitos necessários estão incluídos e definidos para a
realização dos objetivos.
• Realismo: Responsável por verificar se os requisitos propostos estão de acordo com as
tecnologias existentes, orçamentos e prazos propostos.
• Facilidade de verificação: Com o objetivo de testar e validar o sistema é necessário que
os requisitos possam ser testados, verificando sua confiabilidade e demonstrando seu
real funcionamento.
2.2.4 Gerenciamento de requisitos
Através do gerenciamento é possível organizar, planejar, comunicar e concluir os requisitos,
obtendo um melhor controle, aperfeiçoamento e satisfação do cliente em projetos complexos
diminuindo custos que estariam envolvidos na correção dos requisitos (KRUCHTEN, 2003).
59
Utilizando um ciclo iterativo é possível que o software seja organizado por um conjunto de
mini projetos que representam funcionalidades presentes no mesmo. Normalmente possuem
duração fixa e objetivos definidos denominados de iterações, cada qual formada por um conjunto de
atividades de análise de requisitos, projeto e implementação, que permitem testar, integrar e
executar o módulo após sua conclusão (LARMAN, 2004).
Segundo Martins (2001) o gerenciamento de requisitos é uma atividade que ocorre em
paralelo durante as etapas presentes na engenharia de requisitos até a entrega da documentação
(Figura 19).
Figura 19. Cobertura do gerenciamento de requisitos nas etapas da engenharia de requisitos.
Fonte: Martins (2001).
Em um projeto é necessário realizar um acompanhamento constante para permitir a
evolução e refletir as necessidades da organização, já que a compreensão dos problemas a serem
solucionados nem sempre é fácil, tornando os requisitos incompletos (SOMMERVILLE, 2007). A
existência de mudanças após a implantação torna-se quase que inevitável dentro da organização
devido a basicamente dois fatores:
• Em sistemas grandes geralmente os usuários acabam adquirindo mais experiência e
descobrindo novas necessidades com o passar do tempo, podendo causar conflitos e
contradições com os diferentes requisitos propostos; e
• Nem sempre dentro das organizações os responsáveis por negociar o sistema são os
verdadeiros usuários devido a restrições organizacionais e políticas presentes, o que de certa
forma acaba interferindo na definição do escopo, onde após a instalação, novas mudanças e
regras de negócio são introduzidas para refletir as reais necessidades do negócio.
A utilização de uma ferramenta de apoio, seja ela uma ferramenta CASE ou uma planilha,
torna-se necessária e essencial como fonte de gerenciamento, controle e consulta aos envolvidos no
60
projeto, onde para cada requisito é armazenado sua identificação, descrição textual, data e origem
de obtenção (MARTINS, 2001).
Para Cappelli e Santoro (2005) os seguintes benefícios são adquiridos ao realizar o
armazenamento e identificação dos requisitos:
• Controle de alterações para permitir avaliar as modificações realizadas bem como os
responsáveis pelas mesmas;
• Facilidade na geração de documentos de requisitos em forma de versão;
• Facilidade no acesso e visualização dos requisitos de forma única e centralizada.
2.2.4.1 Mudanças
Além de um processo de gerenciamento para realizar o acompanhamento dos requisitos, é
necessário estabelecer e planejar políticas em toda e qualquer mudanças para avaliar os impactos
causados pela evolução do sistema de forma controlada (SOMMERVILLE, 2007).
Para Castro (2000), o gerenciamento de mudanças é formado por um conjunto de políticas,
procedimentos e padrões utilizados para controlar as mudanças de requisitos que ocorram dentro de
um sistema, com o objetivo de identificar problemas, validar e testar as mudanças para garantir a
qualidade.
Existem basicamente duas razões responsáveis por interferir e modificar os requisitos: (i) Os
fatores externos correspondem a toda e qualquer característica relacionada a mudanças no problema
a ser resolvido; e (ii) os fatores internos relacionados às questões de projeto não identificados nas
fases iniciais e na dificuldade de gerenciar os requisitos e suas mudanças (Cappelli; Santoro, 2005).
Para isto é necessário planejar minuciosamente a forma de gerenciamento das mudanças,
seguindo uma referência das modificações e estabelecendo um canal único de controle.
2.2.4.2 Rastreabilidade
Durante o ciclo de vida de um projeto de software, é necessário manter o controle dos
impactos que poderão ser ocasionados durante a ocorrência de mudanças. Garantir o
relacionamento entre os casos de uso, requisitos e demais artefatos, permite que seja avaliado a
implementação proposta pelo sistema (FILHO, 2003).
61
A rastreabilidade é definida como uma atividade responsável por permitir rastrear a ligação
de um requisito a outros elementos do projeto, fornecendo informações para acompanhar seu ciclo
de vida e assim avaliar possíveis impactos que possam ser causados no projeto (KRUCHTEN,
2003).
Sommerville (2007) aponta três tipos de informações disponíveis que podem ser utilizadas
através da rastreabilidade:
• Informações de rastreabilidade da origem: Permitem relacionar os requisitos aos
documentos e stakeholders, que na ocorrência de mudanças, facilitam encontrar e
consultar sobre a mudança;
• Informações de rastreabilidade de requisitos: São responsáveis por interligar um
requisito aos demais requisitos presentes na documentação. Isto permite avaliar quais
requisitos serão afetados diretamente na ocorrência de uma mudança; e
• Informações de rastreabilidade de projeto: Permitem avaliar toda e qualquer parte da
implementação do projeto que possa ser afetada pela alteração do requisito.
Para facilitar a avaliação do relacionamento dos requisitos com os demais componentes do
projeto, a utilização de matrizes de rastreabilidade permite uma melhor visualização entre as
dependências existentes. É possível identificar anormalidades quanto à realização de um
determinado requisito por um caso de uso, principalmente em sistemas com grande complexidade
envolvida no desenvolvimento, servindo como base para o gerenciamento de requisitos e no suporte
a identificação de incompatibilidades gerada. (KOTONYA; SOMMERVILLE, 1997 apud
QUIRINO, 2005).
A matriz a ser utilizada é relativa à dependência existente entre os elementos. Normalmente
as principais matrizes são formadas entre requisitos funcionais e casos de uso, devido ao seu forte
acoplamento (SANTOS; VARGAS; ABREU, 2004).
Uma forma alternativa apontada por (KOTONYA, SOMMERVILLE, 1997 apud
QUIRINO, 2005) são as listas de relacionamento, formada por requisitos e dependências, porém sua
utilização não permite uma avaliação inversa dificultando a visualização.
62
O gerenciamento e avaliação dos impactos causados por alterações no projeto são divididos
em níveis, dependendo de quando e em que parte do projeto foram realizadas. Se a mudança ocorrer
durante a fase de especificação, deve ser avaliado como esta alteração afetará o restante dos
requisitos (SANTOS; VARGAS; ABREU, 2004). Já para uma alteração durante a fase de
implementação deve-se avaliar tanto os impactos causados entre os requisitos, quanto no
funcionamento geral do sistema e por fim, caso uma modificação seja feita após o sistema estar
concluído, além das etapas de verificação de requisitos e sistema, deve ser feito uma avaliação
adicional para verificar como os stakeholders do negócio serão afetados.
Quando se trata de um número pequeno de requisitos (i.e., aproximadamente 250), as tabelas
ou matrizes de rastreabilidade podem ser utilizadas através de uma simples planilha, porém se
utilizadas sobre uma grande quantidade de informações as tabelas acabam tornando-se
problemáticas, pois impedem uma fácil leitura e compreensão (CASTRO, 2000).
Para permitir controle durante o rastreamento, é necessário definir políticas sobre como e
quais informações estarão disponíveis. A Figura 20 representa um exemplo do impacto que pode ser
causado por uma alteração nos requisitos. Está matriz de rastreabilidade realiza o cruzamento entre
RF x RF. A primeira coluna e a primeira linha são responsáveis por relacionar e nomear cada
requisito com um identificador único. Avaliando o requisito R1, é possível verificar a sua
dependência com os requisitos R3 e R4. No caso de realizar uma alteração no requisito R4, é
necessário fazer uma avaliação nos impactos que serão gerados aos requisitos R1 e R3, pois na
coluna R4 e possível visualizar a dependência de R1 e R3 com R4 (SANTOS; VARGAS; ABREU,
2004).
63
Figura 20. Exemplo de matriz de rastreabilidade entre requisitos.
Fonte: SANTOS; VARGAS; ABREU (2004).
2.3 Diagrama de Atividades
Para que uma tarefa seja executada por um computador, é necessário definir uma seqüência
de passos necessários para atingir determinado objetivo através de um processo. Na UML, esta
seqüência de passos é representada por diagramas de atividades (LARMAN, 2004). Seu objetivo é
fornecer uma metodologia para representar, visualizar, especificar e documentar aspectos dinâmicos
envolvidos em uma operação, formados por etapas seqüenciais ou concorrentes de um processo
computacional (BOOCH; RUMBAUGH; JACOBSON, 2006).
Basicamente, um diagrama de atividades é formado por um início, um conjunto de ações e
uma transição de saída (BASTOS, [200-?]). Da mesma forma que uma atividade pode ser
decomposta em diversas sub atividades, com o objetivo de aumentar o nível de detalhamento a ser
alcançado BOOCH, RUMBAUGH e JACOBSON (2006) fazem a analogia de uma atividade a um
processamento não atômico dentro de uma máquina de estados, onde a cada atividade (i.e., estado),
esta é expandida em um conjunto de ações formadas por entradas e saídas, definindo um
processamento atômico através da mudança de estado ou comunicação de mensagens (e.g.,
chamadas de função, acesso a um banco de dados).
. Para Larman (2004), a utilização dos diagramas de atividades oferece uma notação mais
clara sobre a execução de tarefas, facilitando a visualização de fluxos de trabalho e processos do
negócio (Figura 21), normalmente representados através dos casos de uso.
64
Figura 21. Diagrama de atividades representando uma pesquisa em um sistema de buscas.
Da mesma forma que casos de uso são mecanismos facilitadores para a descoberta de
requisitos, a utilização dos diagramas de atividades pode fornecer uma notação mais elaborada e
detalhada do funcionamento de todas as atividades dinâmicas envolvidas no processo de um
negócio (ibidem). Já para Bastos ([200-?]) a associação entre um caso de uso e o diagrama de
atividades está relacionada à descrição das tarefas executadas pelo ator com base no ponto de vista
da execução do sistema.
Booch, Rumbaugh e Jacobson (2006) descrevem os componentes básicos existentes em um
diagrama de atividades:
• Nós: Representam uma unidade organizacional dentro de uma atividade ou um grupo de
atividades (Figura 22). Dependendo do nível de detalhamento desejado, será necessário
decompor em atividades mais específicas até atingir o seu limite (i.e., ações).
Normalmente a escolha da divisão pode ser feita com base no tempo e espaço necessário
para sua execução, principalmente em sistemas complexos;
65
• Ações: Processamento de uma parte atômica resultante da execução de uma tarefa (e.g.,
chamadas de operações, envio de sinais, criação de objetos, avaliação de expressões)
(Figura 22) (BASTOS, [200-?]);
Figura 22. Representação de uma atividade ou ação.
• Estado inicial e final: São responsáveis por determinar o início e o fim do fluxo de um
diagrama de atividades, devendo sempre haver um único estado inicial e existir um ou
diversos estados finais (Figura 23).
Figura 23. Representação de um estado inicial (esquerda) e um estado final (direita).
• Fluxos/transição: Responsável por representar a passagem do controle para a próxima
atividade através do fluxo executado (Figura 24). A passagem de uma ação para outra é
feita através de uma seta direcional, informando o sentido da atividade sucessora de um
evento;
Figura 24. Representação de uma transição por uma seta.
66
• Ramificação ou desvio: permite definir a execução de uma tarefa com base na decisão
de uma expressão booleana (i.e., verdadeiro ou falso), desta forma um fluxo alternativo
pode ser utilizado, já que nem sempre uma transição segue seqüencialmente (Figura 25);
e
Figura 25. Elemento de decisão com dois fluxos (sim/não).
• Bifurcação (fork) ou paralelismo: divide o fluxo do controle em um ou mais fluxos,
dependendo do sistema podem representar a execução concorrente e sincronizada
(BASTOS, [200-?]). Já para permitir que diversos fluxos sigam um único caminho, a
união é responsável por agrupar os fluxos concorrentes de forma sincronizada em um
fluxo único ( Figura 26).
Figura 26. Bifurcação em um diagrama de atividades.
Além dos componentes básicos de um diagrama de atividade, um recurso existente nos
pacotes da UML são os particionamentos de atividades, utilizados para dividir as atividades levando
em conta um grupo ou responsável pela sua execução e identificar as ações que possuem
características em comum (OMG, 2007; BASTOS, [200-?]). Existem basicamente três formas de
representar os particionamentos de atividades, utilizando uma notação hierárquica, multi-
dimensional ou na forma de raias (swimlanes). No exemplo da figura 27 é apresentada a divisão das
67
atividades de acordo com o tipo de usuário (i.e., administrador, analista, cliente) utilizando a
notação de raias.
Figura 27. Particionamento separando as atividades de acordo com o tipo de usuário.
2.4 Análise de ferramentas similares
A utilização de ferramentas CASE, surgiram da necessidade de facilitar e acelerar a
produtividade e qualidade nos processos da engenharia de software, tanto para desenvolvedores
quanto para analistas de sistema (KROTH, 2006).
A escolha da ferramenta ideal depende principalmente da metodologia do processo de
engenharia adotado. Entre os diversos padrões existentes, cabe aos responsáveis escolher a
ferramenta que melhor se adapte as necessidades e aos principais processos utilizados para a
informatização.
Kroth (2006) aponta os objetivos e características das ferramentas CASE, como: (i) o
aumento na produtividade; (ii) a automação e aumento da interação com os usuários na definição do
sistema; (iii) a liberação e aceitação dos requisitos para a aprovação; e (iv) facilitadores de uso,
principalmente com a construção de diagramas para visualizar e detectar os processos, permitindo
flexibilidade de apresentação e documentação do escopo do projeto.
68
Na elaboração deste projeto, procurou-se realizar um estudo de algumas ferramentas CASE
encontradas no mercado e que mais se assemelham a ferramenta proposta, com o objetivo de
apresentar algumas de suas principais funcionalidades.
2.4.1 Enterprise Architect 6.5
Desenvolvida pela empresa Sparx System, a ferramenta Entreprise Architect permite
desenvolver diversos projetos na área de engenharia de software seguindo os padrões da UML.
Figura 28. Especificação de requisitos no Enterprise Architect 6.5.
Esta ferramenta permite a construção de diagramas e modelos de forma completa como:
diagramas de caso de uso, especificação de requisitos ( Figura 28), diagramas de classe, diagramas
de atividade ( Figura 29) além de conter um módulo responsável por gerar uma matriz de
rastreabilidade entre diversos elementos do projeto.
69
Figura 29. Exemplo de diagrama de atividades gerado no Enterprise Architect 6.5.
Como ferramenta de colaboração, permite a criação de réplicas do projeto, dividindo tarefas
entre analistas e desenvolvedores para mais tarde agrupar as informações. Segundo Rech (2007), é
possível ainda realizar o compartilhamento de informações em nível de autenticação, bloqueio de
acesso a usuários e a conexão aos principais SGBDs disponíveis no mercado (e.g., Oracle, MySQL,
PostgreSQL).
2.4.2 CONTROLA
Ferramenta de apoio ao processo de engenharia de software em pequenas empresas,
desenvolvida no trabalho de conclusão de curso para Bacharel em Sistemas de Informação da
faculdade de Viçosa-MG por Clayton Vieira Fraga Filho em 2005. A ferramenta CONTROLA (
Figura 30), foi desenvolvida com o objetivo de auxiliar na elaboração de diversas atividades
referentes à engenharia de software em pequenas empresas, que geralmente não se utilizam de
70
processos específicos na elaboração de projetos e estão focadas no atendimento imediato do
problema do cliente (FRAGA FILHO, 2005).
Figura 30. Tela principal da ferramenta CONTROLA.
Fonte: FRAGA FILHO (2005).
Como funcionalidade, o gerenciamento de requisitos permite realizar o cadastro dos
requisitos de um produto de software, definindo diversos atributos para permitir avaliar e aprovar
pelos responsáveis e clientes, além de oferecer controle de versão para manter documentadas as
alterações realizadas.
Através da construção de matrizes de rastreabilidade (Figura 31), é possível construir
relacionamentos entre alguns dos artefatos fornecidos pela ferramenta (e.g., casos de uso, requisitos,
casos de testes, implementações).
71
Figura 31. Matriz de rastreabilidade criada pela ferramenta CONTROLA.
Fonte: FRAGA FILHO (2005).
Algumas características interessantes estão presentes nesta ferramenta. Uma delas é a
presença do método de priorização de requisitos baseados em valor, custo e risco proposto por Karl
Wiegers (2003 apud FRAGA FILHO, 2005).
Este método é baseado na atribuição de valores com base nos benefícios obtidos quando um
requisito é adicionado ao sistema ou por uma penalidade no caso de sua ausência, resultando em
uma prioridade de desenvolvimento, onde a importância calculada é proporcional ao valor agregado
e inversamente proporcional ao custo e risco de implementação (FRAGA FILHO, 2005).
2.4.3 ArgoUML
A ferramenta ArgoUML é uma ferramenta CASE open-source desenvolvida em Java para a
modelagem de diagramas seguindo padrões presentes na UML. Entre os padrões utilizados podem
se citar a utilização da especificação 1.4 da XMI, SVG (Scalable Vectorial Graphics) e OCL
(Object Constraint Language) (PICHILIANI; HIRATA, 2006).
72
Entre as principais características encontram-se à geração automática de código a partir do
modelo de classes, o auxílio à engenharia reversa e a realização de críticas dos modelos gerados
(ibidem).
Apesar desta ferramenta não ser originalmente colaborativa, uma adaptação realizada por
Pichiliani e Hirata (2006), possibilitou adicionar funcionalidades voltadas à colaboração através da
internet (Figura 32). Nesta versão os usuários podem compartilhar um espaço de trabalho, visualizar
e gerenciar as modificações que ocorrem em tempo real. Um sistema de bate papo é responsável por
melhorar a comunicação entre os participantes. Travas e indicadores visuais apontam as ações
sendo executadas dentro de um projeto.
Figura 32. Ferramenta Colaborativa ArgoUML.
Fonte: PICHILIANI E HIRATA (2006).
2.4.4 SPRES – Ferramenta Case para Especificação de Requisitos.
Desenvolvida como trabalho de conclusão do curso de Ciência da Computação em 2005
pelo acadêmico Júlio Cezar Chrystpher Quirino, esta ferramenta projetada em C++, rodando como
73
um aplicativo desktop na plataforma Windows permite auxiliar nos processos de especificação de
requisitos de software (ERS) (Figura 33).
Figura 33. ERS modelada na Ferramenta SPRES.
Fonte: QUIRINO (2005)
Entre as funcionalidades presentes nesta ferramenta estão à especificação de requisitos de
software seguindo o padrão IEEE 830-1998 proposto por IEEE(1998), o gerenciamento através da
rastreabilidade dos requisitos e a geração da ERS baseado no modelo proposto pelo IEEE e RUP
(Rational Unified Process – Processo Unificado da Rational). A ERS gerada pode ser salva em dois
formatos, o primeiro para leitura em processadores de textos convencionais (e.g., Microsoft Word,
Open Office) e o segundo em XML, para permitir que as informações possam ser utilizadas por
qualquer outro software. O sistema conta também com o cadastro de projetos, a criação de novos
atributos para os requisitos e registro de versões da documentação ERS.
74
2.4.5 Análise comparativa entre as ferramentas
O Quadro 1 apresenta uma comparação das funcionalidades existentes em algumas das
ferramentas similares disponíveis no mercado em comparação com a ferramenta WebCASE na
versão atual e em sua nova proposta.
Quadro 1. Comparação da ferramenta WebCASE com ferramentas similares.
Descrição WebCASE 1.0
WebCASE 2.0
CONTROLA Enterprise Architect
SPRES ArgoUML
Modelagem colaborativa
X X X X
Exportação XMI X X Importação XMI X X X X Modelagem Casos de Uso
X X X X
Controle de versão X X X X Ferramenta web X X Participação do cliente
X X
Modelagem Diagrama de Atividades
X X X
Especificação de requisitos
X X X X
Matriz de Rastreabilidade
X X X X
Geração ERS X X Chat na ferramenta X X X
A partir da comparação entre as ferramentas, é possível avaliar que somente a WebCASE
possui o requisito de ser uma ferramenta executada diretamente por um navegador Web, além de
contar com a participação do cliente diretamente na aprovação de casos de uso e requisitos de um
projeto.
O suporte aos arquivos XMI, apesar de ser um padrão internacional para troca de
informações da UML, não estava presente em algumas ferramentas de modelagem avaliadas,
limitando a possibilidade de migrar as informações entre as ferramentas.
Um dos aspectos observado nas ferramentas pesquisadas, mas que não se encontra na
ferramenta WebCASE é o controle de versão, para manter um histórico de evolução do projeto e a
75
possibilidade de geração da ERS conforme observado nas ferramentas Enterprise Architect e
SPRES.
Pode-se observar ainda que as funcionalidades propostas para a ferramenta WebCASE
permitirão uma evolução na documentação de aspectos importantes dos principais processos de
engenharia de requisitos, permitindo gerenciar, avaliar e detectar possíveis falhas nas fases iniciais
dos processos de engenharia de software.
76
3 PROJETO
Este capítulo apresenta a metodologia empregada no desenvolvimento deste trabalho no que
se refere à modelagem lógica do sistema, adotando os conceitos e paradigmas da engenharia de
software.
3.1 Modelagem de negócio e funcionalidades
A etapa de Modelagem de Negócio tem o objetivo de confeccionar um documento para
mapear as tarefas e atividades atendidas por um sistema, provendo uma melhor compreensão do
negócio e facilitando a visualização dos relacionamentos. Uma tarefa corresponde ao resultado final
que se deseja alcançar com a utilização de um sistema (i.e., o que deve ser feito), e as atividades
apresentam os meios necessários para sua realização (i.e., como deve ser feito) (SCACH, 2005 apud
BUGHI 2007).
No Apêndice A, denominado “Documento de Modelagem do Sistema”, são apresentados os
artefatos gerados durante a modelagem de negócio. Porém, as principais tarefas e atividades
levantadas pela análise são dispostas neste capítulo.
A modelagem foi desenvolvida segundo a notação UML, com artefatos que possibilitam
avaliar diversos aspectos do projeto e definir a estrutura necessária para a implementação do
sistema.
3.1.1 Requisitos
As subseções seguintes apresentam de forma sucinta somente os novos requisitos levantados
para a construção da Ferramenta WebCASE, os requisitos definidos na versão 1.0 da ferramenta são
apresentados no Apêndice A.
3.1.1.1 Requisitos Funcionais
Os requisitos funcionais elencados são:
• RF 01. Permitir ao analista cadastrar um requisito de acordo com seu tipo;
• RF 02. Permitir ao administrador cadastrar categorias para requisitos e regras de
negócio;
77
• RF 03. Permitir ao analista criar uma matriz de rastreabilidade e realizar o
relacionamento entre os elementos;
• RF 04. Permitir ao analista criar um pacote de diagrama de atividades;
• RF 05. Permitir ao cliente aprovar ou rejeitar um requisito;
• RF 06. Permitir ao analista importar requisitos de uma instância XMI gerada pelo
Enterprise Architect 6.5;
• RF 07. Permitir ao analista importar um diagrama de atividades de uma instância XMI
gerada pelo Enterprise Architect 6.5; e
• RF 08. Permitir ao analista criar pacote de requisitos/regras de negócio.
3.1.1.2 Requisitos Não-Funcionais
Os requisitos não-funcionais identificados são:
• RNF 01. A integração das novas funcionalidades não deverá interferir no
funcionamento das funções já presentes na ferramenta;
• RNF 02. As tecnologias utilizadas no desenvolvimento da ferramenta WebCASE serão
mantidas, sendo elas o PHP 5.0, JavaScript;
• RNF 03. O banco de dados será mantido, sendo este o MySQL versão 5.0;
• RNF 04. A compatibilidade das funcionalidades deve ser mantida a fim de serem
executadas nos navegadores Firefox 2.0 ou superior e Internet Explorer 5.5 ou
superior;
• RNF 05. A importação de requisitos e diagramas de atividades deve ser feito para o
padrão XMI versão 2.1 do Enterprise Architect versão 6.5;
• RNF 06. As informações de um relacionamento na matriz de rastreabilidade devem ser
exibidas ao posicionar o mouse sobre as células da matriz; e
78
• RNF 07. Os particionamentos de atividades devem conter um atributo de cor para
melhor distinção.
• RNF 08. O sistema deve ser compatível com o Mozilla Firefox e Internet Explorer;
• RNF 09. O sistema deverá rodar em um servidor com interpretador PHP;
• RNF 10. O sistema deve utilizar banco de dados MySQL;
• RNF 11. O acesso as funcionalidades do sistema deverá ser feita com um controle de
acesso através de login e senha; e
• RNF 12. O sistema deverá ser compatível com a versão 2.1 da XMI gerada pelo
Enterprise Architect 6.5.
3.1.1.3 Regras de Negócio
As novas regras de negócios identificadas para a versão 2.0 da ferramenta são:
• RN 01. Um requisito deverá ser do tipo funcional, não funcional ou regra de negócio;
• RN 02. Uma matriz de rastreabilidade deve realizar o rastreamento entre Requisitos
Funcionais, Regras de Negócio e Casos de Uso;
• RN 03. O administrador será responsável por cadastrar as categorias de requisitos e
regras de negócio que estarão disponíveis para todos os projetos;
• RN 04. Um caso de uso poderá ser relacionado com requisitos funcionais, casos de uso
e regras de negócio;
• RN 05. Um diagrama de atividades poderá conter os seguintes elementos: nó inicial, nó
final, atividades, ações, desvio e bifurcação (fork);
• RN 06. Um diagrama de atividades deve conter apenas um nó inicial e possibilitar
vários nós finais;
• RN 07. Um elemento do diagrama de atividades poderá se relacionar a mais de um
elemento, com exceção do nó inicial;
79
• RN 08. Um diagrama de atividades deve estar inserido dentro de um pacote;
• RN 09. Uma matriz de rastreabilidade deve pertencer a um projeto;
• RN 10. Um requisito deve pertencer a um pacote;
• RN 11. Um requisito deve possuir um identificador único;
• RN 12. Um projeto deve possuir uma única matriz de cada tipo entre os tipos de
relacionamento existente (UC x RF, RF x RF, RF x RN, UC x RN);
• RN 13. Um requisito pode estar associado a mais de um caso de uso;
• RN 14. Um requisito ou regra de negócio deverá estar relacionado a uma categoria.
• RN 15. Um elemento do diagrama de atividades não pode se relacionar com ele
mesmo;
• RN 16. Um elemento nó inicial do diagrama de atividades não poderá receber ligação
de outros elementos;
• RN 17. Um elemento nó final do diagrama de atividades não poderá realizar ligação
com outros elementos, somente receber;
• RN 18. Todos os elementos de um diagrama de atividades serão associados pela
ligação "controle de fluxo" possuindo informações de condição de guarda e mensagem
de transição; e
• RN 19. Um diagrama pode conter particionamentos de atividades.
3.1.2 Casos de uso
Os casos de uso contemplados pela ferramenta WebCASE estão descritos, detalhadamente,
no Apêndice A. Este capítulo apresenta resumidamente os casos de uso da versão 1.0 que sofreram
modificação e os casos de uso relacionados as novas funcionalidades.
80
3.1.2.1 Casos de uso alterados
• Módulo analista
• Importar diagrama de instância XMI: Este caso de uso foi modificado para permitir a
importação de requisitos e diagramas de atividades juntamente com os casos de uso
através de arquivos XMI (versão 2.1) gerados pela ferramenta Enterprise Architect
versão 6.5; e
• Detalhar caso de uso: Adicionada função para permitir relacionar os casos de uso aos
requisitos cadastrados no mesmo projeto.
3.1.2.2 Novos casos de uso
• Módulo administrador
• Manter tipos de requisitos: Como existem diversos tipos de requisitos não-funcionais
relacionados a funções e características específicas, este caso de uso é responsável por
manter os tipos de requisitos não-funcionais no sistema.(e.g., hardware, software,
usabilidade, performance, implementação, segurança). Permite também categorizar os
requisitos funcionais e regras de negócio de acordo com as necessidades.
• Módulo analista
• Manter requisito: Permite ao analista cadastrar, editar e excluir um requisito através de
um formulário;
• Desenhar diagrama de atividades: Permite ao analista manter um diagrama de
atividades dentro de um pacote adicionando os elementos disponíveis;
• Gerar matriz de rastreabilidade: Permite ao analista manter uma matriz de
rastreabilidade selecionando a origem e destino do rastreamento desejado (e.g., RN x
UC).
81
• Módulo cliente
• Aprovar requisito: Permite a um cliente aprovar ou reprovar um requisito criado por
um analista, com a possibilidade de adicionar um comentário informando o motivo da
escolha.
3.1.3 Diagrama de classes
No modelo de classes apresentado pela Figura 34, três novas classes foram adicionadas para
contemplar as novas funções da ferramenta:
• wcTraceabilityMatrix: Classe responsável por representar uma matriz de
rastreabilidade existindo uma origem e destino para realizar a relação entre os
elementos;
• wcRequirement: Classe responsável por representar um requisito modelado juntamente
com seu identificador, prioridade, estabilidade, dificuldade e status; e
• wcRequirementCategory: Classe responsável por representar uma categoria de
requisito ou regra de negócio.
Com a presença de elementos não visuais (requisitos) ao projeto, foi realizada uma alteração
na estrutura das classes para diferenciar os elementos visuais dos não-visuais, através da classe
wcVisualElement.
A classe wcLink foi modificada e agora possui dois novos atributos: (i) guard, para
informar a condição de guarda do relacionamento; e (ii) weight para informar a mensagem de
transição. A classe wcAdministrador foi alterada conforme a implementação e passa a herdar da
classe wcUser.
Para os elementos pertencentes ao diagrama de atividades, foram inseridas classes
relacionadas a cada tipo (e.g., atividade, nó inicial), responsáveis por definir seu formato e estrutura.
class Diagrama de Classes
wcUser
- email: string
- fone: string
- login: string
- mode: int
- password: string
wcProject
- scope: string
wcPackage
- packageEaId: string
- packageType: int
wcUseCase
- clientComent: string
- state: int
wcActor
wcLink
- guard: string
- weight: string
wcElement
- author: string
- creationDate: date
- elementEaId: string
- lastChange: date
- mode: int
- scope: string
- sessionTime: int
- state: int
wcObject
- id: int
- name: string
wcConstraint
- mode: int
- scope: string
wcScenario
- mode: int
- scope: string
wcAdministrator
wcAnalyst wcClient
wcRequirement
- clienteComment: string
- dificult: int
- identifier: string
- priority: string
- stability: string
- state: int
wcTraceabilityMatrix
- checked
- sourceElement
- targetElement
wcRequiremenCategory
- abbreviation: string
- mode: int
- name: string
wcClientComment
- comment: string
- commentDate: date
wcStartNode
wcVisualElement
- height: int = 80
- left: int = 0
- top: int = 0
- width: int = 100
wcEndNode wcActiv ityNodewcDecisionNode wcForkNodewcPartition
- color: string
wcXmi
1
-requirementType
0..*
0..*
1
0..*
-source
1
-condition 0..*1
0..*
-target
1
0..*
1
0..*
1
-scenario
0..* 1
-umlElement 0..*
1
-user0..* 0..*
1 -pakages0..*
1
-package
0..*
Figura 34. Modelo de classes modificado da ferramenta WebCASE.
3.1.4 Diagrama Entidade-Relacionamento
Após a definição das classes de domínio utilizadas pela ferramenta WebCASE, foi construído o
diagrama de Entidade-Relacionamento, apresentando a estrutura do banco de dados relacionado às
classes de domínio descritas.
Vale ressaltar que o modelo foi adaptado e corrigido conforme apresentado na Figura 34, com a
inclusão de informações ausentes em entidades já existentes do modelo original e a adição de novas
entidades necessárias para satisfazer os novos requisitos deste projeto.
As seguintes novas entidades foram adicionadas:
• wc_requirement: Entidade responsável por armazenar informações específicas de um
requisito (e.g., identificador, prioridade, estabilidade, dificuldade);
• wc_historical_requirement: Entidade responsável por armazenar as informações de um
requisito, permitindo manter histórico durante a ocorrência de aprovação ou reprovação pelo
cliente;
• wc_requirement_category: Entidade responsável por armazenar as categorias de requisitos
cadastradas pelo administrador no sistema contendo nome, abreviação e o tipo de elemento
(requisito funcional, requisito não-funcional, regra de negócio); e
• wc_traceability_matrix: Responsável por representar o relacionamento dos elementos em
uma matriz de rastreabilidade.
As únicas modificações realizadas no modelo ER foram nas seguintes entidades:
• wc_link: adicionando informações de relacionamento utilizado no diagrama de atividades e
dois atributos responsáveis por representar a condição de guarda e mensagem de transição
no relacionamento entre dois elementos; e
• wc_package: adicionado um atributo para identificar o tipo de pacote (pacote de casos de
uso, pacote de requisitos ou pacote de diagrama de atividades).
84
Figura 35. Modelo ER modificado da ferramenta WebCASE.
85
3.1.5 Diagrama de atividades
O diagrama de atividades da Figura 36 apresenta as possíveis operações realizadas por cada tipo
de usuário, com destaque para as atividades em verde que indicam as alterações propostas para a nova
versão da ferramenta.
Figura 36. Diagrama de atividades com as novas funcionalidades integradas.
4 IMPLEMENTAÇÃO
Neste capítulo são apresentados os resultados obtidos durante a fase de implementação e
integração com os módulos já existentes da ferramenta WebCASE, abordando as novas bibliotecas
encontradas, capazes de acelerar o desenvolvimento e melhorar a usabilidade do sistema, visto que
as aplicações RIA para a Web 2.0 encontram-se em constante evolução.
4.1 Banco de dados
No decorrer da elaboração dos novos módulos observou-se a necessidade de adaptar o
modelo ER anteriormente proposto, visto que algumas informações estariam melhor dispostas em
novas entidades, estas modificações encontram-se inseridas na seção 3.1.4.
Ao verificar a estrutura utilizada no banco de dados, observou-se o uso da codificação ISO-
8859-19. Como as requisições HTTP realizadas através do objeto XMLHttpRequest são
necessariamente feitas em UTF-8, optou-se por alterar o banco de dados e a aplicação para o padrão
UTF-8, reduzindo consideravelmente o número de conversões necessárias durante o processamento
das requisições.
4.2 Draw2d
Após analisar a implementação do diagrama de casos de uso na ferramenta WebCASE,
foram pesquisadas atualizações e bibliotecas capazes de simplificar o processo de elaboração dos
novos diagramas, com o objetivo de adicionar novas características e aumentar a liberdade de
manipulação dos elementos por parte do usuário.
A biblioteca Draw2d desenvolvida por Herz (2008) disponibilizada sob licença LGPL,
permite elaborar diagramas para as mais diversas finalidades. Baseada na JavaScript Vector
Graphics Library, a mesma utilizada na elaboração dos diagramas de casos de uso, é capaz de
simplificar e contornar diversos problemas quanto ao relacionamento, agrupamento e manuseio dos
elementos visuais presentes em um diagrama.
9Padrão desenvolvido pela ISO responsável por representar a codificação de caracteres do alfabeto latino, conhecido também como Latin-1.
88
Como exemplos de ferramentas disponíveis empregando a biblioteca Draw2d, estão a Open-
jACOB Blooper, uma ferramenta web para controle de defeitos (defect tracker) e o Digisim, uma
ferramenta para mapear e simular circuitos digitais. A escolha de utilização desta biblioteca,
justifica-se pela simples e rápida integração em ambientes desenvolvidos com a biblioteca ExtJS e a
capacidade de inserir funcionalidades complexas sobre elementos visuais de forma rápida e simples.
4.3 ExtJS
Antes de iniciar o desenvolvimento dos módulos propostos, foi realizado um estudo sobre a
biblioteca ExtJS a fim de avaliar a possibilidade de migração da versão adotada na ferramenta para
a última versão disponível (versão 2.2). Entre as principais evoluções encontradas nesta versão,
podem-se citar a existência de novos componentes, a realização de melhorias na estrutura da
biblioteca, permitindo uma maior rapidez (de desenvolvimento e de performance) e ainda correções
de falhas existentes nas versões anteriores. Porém, as melhorias realizadas na estrutura da biblioteca
inviabilizaram o seu uso, pois implicaram em alterações na forma de codificar os componentes, o
que, por sua vez, consumiria grande parte do tempo disponível para o desenvolvimento deste
projeto.
4.4 Layout
Para iniciar as alterações da ferramenta, foram modificados alguns elementos básicos da
interface, com o objetivo de melhorar a usabilidade da ferramenta, compreender o funcionamento e
a forma de operação da biblioteca ExtJS.
Como exemplo mais notável destas alterações, pode-se citar o menu principal (Figura 37),
atualizado através do plugin Accordion Panel (Sakalos, 2008), que além de manter o padrão de
interface da ferramenta permite: (i) realizar pesquisas entre as opções digitando no campo
”Pesquisar” qualquer parte do texto que indique a ação desejada; e (ii) expandir e retrair os painéis
existentes através dos botões superiores do menu.
89
Figura 37. Novo menu da WebCASE em comparação com o menu da versão anterior.
90
5 APRESENTAÇÃO DA FERRAMENTA
As modificações e os novos módulos desenvolvidos são descritos e elencados juntamente
com os requisitos e regras de negócio a que se referem, para demonstrar a realização das atividades
previstas na etapa de projeto.
A seção 5.1 apresenta os resultados obtidos da elaboração do módulo para modelagem dos
diagramas de atividades. Na seção 5.2 é descrito o cadastro dos tipos de requisitos utilizado tanto no
cadastro de requisitos para identificação e atribuição dos identificadores, quanto nas matrizes de
rastreabilidade. Na seção 5.3 é apresentado o módulo para especificação de requisitos e regras de
negócio. A seção 5.4 descreve o módulo para aprovação de requisitos na perspectiva do cliente, a
seção 5.5 descreve as matrizes de rastreabilidade responsáveis pelo gerenciamento dos requisitos e
por fim na seção 5.6 são apresentadas as modificações dos módulos já presentes na primeira versão
da WebCASE.
5.1 Módulo diagrama de atividades
Para a implementação do módulo de diagrama de atividades, foi utilizada a biblioteca
Draw2d (seção 4.2), formada por diversos elementos visuais e funcionalidades que proporcionam
maior usabilidade para o usuário.
A inclusão de um novo diagrama é feita através da criação de um pacote de diagrama de
atividades (RF 04, RN 08), quanto à realização do relacionamento entre os elementos do diagrama
(RN 07), utilizaram-se três algoritmos de representação fornecidos pelo Draw2d, curva normal,
bezier e manhatten, facilitando a disposição e representação das conexões entre os elementos,
conforme apresentado na Figura 38.
91
Figura 38. Diferentes formas de representação de relacionamento no diagrama de atividades.
O diagrama de atividades conta ainda com a opção de alinhar e movimentar os elementos de
acordo com a matriz de linhas apresentada ao fundo do diagrama, bastando para isso selecionar a
opção ”alinhar a grade” (Figura 39) através do menu exibido pelo botão esquerdo do mouse.
Figura 39. Menu popup com opções para facilitar a manipulação dos elementos
A adição de elementos ao diagrama é realizada através de ações de arrastar e soltar (drag’n
drop), tornando o seu uso similar a outras ferramentas para elaboração de diagramas. Mesmo não
tendo sido previsto durante a etapa de modelagem, dois novos elementos foram adicionados à este
diagrama (RN 05), bifurcação e união (descritos na seção 2.3). Optou-se por incluir estes elementos
dada sua importância durante a criação de diagramas de atividades e a facilidade de implementação
obtida pela biblioteca Draw2d, que não interferiram no tempo previsto para o desenvolvimento.
92
Outra funcionalidade implementada para o diagrama de atividades consiste em um conceito
especificado pela OMG UML 2.0, denominado Activity Partition (Particionamento de Atividade10),
que permite organizar as atividades de maneira lógica, sem afetar o fluxo das atividades (RN 19). A
criação destas áreas no diagrama é feita da mesma forma que a adição dos elementos, bastando
arrastar e soltar sobre o diagrama, permitindo inserir uma descrição e personalizar a cor de fundo
para facilitar a separação de responsabilidades (Figura 40).
Figura 40. Separação de responsabilidades através do particionamento de atividades.
O relacionamento entre dois elementos é realizado através dos conectores representados por
pequenos círculos (i.e., portas de conexão), arrastando a porta de origem até a porta de destino
(Figura 41).
10 Tradução livre do autor.
93
Figura 41. Relacionamento entre dois elementos conectando entre duas portas.
Todos os relacionamentos (RN 18) possuem atributos que permitem definir as condições de
guarda e mensagem de transição para o próximo elemento, estas informações encontram-se em uma
janela de cadastro acessada ao realizar um duplo clique sobre o relacionamento desejado (Figura
42). Os elementos presentes em um diagrama de atividades podem se relacionar livremente entre si,
mas nunca se relacionar com ele mesmo (RN 15), com exceção do nó inicial que não pode receber
ligações de outros elementos (RN 16) e só pode existir um elemento no diagrama (RN 06), e o nó
final que somente recebe ligações de outros elementos (RN 17), porém pode existir em mais
quantidade (RN 06).
94
Figura 42. Cadastro de informações de relacionamento do diagrama de atividades.
Para editar um elemento do diagrama basta executar um duplo clique ou selecionar o botão
existente ao lado do elemento. A tela exibida é apresentada na Figura 43 e permite informar a
descrição e observação do elemento juntamente com histórico de alterações realizadas. Os
históricos estão relacionados à alteração de informações e não a cada movimentação feita sobre o
diagrama reduzindo a presença de informações desnecessárias.
95
Figura 43. Tela para edição de elemento do diagrama de atividades.
5.2 Especificação de Requisitos e Regras de Negócio
Seguindo o conceito utilizado para visualização dos elementos, os requisitos e regras de
negócio de um projeto são armazenados em pacotes (RF 01, RN 10), que permitem agrupar e exibir
as informações em forma de listagem. Estes pacotes contam com a opção de exibir dados de forma
sumarizada ou completa além de conter diversas opções de filtros (e.g., por nome ou atributos),
facilitando a busca de informações em diferentes níveis de detalhamento (Figura 44).
Figura 44. Diversas opções de filtros em um pacote de requisitos.
Qualquer que seja o elemento deste pacote ele deve conter um identificador único (RN 11)
capaz de diferenciá-lo dos demais, assim após realizar uma inserção ou alteração é verificada a
96
unicidade do identificador dentro do projeto. A Figura 45 apresenta o formulário utilizado para
cadastrar os requisitos.
Figura 45. Tela de cadastro de requisito.
Tratando-se da colaboração de usuários, foi utilizado o mesmo conceito para edição dos
casos de uso já presente na versão 1.0 da ferramenta, através de um bloqueio para o solicitante com
tempo limite de 5 minutos ou até as alterações serem salvas, liberando novamente para outro
usuário realizar novas modificações.
É possível manter as categorias de requisitos (Figura 46) de forma organizada e centralizada
para todos os projetos através do cadastro de tipos de requisitos (RN 14), realizado pelo
administrador do sistema (RF 02, RN 03). Segundo a definição proposta inicialmente, somente os
requisitos não-funcionais estariam relacionados a uma categoria, para não limitar o escopo optou-se
por manter as categorias (RN 01) entre os requisitos funcionais, requisitos não-funcionais e regras
de negócio, assim todos os identificadores podem ser adaptados conforme a necessidade.
97
Figura 46. Cadastro de categorias de requisitos.
5.2.1 Aprovação de Requisitos
Após realizar o cadastro de um requisito, o analista deve liberá-lo para aprovação por parte
do cliente (RF 05). O conceito utilizado é o mesmo existente para a aprovação de casos de uso,
onde o cliente acessa o sistema através de um módulo específico e realiza a aprovação/reprovação,
podendo ainda inserir um comentário a respeito de sua escolha (Figura 47).
Figura 47. Tela para aprovação/reprovação de requisitos pelo cliente.
98
O histórico das informações permanece salvo até o momento da aprovação do cliente, onde
um novo histórico é gerado caso existam alterações posteriores a sua escolha. Neste histórico são
armazenadas a descrição, observação, informações adicionais e comentários do cliente sobre o
requisito, juntamente com a data e o responsável pela alteração.
5.3 Matriz de Rastreabilidade
Através das matrizes de rastreabilidade é possível realizar o relacionamento entre requisitos
funcionais, regras de negócio e casos de uso de forma bidirecional (RF 03, RN 02, RN 09, RN 12).
Na modelagem proposta estes relacionamentos estavam restritos a três formas (RF x UC, RF x RN,
RF x RF), porém optou-se por permitir relacioná-los entre si (RF, RN, UC), possibilitando verificá-
las em diferentes visões.
Outro fator analisado durante a elaboração das matrizes de rastreabilidade foi quanto à
visualização do relacionamento entre dois elementos. Como exemplo, na ferramenta Enterprise
Architect a descrição presente nos elementos verticais estava limitada a um tamanho específico,
dificultando a ampliação e visualização das informações (Figura 49).
Figura 48. Comparacão entre a matriz de rastreabilidade da Enterprise Architect (esquerda) e WebCASE (direita).
99
Para contornar este problema, foram utilizados tooltips (dicas) para exibir por completo as
informações de relacionamento em cada célula da matriz, fornecendo uma melhor usabilidade e
facilidade na utilização (Figura 49).
Figura 49. Visualização entre relacionamentos na matriz de rastreabilidade.
5.4 Alterações realizadas na versão 1.0
Nesta seção são apresentadas as modificações realizadas para integrar e adaptar os módulos
da ferramenta WebCASE existentes na versão inicial, mantendo suas características iniciais de
acordo com as metas estabelecidas neste projeto, obtendo como resultado, a ferramenta em suas
condições normais de funcionamento.
5.4.1 Casos de Uso
Foi adicionada uma nova aba que permite realizar o relacionamento entre requisitos
funcionais, regras de negócio e casos de uso (RN 04, RN 13). Sua estrutura assemelha-se ao padrão
utilizado em uma matriz de rastreabilidade com a diferença de ser formado por um conjunto de
filtros com a finalidade de facilitar a busca de elementos. Qualquer que seja o relacionamento
realizado em um caso de uso, este será visualizado diretamente na matriz de rastreabilidade e vice-
versa (Figura 50).
Figura 50. Relacionamento de um caso de uso com outros elementos.
5.4.2 Pacotes
Conforme a implementação da versão 1.0, um projeto dentro da ferramenta pode conter
diversos pacotes responsáveis por agrupar os elementos de acordo com as necessidades e assim
facilitar a localização das informações. Para diferenciar os tipos de pacotes, o cadastro passa a ser
formado pelo nome e o tipo do pacote (e.g., pacote de casos de uso, pacote de requisitos (RF 08) ou
pacote de diagrama de atividades), conforme apresentado na Figura 51.
Figura 51. Nova tela do cadastro de Pacotes
5.4.3 Importação XMI
Após concluir o desenvolvimento dos novos módulos, foi iniciada a adaptação do
importador de arquivos XMI a fim de aceitar os novos elementos existentes na versão 2.0 da
ferramenta.
Sua modelagem clara e simples permitiu adicionar os novos elementos sem realizar grandes
alterações em sua estrutura geral, tornando esta tarefa rápida de desenvolver e testar. Os testes
executados foram feitos de duas formas, a primeira importando cada tipo de pacote (requisitos,
casos de uso, diagrama de atividades) separadamente, e o segundo realizando a importação de um
projeto contendo os três tipos de pacotes, ambos importaram os dados mapeados no documento
XML corretamente.
Na fase em que se encontra o importador é possível importar os diagramas de casos de uso
(versão 1.0), requisitos e regras de negócio (RF 06) formado por sua descrição, observação, status,
dificuldade, prioridade e tipo de requisito, e por fim o diagrama de atividades (RF 07), limitando-se
102
aos elementos implementados na ferramenta (nó inicial, nó final, atividade, decisão,
união/bifurcação) e os particionamentos de atividades definidos na UML.
Caso ocorra a existência de elementos que não fazem parte do escopo deste projeto, estes
elementos são ignorados durante a importação e não afetam ou causam erros durante a leitura dos
arquivos XMI.
5.4.3.1 Estrutura de importação
Para facilitar a compreensão dos novos elementos importados esta seção apresenta as
marcações utilizadas dos arquivos XMI gerados pela ferramenta Enterprise Architect utilizando a
especificação 2.1 da XMI. Os elementos relacionados às funcionalidades da versão 1.0 encontram-
se documentadas no TCC do autor da versão inicial da ferramenta WebCASE, Vagner Rech.
Da mesma forma que os diagramas de caso de uso estão inseridos dentro da marcação
packagedElement, os diagramas de atividades e pacotes de requisitos são formados pela mesma
estrutura. A diferenciação entre os elementos encontrados são definidos através do atributo xmi:type
descritos abaixo na Tabela 1.
Valor Descrição
uml:Activity
Dependendo do escopo em que se encontra pode representar um pacote
de um diagrama de atividades ou um elemento atividade de um
diagrama de atividades.
uml:ControlFlow
Representa uma associação entre dois elementos em um diagrama de
atividades.
uml:InitialNode Representa um nó inicial em um diagrama de atividades.
uml:FinalNode Representa um nó final em um diagrama de atividades.
uml:DecisionNode Representa um elemento de decisão em um diagrama de atividades.
uml:Requirement Representa de um requisito.
103
uml:Class Representa um pacote de requisitos.
uml:ActivityPartition
Representa um particionamento de atividade de um diagrama de
atividades.
uml:ForkNode Representa um elemento de bifurcação/união em um diagrama de
atividades.
Tabela 1. Tabela de novos elementos utilizados na importação XMI.
As informações geométricas, posicionamento de elementos e atributos específicos de cada
diagrama, encontram-se inseridas na seção xmi:extension de forma semelhante a existente nos
diagramas de casos de uso.
104
6 TESTES E VALIDAÇÃO
Os resultados dos testes aplicados para validação da ferramenta são apresentados neste
capítulo e tem como objetivo avaliar seu funcionamento em condições normais de uso.
Segundo Dijkstra (1972 apud GOLDMAN; KON, 2004), a realização de testes é uma
maneira eficaz de detectar a presença de erros, porém insuficiente para demonstrar a sua total
ausência. Outro motivo para a realização de testes, está na tentativa sistemática de encontrar erros
em programas que espera-se estar em pleno funcionamento (GOLDMAN; KON, 2004).
Inicialmente os testes foram executados em paralelo ao desenvolvimento para verificar
possíveis falhas e garantir a integração entre os módulos da versão inicial da ferramenta. Após a
conclusão das atividades de programação, foi elaborado um formulário com questões relacionadas à
usabilidade e conformidade com os requisitos e regras de negócio (Apêndice B).
Os testes realizados foram aplicados juntamente com onze alunos da disciplina de
Engenharia de Software com o apoio da professora Adriana Gomes Alves do sétimo período do
curso de Ciência da Computação na Universidade do Vale do Itajaí. Para facilitar a compreensão e
focar nos objetivos de validação e conformidade, foi feita uma breve apresentação da ferramenta
aos envolvidos descrevendo a forma de execução do teste, onde cada pessoa acessaria o servidor de
aplicação da ferramenta WebCASE através de um usuário permitindo criar seu projeto de forma
individual. A escolha deste grupo de testes justifica-se pelo grau de conhecimento dos usuários
sobre o tema abordado neste trabalho, o que permitiu avaliar a ferramenta sobre diferentes visões.
Os resultados coletados foram tabulados em uma planilha para possibilitar a análise das
informações através de gráficos e comentários realizados pelos alunos (Apêndice C).
O gráfico da Figura 52 apresenta os resultados de eficácia para avaliar se a ferramenta
atendeu ou não os requisitos propostos juntamente com o número de erros (Eficiência) detectados
em cada módulo durante a realização dos testes.
105
Eficácia
53
6 56
1.1 Requisitos 1.2 Casos de Uso 1.3 Matriz de
Rastreabilidade
1.4 Diagrama de
Atividades
1.5 Aprovação de
Requisitos pelo
Cliente
Sim Não Eficiência(Erros)
Figura 52.Gráfico apresentando a relação de eficácia e erros dos módulos desenvolvidos.
6.1 Resultados de Usabilidade
Avaliando os resultados obtidos de informações de usabilidade, foi observada uma boa
eficiência na utilização da ferramenta onde apenas não existiu completa satisfação na ocorrência de
falhas, algumas relacionadas a funções pertinentes a primeira versão da ferramenta, visto que os
testes aplicados eram formados por tarefas de avaliação da integração.
A usabilidade do módulo para gerenciamento de requisitos obteve uma boa eficiência, foram
sugeridas melhorias quanto à disposição de alguns elementos na interface para torná-la mais
intuitiva. Os principais problemas encontrados estavam relacionados à realização de pesquisas onde
alguns filtros não buscavam as informações corretamente.
Durante a criação de um pacote a árvore do projeto não era atualizada automaticamente,
dando a impressão que a mesma não havia sido criada, fazendo com que o usuário adicionasse um
novo pacote. Apesar de não fazer parte do escopo do trabalho, foram corrigidas algumas falhas
juntamente com a atualização automática da árvore após a criação de um pacote.
No módulo de relacionamento para casos de uso, ocorreram apenas alguns erros ao filtrar as
informações e durante o relacionamento de elementos, visto que ocorria uma falha ao liberar o
elemento para edição.
106
Para avaliar a usabilidade da matriz de rastreabilidade, foi solicitada aos usuários a criação
de uma matriz para verificar se os relacionamentos entre os elementos estavam simples de serem
visualizados, visto que na ferramenta Enterprise Architect, adotada pelos alunos de Engenharia de
Software, existem algumas limitações dependendo do tamanho da descrição dos elementos das
colunas. De acordo com as respostas, a matriz possui boa usabilidade e permite uma boa
visualização do relacionamento entre os elementos.
No diagrama de atividades, foi verificada uma boa usabilidade contendo apenas algumas
falhas de relacionamento entre os elementos, solucionada através da análise de dados coletados dos
projetos criados durante o teste que facilitaram a sua detecção e posterior correção.
Os testes de aprovação de requisitos foram executados apenas por alguns usuários com
acesso a uma conta do tipo cliente, onde durante a aprovação do requisito o software se comportou
de forma inesperada em alguns casos, impossibilitando descobrir a falha ocorrida durante o teste,
mas que foram corrigidas após analisar as informações coletadas.
6.2 Conformidade dos requisitos e regras de negócio
Em relação aos testes de conformidade, duas regras de negócio (RN 07 e RN 16), não
haviam sido atendidas devido a problemas encontrados no diagrama de atividades, sendo estas
corrigidas e testadas novamente.
Como a escala utilizada para avaliação era entre um e cinco, todos os itens que obtiveram
nota inferior à metade (três) foram reavaliados, para tentar reduzir ao máximo o número de erros. A
Figura 53 e Figura 54, apresentam os resultados de avaliação de conformidade dos requisitos e
regras de negócio. Como a implementação da importação de arquivos XMI (RF 07) ainda estava
para ser concluída quando os testes foram executados, sua validação não foi realizada pelos
testadores, sendo este o motivo pelo qual a coluna referente ao RF7 não possui informações no
gráfico da Figura 54.
107
Conformidade Requisitos Funcionais
0
1
2
3
4
5
6
7
8
Não Atende
Parcialmente
Médio
Atende
Completamente
Não Disponível
Não Atende 0 0 0 0 0 0 0 0
Parcialmente 0 0 1 0 1 0 0 0
Médio 1 0 1 0 0 0 0 0
Atende 1 1 2 2 0 1 0 2
Completamente 7 5 5 7 7 3 0 3
Não Disponível 0 3 0 0 1 0 0 0
RF 01 RF 02 RF 03 RF 04 RF 05 RF 06 RF 07 RF 08
Figura 53.Gráfico apresentando a conformidade dos requisitos funcionais.
Conformidade Regras de Negócio
0
2
4
6
8
10
Não Atende
Parcialmente
Médio
Atende
Completamente
Não Disponível
Não Atende 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0
Parcialmente 0 1 0 1 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0
Médio 1 0 2 1 1 0 1 0 0 0 0 1 0 0 0 1 2 0 0
Atende 0 2 1 1 1 0 1 0 1 2 0 1 2 1 1 0 0 2 1
Completamente 7 5 4 5 7 7 6 8 7 6 8 7 5 7 7 5 7 3 4
Não Disponível 1 1 3 1 0 1 0 1 1 1 1 0 1 0 1 1 0 0 0
RN
01
RN
02
RN
03
RN
04
RN
05
RN
06
RN
07
RN
08
RN
09
RN
10
RN
11
RN
12
RN
13
RN
14
RN
15
RN
16
RN
17
RN
18
RN
19
Figura 54.Gráfico apresentando a conformidade das regras de negócio.
108
6.3 Teste de compatibilidade com navegadores
Os testes foram realizados em dois dos principais navegadores, Internet Explorer versão 6 e
Firefox versão 2 e 3, além do Google Chrome. Os resultados demonstraram total funcionamento no
Firefox e no Google Chrome. Este por sua vez obteve excelentes resultados tanto na velocidade de
carregamento da ferramenta, quanto na utilização de recursos de memória, em que o nível chegou a
ser 50% inferior comparado ao Firefox. O navegador Internet Explorer, por sua vez, comportou-se
de maneira inesperada em algumas situações, sendo necessária à atualização da página para
continuar o uso da ferramenta.
Ao analisar a taxa de transferência dos dados entre cliente e servidor através de uma
conexão de 300 Kbps, observou-se um alto tráfego na rede. Tendo isto em vista, foram pesquisadas
formas de reduzir o tamanho dos arquivos transferidos.
A primeira alternativa testada foi a diminuição de código JavaScript (Minify), que realiza a
remoção de caracteres desnecessários (e.g., espaços, tabulações, comentários) e a redução do nome
de variáveis, funções e classes sem modificar suas funcionalidades. Esta alternativa é útil
principalmente por linguagens interpretadas que são implantadas e transmitidas pela internet, como
exemplos de minifiers, pode-se citar o MINIFY e o Yahoo UI Compressor, que reduzem o tamanho
de arquivos JavaScript e CSS.
A segunda alternativa testada é através da ativação do módulo Deflate do serviço Apache.
Este módulo permite compactar o arquivo antes de sua transmissão pela rede, reduzindo, em alguns
casos, o tamanho e a taxa de transferência em mais de 50%. Os testes foram visualizados através do
plugin firebug disponível no navegador Firefox e demonstraram uma redução de aproximadamente
60% conforme apresentado na Figura 55.
Figura 55.Comparação da taxa de transferência com a ativação do modulo deflate no Apache.
109
7 CONCLUSÕES
Este trabalho teve como objetivo realizar a evolução da ferramenta WebCASE, adicionando
recursos para facilitar a análise e gerenciamento de projetos de software. Os novos conceitos
inseridos serviram para ajudar a consolidar a WebCASE como ferramenta didática, principalmente
por seus diferenciais que, se mantidos através de uma evolução gradual, poderão torná-la completa
para o uso na engenharia de software.
Para a primeira fase deste trabalho (TCC I), foi realizado um estudo da documentação e das
tecnologias utilizadas em sua primeira versão, com intuito de verificar seu funcionamento. Na
fundamentação teórica (Capítulo 2), foram abordados os tópicos relacionados à engenharia de
software, processos da engenharia de requisitos e os conceitos pertinentes à elaboração de
diagramas de atividades seguindo a notação da UML.
Na parte de projeto (Capítulo 3), foram elencados e documentados os requisitos e regras de
negócios necessários para o desenvolvimento das novas funcionalidades. Todos os diagramas
existentes na modelagem do projeto foram atualizados e suas divergências corrigidas para facilitar
sua compreensão por outros pesquisadores.
Após a conclusão da documentação, foram pesquisadas atualizações da biblioteca ExtJS,
para garantir a compatibilidade em possíveis projetos futuros. Porém, a nova versão impactou em
mudanças que inviabilizariam a migração devido ao grande número de conversões necessárias.
Na etapa de desenvolvimento (Capítulo 4), inicialmente foram alterados alguns elementos
básicos de interface e realizadas pequenas correções que facilitaram a compreensão da biblioteca
ExtJS. Durante a implementação, foi necessário estudar conceitos pertinentes a orientação a objetos
em JavaScript e a notação JSON, utilizada para realizar a troca de informações entre o cliente e o
servidor.
No desenvolvimento do módulo de elaboração de diagrama de atividades, procurou-se tomar
cuidado quanto à usabilidade fornecida para o usuário e manter certa similaridade a outras
ferramentas disponíveis no mercado. Após pesquisar diferentes sites para aplicações RIA,
descobriu-se uma poderosa biblioteca, a Draw2d, capaz de resolver os problemas relacionados à
criação de elementos visuais. Como a criação destes elementos não é feita de forma nativa pelo
navegador, a utilização de uma biblioteca de suporte permite focar os esforços nas regras da
110
aplicação, abstraindo a complexidade envolvida e facilitando a manutenção do sistema. Algumas
dúvidas encontradas na utilização desta biblioteca foram sanadas através de contato direto com o
responsável pelo desenvolvimento, Andréa Herz, que auxiliou na resolução dos problemas.
Finalizadas as atividades previstas no projeto, procurou-se aplicar um plano de testes para
certificar-se que a ferramenta encontrava-se em funcionamento. Durante a aplicação dos testes, foi
solicitado para alguns usuários um feedback a respeito da ferramenta, sendo exaltada por alguns
testadores a capacidade que as novas bibliotecas possuem em transformar as aplicações web
similares às aplicações stand alone.
Avaliando a situação em que o trabalho se encontra, conclui-se que os objetivos propostos
foram contemplados dentro das especificações estabelecidas na fase conceitual e prática, através de
pesquisas e absorção de novos conhecimentos que permitiram executar um projeto de extensão
sobre uma ferramenta previamente modelada, bem codificada e documentada além de suprir as
necessidades de: projeto, gerência, desenvolvimento, documentação, validação e testes que são o
alicerce de formação para um analista de sistemas, cientista da computação, gerente de TI e/ou
produtor de pesquisa e desenvolvimento. Prova disto é verificado com os resultados onde as
funcionalidades encontram-se integradas e em seu devido funcionamento.
7.1 Trabalhos Futuros
Após finalizar os novos módulos da ferramenta WebCASE e realizar diversas pesquisas
sobre tecnologias para a internet, foi possível observar o surgimento de novas tendências que
permitem executar tarefas antes limitadas a aplicações stand alone.
Para permitir o aprimoramento da ferramenta seguindo a tendência das tecnologias
utilizadas, sugere-se como atividades iniciais a atualização e migração da biblioteca ExtJS para a
sua nova versão, avaliando a possibilidade em se utilizar alguns dos Wrappers existentes em PHP
ou Java (e.g., ExtPHP, PHP-Ext, Ext-GWT) que facilitariam a criação dos principais componentes,
reduzindo o tempo gasto na codificação de códigos e a migração para futuras versões da biblioteca.
Outra recomendação é a alteração do diagrama de casos de uso para utilizar a biblioteca
Draw2d, que além de melhorar a usabilidade e facilitar a manutenção, permite desenvolver novos
componentes de forma bastante rápida.
111
Essas alterações podem ser consideradas periféricas no ponto de vista da pesquisa científica,
porém evoluções da ferramenta no sentido de incluir outros diagramas necessários para a
modelagem de um software, como diagramas de classes, diagramas Entidade-Relacionamento e
demais artefatos presentes na UML, poderão agregar valores a ferramenta, ampliar a sua utilização
acadêmica e até mesmo profissional.
Fica como sugestão a utilização do framework Symfony para padronizar e organizar a
estrutura das requisições e do projeto em módulos relacionados. Desenvolvido de acordo com o
padrão arquitetural MVC, permite implementar funcionalidades orientadas a objetos e utilizar uma
camada ORM (Object Role Modeling) para abstração de acesso a dados (e.g., Propel, Doctrine).
Através de uma camada ORM é possível acessar as informações do modelo relacional na forma de
objetos, livre de conceitos relacionados a banco de dados específicos, garantindo maior
portabilidade em caso de migração para outros SGBDs.
112
REFERÊNCIAS BIBLIOGRÁFICAS
ALECRIM, Emerson. Conhecendo o servidor apache, 2006. Disponível em: <http://www.infowester.com/servapach.php>. Acesso em: 16 mai. 2008.
BASTOS, R.M. Modelos de caso de uso - Diagrama de atividades, [200-?]. Disponível em: <http://www.inf.pucrs.br/~bastos/ModelagemSistemasInformacao/ModeloCasosUso-DiagAtividades.pdf>. Acesso em: 04 mai. 2008.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do. 4. ed. Rio de Janeiro: Campus, 2006.
BRASIL, Mysql. MySQL Brasil, 2008. Disponível em: <http://www.mysqlbrasil.com.br/?q=node/3>. Acesso em: 20 abr. 2008.
BRODSKY, S. XMI Opens Application Interchange, 1999 Disponível em: <www.cin.ufpe.br/~aad/garbage/xmiwhite0399.pdf>. Acesso em: 20 abr. 2008.
BUGHI, C. H. Observatório Virtual sobre a biodiversidade marinha no Brasil baseado em conceito WebGIS. Dissertação (mestrado em Ciência e Tecnologia Ambiental) - Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2007.
CAPPELLI, C., SANTORO, F. Modelagem de processos e engenharia de requisitos, 2005. Disponível em: <twiki.dcc.ufba.br/pub/Residencia/MaterialModuloBP2/MPN-Aula6b.pdf>. Acesso em: 28 mai. 2008.
CASTRO, J. Gerenciamento de Requisitos, 2000. Disponível em: <http://www.creupiapostilas.hpg.ig.com.br/erenciamentomudanca.ppt>. Acesso em: 23 mai. 2008.
COLOSSI, N., QUEIROZ E. G., CONSENTINO, A. Mudanças no contexto do ensino superior do Brasil: Uma tendência ao ensino colaborativo, 2001. Disponível em: <http://www.pp.ufu.br/Cobenge2001/trabalhos/CPI008.pdf>. Acesso em: 13 mar. 2008.
COSTA, C. J. Desenvolvimento para web, [200-?]. Disponível em: <http://books.google.com.br/books?id=Jn6dTDF-wcsC>. Acesso em: 16 mai. 2008
CYSNEIROS, L.M. Requisitos Não-funcionais: Da Elicitação ao Modelo Conceitual, 2008. Disponível em: <www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdf>. Acesso em: 14 mai. 2008.
DEXTRA SISTEMAS. PHP a linguagem franca da Web, 2008 Disponível em: < www.dextra.com.br/empresa/artigos/php.htm>. Acesso em: 20 abr. 2008.
FERNANDES, D. B. Análise de sistemas orientada ao sucesso: Por que os projetos atrasam? São Paulo: Ciência Moderna, 2005.
113
FILHO, P., Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2. ed. Rio de Janeiro: Ltc, 2003.
FRAGA FILHO, C.V. CONTROLA - Ferramenta de apoio ao processo de desenvolvimento de software em pequenas empresas, 2005. Disponível em: <http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=784>. Acesso em: 05 mai. 2008.
GARRETT, J. J. Ajax: A new approach to web applications, Adaptive Path Publications, 2005. Disponível em: <http://www.adaptivepath.com/publications/essays/archives/000385.php>. Acessado em: 31 mar. 2006.
GEROSA, M.A., RAPOSO, A.B., FUKS, H. Engenharia de groupware: desenvolvimento de aplicações colaborativas, 2002. Disponível em: <http://www.tecgraf.puc-rio.br/publications/artigo_2002_engenharia_groupware.pdf>. Acesso em: 13 mar. 2008.
GHEZZI, C., JAZAYERI M., MANDRIOLI, D. Fundamentals of Software Engineering. Upper Saddle River, NJ: Prentice Hall, 1991.
GOLDMAN, A.; KON, F. Testes de Software, 2004. Disponível em: <www.ime.usp.br/~kon/presentations/testes2004.ppt>. Acesso em: 04 nov. 2008.
GUSTAFSON, A. D. Teoria e Problemas de Engenharia de Software. Porto Alegre: Bookman, 2003. Coleção Shaum.
HERZ, A. Open-jACOB Draw2D, 2008. Disponível em: <http://draw2d.org>. Acesso em: 25 set. 2008.
IEEE. Recommended Practice for Software Requirements Specifications Std 830, 1998. New York: IEEE: 1998.
JACQUART, R.Building The Information Society, 2004. Ed. Springer. Disponível em: <http://books.google.com/books?id=L9RV64XQRecC&printsec=frontcover&hl=pt-BR&source=gbs_summary_r>. Acesso em: 10 mar. 2008.
KROTH, E. Ferramentas Case – Requisitos de Software, 2006. Disponível em: < inf.upf.br/pos/bd/CaseTools4.pdf >. Acesso em: 05 mai. 2008.
KRUCHTEN, P. Introdução ao RUP - Rational Unified Process. 5. ed. Rio de Janeiro: Ciência Moderna, 2003.
LARMAN, C. Utilizando UML e Padrões. 2. ed. Porto Alegre: Bookman, 2004.
LIMA, E.; BOECKMANN, G.; MONTEIRO, M.; SILVA, M; SAMPAIO, S.R. UML – Unified Modeling Language, 2000. Disponível em: <http://www.dei.unicap.br/~almir/seminarios/2000.2/3mno/uml>. Acesso em: 20 mar. 2008.
MACROMEDIA, ActionScript 2.0 Dictionary. Macromedia Press, 2003.
114
MAHEMOFF, Michael. Ajax Design Patterns: Creating WEB 2.0 Sites with Programming and Usability Patterns. Sebastopol, Califórnia: O’Reilly & Associates, 2006.
MARTINS, L.E.G. Engenharia de requisitos, 2001. Disponível em: <http://www.unimep.br/~lgmartin/ER_Aula7.ppt>. Acesso em: 27 mai. 2008.
MAZZOLA, V.B. Engenharia de Software. Disponível em: <http://www.inf.ufsc.br/~jbosco/ii/IIcap6.doc>. Acesso em: 01 abr. 2008
MEDEIROS, E. Desenvolvendo software com UML Definitivo. São Paulo: Pearson Makron Books, 2004.
MOOCK, Colin. Essential ActionScript 3.0. Sebastopol, Califórnia: O’Reilly & Associates, 2007.
PERRY, Bruce. Ajax Hacks. Sebastopol, Califórnia: O’Reilly & Associates, 2006.
PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prática. 2. ed. Rio de Janeiro: Campus, 2001.
PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. São Paulo: Prentice Hall, 2004.
PICHILIANI, M.C., HIRATA C.M. Uma ferramenta de software livre para apoiar a construção colaborativa de diagramas UML. VIII Workshop sobre software livre. Porto Alegre, 2006.
QUATRANI, T. Visual Modeling With Rational Rose 2000 And UML. 2000. Pearson Book.
QUIRINO, J.C.C. Ferramenta Case para especificação de requisitos de software observando IEEE-830-1998 e RUP. Trabalho de conclusão de curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnologias da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2005.
RAMOS L; STRECHT P. Aplicação de Reverse Engineering: Java para UML. [200-?]. Disponível em: <www.dei.isep.ipp.pt/~psousa/aulas/EINF/EINF-UML.pdf>. Acesso em: 10 maio 2008.
RECH, V. Ferramenta Web Colaborativa para Modelagem de Casos de Uso. Trabalho de conclusão de curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnologias da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2007.
REFSNES DATA, Browser Statistics. 2008. Disponível em: <http://www.w3schools.com/browsers/browsers_stats.asp>. Acesso em: 15 nov. 2008.
REZENDE, D.A. Engenharia de Software e Sistemas de Informação. Rio de Janeiro: Brasport, 1999.
115
SAKALOS, J. Saki’s Extensions, Plugins and Know-How, 2008. Disponível em: <http://www.extjs.eu>. Acesso em: 10 set. 2008.
SANTOS, F., VARGAS K., ABREU, C. Rastreabilidade de requisitos através da web, 2004. Disponível em: <http://www.inf.furb.br/seminco/2004/artigos/107-vf.pdf>. Acesso em: 20 mai. 2008.
SILVA, A. M.P.A., ROCHA, T. A. Modelagem de uma Ferramenta Case Orientada a Objetos. 1998. Disponível em: <http://www.cin.ufpe.br/~tar/trabalhos/graduacao.htm>. Acesso em: 15 mar. 2008.
SOARES, A.L. FARIA J.P. Engenharia de Requisitos, Especificação e Documentação. Disponível em: <http://paginas.fe.up.pt/~jpf/teach/ERSS/erss-documentacao.ppt>. Acesso em: 20 mai. 2008.
SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Prentice Hall, 2007.
STREIBEL, Martins. Implementando Web Services. Trabalho de conclusão de curso (Curso de Especialização em Web e Sistemas de Informação) – Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2005.
TECHTERMS. Standalone. 2008. Disponível em: <http://www.techterms.com/definition/standalone>. Acesso em: 17 dez. 2008.
UNESP. O processo de engenharia de requisitos. 2006. Disponível em: <http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/aula06_ProcessoRequisitos.pdf>. Acesso em: 20 mai. 2008.
VEDOVELLI, F. Introduction to Ext (Portuguese). 2007. Disponível em: <http://extjs.com/learn/Tutorial:Introduction_to_Ext_(Portuguese)>. Acesso em: 10 jun. 2008.
WOOLSTON, Daniel. Pro Ajax and the .NET 2.0 Platform.Berkeley, Califórnia: Apress, 2006.
116
APÊNDICE A
DOCUMENTO DE MODELAGEM DO SISTEMA
118
A DETALHAMENTO DE CASOS DE USO
Nesta seção são detalhados os casos de uso adicionados a modelagem da ferramenta
WebCASE. Na Figura 56 é apresentado o novo caso de uso UC 02.03 responsável por permitir o
cadastro de categorias de requisitos.
Módulo Administrador
uc PCT 02 -- Módulo Administrador
Analista
(from PCT 03 -- Módulo analista)
Administrador
UC02.01 - Cadastra
Administradores e
Analistas
UC02.02 - Gerencia
projetos
UC02.03 - Cadastra
categoria de
requisitos
Figura 56. Casos de uso do módulo administrador.
A.1 UC 02.03 – MANTER CATEGORIA DE REQUISITOS
Permite ao administrador manter as categorias dos requisitos e regra de negócio, definindo a
abreviação do elemento. Ex: Segurança, usabilidade, implementação, hardware, etc.
Relações
• RF 02. O sistema deverá permitir cadastrar categorias para os requisitos não-funcionais;
e
• RN 03. O administrador será responsável por cadastrar as categorias de requisitos e
regras de negócio que estarão disponíveis para todos os projetos.
119
Módulo analista
Na Figura 57 os casos de uso UC 03.08, UC 03.09 e UC 03.10, foram adicionado ao
modelo, já os casos de uso UC 03.03 e UC 03.06 já existiam, porém foram modificados para se
adequar às novas funcionalidades. As relações apresentadas referem-se aos requisitos e regras de
negócio da nova versão.
uc PCT 03 -- Módulo analista
Usuário
(from PCT 01 -- Módulo usuário)
Analista
UC03.01 - Desenha
diagrama
UC03.02 - Abre
projeto
UC03.03 - Detalha
casos de uso
UC03.05 - Inicia bate-
papo
UC03.06 - Importa
diagrama de
instância XMI
UC03.04 - Gerencia
Pacotes
UC03.07 - Cadastra
Cliente
UC03.08 - Mantém
Requisito
UC03.09 - Desenha
diagrama de
ativ idades
Os UC em amarelo (03.03 e 03.06)
indicam casos de uso já existentes
mas que foram modificados para
contemplar as novas
funcionalidades da versão atual
deste documento.
UC03.10 - Gera
matriz de
rastreabilidade
Figura 57. Casos de uso do módulo analista.
A.2 UC 03.03 – DETALHAR CASOS DE USO
Permite ao analista selecionar um caso de uso e iniciar sua modelagem adicionando cenários
e observações ao elemento. Quando um caso de uso já se encontrar em edição por um usuário, os
demais apenas poderão ler as informações de detalhamento contidas no elemento até que este seja
liberado.
Na nova versão permite ao analista relacionar um caso de uso a um ou mais requisitos
funcionais, regras de negócio ou casos de uso.
120
Relações
• RN 04. Um caso de uso poderá ser relacionado com requisitos funcionais, casos de uso e
regras de negócio.
A.3 UC 03.06 – IMPORTAR DIAGRAMA DE INSTÂNCIA XMI
Permite ao analista selecionar um arquivo XMI gerado pelo Enterprise Architect e importar
os diagramas de casos de uso.
Na nova versão da ferramenta serão importados também os requisitos e diagramas de
atividades do Enterprise Architect.
Relações
• RF 06. O sistema deverá permitir ao analista importar requisitos de uma instância XMI
gerada pelo Enterprise Architect; e
• RF 07. O sistema deverá permitir ao analista importar um diagrama de atividades de uma
instância XMI gerada pelo Enterprise Architect.
A.4 UC 03.08 – MANTER REQUISITO
Permite ao analista cadastrar um requisito de acordo com seu tipo funcional, não funcional
ou regra de negócio, determinar sua prioridade, status, estabilidade e dificuldade.
Relações
• RF 01. O sistema deve permitir ao analista cadastrar um requisito de acordo com seu tipo;
• RF 08. O sistema deve permitir ao analista criar um pacote de requisitos/regras de negócio;
• RN 01. Um requisito deverá ser do tipo funcional, não funcional ou regra de negócio;
• RN 10. Um requisito deve pertencer a um pacote;
• RN 11. Um requisito deve possuir um identificador único;
• RN 14. Um requisito ou regra de negócio deverá estar relacionado a uma categoria.
121
A.5 UC 03.09 – DESENHAR DIAGRAMA DE ATIVIDADES
Permite ao analista do sistema criar um diagrama de atividades e adicionar os elementos nó
inicial, nó final, atividade, ação, nó de decisão, bifurcação e realizar o relacionamento dos
elementos entre si.
Relações
• RF 04. O sistema deverá permitir ao analista criar um pacote de diagrama de atividades;
• RN 05. Um diagrama de atividades poderá conter os seguintes elementos: nó inicial, nó
final, atividades, ações, desvio e bifurcação (fork)
• RN 06. Um diagrama de atividades deve conter apenas um nó inicial e vários nós finais;
• RN 07. Um elemento do diagrama de atividades poderá se relacionar a mais de um
elemento, com exceção do nó inicial;
• RN 08. Um diagrama de atividades deve estar inserido dentro de um pacote;
• RN 15. Um elemento do diagrama de atividades não pode se relacionar com ele mesmo;
• RN 16. Um elemento nó inicial do diagrama de atividades não poderá receber ligação de
outros elementos;
• RN 17. Um elemento nó final do diagrama de atividades não poderá realizar ligação com
outros elementos;
• RN 18. Todos os elementos de um diagrama de atividades serão associados pela ligação
"controle de fluxo" possuindo informações de condição de guarda e mensagem de transição;
e
• RN 19. Um diagrama pode conter particionamentos de atividades.
A.6 UC 03.10 – GERAR MATRIZ DE RASTREABILIDADE
Permite ao analista criar uma matriz de rastreabilidade entre Casos de Uso, Requisitos
Funcionais e Regras de Negócio e realizar o relacionamento entre estes artefatos (linha x coluna)
permitindo avaliar e analisar possíveis implicações que possam existir no projeto.
122
Relações
• RF 03. O sistema deverá permitir ao analista criar uma matriz de rastreabilidade e realizar o
relacionamento entre os elementos;
• RN 02. Uma matriz de rastreabilidade deve realizar o rastreamento entre Requisitos
Funcionais, Regras de Negócio e Casos de Uso;
• RN 09. Uma matriz de rastreabilidade deve pertencer a um projeto;
• RN 12. Um projeto deve possuir uma única matriz de cada tipo entre os tipos de
relacionamento existente (UC x RF, RF x RF ou RF x RN, UC x RN, RF x RN); e
• RN 13. Um requisito pode estar associado a mais de um caso de uso.
Módulo Cliente
Na figura 45 é apresentado o modelo de casos de uso do cliente com a adição de um novo
caso de uso UC 04. 02, responsável por aprovar ou reprovar um caso de uso.
uc PCT 04 -- Módulo cliente
Usuário
(from PCT 01 -- Módulo usuário)
Cliente
UC04.01 - Aprov a
casos de uso
UC04.02 - Aprov a
requisito
Figura 58. Casos de uso do módulo cliente.
A.7 UC 04.02 - APROVAR REQUISITO
Permite ao cliente aprovar ou reprovar um requisito já cadastrado pelo analista em um
projeto na qual o Cliente se encontra cadastrado.
123
Relações
RF 05. O sistema deverá permitir ao cliente aprovar ou rejeitar um requisito.
B DICIONÁRIO DE DADOS
O dicionário de dados apresentado na seqüência, apresenta a situação atual após realizar a
implementação das novas funcionalidades na ferramenta.
B.1 ENTIDADE WC_CONSTRAINT
Esta entidade permite armazenar as pré-condições e pós-condições de um caso de uso. Cada
condição pode estar relacionada com apenas um único caso de uso.
Quadro 2. Entidade wc_constraint.
Atributo Definição do atributo Tipo
constraint_id Identificador único da condição. int fk_historical_elementId Identificador único do elemento UML. int
constraint_mode
Define o tipo da condição podendo assumir os seguintes valores: 0: Pré-condição; e 1: Pós-condição.
int
constraint_scope Texto com a descrição a condição. text
B.2 ENTIDADE WC_LINK
Esta entidade permite armazenar o relacionamento dos elementos presente no diagrama de
casos de uso e no diagrama de atividades.
124
Quadro 3. Entidade wc_link.
Atributo Definição do atributo Tipo target_id Identificador único do elemento fonte. int source_id Identificador único do elemento destino. int
link_mode
Define o tipo de relacionamento podendo assumir os seguintes valores: 0: Associação; 1: Generalização; 2: Extenção; 3: Inclusão; e 4: Controle de Fluxo.
int
link_style Estilo da conexão, manhatten, normal ou bezier int source_port Porta origem de conexão int target_port Porta destino de conexão Int guard Condição de guarda varchar(200) weight Mensagem de transição text
B.3 ENTIDADE WC_SCENARIO
Esta entidade define um cenário para um caso de uso. Um cenário pode estar relacionado
com apenas um único caso de uso.
Quadro 4. Entidade wc_scenario.
Atributo Definição do atributo Tipo
scenario_id Identificador único do cenário. int
fk_historical_element_id Identificador único do elemento UML (caso de uso) relacionado com o cenário.
int
scenario_name Nome do cenário varchar(45)
scenario_mode
Define o tipo de cenário assumindo os seguintes valores: 0: Cenário principal; 1: Cenário alternativo; e 2: Cenário de exceção.
int
scenario_scope Texto com o fluxo do cenário. text
B.4 ENTIDADE WC_ELEMENT
Entidade responsável por armazenar os elementos existentes nos pacotes de um projeto.
125
Quadro 5. Entidade wc_element.
Atributo Definição do atributo Tipo element_id Identificador único do elemento. int
user_owner_id Identificador único do analista que está editando o caso de uso.
int
package_id Identificador único do pacote pai do elemento. int element_name Nome do elemento. varchar(45) element_author Nome do autor do elemento. varchar(45) element_creation_date Data de criação do elemento. date
element_state
Status do elemento. Os valores assumidos pode m ser: 0: Em elaboração; 1: Aguardando aprovação do cliente; 2: Aprovado pelo cliente; e 3: Rejeitado pelo cliente;
int
session_time Define o tempo que a seção do usuário que edita ou editou o caso de uso pela última vez foi criada.
int
element_mode
Define o tipo do elemento assumindo os seguintes valores: 0: Caso de uso; 1: Ator; 2: Requisito/Regra de Negócio; 3: Nó Inicial; 4: Atividade; 5: Nó Final; 6 e 7: Bifurcação/União; 8: Decisão; e 9: Particionamento de Atividade.
int
element_ea_id Armazena o identificador em caso de importação por arquivo XMI
varchar(45)
B.5 ENTIDADE WC_HISTORICAL_ELEMENT
Esta entidade permite armazenar um histórico de alterações de um elemento UML (caso de
uso ou ator) em um diagrama de casos de uso ou dos elementos presentes no diagrama de
atividades.
126
Quadro 6. Entidade wc_historical_element.
Atributo Definição do atributo Tipo
h_element_id Identificador único do histórico do elemento. int
fk_element_id Identificador único do elemento pai. int h_element_scope Descrição do elemento. text h_last_change_user Nome do usuário que alterou o elemento. varchar(45) h_last_change Data da última alteração do elemento. date
h_element_state
Status do elemento. Os valores assumidos podem ser: 0: Em elaboração; 1: Aguardando aprovação do cliente; 2: Aprovado pelo cliente; e 3: Rejeitado pelo cliente;
int
h_element_width Largura em pixel do elemento. int h_element_height Altura em pixel do elemento. int h_elment_top Posição na coordenada Y em pixel do elemento. int h_element_left Posição na coordenada X em pixel do elemento. int
h_element_ea_id Armazena o identificador em caso de importação por arquivo XMI
varchar(45)
h_element_color Atributo para informa a cor de fundo de um elemento varchar(5)
B.6 ENTIDADE WC_PACKAGE
Define um pacote para diagramas de casos de uso. Um pacote está relacionado com um
único projeto e pode conter nenhum, um ou muitos outros pacotes ou elementos UML, no caso,
atores e casos de uso.
127
Quadro 7. Entidade wc_package.
Atributo Definição do atributo Tipo
package_id Identificador único para um pacote. int
fk_package_id Identificador único para um pacote. Se nulo, é um elemento raiz do projeto.
int
fk_project_id Identificador único do projeto. int package_name Define o nome do pacote. varchar(45)
package_ea_id Armazena o identificador em caso de importação por arquivo XMI
varchar(45)
package_type
Informa o tipo de pacote 1: Pacote de Diagrama de Casos de Uso; 2: Pacote de Requisitos; e 3: Pacote de Diagram de Atividades.
int
B.7 ENTIDADE WC_PROJECT
Esta entidade define um projeto na ferramenta.
Quadro 8. Entidade wc_project.
Atributo Definição do atributo Tipo
project_id Identificador único do projeto. int project_name Define o nome do projeto. varchar(45) project_scope Contém um texto descrevendo o projeto. int
B.8 ENTIDADE WC_USER
Esta entidade permite armazenar usuários do sistema. Os usuários podem estar relacionados
com nenhum, um ou muitos projetos. Um projeto pode ter nenhum, um ou muitos analistas, clientes
e pacotes.
128
Quadro 9.Entidade wc_user.
Atributo Definição do atributo Tipo
user_id Identificador único para usuário. int user_name Nome do usuário. varchar(45) user_login Identificador de usuário. varchar(45) user_password Senha do usuário varchar(45) user_mail E-mail do usuário. varchar(45) user_fone Telefone do usuário. int
user_mode
Define o tipo de usuário. Os valores possíveis são: 0: Administrador 1: Analista 2: Cliente
int
B.9 ENTIDADE WC_PROJECT_HAS_WC_USER
Entidade que relaciona os usuários de um projeto (analista e cliente). Um projeto pode ter
nenhum, um ou muitos analistas e clientes.
Quadro 10. Entidade wc_project_has_wc_user.
Atributo Definição do atributo Tipo
fk_project_id Identificador único do projeto. int fk_user_id Identificador do usuário int
B.10 ENTIDADE WC_CLIENT_COMMENT
Esta entidade permite armazenar comentários de clientes para um caso de uso.
Quadro 11. Entidade wc_client_comment.
Atributo Definição do atributo Tipo
fk_user_id Identificador único do cliente. int fk_historical_element_id Identificador único do elemento UML. int client_comment Comentário do cliente text client_comment_date Data de criação do registro Date
Abaixo são apresentadas as entidades criadas para permitir o desenvolvimento das novas funcionalidades.
129
B.11 ENTIDADE WC_REQUIREMENT
Esta entidade permite armazenar os requisitos cadastrados nos projetos.
Quadro 12. Entidade wc_requirement.
Atributo Definição do atributo Tipo
fk_element_id Identificador único do elemento. int fk_requirement_type_id Categoria de requisito. int requirement_identifier Identificador do requisito varchar(45)
requirement_priority
Prioridade para o requisito. Os valores possíveis são: 1: Baixa; 2: Média; e 3: Alta.
int
requirement_difficulty
Dificuldade de implementação do requisito. Os valores possíveis são: 1: Baixa; 2: Média; e 3: Alta.
int
requirement_stability Estabilidade do requisito. Os valores possíveis são: 1: Estável; e 2: Não estável.
int
requirement_status
Status do requisito. Os valores possíveis são: 1: Implementado; 2: Obrigatório; 3: Proposto; e 4: Válido.
int
requirement_observation Observação do requisito int
B.12 ENTIDADE WC_HISTORICAL_REQUIREMENT
Entidade responsável por armazenar o histórico dos requisitos.
Quadro 13. Entidade wc_historical_requirement.
Atributo Definição do atributo Tipo
h_element_id Identificador único do histórico do elemento. int
fk_element_id Identificador único do elemento pai. int h_requirement_scope Descrição do elemento. text h_last_change_user Nome do usuário que alterou o elemento. varchar(45) h_last_change Data da última alteração do elemento. date
h_requirement_state
Status do elemento. Os valores assumidos podem ser: 0: Em elaboração; 1: Aguardando aprovação do cliente; 2: Aprovado pelo cliente; e 3: Rejeitado pelo cliente;
int
h_element_ea_id Armazena o identificador em caso de importação por arquivo XMI
varchar(45)
B.13 ENTIDADE WC_REQUIREMENT_CATEGORY
Esta entidade permite armazenar as categorias de requisitos não-funcionais.
Quadro 14. Entidade wc_requirement_category.
Atributo Definição do atributo Tipo
requirement_category_id Identificador único da categoria de requisito. int requirement_category_name Nome da categoria de requisito. int requirement_category_abbr Abreviação ou nome curto da categoria. text
requirement_mode
Tipo de requisito 1: Requisito Funcional; 2: Requisito Não-Funcional; e 3: Regra de Negócio.
int
B.14 ENTIDADE WC_TRACEABILITY_MATRIX
Esta entidade permite armazenar o relacionamento dos elementos em uma matriz de
rastreabilidade.
Quadro 15. Entidade wc_traceability_matrix.
Atributo Definição do atributo Tipo fk_element_source_id Elemento Origem int fk_element_target_id Elemento Destino int checked Informa se os elementos estão ou não relacionados int
C REQUISITOS DA VERSÃO 1.0
REQUISITOS FUNCIONAIS
• RF 01: O sistema deverá permitir ao administrador cadastrar novos administradores;
• RF 02: O sistema deverá permitir ao administrador gerenciar analistas;
• RF 03: O sistema deverá permitir ao analista definir o(s) cliente(s) de um projeto;
• RF 04: O sistema deverá permitir ao administrador criar projetos e definir seus analistas
colaboradores;
• RF 05: O sistema deverá permitir ao administrador excluir projetos;
• RF 06: O sistema deverá permitir ao analista abrir um projeto na qual está definido como
analista;
• RF 07: O sistema deverá permitir ao analista adicionar ou remover pacotes em um projeto;
• RF 08: O sistema deverá permitir ao analista desenhar um diagrama de casos de uso;
• RF 09: O sistema deverá permitir ao analista detalhar casos de uso;
• RF 10: O sistema deverá permitir ao analista importar um diagrama de casos de uso de uma
instância XMI gerada pelo Enterprise Architect;
• RF 11: O sistema deverá permitir ao analista comunicar-se com os demais analistas através
de um chat;
• RF 12: O sistema deverá permitir ao cliente aprovar ou rejeitar casos de uso; e
132
• RF 13: O sistema deverá permitir aos usuários atualizarem seu perfil (senha, dados
pessoais).
REGRA DE NEGÓCIO
• RN 01: Um caso de uso ou ator poderá ser editado por apenas um analista em um mesmo
momento;
• RN 02: Quando em edição, um caso de uso deverá ficar disponível como somente leitura
para os demais analistas;
• RN 03: Os esteriótipos de Inclusão (« include ») e Extensão (« extend ») devem ocorrer
apenas entre casos de uso;
• RN 04: Associações devem ocorrer apenas entre atores e casos de uso;
• RN 05: Generalizações devem ocorrer entre elementos (casos de uso e atores) do mesmo
tipo; e
• RN 06: Um caso de uso só poderá ser avaliado por um cliente após ser liberado por um
analista.
REQUISITOS NÃO FUNCIONAIS
• RNF 01: O sistema deve estar em conformidade com o W3C;
• RNF 02: O sistema deverá rodar em um servidor com interpretador PHP;
• RNF 03: O sistema deve utilizar banco de dados MySQL;
• RNF 04: O acesso às funcionalidades do sistema deverá ser feito com controle de acesso
através de identificador de usuário e senha; e
• RNF 05: O sistema deverá ser compatível com a versão 2.1 da XMI gerada pelo Enterprise
Architect 6.5.
133
APÊNDICE B
DOCUMENTO DE TESTES
134
Documento de teste da ferramenta WebCASE v2.0
Ambiente para teste Os diagramas fornecidos no anexo deverão ser utilizados para guiá-lo durante os testes da ferramenta. Aconselha-se o preenchimento dos testes de usabilidade durante a criação dos diagramas.
1. Usabilidade O presente teste destina-se a verificar o grau de usabilidade da ferramenta WebCASE elaborado no âmbito do Trabalho de Conclusão de Curso do aluno Haissam Yebahi. Gradação das respostas: 1 (Muito fácil)
2 (Fácil) 3 (Dificuldade média) 4 (Difícil) 5 (Muito Difícil)
1.1 Requisitos
Eficiência Dificuldade Observações Descrição
Eficácia (Sim/Não) No. de
erros 1 2 3 4 5
Tarefa 1. Criar pacote para cadastro de requisito
Tarefa 2. Cadastrar um requisito funcional
Tarefa 3. Cadastrar uma regra de negócio
Tarefa 4. Cadastrar um requisito não-funcional
Tarefa 5. Alterar um requisito/regra de negócio
Tarefa 6. Excluir um requisito/regra de negócio
Tarefa 7. Pesquisar um requisito/regra de negócio no pacote
Tarefa 8. Filtrar requisitos por tipo
Tarefa 9. Filtrar requisitos por
135
informações adicionais Tarefa 10. Liberar requisito para aprovação pelo cliente
1.2 Casos de Uso11
Eficiência Dificuldade Observações Descrição
Eficácia (Sim/Não) No. de
erros 1 2 3 4 5
Tarefa 1. Selecionar requisitos e/ou regras de negócio a serem relacionados ao caso de uso
Tarefa 2. Relacionar requisito e/ou regras de negócio ao caso de uso
Tarefa 3. Remover relacionamento entre caso de uso e requisitos/regras de negócio
Tarefa 4. Filtrar requisitos e/ou regras de negócio relacionados ao caso de uso.
1.3 Matriz de rastreabilidade
Eficiência Dificuldade Observações Descrição
Eficácia (Sim/Não) No. de
erros 1 2 3 4 5
Tarefa 1. Gerar uma matriz de rastreabilidade entre Requisitos funcionais x Caso de Uso.
Tarefa 2. Relacionar
11 O módulo de Casos de Uso corresponde a primeira versão da ferramenta, por isso, deverá ser analisado somente a integração do Caso de uso com o módulo de requisitos.
136
um requisito funcional a um caso de uso. Tarefa 3. Remover relacionamento entre um requisito funcional e um caso de uso. (Mantenha ao menos um relacionamento para teste posterior)
Tarefa 4. O relacionamento é simples de ser visualizado através do painel visível sobre a célula correspondente?
Tarefa 5. Gerar uma matriz de rastreabilidade entre Caso e Uso x Caso de Uso.
Tarefa 6. Relacionar um Caso de Uso a um outro Caso de Uso.
1.5 Diagrama de Atividades
Eficiência Dificuldade Observações Descrição
Eficácia (Sim/Não) No. de
erros 1 2 3 4 5
Tarefa 1. Criar um pacote para o diagrama de atividades
Tarefa2. Adicionar nó inicial ao diagrama
Tarefa 3. Adicionar elementos Atividade ao diagrama.
Tarefa 4. Adicionar elemento decisão ao diagrama
Tarefa 5. Relacionar o elemento decisão a elementos Atividades.
Tarefa 6. Adicionar a condição de guarda ao fluxo. (selecionar o
137
relacionamento entre dois elementos). Tarefa 7. Adicionar um elemento bifurcação ao diagrama.
Tarefa 8. Alterar elemento do diagrama.
Tarefa 9. Excluir elemento do diagrama.
Tarefa 10. Adicionar particionamento ao diagrama
Tarefa 11. Alterar informações do particionamento
1.6 Aprovação de Requisito pelo cliente (Entrar no sistema com o usuário: cliente, senha: cliente, abrir o pacote e aprovar/rejeitar o requisito)
Eficiência Dificuldade Observações Descrição
Eficácia (Sim/Não) No. de
erros 1 2 3 4 5
Tarefa 1. Abrir um pacote de requisitos
Tarefa 2. Aprovar um requisito
Tarefa 3. Rejeitar um requisto
138
2. Avaliação de Conformidade A avaliação do atendimento aos requisitos especificados para a ferramenta consiste em um importante instrumento para verificar se o produto final (no caso, a ferramenta WebCASE) está de acordo com o projetado. Avalie cada item com notas de 1 (não atende) a 5 (atende plenamente). Caso não consiga avaliar por questões de nível de acesso, avalie o requisito como N.D (Não Disponível) 2.1 Atendimento aos requisitos funcionais Requisito Avaliação RF 01. O sistema deverá permitir ao analista cadastrar um requisito de acordo com seu tipo;
RF 02. O sistema deverá permitir ao administrador cadastrar categorias para requisitos e regras de negócio;
RF 03. O sistema deverá permitir ao analista criar uma matriz de rastreabilidade e realizar o relacionamento entre os elementos;
RF 04. O sistema deverá permitir ao analista criar um diagrama de atividades;
RF 05. O sistema deverá permitir ao cliente aprovar ou rejeitar um requisito;
RF 08. O sistema deve permitir ao analista inserir particionamento de atividades (similar às raias) em um diagrama de atividades.
2.2 Atendimento às regras de negócio Regras de Negócio Avaliação RN 01. Um requisito deverá ser do tipo funcional, não funcional ou regra de negócio;
RN 02. Uma matriz de rastreabilidade deve realizar o rastreamento entre Requisitos Funcionais, Regras de Negócio e Casos de Uso;
RN 03. O administrador será responsável por cadastrar as categorias de requisitos não funcionais que estarão disponíveis para todos os projetos;
RN 04. Um caso de uso poderá ser relacionado com requisitos funcionais, casos de uso e regras de negócio;
RN 05. Um diagrama de atividades poderá conter os seguintes elementos: nó inicial, nó final, atividades, ações, desvios e bifurcação (fork);
RN 06. Um diagrama de atividades deve conter apenas um nó inicial e vários nós finais.
RN 07. Um elemento do diagrama de atividades poderá se relacionar a mais de um elemento, com exceção do nó inicial;
RN 08. Um diagrama de atividades deve estar inserido dentro de um pacote;
RN 09. Uma matriz de rastreabilidade deve pertencer a um projeto; RN 10. Um requisito deve pertencer a um pacote;
139
RN 11. Um requisito deve possuir um identificador único; RN 12. Um projeto deve possuir uma única matriz entre os tipos de relacionamento existente na ferramenta (UC x RF, RF x RF ou RF x RN, UC x RN, RF x RN);
RN 13. Um requisito pode estar associado a mais de um caso de uso; RN 14. Um requisito ou regra de negócio deverá estar relacionado a uma categoria.
RN 15. Um elemento do diagrama de atividades não pode se relacionar com ele mesmo;
RN 16. Um elemento nó inicial do diagrama de atividades não poderá receber ligação de outros elementos;
RN 17. Um elemento nó final do diagrama de atividades não poderá realizar ligação com outros elementos;
RN 18. Todos os elementos de um diagrama de atividades serão associados pela ligação "controle de fluxo".e
RN 19. Um pacote de diagrama de atividades pode conter particionamentos de atividades.
3. Sugestões Espaço reservado para que você escreva as críticas e/ou sugestões em relação ao uso da ferramenta WebCASE. _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _______________________________________________________________________________ _____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
140
Diagrama de atividades
Abre projeto
Entrar no Sistema
Criar pacote? Cria pacote requisitos
Abrir pacote
Cadastrar Requisito
Liberar para
avaliação?Libera requisito para
av aliação
Sai do sistemaEnv iar email para cliente
Alterar 'status' dorequisito
Sai do sistema
[Sim]
[Sim]
[Nao]
141
Diagrama de Casos de Uso
Gerente
UC 01.1 Manter
Usuários do Sistema
Atendente
UC 01.2 Manter
Clientes
UC 01.3 Visualizar
Histórico
«include»
Requisitos funcionais
custom 2.2.1 Requisitos Funcionais
RF 01. O sistema deverá permitir ao administrador cadastrar novos administradores.
RF 02. O sistema deverá permitir ao administrador cadastrar novos analistas.
RF 03. O sistema deverá permitir ao analista cadastrar novos clientes.
RF 04. O sistema deverá permitir ao analista definir o(s) cl iente(s) de um projeto.
Requisitos não-funcionais
custom 2.2.2 Requisitos Não Funcionais
RNF 01.O sistema deve ser compatível com o Mozil la Firefox e Internet Explorer.
RNF 02. O sistema deverá rodar em um servidor com interpretador PHP.
RNF 03. O sistema deve util izar banco de dados MySQL.
RNF 04. O acesso as funcionalidades do sistema deverá ser feita com um controle de acesso através de login e senha.
Regras de negócio
custom 2.2.3 Regras de Negócio
RN 01. Um caso de uso ou ator poderá ser editado por apenas um colaborador em um mesmo momento.
RN 03. Os esteriótipos de Inclusão (« include ») e Extensão (« extend ») devem ocorrer apenas entre casos de uso.
RN 02. Quando em edição, um caso de uso deverá ficar disponível como somente leitura para os demais colaboradores.
RN 04. Associações devem ocorrer apenas entre atores e casos de uso.
RN 05. Generalizações devem ocorrer entre elementos (casos de uso e atores) do mesmo tipo.
143
APÊNDICE C
RESULTADOS DOS TESTES
RESULTADOS
1. Avaliação de Usabilidade
Dificuldade
1.1 Requisitos Eficácia Num. Erros 1 2 3 4 5
Sim Não Eficiência Muito Fácil Fácil Médio Difícil Muito Difícil
Tarefa 1 10 1 2 5 1 3 1 0
Tarefa 2 11 0 0 4 6 0 0 0
Tarefa 3 11 0 0 6 3 1 0 0
Tarefa 4 11 0 0 7 1 1 1 0
Tarefa 5 10 0 0 5 3 0 1 0
Tarefa 6 11 0 0 7 3 0 0 0
Tarefa 7 11 0 0 9 1 0 0 0
Tarefa 8 11 0 0 10 0 0 0 0
Tarefa 9 10 1 3 10 0 0 0 0
Tarefa 10 9 1 0 8 1 0 0 0
Dificuldade
1.2 Casos de Uso Eficácia 1 2 3 4 5
Sim Não Eficiência Muito Fácil Fácil Médio Difícil Muito Difícil
Tarefa 1 11 0 0 2 4 2 1 2
Tarefa 2 11 1 0 1 6 3 0 1
Tarefa 3 10 1 1 3 5 3 0 0
Tarefa 4 8 2 2 4 3 2 0 1
Dificuldade
1.3 Matriz de Rastreabilidade Eficácia 1 2 3 4 5
Sim Não Eficiência Muito Fácil Fácil Médio Difícil Muito Difícil
Tarefa 1 10 1 0 5 4 1 0 1
Tarefa 2 11 0 0 7 3 1 0 0
Tarefa 3 10 1 1 6 3 2 0 0
Tarefa 4 10 1 0 4 5 2 0 0
Tarefa 5 9 2 3 6 4 0 0 1
Tarefa 6 10 1 2 6 3 1 0 1
145
Dificuldade
1.4 Diagrama de Atividades Eficácia 1 2 3 4 5
Sim Não Eficiência Muito Fácil Fácil Médio Difícil Muito Difícil
Tarefa 1 10 0 1 7 4 0 0 0
Tarefa 2 10 0 0 8 1 2 0 0
Tarefa 3 10 0 1 7 3 1 0 0
Tarefa 4 9 1 1 8 2 1 0 0
Tarefa 5 10 1 0 8 3 0 0 0
Tarefa 6 10 0 1 6 4 1 0 0
Tarefa 7 10 0 1 8 3 0 0 0
Tarefa 8 10 0 0 7 4 0 0 0
Tarefa 9 10 0 0 10 1 0 0 0
Tarefa 10 10 0 0 9 2 0 0 0
Tarefa 11 10 0 1 9 2 0 0 0
Dificuldade
1.5 Aprovação de Requisitos Eficácia 1 2 3 4 5
Sim Não Eficiência Muito Fácil Fácil Médio Difícil Muito Difícil
Tarefa 1 6 1 1 4 1 1 0 0
Tarefa 2 5 2 2 4 1 0 0 0
Tarefa 3 5 2 2 4 0 1 0 0
Usabilidade 1.1 Requisitos
0
5
10
15
Sim
Não
Sim 10 11 11 11 10 11 11 11 10 9
Não 1 0 0 0 0 0 0 0 1 1
Tarefa
1
Tarefa
2
Tarefa
3
Tarefa
4
Tarefa
5
Tarefa
6
Tarefa
7
Tarefa
8
Tarefa
9
Tarefa
10
Usabilidade 1.2 Casos de Uso
0
2
4
6
8
10
12
Sim
Não
Sim 11 11 10 8
Não 0 1 1 2
Tarefa 1 Tarefa 2 Tarefa 3 Tarefa 4
Usabilidade 1.3 Matriz de Rastreabilidade
0
5
10
15
Sim
Não
Sim 10 11 10 10 9 10
Não 1 0 1 1 2 1
Tarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6
Usabilidade 1.4 Diagrama de Atividades
0
2
4
6
8
10
12
Sim
Não
Sim 10 10 10 9 10 10 10 10 10 10 10
Não 0 0 0 1 1 0 0 0 0 0 0
Tarefa
1
Tarefa
2
Tarefa
3
Tarefa
4
Tarefa
5
Tarefa
6
Tarefa
7
Tarefa
8
Tarefa
9
Tarefa
10
Tarefa
11
Usabilidade 1.5 Aprovação de Requisitos
0
1
2
3
4
5
6
7
Sim
Não
Sim 6 5 5
Não 1 2 2
Tarefa 1 Tarefa 2 Tarefa 3