Você está na página 1de 0

UNIVERSIDADE DO VALE DO ITAJA

CENTRO DE CINCIAS TECNOLGICAS DA TERRA E DO MAR


CURSO DE CINCIA DA COMPUTAO












WEBCASE FERRAMENTA COLABORATIVA PARA ESPECIFICAO
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 CINCIAS TECNOLGICAS DA TERRA E DO MAR
CURSO DE CINCIA DA COMPUTAO












WEBCASE FERRAMENTA COLABORATIVA PARA ESPECIFICAO
DE REQUISITOS E MODELAGEM DE DIAGRAMAS DE ATIVIDADES

rea de Engenharia de Software


por


Haissam Yebahi





Relatrio apresentado Banca Examinadora do
Trabalho de Concluso do Curso de Cincia da
Computao para anlise e aprovao.
Orientador: Carlos Henrique Bughi, M.Sc.







Itaja (SC), novembro de 2008
ii
AGRADECIMENTOS
Admito que no foi nada fcil chegar at esta fase, diversas foram as barreiras, falta de recursos,
restando como nico suporte o apoio de pessoas que sem dvida foram essenciais ao longo desses
cinco anos.
Em primeiro lugar agradeo a Deus, por ter me guiado diante de tantas dvidas mesmo quando a
esperana parecia no ser suficiente e hoje fica como uma grande experincia de vida.
Aos meus pais, Abdala Yebahi e Doralina Comelli, por toda educao e ensinamentos que me
tornaram a pessoa que sou.
A professora Adriana Gomes Alves por auxiliar e permitir a realizao dos testes durante sua aula
que tiveram grande importncia para verificar o funcionamento da nova verso 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 incio da faculdade.
Ao meu orientador Carlos Henrique Bughi, por confiar na minha capacidade e orientar durante este
ano, com diversas contribuies motivaes e cobranas que tornam possvel a realizao deste
projeto.
A famlia dos meus grandes amigos Jean Rauwers, Pai Joo, Dalva Rauwers, Daniel Hasse,
Janete Hasse e Hari Hasse, que me auxiliaram e que hoje considero parte da minha famlia, afinal
tiveram que me agentar por um bom tempo. Ao futuro aluno do curso de Cincia da Computao,
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 criao de imagens utilizadas no design da
ferramenta WebCASE.
As demais pessoas, amigos professores, avaliadores que apoiaram e contriburam para a realizao
deste projeto com idias, sugestes e crticas.
iii
SUMRIO

1 INTRODUO.................................................................................... 10
1.1 PROBLEMATIZAO................................................................................... 13
1.1.1 Formulao do Problema............................................................................... 13
1.1.2 Soluo Proposta............................................................................................. 13
1.2 OBJETIVOS ...................................................................................................... 13
1.2.1 Objetivo Geral ................................................................................................. 13
1.2.2 Objetivos Especficos ...................................................................................... 14
METODOLOGIA..................................................................................................... 15
1.3 ESTRUTURA DO TRABALHO ..................................................................... 17
2 FUNDAMENTAO TERICA...................................................... 19
2.1 ANLISE TCNICA DA FERRAMENTA WEBCASE.............................. 19
2.1.1 Funcionalidades............................................................................................... 19
2.1.2 Modelo conceitual e estrutura fsica do banco de dados............................. 25
2.1.3 Tecnologias ...................................................................................................... 33
2.1.4 Consideraes 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 ANLISE 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 Especificao de Requisitos. .................. 72
2.4.5 Anlise comparativa entre as ferramentas................................................... 74
3 PROJETO............................................................................................. 76
3.1 MODELAGEM DE NEGCIO 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 IMPLEMENTAo.............................................................................. 87
4.1 BANCO DE DADOS......................................................................................... 87
4.2 DRAW2D............................................................................................................ 87
4.3 EXTJS................................................................................................................. 88
4.4 LAYOUT............................................................................................................ 88
iv
5 Apresentao da Ferramenta.............................................................. 90
5.1 MDULO DIAGRAMA DE ATIVIDADES.................................................. 90
5.2 ESPECIFICAO DE REQUISITOS E REGRAS DE NEGCIO........... 95
5.2.1 Aprovao de Requisitos ................................................................................ 97
5.3 MATRIZ DE RASTREABILIDADE.............................................................. 98
5.4 ALTERAES REALIZADAS NA VERSO 1.0...................................... 100
5.4.1 Casos de Uso .................................................................................................. 100
5.4.2 Pacotes............................................................................................................ 101
5.4.3 Importao XMI ........................................................................................... 101
6 TESTES E VALIDAO................................................................. 104
6.1 RESULTADOS DE USABILIDADE............................................................. 105
6.2 CONFORMIDADE DOS REQUISITOS E REGRAS DE NEGCIO..... 106
6.3 TESTE DE COMPATIBILIDADE COM NAVEGADORES .................... 108
7 CONCLUSES.................................................................................. 109
7.1 TRABALHOS FUTUROS.............................................................................. 110
REFERNCIAS BIBLIOGRFICAS................................................. 112
A DETALHAMENTO DE CASOS DE USO...................................... 118
B DICIONRIO DE DADOS............................................................... 123
C REQUISITOS DA VERSO 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 Especificao 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 Negcio
RUP Rational Unified Process
RNF Requisitos No-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 Concluso 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. Aprovao de Casos de Uso pelo cliente............................................................................25
Figura 7. Modelo de classes original da ferramenta WebCASE........................................................26
Figura 8. Exemplo de cdigo para inserir informaes no banco de dados. ......................................27
Figura 9. Framework para conexo ao banco de dados da ferramenta WebCASE. ..........................30
Figura 10. Modelo ER da ferramenta WebCASE. .............................................................................31
Figura 11. Comunicao entre cliente servidor atravs de um navegador Web.................................34
Figura 12. Exemplo de comunicao utilizando AJAX.....................................................................39
Figura 13. Tabela de dados criada com a biblioteca ExtJS................................................................40
Figura 14. Cdigo para a gerao de uma tabela utilizando a biblioteca ExtJS. ...............................41
Figura 15. Pontes entre diferentes ferramentas e empresas. ..............................................................42
Figura 16. Distribuio 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. Representao de uma atividade ou ao. ........................................................................65
Figura 23. Representao de um estado inicial (esquerda) e um estado final (direita). .....................65
Figura 24. Representao de uma transio por uma seta..................................................................65
Figura 25. Elemento de deciso com dois fluxos (sim/no). .............................................................66
Figura 26. Bifurcao em um diagrama de atividades. ......................................................................66
Figura 27. Particionamento separando as atividades de acordo com o tipo de usurio. ....................67
Figura 28. Especificao 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 comparao com o menu da verso anterior. ..................89
Figura 38. Diferentes formas de representao de relacionamento no diagrama de atividades.........91
Figura 39. Menu popup com opes para facilitar a manipulao dos elementos.............................91
Figura 40. Separao de responsabilidades atravs do particionamento de atividades......................92
Figura 41. Relacionamento entre dois elementos conectando entre duas portas. ..............................93
Figura 42. Cadastro de informaes de relacionamento do diagrama de atividades. ........................94
Figura 43. Tela para edio de elemento do diagrama de atividades.................................................95
Figura 44. Diversas opes 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 aprovao/reprovao de requisitos pelo cliente. .............................................97
Figura 48. Comparaco entre a matriz de rastreabilidade da Enterprise Architect (esquerda) e
WebCASE (direita). ...................................................................................................................98
Figura 49. Visualizao 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.Grfico apresentando a relao de eficcia e erros dos mdulos desenvolvidos.............105
Figura 53.Grfico apresentando a conformidade dos requisitos funcionais. ...................................107
Figura 54.Grfico apresentando a conformidade das regras de negcio..........................................107
Figura 55.Comparao da taxa de transferncia com a ativao do modulo deflate no Apache. ....108
Figura 56. Casos de uso do mdulo administrador. .........................................................................118
Figura 57. Casos de uso do mdulo analista. ...................................................................................119
Figura 58. Casos de uso do mdulo cliente......................................................................................122
viii
RESUMO
YEBAHI, Haissam. WebCASE - Ferramenta Colaborativa para Especificao de Requisitos e
Modelagem de Diagramas de Atividades. Itaja, 2008. 149 f. Trabalho de Concluso de Curso
(Graduao em Cincia da Computao)Centro de Cincias Tecnolgicas 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 realizao das tarefas envolvidas na soluo de um problema. Manter as
informaes organizadas em um ambiente de trabalho compartilhado facilitam o gerenciamento e
rastreamento das mudanas em um projeto. Como resultados possvel negociar compromissos,
melhorar estimativas de prazo, alm de diminuir falhas, aumentando a satisfao do cliente e da
empresa responsvel pelo projeto. Atravs das ferramentas CASE (Computer Aided Software
Engineering Engenharia de Software Auxiliada por Computador), possvel realizar as atividades
envolvidas nos processos de engenharia de software em um nvel de especificao maior, com
nfase na anlise, qualidade e produtividade de um projeto. Sua utilizao permite facilitar o
entendimento humano e a comunicao, onde a tcnica empregada para a representao deve ser
capaz de expor e simplificar as etapas envolvidas no processo, incluindo informaes para seu
aprimoramento e real utilizao. Seguindo este conceito, a ferramenta WebCASE foi desenvolvida
para auxiliar as etapas iniciais da engenharia de software atravs da elaborao de diagramas de
casos de uso e permitir a interao e colaborao entre os responsveis. Tendo em vista que a
verso inicial da WebCASE contemplava uma parte dos processos existentes durante a modelagem
de um software, este projeto apresenta a extenso e evoluo da ferramenta atravs da incluso e
integrao de trs novas funcionalidades: (i) permitir a especificao de requisitos (requisitos
funcionais, no-funcionais e regras de negcio), (ii) elaborao de diagramas de atividades e (iii) a
gerao de matrizes de rastreabilidade entre requisitos funcionais, casos de uso e regras de negcio.
A ferramenta conta ainda com um mdulo para importao de arquivos XMI (XML-based Metadata
Interchange Intercmbio de metadados baseado em XML) gerados pela ferramenta Enterprise
Architect 6.5, tornando rpida a migrao de informaes entre estas aplicaes. Entre os
diferenciais da ferramenta WebCASE pode-se citar a utilizao de recursos open-source que
reduzem custos tanto no desenvolvimento, utilizao e principalmente pelo fato de ser uma
ferramenta desenvolvida para a plataforma Web. A execuo e desenvolvimento deste projeto de
pesquisa justificam-se por contemplar diversas reas da Cincia da Computao (e.g., Programao,
Engenharia de Software, Banco de Dados) e por possibilitar a evoluo de um projeto acadmico de
grande importncia, no somente pela incluso de conceitos at ento ausente em ferramentas
CASE, mas tambm como um instrumento de auxlio 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 its 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 its 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 INTRODUO
O aprimoramento de tcnicas 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 obteno de sucesso no desenvolvimento de
software, est em realizar uma boa documentao e especificao dos problemas a serem
solucionados. Para isto necessrio que um software passe por uma anlise detalhada, dividindo-o
em subproblemas de forma organizada a fim de encontrar os requisitos necessrios para seu pleno
funcionamento.
Para Gustafson (2003), um software possui um ciclo de vida formado por atividades
seqenciais denominadas milestones, onde so produzidos diversos artefatos (e.g., contratos,
avaliaes, cdigos fontes, documentao para os usurios) com a finalidade de avaliar o progresso
de desenvolvimento do sistema.
Seguindo estes conceitos possvel analisar sua natureza e complexidade, para mais tarde
sintetizar os mdulos definidos com maior clareza e menor probabilidade de reestruturao durante
o desenvolvimento. Como vantagens podem-se citar a reduo de custos na gesto dos recursos
necessrios e a estimativa de prazos dentro de um limite tolervel de tempo, existindo maior
satisfao para o cliente e equipe responsvel pelo projeto (PFLEEGER, 2004).
Pesquisas realizadas nesta rea comprovaram que uma boa engenharia e documentao,
resultam em produtos melhor sucedidos e menos propcios a falhas, mesmo existindo um aumento
no tempo necessrio 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 esto fortemente interligados. Para Braude
(2005 apud Rech, 2007) um caso de uso descreve de forma simplificada as variadas aes de uma
tarefa dentro de uma aplicao especfica, definindo as aes necessrias com base nas diversas
condies encontradas para sua realizao. A etapa de identificao dos casos de uso pode ser
auxiliada pela elaborao de diagramas de atividades, que servem para demonstrar o fluxo dos
processos existentes em sistemas.
Conforme citado por Jacquart (2004), o Standish Group, grupo responsvel por realizar
investigaes de aplicaes crticas, 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 concludos e apenas 16% eram entregues
11
dentro do prazo estipulado. Entre os fatores de insucesso, merecem destaque a m especificao e a
modificao dos requisitos durante a etapa de modelagem.
Quatrani (2000) apresenta um conceito sobre a importncia de uma boa definio em um
projeto, denominado de Tringulo do Sucesso. Para que um projeto seja bem sucedido necessrio
definir trs pontos que devem estar fortemente atrelados entre si: processo, notao e ferramenta. O
processo define a parte responsvel pela correta compreenso do problema, a notao responsvel
pela comunicao entre os envolvidos no processo e a ferramenta atua como um quadro de
comunicao, permitindo analisar e descrever os processos necessrios.
Atualmente as empresas e responsveis 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 grficos e linguagem padro, normalmente
a UML (Unified Modeling Language Linguagem de Modelagem Unificada), para projetar
softwares de forma completa (PFLEEGER, 2004).
A utilizao de ferramentas CASE tem como caracterstica facilitar a compreenso e a
comunicao, onde a tcnica empregada para representao das informaes deve ser capaz de
expor e simplificar as etapas envolvidas no processo (SILVA; ROCHA, 1998).
Quatrani (2000) aponta a interao entre os envolvidos (e.g., desenvolvedores, analistas,
clientes) como tarefa fundamental realizada desde o incio do projeto, definindo como os problemas
e processos sero resolvidos, transformando-os em operaes realizadas pelo computador atravs de
um software.
Com a internet novos conceitos surgiram para a comunicao e realizao de tarefas, de
forma descentralizada e geograficamente distribuda, denominada modelo de comunicao
colaborativa (COLOSSI; QUEIROZ; CONSENTINO, 2001). Este modelo permite que a interao
entre as pessoas continue de forma produtiva, existindo cooperao e coordenao por parte dos
participantes em um espao de trabalho compartilhado, atravs da negociao de compromissos e
conhecimento (GEROSA; RAPOSO; FUKS, 2002).
As ferramentas existentes no mercado para modelagem de sistemas, nem sempre possuem
uma maneira simples e flexvel de realizar o compartilhamento das informaes entre os envolvidos
em um projeto de software. Como alternativa a este cenrio, o acadmico do curso de Cincia da
Computao da Universidade do Vale do Itaja, Vagner Rech, desenvolveu uma ferramenta CASE
em seu trabalho de concluso de curso no ano de 2007. Como caracterstica principal, a ferramenta
denominada WebCASE rene a parte de comunicao 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 colaborao entre usurios e analistas durante a modelagem de um
sistema atravs da Internet, para acelerar os processos de correo e aceitao por parte do cliente.
A WebCASE foi desenvolvida com o propsito de auxiliar a engenharia de software atravs
da documentao de diagramas de casos de uso contendo atores, cenrios, pr-condies, ps-
condies, histrico de atualizaes, comunicao entre os usurios, atravs de salas de bate papo
(chats) e aprovao dos casos de uso pelos clientes.
Sua utilizao estende-se como uma ferramenta de apoio ao ensino da disciplina de
Engenharia de Software, para permitir uma melhor viso do negcio e facilitar a compreenso dos
diagramas de caso de uso, visto que muitas das ferramentas existentes no mercado possuem alto
custo para aquisio.
Sabendo-se que a verso inicial da ferramenta WebCASE contempla somente uma das
etapas existentes na modelagem de software, a proposta deste trabalho consiste na evoluo da
ferramenta atravs da incluso de trs novos mdulos: (i) mdulo para especificao de requisitos
(requisitos funcionais, no-funcionais e regras de negcio); (ii) mdulo para elaborao de
diagrama de atividades; e (iii) mdulo para gerao de matriz de rastreabilidade entre: requisitos
funcionais, casos de uso e regras de negcio;
Atravs da especificao dos requisitos e regras de negcio, possvel descrever as
principais funcionalidades e recursos de um software, definindo o que ele poder fazer alm de
relacionar suas restries e aspectos pertinentes ao negcio (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 no-funcionais, utilizados para
descrever aspectos relacionados s necessidades envolvidas em relao aos usurios e equipamentos
(e.g., usabilidade, desempenho, confiabilidade, hardware, segurana) (CONALLEN, 2003 apud
QUIRINO, 2005).
A elaborao de um diagrama de atividade tem como objetivo demonstrar o fluxo seqencial
das aes em um processo do sistema, possibilitando de maneira alternativa expressar como,
quando e onde elas acontecem. Sua representao feita utilizando-se elementos grficos visuais,
entre os principais podem ser citados os estados iniciais, estados finais, atividades e elementos de
deciso que permitem decidir um fluxo alternativo para uma determinada ao (LIMA et al., 2000).
13
Uma forma de verificar se os requisitos de software encontram-se contemplados pelos casos
de uso atravs da rastreabilidade entre estes elementos. Utilizando as matrizes de rastreabilidade
possvel visualizar o relacionamento entre os componentes do projeto (e.g., requisitos funcionais,
no-funcionais, regras de negcio, casos de uso) (KOTONYA; SOMMERVILLE 1997 apud
QUIRINO, 2005).
1.1 PROBLEMATIZAO
1.1.1 Formulao do Problema
Tratando-se de projetos de software, a utilizao de ferramentas CASE colaborativa para
auxiliar de forma eficiente a produo 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 disponveis para a elaborao de diagramas
de atividades e para a especificao de requisitos, porm o acesso descentralizado e em tempo real
permanece um tanto quanto ausente, pois muitas vezes as informaes necessitam ser
desmembradas da ferramenta em que foram projetadas, para posteriormente serem avaliadas pelas
equipes envolvidas.
1.1.2 Soluo Proposta
A execuo e desenvolvimento deste projeto de pesquisa justificam-se por contemplar
diversas reas da Cincia da Computao, como Programao e Engenharia de Software, bem como
por possibilitar a evoluo de um projeto acadmico de grande importncia no somente pela
incluso de conceitos ausentes na ferramentas, mas tambm como um instrumento de auxlio
disciplina de Engenharia de Software.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Integrar novas funcionalidades ferramenta WebCASE, para permitir a especificao de
requisitos, modelagem de diagramas de atividades e gerao de matrizes de rastreabilidade entre os
elementos (requisitos funcionais, regras de negcio e casos de uso).
14
1.2.2 Objetivos Especficos
Pesquisar e analisar solues similares de ferramentas de modelagem;
Analisar e compreender o funcionamento da ferramenta WebCASE;
Pesquisar os conceitos e tecnologias necessrias continuidade do projeto;
Estudar os conceitos relacionados ao gerenciamento, especificao e processos da
engenharia de requisitos;
Estudar a notao UML com nfase nos diagramas de atividades;
Determinar os requisitos exigidos pelo sistema;
Realizar a modelagem conceitual do sistema;
Implementar o sistema;
Mdulo para modelagem de Diagrama de Atividades;
N inicial e final;
Atividades;
Bifurcao (fork); e
N de deciso.
Mdulo para especificao de requisitos, e regras de negcio;
Descrio Requisito/Identificadores;
Status/Prioridade/Estabilidade/Dificuldade;
Cadastro de tipos de requisito; e
Aprovao/Rejeio pelo cliente.
Matriz de Rastreabilidade
Rastreabilidade entre requisitos funcionais, regras de negcio e casos de uso;
Importao de informaes geradas pela ferramenta Enterprise Architect verso 6.5
atravs da especificao XMI 2.1 (XML-based Metadata Interchange Intercmbio de
metadados baseado em XML) para diagramas de atividades e requisitos de software.
Testar e validar a implementao do sistema atravs de um caso de teste aplicado aos alunos
da disciplina de engenharia de software do curso de Cincia da Computao da UNIVALI,
para validar a usabilidade de todas as funcionalidades e conformidade dos requisitos e regras
de negcio; e
Documentar o desenvolvimento e os resultados alcanados.
15
Metodologia
Para a realizao do presente projeto, sua estrutura foi dividida em seis grandes etapas
listadas abaixo:
Levantamento bibliogrfico: Estudo das funcionalidades a serem adicionadas na
ferramenta, a fim de contemplar os requisitos propostos. Os conceitos envolvidos no projeto
so documentados nesta etapa, para permitir maior clareza e viabilizar sua concluso.
Fundamentao sobre os processos envolvidos na engenharia de requisitos, juntamente
com a relao das funcionalidades j presentes na ferramenta WebCASE e estudo das
caractersticas presentes na especificao de software segundo o padro IEEE 830-1998;
Fundamentao terica sobre gerenciamento, mudanas de requisitos e metodologias
aplicadas ao rastreamento de requisitos de software atravs das matrizes de
rastreabilidade;
Fundamentao terica 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 comparao e especificao dos requisitos seguindo
caractersticas presentes em ferramentas CASE.
Anlise Tcnica: Estudo da ferramenta WebCASE com o objetivo de compreender seu
funcionamento, verificando as necessidades para se adaptar ao requisitos deste projeto e
analisando as tecnolgicas envolvidas no ambiente proposto, suas particularidades e
compatibilidades.
Execuo da ferramenta, estudo da documentao e cdigos fontes disponveis;
Estudo das tecnologias utilizadas na ferramenta: JSON (JavaScript Object Notation
Notao de Objetos em JavaScript), framework Ext JS, JavaScript, PHP e MySQL; e
16
Pesquisa do padro para gerenciamento de objetos e troca de informaes baseadas no
padro XML (Extensible Markup Language Linguagem de Marcao Extendida) em
ferramentas de modelagem UML atravs da especificao XMI.
Levantamento de Requisitos e Modelagem: Definio dos requisitos e funcionalidades da
ferramenta proposta.
Definio dos requisitos e regras de negcio necessrio para contemplar o
funcionamento do sistema proposto;
Modelagem UML do sistema seguindo as metodologias apresentadas em livros. A
anlise dever abranger a especificao e componentes de software necessrios para
adicionar os mdulos propostos no escopo do trabalho. Para isto sero modelados e
alterados se preciso, os casos de uso, diagramas de classe e diagramas de atividades; e
Alterao 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, alterao da soluo existente, que
posteriormente passar por testes e validao.
Alterao da estrutura do banco de dados, adicionando novas tabelas para suprir as
necessidades do sistema; e
Implementao dos mdulos propostos de acordo com a definio dos requisitos. Todo o
desenvolvimento deve seguir a modelagem realizada e as funcionalidades descritas no
escopo do trabalho.
Testes e Validao: Realizao de testes e validaes sobre a soluo proposta, verificando
suas funcionalidades e corrigindo-as caso seja necessrio.
Realizao de testes das novas funcionalidades com alunos do curso de Cincia da
Computao da UNIVALI, que estejam cursando uma das disciplinas de engenharia de
software. Sero avaliados os novos servios implementados, analisando se os mesmos
alcanaram os resultados esperados; e
17
Testes de integrao com as funcionalidades existentes, atravs da definio e aplicao
de um estudo de caso para certificar-se que a ferramenta executa suas funes
inicialmente propostas nesta nova verso.
Documentao: Ao longo do projeto so registrados os passos executados desde o
levantamento do problema, a fundamentao terica, a proposta de uma nova soluo, o
desenvolvimento, testes, validaes, os resultados finais e concluses. Essa documentao
deve permitir que outros pesquisadores possam compreender a soluo, acrescentar novas
funcionalidades em verses futuras e efetuar os mesmos experimentos e testes feitos para
sua validao.
1.3 Estrutura do trabalho
No primeiro captulo apresentada uma introduo sobre o projeto, objetivos e a devida
importncia na rea de Cincia da Computao, 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 captulo (Fundamentao Terica), so definidos os principais conceitos
relacionados ao projeto, tecnologias e funcionalidades presentes na fase atual da ferramenta
WebCASE, conflitos encontrados entre o modelo terico e implementao para facilitar a
compreenso das etapas descritas, alm de ser realizado um estudo sobre algumas ferramentas
similares disponveis.
O terceiro captulo (Projeto) descreve as fases envolvidas no desenvolvimento das novas
funcionalidades ferramenta WebCASE, sua documentao, diagramas de atividade da UML,
requisitos e regras de negcio, diagrama de classes e modelo ER do banco de dados com a nova
estrutura contendo as modificaes realizadas para suprir as necessidades da nova verso.
No quarto (Implementao) e quinto (Apresentao da Ferramenta) captulo so
apresentados os resultados obtidos durante a implementao dos mdulos propostos, descrevendo o
as funcionalidades implementadas.
O sexto captulo apresenta os resultados dos testes aplicados com alunos do curso de
Cincia da Computao para avaliar a usabilidade e conformidade dos requisitos e verificar o
funcionamento da ferramenta nos principais navegadores.
18
O stimo e ltimo captulo apresenta as concluses, dificuldades encontradas durante o
desenvolvimento e sugestes para trabalhos futuros que possam aprimorar e expandir as
funcionalidades presentes na ferramenta.
19
2 FUNDAMENTAO TERICA
Neste capitulo so estudados e analisados os conceitos envolvidos no projeto de acordo com
a proposta inicial e assim servir como base para seu desenvolvimento.
A seo 2.1 apresenta um estudo tcnico sobre a ferramenta WebCASE, suas
funcionalidades e tecnologias utilizadas.
Na seo 2.2 so apresentados os problemas e motivaes da necessidade de gerenciar
projetos de software, a definio de requisitos, a engenharia de requisitos abordando seus quatro
processos, algumas das principais tcnicas utilizadas no reconhecimento de requisitos e as
principais caractersticas propostas pelo padro IEEE 830-1998 para especificao de requisitos.
Na seo 2.3 so apresentados os fundamentos sobre diagramas de atividades da UML
juntamente com a notao dos seus elementos.
Por fim, na seo 2.4, so exemplificadas algumas ferramentas CASE disponveis no
mercado, com as caractersticas presentes no foco deste trabalho atravs de uma tabela comparativa.
2.1 Anlise tcnica da Ferramenta WebCASE
Com o propsito de analisar e compreender a ferramenta WebCASE, realizou-se um estudo
de seu funcionamento, documentao, funcionalidades presentes na verso inicial, integrao dos
novos objetivos com os j existentes, alm da modelagem conceitual e tecnologias utilizadas no
desenvolvimento. Esta anlise visa verificar as possveis implicaes e modificaes necessrias
para atender as necessidades dos novos mdulos propostos que estaro 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 elaborao,
mantendo um histrico de atualizaes e permitindo trabalhar de forma concorrente sobre um
mesmo projeto (RECH, 2007).
20
A ferramenta WebCASE possui opes diferenciadas de acordo com o tipo de usurio
autenticado (cliente, analista e administrador). As sees seguintes foram baseadas no trabalho de
concluso de curso do acadmico Vagner Rech e apresentam as funcionalidades presentes na
ferramenta em sua verso inicial (RECH, 2007).
2.1.1.1 Perfil de usurio
O controle de acesso e realizado por nvel de usurio divididos em trs categorias, cada qual
com suas devidas permisses.
Administrador: o perfil com maior nmero de funcionalidades dentro do sistema.
Permite consultar, cadastrar, alterar e excluir administradores e analistas (Figura 1),
gerenciar projetos e definir os analistas responsveis pelos mesmos. Um administrador
pode executar as funcionalidades presentes no perfil Analista, mas no do perfil Cliente;
Analista: Grupo de usurios que podem abrir projetos, adicionar e remover pacotes,
cadastrar clientes, modelar e desenhar diagramas de casos de uso com seu respectivo
detalhamento, alm de permitir importar diagramas de casos de uso da ferramenta
Enterpise Architect verso 6.5 atravs de arquivos XMI na verso 2.1; e
Cliente: Este o perfil de usurio com o menor nmero de funcionalidades disponveis,
entre suas aes esto aprovao e rejeio de casos de uso, realizao de anotaes e
participao 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
Mdulo principal do sistema (Figura 2) permite aos analistas de um projeto criar os
diagramas inserindo casos de uso, atores e realizar a associao entre os elementos (associao,
generalizao, incluso e extenso).

Figura 2. Exemplo de um diagrama de casos de uso.
22
Em relao ao nvel de detalhamento (Figura 3), possvel inserir informaes sobre cada
caso de uso como cenrios, observaes, condies e a liberao para aprovao pelo cliente. Existe
na ferramenta um controle que permite a edio 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 usurios com perfil administrador adicionar novos projetos ou excluir projetos
existentes. Conforme apresentado na Figura 4, no momento da incluso de um novo projeto,
possvel definir quais sero os analista j cadastrados, que participaro 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 comunicao entre os usurios,
sem a necessidade de utilizar um sistema externo. Este fator relevante j que a colaborao uma
das caractersticas presentes na WebCASE.
A Figura 5 apresenta a tela do chat que permite aos usurios da ferramenta WebCASE,
acessar o sistema de bate papo, visualizar e trocar mensagens (on-line). As mensagens enviadas
ficam armazenadas mantendo um histrico das conversas realizadas.
24

Figura 5. Chat agregado a ferramenta WebCASE.
2.1.1.5 Importao de arquivos XMI
A importao de diagramas de caso de uso de outras ferramentas feito atravs do mdulo
de importao utilizando arquivos no padro XMI 2.1. Atualmente existe apenas suporte para
importao de arquivos gerados pela ferramenta Enterprise Architect na verso 6.5, sendo esta
restrio mantida neste projeto.
2.1.1.6 Aprovao de casos de uso
Aps 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 comentrio para o analista (Figura 6).
25

Figura 6. Aprovao de Casos de Uso pelo cliente.
2.1.2 Modelo conceitual e estrutura fsica do banco de dados
Uma importante etapa na anlise da ferramenta consiste no estudo das classes e estrutura do
banco de dados presente na primeira verso ( Figura 7). Na seqncia apresentado um breve
detalhamento do modelo de diagrama de classes da ferramenta, com o objetivo de identificar sua
utilizao.
26

Figura 7. Modelo de classes original da ferramenta WebCASE.
Fonte: Rech (2007).
A seguir so descritas as classes presentes no modelo proposto por Rech (2007)
desenvolvidas tanto do lado cliente utilizando-se a linguagem JavaScript quanto do lado servidor
atravs da linguagem PHP.
wcObject: Responsvel por definir os atributos e mtodos comuns a todas as demais
classes existentes no modelo. Entre as operaes possveis esto: inserir, atualizar,
remover, listar informaes de acordo com o objeto. Na Figura 8, um objeto do tipo
wcElement criado conforme o parmetro passado ao mtodo setTable na linha 12 e
seus atributos enviados na linha 14 para o mtodo insert da classe wcObject, responsvel
por gravar as informaes no banco de dados. Isto permite que atravs de uma nica
classe qualquer ao possa ser realizada no meio de persistncia. Estas classes
27
encontram-se implementadas tanto do lado servidor atravs do arquivo
wcObject.class.php quanto do lado cliente atravs do arquivo object.js;

Figura 8. Exemplo de cdigo para inserir informaes no banco de dados.
wcElement: Para qualquer elemento adicionado a um pacote a classe wcElement
herdada da classe wcObject responsvel por representar as caractersticas bsicas de
um elemento como descrio, dimenses, posicionamento na tela. Encontra-se
implementada do lado cliente no arquivo package.js, contendo os mtodos comuns de
manipulao 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 esto presentes na ferramenta e representadas por
wcUseCase e wcActor;
wcUseCase: Responsvel 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 so
herdadas de wcElement e no possui informaes adicionais. Em sua implementao
existem mtodos especficos para adicionar e renomear um ator.
wcUser: Classe herdada da classe wcObject responsvel por definir um usurio do
sistema formada por atributos que definem as principais caractersticas presentes nos trs
tipos de usurios da ferramenta (administrador, analista e cliente) e os mtodos que
28
permitem realizar as funes de acordo com o perfil de acesso de cada usurio.
Encontra-se implementada no lado servidor atravs do arquivo wcUser.class.php para
permitir pesquisar e controlar as informaes de um usurio no banco de dados e no lado
cliente implementada no arquivo user.js, responsvel por criar as requisies que sero
encaminhadas para o servidor de aplicao;
wcAdministrator: Classe especialista de wcUser responsvel por definir as operaes
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, porm ao invs de estender da classe wcAnalyst de acordo
com o modelo esta estendendo da classe wcUser;
wcAnalyst: Classe especialista de wcUser, responsvel 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 responsvel 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 responsvel por representar um projeto criado na ferramenta, como
tambm herda da classe wcObject possuindo um nico atributo para armazenar a
descrio de um projeto. Permite adicionar pacotes, definir clientes e analistas presentes
em um projeto. Implementada do lado servidor atravs da classe wcProject.class.php,
responsvel por criar objetos que sero 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 existncia de subpacotes no necessria, mas para poder inserir casos de
uso e atores necessrio que exista ao menos um pacote. Esta classe encontra-se
implementada do lado cliente atravs do arquivo package.js que possui todas as
operaes possveis em um pacote. Nesta classe existem diversas funes responsveis
29
por tratar as operaes realizadas em um pacote como movimentao de elementos na
tela (e.g. drag and drop), redimensionamento, relacionamento entre elementos, criao e
remoo do pacote, etc;
wcConstraint: Classe responsvel por representar as pr-condies e ps-condies de
um caso de uso. Encontra-se desenvolvida no lado cliente dentro do arquivo
analyst_dialogs.js, entre seus mtodos esto montar e exibir as telas para cadastro de
condies de um caso de uso;
wcScenario: Representa um cenrio presente em um caso de uso, tambm possui um
atributo para adicionar uma descrio e outro para informar o tipo de cenrio (e.g.,
principal, alternativo, exceo) e est implementada dentro do arquivo analyst_dialogs.js
contendo os mtodos para exibir e cadastrar a tela de cenrios de um caso de uso; e
wcLink: Classe responsvel por representar e definir o tipo de conexo pelo atributo
mode (e.g., associao, incluso, exceo) entre dois objetos da classe wcElements. Sua
implementao no lado cliente foi realizada dentro do arquivo package.js que possui
como funcionalidades, desenhar, remover, verificar o tipo de conexo entre os elementos
e adicionar um texto informando o tipo de conexo representada.
A classe de importao e tratamento de arquivos XMI encontra-se implementada, porm no
referenciada dentro do modelo de classes da ferramenta WebCASE. Representada pelo arquivo
wcXMI.class.php no lado servidor, responsvel por tratar o arquivo escrito em XML e inserir as
informaes no banco de dados para serem acessadas atravs de um projeto;
Segundo Rech (2007) um framework de persistncia de dados foi desenvolvido com o
objetivo de acelerar e facilitar manutenes nos processos de consulta ao banco de dados, utilizando
os conceitos de orientao a objeto, o framework formado por seis classes, apresentadas no
diagrama da Figura 9 e descritas abaixo:
30

Figura 9. Framework para conexo ao banco de dados da ferramenta WebCASE.
Fonte: Rech (2007).
wcDBConfig: Classe responsvel por armazenar as informaes de conexo com o
banco de dados como usurio, senha, host e database;
wcDBConnection: Classe responsvel por realizar a conexo com o banco de dados
utilizado pela ferramenta WebCASE, possui funes para abrir, fechar e selecionar a
conexo ativa com o banco de dados;
wcFields: Classe que salva os campos retornado de uma consulta ao banco de dados ou
os campos que sero inseridos atravs de um comando insert ou update;
31
wcDBQuery: Classe responsvel por executar as instrues SQL, formada por dois
mtodos, um para realizar consultas e outro para inserir, remover e editar informaes no
banco de dados; e
wcMySQL: Classe que realiza a conexo com o banco de dados MySQL.
Na Figura 10 apresentado o DER (Diagrama Entidade Relacionamento) do banco de dados
da ferramenta WebCASE, onde a descrio das tabelas geradas exemplificada na seqncia.

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 no estar presente no
32
modelo lgico, esta entidade conta com um campo identificador (package_ea_id), utilizado
nos caso de importao 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 importao de arquivo XMI, encontrava-se presente somente no modelo fsico do
banco de dados;
wcProject: Entidade que armazena os projetos cadastrados na ferramenta, formado pelo
nome e descrio do projeto;
wcProjectHasWcUser: Entidade gerada a partir da relao de wcProject e wcUser, permite
relacionar um usurio do sistema a vrios projetos;
wcUser: Entidade responsvel por armazenar as informaes dos usurios com acesso ao
sistema, como analistas, clientes e administradores;
wcLink: Armazena o relacionamento e tipos de associao (e.g., associao, incluso,
extenso) utilizados entre casos de uso e atores;
wcClientComment: Armazena os comentrios realizados pelos clientes em um caso de uso
juntamente com a data da realizao do mesmo. No modelo lgico, esta entidade possui uma
chave estrangeira para a entidade wcElement, porm no modelo fsico do banco de dados
encontra-se relacionada entidade wcHistoricalElement;
wcHistoricalElement: Armazena informaes de quem e quando realizou modificaes nos
elementos (casos de uso e atores). Quando um caso de uso aprovado, um novo histrico
gerado, mantendo um histrico das modificaes realizadas no seu escopo.
wcConstraint: Armazena as pr-condies e ps-condies dos casos de uso. Cada
condio, relaciona-se somente a um caso de uso e formada pelo tipo da condio e a
respectiva descrio; e
wcScenario: Define um cenrio pertencente a um nico caso de uso, armazenando o nome
do cenrio, tipo e descrio.
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 Aplicaes Ricas para Internet)). Para acessar o
sistema necessrio apenas um computador conectado ao servidor de aplicao e um navegador
web como o Firefox (2.0 ou superior) ou Internet Explorer (5.5 ou superior). Navegadores web ou
Web Browsers so aplicaes executadas em um computador (cliente), que permitem exibir
contedos dinmicos de pginas disponibilizadas em outros computadores (servidores). Seu acesso
pode ser realizado de duas formas, atravs de uma rede local ou atravs de conexes remotas pela
internet, que utilizam como meio de comunicao um protocolo de transferncia de hipertexto
(COSTA, [200-?]).
So explicadas, na seqncia, as tecnologias utilizadas no desenvolvimento da ferramenta,
tanto do lado cliente quanto do lado servidor. Vale ressaltar que a maioria das solues presentes
so open-source
1
e de grande utilizao e aceitao pelos desenvolvedores com foco em aplicaes
web.
2.1.3.1 Servidor Web
Para permitir a comunicao entre cliente e servidor de aplicao (Figura 11), foi utilizado o
servidor Web Apache
2
, responsvel por disponibilizar o sistema atravs da internet ou intranet. Este
servio utiliza-se do protocolo HTTP (Hypertext Transfer Protocol Protocolo de Transferncia de
Hipertexto) para responder as requisies dos usurios, alm de permitir a execuo de aplicaes
CGI (Common Gateway Interface - Interface Comum de Sada) e linguagens de scripts, como PHP
(Hypertext Preprocessor) e JSP (Java Server Pages) (ALECRIM, 2006).



1
Software de utilizao livre e sem custos com liberdade para adaptao e distribuio de cpias, permitindo tambm
modificar o cdigo-fonte e disponibilizar de forma gratuita para toda a comunidade com o objetivo de beneficiar a todos
os usurios e desenvolvedores. (SEABRA, 2007)
2
Disponvel em: http://www.apache.org
34

Figura 11. Comunicao entre cliente servidor atravs de um navegador Web.
Fonte: Adaptado de STREIBEL (2005).
2.1.3.2 Linguagem de programao
A linguagem de programao adotada, o PHP
3
(Hypertext Preprocessor) verso 5.0,
consiste em uma linguagem de script interpretada no lado servidor, que permite disponibilizar
contedos dinmicos e interagir com os usurios atravs de formulrios presentes nas pginas web,
conforme o esquema apresentado na Figura 11 (COSTA, [200-?]).
Como diferenciais presentes no PHP em relao a algumas outras linguagens para a Web,
podem-se citar (DEXTRA SISTEMAS, 2008):
Disponvel para os mais diversos sistemas operacionais existentes (e.g., Windows, Mac
OS, Linux, Solaris). Atualmente suportado pelos principais servidores de aplicao
(e.g., Apache, IIS (Microsoft Internet Information Service), Xitami, Netscape);



3
Disponvel em: http://www.php.net/
35
O suporte a grande variedade de SGBDs (Sistema Gerenciador de Banco de Dados)
permite que o servidor de aplicao comunique-se com os principais e mais diversos
bancos de dados existentes no mercado como PostgreSQL, MySQL, Oracle, Interbase,
SQL Server e suporte ao padro ODBC (Open Database Connectivity - Padro Aberto
de Conexes a Bancos de Dados), que permite acessar diferentes tipos de bancos de
dados atravs de uma interface padro;
Possui diversas bibliotecas para facilitar a leitura e escrita de arquivos textos, alm de ser
compatvel com os principais padres de interpretadores XML propostos pelo W3C
4

(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 programao pode ser realizada tanto de forma procedural e seqencial
(procedimentos e funes), ou atravs da programao orientada a objeto (suportada nas
verses mais recentes a partir do PHP 5.0), que permite desenvolver os mais diversos
frameworks de aplicaes RAD (Rapid Application Developlment Desenvolvimento
Rpido de Aplicaes), alm de permitir a integrao com outras linguagens de
programao como JAVA e .NET;
A gerao de arquivos em PDF (Portable Document Format Formato de Documento
Porttil), manipulao de imagens, criao de animaes dinmica (i.e., on the fly) em
flash, envio de e-mails e compactao de arquivos, feita de forma simples com uma
grande quantidade de funcionalidades; e
Possui suporte a diversos protocolos de comunicao como HTTP, POP (Post Office
Protocol Protocolo de Transferncia de Mensagens), SMTP (Simple Mail Transfer
Protocol Protocolo de Transferncia Simples do Correio), FTP (File Transfer Protocol
Protocolo de Transferncia de Arquivos) at em nveis mais baixos como a abertura
direta de sockets, que permite interagir com qualquer outro protocolo.




4
Disponvel em: http://www.w3.org
36
2.1.3.3 Banco de dados
O armazenamento das informaes da ferramenta WebCASE feito utilizando-se o SGBD
relacional MySQL verso 5.0 na verso open-source. Entre os principais motivos para o sucesso
deste banco de dados esto velocidade, confiabilidade e facilidade de utilizao (MySQL
BRASIL, 2008).
Suas principais caractersticas so abordadas a seguir (MySQL BRASIL, 2008):
Todas as consultas realizadas pelo MySQL so feitas utilizando-se a linguagem SQL
(Structured Query Language - Linguagem Estrutural de Consulta) definida pelo
padro ANSI/ISO SQL;
Possui grande portabilidade, desenvolvido em C e C++ composto por diversas APIs
(Application Programming Interface Interface de Programao de Aplicativos)
disponveis 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
no transacional, integridade referencial atravs de chaves primrias e estrangeiras,
realizao de consultas, atualizao de dados, insero, remoo, criao de ndices para
acelerar consultas. Conta ainda com um sistema de privilgios e senhas que podem ser
baseadas em estaes e mquinas;
Suporte a prepared statement, permite realizar consultas mais rapidamente de forma
otimizada, modificando-se apenas os parmetros. Isto ocorre devido existncia de trs
etapas durante a sua preparao: anlise, reestruturao e execuo. Utilizando-se esta
funcionalidade possvel que as etapas de anlise e reestruturao sejam executadas
uma nica vez e no sempre que a consulta executada;
Completo suporte e ampla biblioteca de operadores, funes para manipulao de
informaes e subconsultas, desenvolvida de forma otimizada para se obter grande
ganho em performance. Recursos para criaes de views (i.e., tabelas de visualizao de
informaes, baseadas em campos de uma ou mais tabelas), alm de permitir adicionar
funes de agrupamento (e.g., somatrio, mdia, mximo, mnimo); e
37
Suporte a programao diretamente no SGBD como stored procedures, funes, triggers
(i.e., gatilhos disparados automaticamente aps a ocorrncia de um evento (e.g., insero
de dados em uma tabela)).
2.1.3.4 Interface grfica e comunicao cliente servidor
Como atrativo da ferramenta WebCASE em relao a outros sistemas web, pode-se citar a
adoo do conceito RIA
5
. Termo utilizado pela primeira vez em 2001 pela Macromedia para definir
aplicaes web que seguem o estilo de aplicaes stand-alone
6
, com alto nvel de interao com o
usurio (MACROMEDIA, 2003).
Para tal, aplicaes RIA extrapolam o padro tradicional da Web, baseado em simples
formulrios HTML (Hyper Text Markup Language - Linguagem de Marcao de Hipertexto),
transferindo para o cliente boa parte da implementao lgica e deixando para o servidor apenas a
tarefa de conexo e manipulao de banco de dados, (MOOCK, 2007; WOOLSTON, 2006).
2.1.3.5 AJAX
Um dos maiores responsveis pelo aumento da popularidade de aplicaes web com
interfaces ricas foi, alm da evidente necessidade de diminuir a diferena entre aplicaes web e
aplicaes stand-alone, a popularizao do AJAX (Asynchronous JavaScript And XML - XML e
JavaScript Assncrono) (BUGHI, 2007).
O AJAX no pode ser considerado uma linguagem de programao, nem uma nova
tecnologia, a melhor maneira de definir AJAX, segundo Mahemoff (2006), a mistura de
tecnologias providas por navegadores, como JavaScript e XML, atravs de solicitaes assncronas
de informao. Conforme Perry (2006), as tecnologias necessrias para a utilizao do AJAX so:
JavaScript, linguagem de programao embutida em pginas web que permite a criao
de contedo dinmico interpretada pelo navegador no lado cliente;
Modelo de representao de XML em forma de objetos manipulveis por uma
linguagem atravs da utilizao do padro DOM;



5
Alguns autores adotam o termo Web 2.0 para definir aplicaes web com interfaces ricas (WOOLSTON, 2006)
6
Aplicaes denominadas auto-suficientes, que no dependem de softwares adicionais ou sistema operacional
especfico para serem executadas (TECHTERMS, 2008)
38
Recuperao de dados assncronos utilizando um objeto JavaScript denominado
XMLHttpRequest; e
Apresentao dos dados baseadas em padres utilizando XHTML (eXtensible Hyper
Text Markup Language - Linguagem de Marcao de Hipertexto Extensvel) 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 seqncia, o projeto Mozilla
implementou uma soluo compatvel com o ActiveX, porm funcionando de maneira nativa para o
navegador. Com o objetivo de padronizar a forma como os navegadores realizariam requisies
assncronas, o W3C incluiu o XMLHttpRequest na especificao DOM nvel 3 (MAHEMOFF,
2006).
Conforme apresentado na Figura 12, o funcionamento de uma aplicao que faz uso do
AJAX (e conseqentemente XMLHttpRequest) consiste em:
1. Requisio inicial pelo navegador;
2. A pgina completa obtida pelo servidor (incluindo o motor AJAX) e enviada para o
navegador;
3. Todas as requisies seguintes so realizadas atravs de chamadas de funes 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 necessrios ou
realiza operaes com os novos dados provenientes do servidor.
39


Umas das formas alternativas presentes para a comunicao por AJAX entre cliente e
servidor na ferramenta WebCASE a tecnologia JSON, que ao contrrio da forma usual onde as
informaes so transportadas como texto ou XML, elas so transmitidas e lidas como objetos
JavaScript.
2.1.3.6 Biblioteca ExtJS
Alm do AJAX e JSON, a ferramenta WebCASE faz uso de uma biblioteca desenvolvida
em JavaScript denominada ExtJS
7
. Voltada para a camada de apresentao, a biblioteca ExtJS
permite criar e adicionar diversos componentes semelhantes aos presentes em aplicaes stand-
alone (e.g., janelas, rvores, painis, formulrios, botes, arraste de elementos).



7
Disponvel em: http://www.extjs.com

Figura 12. Exemplo de comunicao utilizando AJAX
Adaptado de: GARRETT (2005)
40
Atualmente encontra-se na verso 2.1 e est presente na licena comercial ou sob as
condies da licena LGPL (Lesser General Public License Menor Licena Pblica Geral).
Na Figura 13 apresentada uma tabela (grid) com dados formatados e diversas
propriedades atribudas de maneira simples utilizando a biblioteca ExtJS. O cdigo utilizado para a
gerao desta tabela encontra-se disponvel na Figura 14 e apresentado na seqncia.

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 so passados como parmetro na forma de objeto JavaScript no construtor
do GridPanel.
A definio das colunas feita com um objeto do tipo Ext.grid.ColumnModel (linha 22),
para cada coluna deve-se informar seu ttulo (header), largura (width), se a mesma pode ser
ordenada (sortable), o tipo e formato dos dados que sero apresentados. Para este exemplo foi
utilizada uma estrutura auxiliar para armazenar o tipo de dado (i.e., monetrio, datas, textos) de
cada coluna da tabela (linhas 13 a 17).
Alguns atributos adicionais podem ser informados como forar a apresentao total dos
dados na tela (forceFit), ttulo (title), largura da tabela (width) e se a mesma ser renderizada dentro
de um iframe (renderTo).
41

Figura 14. Cdigo para a gerao de uma tabela utilizando a biblioteca ExtJS.
Adaptado de: VEDOVELLI (2007)
2.1.3.7 Formato de troca de documentos
Para permitir a integrao da ferramenta WebCASE com outras ferramentas CASE
existentes, foi adotado o padro XMI, desenvolvido pela OMG
8
(Object Management Group
Grupo de Gerenciamento de Objetos) com o objetivo de padronizar o transporte de componentes
entre aplicaes atravs do XML.



8
Organizao de padres reconhecida internacionalmente, a estrutura da OMG baseada em dois aspectos: (1)
Domnios que representam diversas reas tecnolgicas, como telecomunicao, comrcio eletrnico, simulao e
transporte; (2) e as plataformas que trabalham na especificao de tecnologias como a UML, MOF e XMI.
(BRODSKY, 1999)
42
Para Brodsky (1999) a diversidade de ferramentas disponveis para projetos de software de
extrema importncia, pois permite que novas metodologias sejam propostas para facilitar os
negcios. Uma das vantagens em se utilizar o XML se deve a facilidade existente para a
compreenso e leitura humana (RAMOS e STRECHT, [200-?]).
Conforme Ramos e Strecht ([200-?]), XMI um padro aberto baseado em XML proposto
para o intercmbio de informaes e representao de metamodelos entre aplicaes de modelagem
e desenvolvimento de software (e.g., verso, representao de modelos, relacionamento entre
elementos).
Alguns exemplos incluem: (i) ferramentas de desenvolvimento (e.g., C++, Java); (ii)
ferramentas de modelagem, design, orientao a objetos e UML (e.g., Enterprise Architect,
Rational Rose); e (iii) Bancos de Dados e Data Warehouses (e.g., Oracle 8i,Visual Warehouse),
alm de repositrios e geradores de relatrios e documentao (BRODSKY, 1999).
A recomendao da OMG para a utilizao do padro XMI, tem como objetivo permitir as
empresas participantes colaborar e disponibilizar um canal de comunicao, importao e
exportao de informaes entre as ferramentas (Figura 15).
Na situao atual da XMI, cada software deve saber a respeito das funes de outras
ferramentas, permitindo criar pontes para clientes que necessitam compartilhar informaes entre as
ferramentas.

Figura 15. Pontes entre diferentes ferramentas e empresas.
Fonte: Adaptado de Brodsky (1999).
43
2.1.4 Consideraes sobre a Ferramenta
Com o estudo realizado sobre a ferramenta WebCASE foi possvel avaliar a forma em que
se encontra sua modelagem e implementao, proporcionando uma melhor viso e identificao de
possveis limitaes que possam existir durante a alterao e adio das novas funcionalidades.
Algumas discrepncias relacionadas ao modelo ER e ao modelo de classes so apresentadas
e corrigidas no capitulo 3. Como o objetivo principal deste trabalho est relacionado adio de
novas funcionalidades, s ser feita a correo de falhas se ocorrerem problemas na nova verso.
2.2 Engenharia de Software
Engenharia de software a rea de cincia da computao que lida com a construo de
sistemas de software, sejam eles grandes ou complexos que precisam ser construdos por uma
equipe ou equipes de engenheiros. Normalmente, estes sistemas de softwares existem em vrias
verses, e so utilizados durante vrios anos (GHEZZI; JAZAYERI ; MANDRIOLI, 1991).
Desde a idia inicial at a entrega para o cliente, um software pode passar por mudanas
para corrigir defeitos, reforar 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 distribuio dos principais custos envolvidos para detectar e corrigir erros em
um projeto de software, onde a existncia de falhas tende a diminuir de acordo com os esforos
atribudos s etapas de pr-projeto, ou seja, quanto mais claro for o projeto, menores sero os custos
envolvidos na manuteno e maior ser a sua qualidade.
44
Requisitos
3%
Projeto
7% Codificao
10%
Testes da
Unidade
23%
Testes de
Aceitao
57%

Figura 16. Distribuio dos custos envolvidos em projetos de Software.
Fonte: Adaptado de Peters; Pedrycz (2001).
Atravs 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 gerncia de projeto:
O desenvolvimento de software na maioria dos casos no possui um planejamento inicial
das suas funcionalidades, tornando obscuro, possveis obstculos que somente seriam
encontrados aps o incio da execuo do projeto. Como conseqncias a remodelagem,
a perda de tempo e o aumento nos custos poderiam estar presentes, impedindo uma
avaliao das metodologias empregadas no desenvolvimento;
A insatisfao quase sempre uma das principais caractersticas resultantes ao final do
projeto, isto se deve a alguns fatores como a falta de comunicao entre os envolvidos e
o cliente, para definir o escopo do sistema; e
Como resultado de uma m especificao de software, o aumento no custo total, a falta
de segurana e a alta manuteno, acabam fazendo com que o projeto seja
descontinuado, causando prejuzos tanto para as empresas envolvidas no
desenvolvimento quanto para os clientes.
45
Mesmo no existindo um modelo ideal, necessrio realizar um estudo entre as diferentes
abordagens a fim de encontrar o mais adequado s necessidades de um projeto, onde cada processo
formado por tcnicas e ferramentas que visam facilitar sua compreenso e acelerar o processo de
documentao e anlise seguindo seus conceitos (PFLEEGER, 2004). Sommerville (2007) aponta
quatro atividades comuns entre os diversos processos de engenharia de software existentes:
A especificao de software ou engenharia de requisitos: Tendo descrito as aes do
software, necessrio definir os servios e restries para seu funcionamento, tornando
esta atividade uma etapa crtica, j que possibilita influenciar as etapas posteriores de
desenvolvimento;
O projeto e implementao: Desenvolvimento e codificao do software atendendo as
especificaes e requisitos;
Validao de software: Tanto durante o desenvolvimento quanto na finalizao do
projeto, o software deve ser testado a fim de garantir a qualidade do produto
desenvolvido; e
Evoluo de software: Permite que o software seja mutvel e adaptvel 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 caractersticas e restries do ponto de vista da satisfao das
necessidades do usurio, a fim de fornecer controle e suporte a uma tarefa especfica.
Filho (2001 apud QUIRINO, 2005), afirma que os critrios de aceitao de um produto
esto ligados aos requisitos funcionais do sistema, pois definem as diversas propriedades e funes
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 especificao mais
detalhada, aumentando a dificuldade do processo.
Atravs dos requisitos, toda funcionalidade comportamental e no comportamental pode ser
descrita e avaliada. Muitas das etapas e tcnicas envolvidas so abordadas pela engenharia de
requisitos, onde diversos paradigma e arquiteturas so 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 nvel
de abstrao de sua descrio, permite abranger diversos tipos de leitores e assim facilitar a
comunicao em grupo:
Requisitos de usurio: Utilizam linguagem mais clara e diagramas, exprimindo as
idias das funcionalidades, restries a serem desempenhadas e os servios que sero
executadas pelo software; e
Requisitos de sistema: So mais formais e possuem menor abstrao, descritos atravs
de uma linguagem mais precisa e com maior detalhamento. So utilizados
principalmente por engenheiros de software, arquitetos de sistema e desenvolvedores de
software.
Entre os principais desafios envolvidos no trabalho de determinar os requisitos, esto os de
encontrar, comunicar e documentar de forma clara, os aspectos necessrios s capacidades e
condies 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,
no-funcionais e regras de negcio (requisitos de domnio) (CYSNEIROS, 2008).
A distino entre um requisito funcional e um requisito no-funcional pode no ser simples,
onde um requisito funcional est relacionado a algum tipo de transformao a ser realizada
internamente no software, enquanto que um requisito no-funcional est relacionado como esta
transformao ir se comportar ou que qualidade dever possuir (EAGLE, 1995; CHUNG, 2000
apud CYSNEIROS 2008).
Qualquer que seja a classificao, os requisitos so formados por um conjunto de atributos
que definem suas caractersticas principais (e.g., prioridade, status, descrio) e demais informaes
que possam vir a ser necessrias (SANTOS; VARGAS; ABREU, 2004).


47
2.2.1.1 Requisitos Funcionais
Os requisitos funcionais (RF) descrevem atravs de uma linguagem clara e escrita s
funes que o sistema dever realizar, geralmente so especficos a cada software projetado
(SOMMERVILLE, 2007).
J para Pfleeger (2004) um requisito funcional responsvel por descrever a interao e
comportamento existente entre o sistema e o ambiente, levando em considerao a ocorrncia de
uma ao ou estmulo.
Quirino (2005) define um requisito funcional como uma descrio das atividades executadas
de acordo com as entradas e sadas executadas em resposta a uma ao externa ao sistema.
2.2.1.2 Requisitos No-funcionais
Ao contrrio dos requisitos funcionais os requisitos no-funcionais (RNF) esto
relacionados s propriedades de funcionamento (e.g. confiabilidade, tempo de resposta,
portabilidade, desempenho) e no as funes especficas do sistema. A importncia de um RNF
oposta de um RF onde muitas vezes existe uma maneira alternativa de se executar determinada
tarefa. J a omisso ou falha de um RNF pode comprometer o funcionamento e tornar o sistema
intil. (SOMMERVILLE, 2007).
Outros fatores relacionados aos requisitos no-funcionais so as necessidades de software,
hardware, linguagens de programao utilizadas, recursos financeiros e demais caractersticas que
no esto relacionadas s funcionalidades do software (ibidem).
Para Pfleeger (2004) um requisito no-funcional representa limitaes e restries que
possam existir e que possam interferir na soluo final do sistema. Entre os tipos de RNF propostos
por Sommerville (2007) esto:
Requisitos de produto: Ligados ao comportamento, geralmente so relacionados ao
desempenho, poder de processamento, confiabilidade, tolerncia falhas, portabilidade e
usabilidade;
Requisitos organizacionais: Relacionados s polticas impostas pela organizao do
cliente, alguns exemplos incluem linguagem de programao e sistema operacional; e
48
Requisitos externos: Requisitos voltados aos fatores externos do software, como a
interoperabilidade com softwares de outras organizaes e interfaces de comunicao.
Com a existncia de diversas categorias de RNF, Conallen (2003 apud Quirino, 2005),
classifica os requisitos no-funcionais em:
Usabilidade: Relacionados principalmente a interao software x usurio. Permite que
sejam definidos, como por exemplo, as telas do sistema que devem ser projetadas a fim
de facilitar sua utilizao;
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 crticos esta uma caracterstica essencial, define
restries quanto ao seu total funcionamento e tolerncia falhas, alm de definir
questes relacionadas recuperao de informaes;
Segurana: Definem aspectos necessrios proteo das informaes do software como
nveis e polticas internas da empresa para acesso aos dados;
Hardware: Apontam os requisitos e especificaes de hardware, necessrios ao
funcionamento do software; e
Implantao: Definem aspectos a serem verificados durante a instalao e treinamento
do sistema, a fim de garantir seu correto funcionamento.
2.2.1.3 Regras de Negcio
Para a execuo de tarefas por um software, necessrio que normas e restries sejam
definidas para atender corretamente a determinadas necessidades do negcio. Para Sommerville
(2007) as regras de negcio (RN), ou requisitos de domnio, so restries ou especificaes que
sero executados por uma tarefa e no como ela ser executada.
J para Ross (2003 apud BUGHI, 2007) as regras de negcio so como diretivas que
influenciam ou guiam o comportamento dos negcios em um sistema e so formalizadas atravs de
uma linguagem declarativa.
49
Apesar da importncia de definir corretamente as regras de negcio, sua compreenso pode
ser acompanhada de diversos conflitos originados dos processos envolvidos na gerncia de negcio
e de sistemas de informao de suporte, principalmente com as mudanas dos processos ao longo
dos anos (ALENQUER, 2002 apud QUIRINO, 2005).
Quirino (2005) aponta o processo de definio das regras de negcio como uma atividade
realizada por um analista de negcios e no pelos responsveis 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 responsvel
por definir os objetivos, escopo e descrio dos requisitos a engenharia de requisitos. Focada na
anlise e documentao 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 esto envolvidos na parte de anlise de requisitos:
Ambiente: formado por usurios do sistema, mquinas, servios e operaes de
software, possuem a importncia de especificar como e de que forma as tarefas sero
executadas;
Itens produzidos: descrevem as necessidades envolvidas no processamento, consumo e
produo do sistema;
Funes: descrevem as funes executadas por pessoas e mquinas, necessrias para
realizar um determinado servio; e
Modos de operao: mtodos utilizados, formas de produo e quando as operaes
acontecem.
Rezende (1999) apresenta a comunicao e a capacitao como fatores essenciais durante a
anlise de requisitos devido possibilidade de haver conflitos com exigncias 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 anlise de sistemas, Silva e Rocha (1998) apontam
a necessidade de realizar a interao entre os envolvidos, definindo o que e como determinada
50
tarefa dever ser realizada, avaliando suas origens e separando suas caractersticas, para permitir
que novas habilidades gerenciais sejam propostas e novos modelos de processos sejam definidos.
2.2.3 Processos da Engenharia de Requisitos
A criao e atualizao de um documento contendo a relao 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 definio de requisitos pode ser
dividido em quatro subprocessos (Figura 17) relacionados avaliao da utilidade e adequao para
a empresa: (i) estudo de viabilidade; (ii) anlise e elicitao de requisitos; (iii) especificao; e (iv)
validao do software.

Figura 17. Etapas presentes no processo de engenharia de requisitos.
Fonte: Adaptado de UNESP (2006).
Estas etapas esto inseridas em um processo evolutivo e contnuo ao longo do ciclo de vida
do software, j que na prtica as alteraes nos requisitos podem se tornar constantes, necessitando
gerenciar estas mudanas para obter ao final de cada etapa um artefato reunindo as informaes
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 atravs de resultados
obtidos em relatrios. Assim possvel verificar se sua elaborao capaz de atingir os objetivos
desejados ou se ser necessrio realizar alteraes de oramentos, escopo e prazos anteriormente
definidos (SOMMERVILLE, 2007).
Ainda como fontes de estudo, necessrio verificar se o sistema poder ser implementado
utilizando a tecnologia atual, dentro do oramento existente e se poder ser integrado a outros
sistemas j em operao (UNESP, 2006).
Para Sommerville (2007), a realizao de um estudo de viabilidade formada basicamente
por perguntas, coleta e avaliao de informaes, abordando quais seriam as contribuies
oferecidas soluo proposta, ou seja, se as respostas no forem satisfatrias, deve-se recomendar o
no prosseguimento do desenvolvimento, restando como concluso que o software no ir agregar
valores reais para a empresa.
Entre as pessoas envolvidas no estudo de viabilidade, podem ser citados, gerentes de
departamento, funcionrios, especialistas em tecnologia e demais pessoas familiarizadas com os
processos e regras de negcio.
Alguns questionamentos bsicos, segundo UNESP (2006), so:
Existem problemas nos processos utilizados atualmente? Qual o impacto causado se o
sistema no fosse implementado?
Como o sistema auxiliar as atividades do cotidiano?
Que tecnologias e habilidades sero necessrias implementao do sistema? Esto
dentro das restries definidas de custo e prazo?
2.2.3.2 Elicitao e anlise de requisitos
Como segunda etapa, os engenheiros de software e a equipe tcnica realizam reunies com
os clientes e stakeholders com a finalidade de descobrir maiores detalhes sobre o domnio da
aplicao, desempenho e hardware necessrios.
52
Os stakeholders, segundo Sommerville (2007), so todas as pessoas envolvidas que possuem
influncia direta ou indireta sobre os requisitos do sistema, com isto diversos problemas so
encontrados devido a vrias razes:
Normalmente os usurios e stakeholders possuem requisitos conflitantes e
freqentemente no sabem definir exatamente o que desejam que o sistema realize,
expressando as funcionalidades em termos gerais;
Utilizam linguagem natural e conhecimento implcito do trabalho que dificultam a
identificao dos requisitos, necessitando definir os pontos em comum e avaliar quem
so as potenciais fontes de requisitos; e
Como o ambiente econmico e negcios so dinmicos, os requisitos so modificados
naturalmente, alm de existirem fatores polticos que podem ser influenciados durante o
processo de anlise.
2.2.3.3 Especificao de Requisitos
Parte do processo responsvel por definir e traduzir as informaes coletadas durante o
levantamento de requisitos, que compreende e define os servios exigidos para fornecer uma base
estvel para o projeto do software (SOMMERVILLE, 2007). Esta etapa pode ser considerada uma
das mais crticas, j que a m especificao pode resultar em erros nos estgios posteriores.
Algumas tcnicas 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
obteno.
2.2.3.3.1 Levantamento baseado em ponto de vista
Atravs de entrevistas realizadas com diferentes stakeholders, possvel identificar as
perspectivas, classificando e descobrindo os conflitos entre as fontes de requisitos. Estas entrevistas
consistem na formulao 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 trs
grupos genricos:
53
Pontos de vista de iterao: Responsveis por representar todas as pessoas envolvidas
direta ou indiretamente com o sistema fornecendo detalhes a respeito das caractersticas
e interfaces;
Pontos de vista indiretos: Representam os stakeholders que no utilizam o sistema, mas
acabam por influenciar seus requisitos e restries organizacionais; e
Pontos de vista de domnio: Representam caractersticas e restries de domnio 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, alm de serem mecanismos centrais para a descoberta e
definio de outros requisitos do sistema. Sua finalidade expressar a maneira com que elementos
externos interagem com as funcionalidades disponveis no sistema.
Os diagramas de casos de uso so elementos textuais da UML, geralmente representados em
forma de diagramas, para permitir uma melhor visualizao e entendimento. Para Medeiros (2004)
um caso de uso uma atividade responsvel por representar a execuo de determinada tarefa em
um software atravs do relacionamento e interao 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 usurios. 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 usurios e o caso de uso UC 02.02, para gerenciar grupos de usurios. O UC 02.03 possui
a funcionalidade de manipular permisses para o grupo de usurios e est relacionado atravs de
uma extenso ao UC 02.02.
Para Booch, Rumbaugh e Jacobson (2006) um caso de uso define um comportamento
especfico esperado pelo sistema, sem levar em considerao as aes e aspectos necessrios a sua
implementao dentro do software.
Para Larman (2004), existe uma forte relao entre os requisitos funcionais e os casos de
uso. A principal diferena que os casos de uso descrevem de forma mais detalhada como uma
ao ser executada pelo software durante a implementao, sendo este um dos principais
mecanismos utilizados em diversos processos de software, para a descoberta e definio de
requisitos.
2.2.3.4 Documentao
Durante as fases da engenharia de requisitos, armazenar e organizar as informaes so
tarefas extremamente importantes, pois permite utiliz-las como documento oficial da especificao
do sistema para clientes, desenvolvedores e usurios (PETERS; PEDRYCZ, 2001).
Denominada de Especificao de Requisitos de Software (ERS) so escritas utilizando uma
linguagem natural variando o grau de detalhamento de acordo com o pblico alvo podendo incluir
diagramas, tabelas e demais artefatos para facilitar seu entendimento (SOARES; FARIA, 2008).
Segundo Peters e Pedrycz (2001), a ERS responsvel por descrever as propriedades,
restries e funes executadas dentro de um produto de software, geralmente so escritas durante
todo o processo de engenharia de requisitos.
Para Soares e Faria (2008) os seguintes tpicos so encontrados em um documento de ERS:
Viso geral do sistema, benefcios do desenvolvimento, glossrio com termos tcnicos;
Definio dos servios, requisitos, propriedades do sistema; e
55
Restries de operao, definio do ambiente em que o sistema ser executado e
integrao com outros sistemas.
Ao realizar a descrio dos requisitos devem ser observados os seguintes fatores (PETERS;
PEDRYCZ, 2001):
Funcionalidade: As tarefas que o software dever realizar, suas funes e estados;
Interface externa: Interao do software com o ambiente, pessoas, hardware e outros
software;
Desempenho: Velocidade, disponibilidade, tempo de resposta;
Atributos: Portabilidade, rastreabilidade, manutenibilidade, qualidade, estabilidade,
segurana; e
Restries: Padres de qualidade, linguagens de codificao, recursos, oramento,
ambiente.
2.2.3.4.1 Especificao de requisitos de software segundo IEEE 830-1998
Dentre as diversas abordagens e modelos disponveis para serem utilizados como modelo de
ERS, destaca-se a especificao proposta pelo IEEE (Institute of Electrical and Electronics
Engineers - Instituto dos Engenheiros Eltricos e Eletrnicos), responsvel por definir boas prticas
para a especificao de requisitos proveniente de resultados obtidos de diversos processos da
engenharia de software (PETERS; PEDRYCZ, 2001).
Esta subseo foi escrita baseada na recomendao proposta pelo IEEE, foram extrados do
documento as principais caractersticas que devem estar presentes na especificao de requisitos,
para servir como base na modelagem e desenvolvimento desta atividade na ferramenta WebCASE.
Considerando algumas das informaes necessrias que devem estar presentes no escopo da
ERS abaixo so detalhadas de maneira sucinta, explicando o porqu de sua utilizao (IEEE, 1998).
Caracterstica da ERS
Correta: Uma ERS est correta se, e somente se, todos os requisitos atendem as
necessidades do software, podendo ser avaliada pelos usurios se ela est correta e
reflete os objetivos (ibidem).
Sem ambigidade: Nenhum requisito deve possuir mais de uma interpretao e que no
mnimo cada requisito descrito utilizando um nico termo. Uma forma de representar
os requisitos atravs da utilizao de ferramentas para auxiliar sua descrio atravs de
uma linguagem prpria onde muitas vezes so utilizados diagramas para auxiliar este
processo (ibidem).
Completa: Uma especificao somente poder ser dita completa se todos os seus
requisitos significantes estiverem disponveis, at mesmo os relacionados performance,
funcionalidades e interfaces externas (ibidem).
Consistncia: Para que uma ERS seja considerada consistente necessrio que ela no
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 ocorrncia de aou b
podem acontecer simultaneamente (ibidem).
Classificao por importncia e estabilidade: Em uma ERS os requisitos devem
conter indicadores particulares de importncia e estabilidade. Como nem sempre os
requisitos possuem a mesma importncia, alguns podem ser especiais, essenciais ou
crticos, enquanto outros podem ser apenas desejveis, sendo esta diferena clara e
explcita. J na classificao por necessidade um requisito pode ser distinguido de trs
formas: (i) Essencial: definem implicaes que afetam diretamente o sistema e se no
cumpridos podem acarretar na sua no utilizao; (ii) Condicional: responsveis por
melhorar e adicionar caractersticas ao software, mas no faro que ele seja rejeitado; e
(iii) Opcional: caractersticas que podem no ter tanta importncia e servem para
aprimorar ou adicionar funcionalidades presentes na ERS (ibidem).
Estabilidade: A estabilidade pode ser expressa com base no nmero de modificaes
esperadas, na experincia e conhecimento de eventos que possam afetar a organizao
(e.g., funes, pessoas que possam interferir em um requisito) (ibidem).
57
Verificvel: Toda ERS deve ser verificvel, ou seja, se um requisito puder ser testado
com um custo efetivo atravs de uma pessoa ou mquina e no for ambguo, ento ele
estar cumprindo a especificao do produto. Alguns requisitos que no podem ser
verificados incluem funcionamento adequado, boa interface humana, deve ocorrer
usualmente j que teoricamente o teste de qualidade impossvel por existirem fatores
externos (e.g., configurao de software, hardware, rede) que podem afetar seu perfeito
funcionamento (ibidem).
Modificvel: Toda e qualquer modificao dever ser fcil, completa e consistente
mantendo a estrutura proposta. Para isto necessrio haver coerncia e uma maneira
fcil de organizar os requisitos (e.g., ndices, tabelas, cruzamentos explcitos), e assim
verificar que no existem requisitos redundantes e em conflito, garantindo a propriedade
modificvel a ERS. Vale lembrar que redundncias nem sempre so erros, mas podem
acarretar erros facilmente (ibidem).
Rastrevel: Para que uma ERS seja rastrevel, dever existir uma maneira clara e fcil
para referenciar cada requisito em futuras modificaes e aprimoramentos na
documentao. Basicamente existem duas formas de realizar um rastreamento, uma
atravs de referncias para os requisitos anteriores e outra atravs da atribuio de um
nome ou identificador nico para cada requisito (ibidem).
Preparao conjunta da ERS
Clientes e fornecedores nem sempre esto capacitados a escrever uma especificao de
software sozinhos, assim, necessrio trabalhar em conjunto para definir e concordar com as
funcionalidades propostas pelo software e permitir que uma documentao bem estruturada e
facilmente entendida seja criada (ibidem).
Evoluo da ERS
Como nem sempre possvel descobrir completamente os detalhes nas fases iniciais do
projeto, necessrio que a evoluo da ERS avance juntamente com o progresso do software,
documentando as modificaes e deficincias que possam surgir com os novos requisitos. Duas
consideraes importantes nesta etapa devem ser consideradas: (i) os requisitos devem ser
especificados completamente e na hora em que so descobertos, se por algum motivo estiverem
incompletos devem ser marcados para revises posteriores; e (ii) um processo de modificao
58
formal deve ser iniciado para identificar, controlar e reportar mudanas no projeto, as mudanas
aceitas devem ser incorporadas a ERS. (ibidem).
2.2.3.5 Validao de requisitos
Como etapa final do processo de engenharia de requisitos, a validao permite verificar se
os requisitos no possuem problemas e atendem as definies propostas pelo usurio. O custo de
correo dos requisitos pode ser muito inferior e diminuir o retrabalho se identificados nesta fase, j
que isto normalmente significa mudanas no projeto, na implementao e na realizao de novos
testes para avaliar os requisitos necessrios.
Algumas das verificaes que devem ser realizadas segundo SOMMERVILLE (2007)
incluem:
Validade: Avaliar se o sistema fornece as funes necessrias para desempenhar os
requisitos propostos pelos stakeholders, isto se torna necessrio devido existncia de
diversos pontos de vista.
Consistncia: Responsvel por verificar se os requisitos possuem conflitos ou esto em
contradio para a realizao de uma tarefa.
Completeza: Avaliar se os requisitos necessrios esto includos e definidos para a
realizao dos objetivos.
Realismo: Responsvel por verificar se os requisitos propostos esto de acordo com as
tecnologias existentes, oramentos e prazos propostos.
Facilidade de verificao: Com o objetivo de testar e validar o sistema necessrio que
os requisitos possam ser testados, verificando sua confiabilidade e demonstrando seu
real funcionamento.
2.2.4 Gerenciamento de requisitos
Atravs do gerenciamento possvel organizar, planejar, comunicar e concluir os requisitos,
obtendo um melhor controle, aperfeioamento e satisfao do cliente em projetos complexos
diminuindo custos que estariam envolvidos na correo dos requisitos (KRUCHTEN, 2003).
59
Utilizando um ciclo iterativo possvel que o software seja organizado por um conjunto de
mini projetos que representam funcionalidades presentes no mesmo. Normalmente possuem
durao fixa e objetivos definidos denominados de iteraes, cada qual formada por um conjunto de
atividades de anlise de requisitos, projeto e implementao, que permitem testar, integrar e
executar o mdulo aps sua concluso (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 documentao
(Figura 19).

Figura 19. Cobertura do gerenciamento de requisitos nas etapas da engenharia de requisitos.
Fonte: Martins (2001).
Em um projeto necessrio realizar um acompanhamento constante para permitir a
evoluo e refletir as necessidades da organizao, j que a compreenso dos problemas a serem
solucionados nem sempre fcil, tornando os requisitos incompletos (SOMMERVILLE, 2007). A
existncia de mudanas aps a implantao torna-se quase que inevitvel dentro da organizao
devido a basicamente dois fatores:
Em sistemas grandes geralmente os usurios acabam adquirindo mais experincia e
descobrindo novas necessidades com o passar do tempo, podendo causar conflitos e
contradies com os diferentes requisitos propostos; e
Nem sempre dentro das organizaes os responsveis por negociar o sistema so os
verdadeiros usurios devido a restries organizacionais e polticas presentes, o que de certa
forma acaba interferindo na definio do escopo, onde aps a instalao, novas mudanas e
regras de negcio so introduzidas para refletir as reais necessidades do negcio.
A utilizao de uma ferramenta de apoio, seja ela uma ferramenta CASE ou uma planilha,
torna-se necessria e essencial como fonte de gerenciamento, controle e consulta aos envolvidos no
60
projeto, onde para cada requisito armazenado sua identificao, descrio textual, data e origem
de obteno (MARTINS, 2001).
Para Cappelli e Santoro (2005) os seguintes benefcios so adquiridos ao realizar o
armazenamento e identificao dos requisitos:
Controle de alteraes para permitir avaliar as modificaes realizadas bem como os
responsveis pelas mesmas;
Facilidade na gerao de documentos de requisitos em forma de verso;
Facilidade no acesso e visualizao dos requisitos de forma nica e centralizada.
2.2.4.1 Mudanas
Alm de um processo de gerenciamento para realizar o acompanhamento dos requisitos,
necessrio estabelecer e planejar polticas em toda e qualquer mudanas para avaliar os impactos
causados pela evoluo do sistema de forma controlada (SOMMERVILLE, 2007).
Para Castro (2000), o gerenciamento de mudanas formado por um conjunto de polticas,
procedimentos e padres utilizados para controlar as mudanas de requisitos que ocorram dentro de
um sistema, com o objetivo de identificar problemas, validar e testar as mudanas para garantir a
qualidade.
Existem basicamente duas razes responsveis por interferir e modificar os requisitos: (i) Os
fatores externos correspondem a toda e qualquer caracterstica relacionada a mudanas no problema
a ser resolvido; e (ii) os fatores internos relacionados s questes de projeto no identificados nas
fases iniciais e na dificuldade de gerenciar os requisitos e suas mudanas (Cappelli; Santoro, 2005).
Para isto necessrio planejar minuciosamente a forma de gerenciamento das mudanas,
seguindo uma referncia das modificaes e estabelecendo um canal nico de controle.
2.2.4.2 Rastreabilidade
Durante o ciclo de vida de um projeto de software, necessrio manter o controle dos
impactos que podero ser ocasionados durante a ocorrncia de mudanas. Garantir o
relacionamento entre os casos de uso, requisitos e demais artefatos, permite que seja avaliado a
implementao proposta pelo sistema (FILHO, 2003).
61
A rastreabilidade definida como uma atividade responsvel por permitir rastrear a ligao
de um requisito a outros elementos do projeto, fornecendo informaes para acompanhar seu ciclo
de vida e assim avaliar possveis impactos que possam ser causados no projeto (KRUCHTEN,
2003).
Sommerville (2007) aponta trs tipos de informaes disponveis que podem ser utilizadas
atravs da rastreabilidade:
Informaes de rastreabilidade da origem: Permitem relacionar os requisitos aos
documentos e stakeholders, que na ocorrncia de mudanas, facilitam encontrar e
consultar sobre a mudana;
Informaes de rastreabilidade de requisitos: So responsveis por interligar um
requisito aos demais requisitos presentes na documentao. Isto permite avaliar quais
requisitos sero afetados diretamente na ocorrncia de uma mudana; e
Informaes de rastreabilidade de projeto: Permitem avaliar toda e qualquer parte da
implementao do projeto que possa ser afetada pela alterao do requisito.
Para facilitar a avaliao do relacionamento dos requisitos com os demais componentes do
projeto, a utilizao de matrizes de rastreabilidade permite uma melhor visualizao entre as
dependncias existentes. possvel identificar anormalidades quanto realizao 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 identificao de incompatibilidades gerada. (KOTONYA; SOMMERVILLE, 1997 apud
QUIRINO, 2005).
A matriz a ser utilizada relativa dependncia existente entre os elementos. Normalmente
as principais matrizes so 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) so as listas de relacionamento, formada por requisitos e dependncias, porm sua
utilizao no permite uma avaliao inversa dificultando a visualizao.
62
O gerenciamento e avaliao dos impactos causados por alteraes no projeto so divididos
em nveis, dependendo de quando e em que parte do projeto foram realizadas. Se a mudana ocorrer
durante a fase de especificao, deve ser avaliado como esta alterao afetar o restante dos
requisitos (SANTOS; VARGAS; ABREU, 2004). J para uma alterao durante a fase de
implementao deve-se avaliar tanto os impactos causados entre os requisitos, quanto no
funcionamento geral do sistema e por fim, caso uma modificao seja feita aps o sistema estar
concludo, alm das etapas de verificao de requisitos e sistema, deve ser feito uma avaliao
adicional para verificar como os stakeholders do negcio sero afetados.
Quando se trata de um nmero pequeno de requisitos (i.e., aproximadamente 250), as tabelas
ou matrizes de rastreabilidade podem ser utilizadas atravs de uma simples planilha, porm se
utilizadas sobre uma grande quantidade de informaes as tabelas acabam tornando-se
problemticas, pois impedem uma fcil leitura e compreenso (CASTRO, 2000).
Para permitir controle durante o rastreamento, necessrio definir polticas sobre como e
quais informaes estaro disponveis. A Figura 20 representa um exemplo do impacto que pode ser
causado por uma alterao nos requisitos. Est matriz de rastreabilidade realiza o cruzamento entre
RF x RF. A primeira coluna e a primeira linha so responsveis por relacionar e nomear cada
requisito com um identificador nico. Avaliando o requisito R1, possvel verificar a sua
dependncia com os requisitos R3 e R4. No caso de realizar uma alterao no requisito R4,
necessrio fazer uma avaliao nos impactos que sero gerados aos requisitos R1 e R3, pois na
coluna R4 e possvel visualizar a dependncia 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, necessrio definir uma seqncia
de passos necessrios para atingir determinado objetivo atravs de um processo. Na UML, esta
seqncia de passos representada por diagramas de atividades (LARMAN, 2004). Seu objetivo
fornecer uma metodologia para representar, visualizar, especificar e documentar aspectos dinmicos
envolvidos em uma operao, formados por etapas seqenciais ou concorrentes de um processo
computacional (BOOCH; RUMBAUGH; JACOBSON, 2006).
Basicamente, um diagrama de atividades formado por um incio, um conjunto de aes e
uma transio de sada (BASTOS, [200-?]). Da mesma forma que uma atividade pode ser
decomposta em diversas sub atividades, com o objetivo de aumentar o nvel de detalhamento a ser
alcanado BOOCH, RUMBAUGH e JACOBSON (2006) fazem a analogia de uma atividade a um
processamento no atmico dentro de uma mquina de estados, onde a cada atividade (i.e., estado),
esta expandida em um conjunto de aes formadas por entradas e sadas, definindo um
processamento atmico atravs da mudana de estado ou comunicao de mensagens (e.g.,
chamadas de funo, acesso a um banco de dados).
. Para Larman (2004), a utilizao dos diagramas de atividades oferece uma notao mais
clara sobre a execuo de tarefas, facilitando a visualizao de fluxos de trabalho e processos do
negcio (Figura 21), normalmente representados atravs 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 so mecanismos facilitadores para a descoberta de
requisitos, a utilizao dos diagramas de atividades pode fornecer uma notao mais elaborada e
detalhada do funcionamento de todas as atividades dinmicas envolvidas no processo de um
negcio (ibidem). J para Bastos ([200-?]) a associao entre um caso de uso e o diagrama de
atividades est relacionada descrio das tarefas executadas pelo ator com base no ponto de vista
da execuo do sistema.
Booch, Rumbaugh e Jacobson (2006) descrevem os componentes bsicos existentes em um
diagrama de atividades:
Ns: Representam uma unidade organizacional dentro de uma atividade ou um grupo de
atividades (Figura 22). Dependendo do nvel de detalhamento desejado, ser necessrio
decompor em atividades mais especficas at atingir o seu limite (i.e., aes).
Normalmente a escolha da diviso pode ser feita com base no tempo e espao necessrio
para sua execuo, principalmente em sistemas complexos;
65
Aes: Processamento de uma parte atmica resultante da execuo de uma tarefa (e.g.,
chamadas de operaes, envio de sinais, criao de objetos, avaliao de expresses)
(Figura 22) (BASTOS, [200-?]);

Figura 22. Representao de uma atividade ou ao.
Estado inicial e final: So responsveis por determinar o incio 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. Representao de um estado inicial (esquerda) e um estado final (direita).
Fluxos/transio: Responsvel por representar a passagem do controle para a prxima
atividade atravs do fluxo executado (Figura 24). A passagem de uma ao para outra
feita atravs de uma seta direcional, informando o sentido da atividade sucessora de um
evento;

Figura 24. Representao de uma transio por uma seta.
66
Ramificao ou desvio: permite definir a execuo de uma tarefa com base na deciso
de uma expresso booleana (i.e., verdadeiro ou falso), desta forma um fluxo alternativo
pode ser utilizado, j que nem sempre uma transio segue seqencialmente (Figura 25);
e

Figura 25. Elemento de deciso com dois fluxos (sim/no).
Bifurcao (fork) ou paralelismo: divide o fluxo do controle em um ou mais fluxos,
dependendo do sistema podem representar a execuo concorrente e sincronizada
(BASTOS, [200-?]). J para permitir que diversos fluxos sigam um nico caminho, a
unio responsvel por agrupar os fluxos concorrentes de forma sincronizada em um
fluxo nico ( Figura 26).

Figura 26. Bifurcao em um diagrama de atividades.
Alm dos componentes bsicos de um diagrama de atividade, um recurso existente nos
pacotes da UML so os particionamentos de atividades, utilizados para dividir as atividades levando
em conta um grupo ou responsvel pela sua execuo e identificar as aes que possuem
caractersticas em comum (OMG, 2007; BASTOS, [200-?]). Existem basicamente trs formas de
representar os particionamentos de atividades, utilizando uma notao hierrquica, multi-
dimensional ou na forma de raias (swimlanes). No exemplo da figura 27 apresentada a diviso das
67
atividades de acordo com o tipo de usurio (i.e., administrador, analista, cliente) utilizando a
notao de raias.

Figura 27. Particionamento separando as atividades de acordo com o tipo de usurio.
2.4 Anlise de ferramentas similares
A utilizao 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 padres existentes, cabe aos responsveis escolher a
ferramenta que melhor se adapte as necessidades e aos principais processos utilizados para a
informatizao.
Kroth (2006) aponta os objetivos e caractersticas das ferramentas CASE, como: (i) o
aumento na produtividade; (ii) a automao e aumento da interao com os usurios na definio do
sistema; (iii) a liberao e aceitao dos requisitos para a aprovao; e (iv) facilitadores de uso,
principalmente com a construo de diagramas para visualizar e detectar os processos, permitindo
flexibilidade de apresentao e documentao do escopo do projeto.
68
Na elaborao 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 padres da UML.

Figura 28. Especificao de requisitos no Enterprise Architect 6.5.
Esta ferramenta permite a construo de diagramas e modelos de forma completa como:
diagramas de caso de uso, especificao de requisitos ( Figura 28), diagramas de classe, diagramas
de atividade ( Figura 29) alm de conter um mdulo responsvel 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 colaborao, permite a criao de rplicas do projeto, dividindo tarefas
entre analistas e desenvolvedores para mais tarde agrupar as informaes. Segundo Rech (2007),
possvel ainda realizar o compartilhamento de informaes em nvel de autenticao, bloqueio de
acesso a usurios e a conexo aos principais SGBDs disponveis 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 concluso de curso para Bacharel em Sistemas de Informao da
faculdade de Viosa-MG por Clayton Vieira Fraga Filho em 2005. A ferramenta CONTROLA (
Figura 30), foi desenvolvida com o objetivo de auxiliar na elaborao de diversas atividades
referentes engenharia de software em pequenas empresas, que geralmente no se utilizam de
70
processos especficos na elaborao de projetos e esto 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 responsveis e clientes, alm de oferecer controle de verso para manter documentadas as
alteraes realizadas.
Atravs da construo de matrizes de rastreabilidade (Figura 31), possvel construir
relacionamentos entre alguns dos artefatos fornecidos pela ferramenta (e.g., casos de uso, requisitos,
casos de testes, implementaes).
71

Figura 31. Matriz de rastreabilidade criada pela ferramenta CONTROLA.
Fonte: FRAGA FILHO (2005).
Algumas caractersticas interessantes esto presentes nesta ferramenta. Uma delas a
presena do mtodo de priorizao de requisitos baseados em valor, custo e risco proposto por Karl
Wiegers (2003 apud FRAGA FILHO, 2005).
Este mtodo baseado na atribuio de valores com base nos benefcios obtidos quando um
requisito adicionado ao sistema ou por uma penalidade no caso de sua ausncia, resultando em
uma prioridade de desenvolvimento, onde a importncia calculada proporcional ao valor agregado
e inversamente proporcional ao custo e risco de implementao (FRAGA FILHO, 2005).
2.4.3 ArgoUML
A ferramenta ArgoUML uma ferramenta CASE open-source desenvolvida em Java para a
modelagem de diagramas seguindo padres presentes na UML. Entre os padres utilizados podem
se citar a utilizao da especificao 1.4 da XMI, SVG (Scalable Vectorial Graphics) e OCL
(Object Constraint Language) (PICHILIANI; HIRATA, 2006).
72
Entre as principais caractersticas encontram-se gerao automtica de cdigo a partir do
modelo de classes, o auxlio engenharia reversa e a realizao de crticas dos modelos gerados
(ibidem).
Apesar desta ferramenta no ser originalmente colaborativa, uma adaptao realizada por
Pichiliani e Hirata (2006), possibilitou adicionar funcionalidades voltadas colaborao atravs da
internet (Figura 32). Nesta verso os usurios podem compartilhar um espao de trabalho, visualizar
e gerenciar as modificaes que ocorrem em tempo real. Um sistema de bate papo responsvel por
melhorar a comunicao entre os participantes. Travas e indicadores visuais apontam as aes
sendo executadas dentro de um projeto.

Figura 32. Ferramenta Colaborativa ArgoUML.
Fonte: PICHILIANI E HIRATA (2006).
2.4.4 SPRES Ferramenta Case para Especificao de Requisitos.
Desenvolvida como trabalho de concluso do curso de Cincia da Computao em 2005
pelo acadmico Jlio Cezar Chrystpher Quirino, esta ferramenta projetada em C++, rodando como
73
um aplicativo desktop na plataforma Windows permite auxiliar nos processos de especificao de
requisitos de software (ERS) (Figura 33).

Figura 33. ERS modelada na Ferramenta SPRES.
Fonte: QUIRINO (2005)
Entre as funcionalidades presentes nesta ferramenta esto especificao de requisitos de
software seguindo o padro IEEE 830-1998 proposto por IEEE(1998), o gerenciamento atravs da
rastreabilidade dos requisitos e a gerao 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 informaes possam ser utilizadas por
qualquer outro software. O sistema conta tambm com o cadastro de projetos, a criao de novos
atributos para os requisitos e registro de verses da documentao ERS.

74
2.4.5 Anlise comparativa entre as ferramentas

O Quadro 1 apresenta uma comparao das funcionalidades existentes em algumas das
ferramentas similares disponveis no mercado em comparao com a ferramenta WebCASE na
verso atual e em sua nova proposta.
Quadro 1. Comparao da ferramenta WebCASE com ferramentas similares.
Descrio WebCASE
1.0
WebCASE
2.0
CONTROLA Enterprise
Architect
SPRES ArgoUML
Modelagem
colaborativa
X X X X
Exportao XMI X X
Importao XMI X X X X
Modelagem Casos
de Uso
X X X X
Controle de verso X X X X
Ferramenta web X X
Participao do
cliente
X X
Modelagem
Diagrama de
Atividades
X X X
Especificao de
requisitos
X X X X
Matriz de
Rastreabilidade
X X X X
Gerao ERS X X
Chat na ferramenta X X X


A partir da comparao entre as ferramentas, possvel avaliar que somente a WebCASE
possui o requisito de ser uma ferramenta executada diretamente por um navegador Web, alm de
contar com a participao do cliente diretamente na aprovao de casos de uso e requisitos de um
projeto.
O suporte aos arquivos XMI, apesar de ser um padro internacional para troca de
informaes da UML, no estava presente em algumas ferramentas de modelagem avaliadas,
limitando a possibilidade de migrar as informaes entre as ferramentas.
Um dos aspectos observado nas ferramentas pesquisadas, mas que no se encontra na
ferramenta WebCASE o controle de verso, para manter um histrico de evoluo do projeto e a
75
possibilidade de gerao da ERS conforme observado nas ferramentas Enterprise Architect e
SPRES.
Pode-se observar ainda que as funcionalidades propostas para a ferramenta WebCASE
permitiro uma evoluo na documentao de aspectos importantes dos principais processos de
engenharia de requisitos, permitindo gerenciar, avaliar e detectar possveis falhas nas fases iniciais
dos processos de engenharia de software.
76
3 PROJETO
Este captulo apresenta a metodologia empregada no desenvolvimento deste trabalho no que
se refere modelagem lgica do sistema, adotando os conceitos e paradigmas da engenharia de
software.
3.1 Modelagem de negcio e funcionalidades
A etapa de Modelagem de Negcio tem o objetivo de confeccionar um documento para
mapear as tarefas e atividades atendidas por um sistema, provendo uma melhor compreenso do
negcio e facilitando a visualizao dos relacionamentos. Uma tarefa corresponde ao resultado final
que se deseja alcanar com a utilizao de um sistema (i.e., o que deve ser feito), e as atividades
apresentam os meios necessrios para sua realizao (i.e., como deve ser feito) (SCACH, 2005 apud
BUGHI 2007).
No Apndice A, denominado Documento de Modelagem do Sistema, so apresentados os
artefatos gerados durante a modelagem de negcio. Porm, as principais tarefas e atividades
levantadas pela anlise so dispostas neste captulo.
A modelagem foi desenvolvida segundo a notao UML, com artefatos que possibilitam
avaliar diversos aspectos do projeto e definir a estrutura necessria para a implementao do
sistema.
3.1.1 Requisitos
As subsees seguintes apresentam de forma sucinta somente os novos requisitos levantados
para a construo da Ferramenta WebCASE, os requisitos definidos na verso 1.0 da ferramenta so
apresentados no Apndice A.
3.1.1.1 Requisitos Funcionais
Os requisitos funcionais elencados so:
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
negcio;
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 instncia XMI gerada pelo
Enterprise Architect 6.5;
RF 07. Permitir ao analista importar um diagrama de atividades de uma instncia XMI
gerada pelo Enterprise Architect 6.5; e
RF 08. Permitir ao analista criar pacote de requisitos/regras de negcio.
3.1.1.2 Requisitos No-Funcionais
Os requisitos no-funcionais identificados so:
RNF 01. A integrao das novas funcionalidades no dever interferir no
funcionamento das funes j presentes na ferramenta;
RNF 02. As tecnologias utilizadas no desenvolvimento da ferramenta WebCASE sero
mantidas, sendo elas o PHP 5.0, JavaScript;
RNF 03. O banco de dados ser mantido, sendo este o MySQL verso 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 importao de requisitos e diagramas de atividades deve ser feito para o
padro XMI verso 2.1 do Enterprise Architect verso 6.5;
RNF 06. As informaes de um relacionamento na matriz de rastreabilidade devem ser
exibidas ao posicionar o mouse sobre as clulas da matriz; e
78
RNF 07. Os particionamentos de atividades devem conter um atributo de cor para
melhor distino.
RNF 08. O sistema deve ser compatvel 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 atravs de login e senha; e
RNF 12. O sistema dever ser compatvel com a verso 2.1 da XMI gerada pelo
Enterprise Architect 6.5.
3.1.1.3 Regras de Negcio
As novas regras de negcios identificadas para a verso 2.0 da ferramenta so:
RN 01. Um requisito dever ser do tipo funcional, no funcional ou regra de negcio;
RN 02. Uma matriz de rastreabilidade deve realizar o rastreamento entre Requisitos
Funcionais, Regras de Negcio e Casos de Uso;
RN 03. O administrador ser responsvel por cadastrar as categorias de requisitos e
regras de negcio que estaro disponveis para todos os projetos;
RN 04. Um caso de uso poder ser relacionado com requisitos funcionais, casos de uso
e regras de negcio;
RN 05. Um diagrama de atividades poder conter os seguintes elementos: n inicial, n
final, atividades, aes, desvio e bifurcao (fork);
RN 06. Um diagrama de atividades deve conter apenas um n inicial e possibilitar
vrios ns finais;
RN 07. Um elemento do diagrama de atividades poder se relacionar a mais de um
elemento, com exceo 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 negcio dever estar relacionado a uma categoria.
RN 15. Um elemento do diagrama de atividades no pode se relacionar com ele
mesmo;
RN 16. Um elemento n inicial do diagrama de atividades no poder receber ligao
de outros elementos;
RN 17. Um elemento n final do diagrama de atividades no poder realizar ligao
com outros elementos, somente receber;
RN 18. Todos os elementos de um diagrama de atividades sero associados pela
ligao "controle de fluxo" possuindo informaes de condio de guarda e mensagem
de transio; e
RN 19. Um diagrama pode conter particionamentos de atividades.
3.1.2 Casos de uso
Os casos de uso contemplados pela ferramenta WebCASE esto descritos, detalhadamente,
no Apndice A. Este captulo apresenta resumidamente os casos de uso da verso 1.0 que sofreram
modificao e os casos de uso relacionados as novas funcionalidades.


80
3.1.2.1 Casos de uso alterados
Mdulo analista
Importar diagrama de instncia XMI: Este caso de uso foi modificado para permitir a
importao de requisitos e diagramas de atividades juntamente com os casos de uso
atravs de arquivos XMI (verso 2.1) gerados pela ferramenta Enterprise Architect
verso 6.5; e
Detalhar caso de uso: Adicionada funo para permitir relacionar os casos de uso aos
requisitos cadastrados no mesmo projeto.
3.1.2.2 Novos casos de uso
Mdulo administrador
Manter tipos de requisitos: Como existem diversos tipos de requisitos no-funcionais
relacionados a funes e caractersticas especficas, este caso de uso responsvel por
manter os tipos de requisitos no-funcionais no sistema.(e.g., hardware, software,
usabilidade, performance, implementao, segurana). Permite tambm categorizar os
requisitos funcionais e regras de negcio de acordo com as necessidades.
Mdulo analista
Manter requisito: Permite ao analista cadastrar, editar e excluir um requisito atravs de
um formulrio;
Desenhar diagrama de atividades: Permite ao analista manter um diagrama de
atividades dentro de um pacote adicionando os elementos disponveis;
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
Mdulo cliente
Aprovar requisito: Permite a um cliente aprovar ou reprovar um requisito criado por
um analista, com a possibilidade de adicionar um comentrio informando o motivo da
escolha.
3.1.3 Diagrama de classes
No modelo de classes apresentado pela Figura 34, trs novas classes foram adicionadas para
contemplar as novas funes da ferramenta:
wcTraceabilityMatrix: Classe responsvel por representar uma matriz de
rastreabilidade existindo uma origem e destino para realizar a relao entre os
elementos;
wcRequirement: Classe responsvel por representar um requisito modelado juntamente
com seu identificador, prioridade, estabilidade, dificuldade e status; e
wcRequirementCategory: Classe responsvel por representar uma categoria de
requisito ou regra de negcio.
Com a presena de elementos no visuais (requisitos) ao projeto, foi realizada uma alterao
na estrutura das classes para diferenciar os elementos visuais dos no-visuais, atravs da classe
wcVisualElement.
A classe wcLink foi modificada e agora possui dois novos atributos: (i) guard, para
informar a condio de guarda do relacionamento; e (ii) weight para informar a mensagem de
transio. A classe wcAdministrador foi alterada conforme a implementao 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), responsveis 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 wcActivityNode wcDecisionNode wcForkNode
wcPartition
- color: stri ng
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
-user
0..* 0..*
1 -pakages
0..*
1
-package
0..*

Figura 34. Modelo de classes modificado da ferramenta WebCASE.
3.1.4 Diagrama Entidade-Relacionamento
Aps a definio das classes de domnio utilizadas pela ferramenta WebCASE, foi construdo o
diagrama de Entidade-Relacionamento, apresentando a estrutura do banco de dados relacionado s
classes de domnio descritas.
Vale ressaltar que o modelo foi adaptado e corrigido conforme apresentado na Figura 34, com a
incluso de informaes ausentes em entidades j existentes do modelo original e a adio de novas
entidades necessrias para satisfazer os novos requisitos deste projeto.
As seguintes novas entidades foram adicionadas:
wc_requirement: Entidade responsvel por armazenar informaes especficas de um
requisito (e.g., identificador, prioridade, estabilidade, dificuldade);
wc_historical_requirement: Entidade responsvel por armazenar as informaes de um
requisito, permitindo manter histrico durante a ocorrncia de aprovao ou reprovao pelo
cliente;
wc_requirement_category: Entidade responsvel por armazenar as categorias de requisitos
cadastradas pelo administrador no sistema contendo nome, abreviao e o tipo de elemento
(requisito funcional, requisito no-funcional, regra de negcio); e
wc_traceability_matrix: Responsvel por representar o relacionamento dos elementos em
uma matriz de rastreabilidade.
As nicas modificaes realizadas no modelo ER foram nas seguintes entidades:
wc_link: adicionando informaes de relacionamento utilizado no diagrama de atividades e
dois atributos responsveis por representar a condio de guarda e mensagem de transio
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 possveis operaes realizadas por cada tipo
de usurio, com destaque para as atividades em verde que indicam as alteraes propostas para a nova
verso da ferramenta.




Figura 36. Diagrama de atividades com as novas funcionalidades integradas.
4 IMPLEMENTAO
Neste captulo so apresentados os resultados obtidos durante a fase de implementao e
integrao com os mdulos j existentes da ferramenta WebCASE, abordando as novas bibliotecas
encontradas, capazes de acelerar o desenvolvimento e melhorar a usabilidade do sistema, visto que
as aplicaes RIA para a Web 2.0 encontram-se em constante evoluo.
4.1 Banco de dados
No decorrer da elaborao dos novos mdulos observou-se a necessidade de adaptar o
modelo ER anteriormente proposto, visto que algumas informaes estariam melhor dispostas em
novas entidades, estas modificaes encontram-se inseridas na seo 3.1.4.
Ao verificar a estrutura utilizada no banco de dados, observou-se o uso da codificao ISO-
8859-1
9
. Como as requisies HTTP realizadas atravs do objeto XMLHttpRequest so
necessariamente feitas em UTF-8, optou-se por alterar o banco de dados e a aplicao para o padro
UTF-8, reduzindo consideravelmente o nmero de converses necessrias durante o processamento
das requisies.
4.2 Draw2d
Aps analisar a implementao do diagrama de casos de uso na ferramenta WebCASE,
foram pesquisadas atualizaes e bibliotecas capazes de simplificar o processo de elaborao dos
novos diagramas, com o objetivo de adicionar novas caractersticas e aumentar a liberdade de
manipulao dos elementos por parte do usurio.
A biblioteca Draw2d desenvolvida por Herz (2008) disponibilizada sob licena LGPL,
permite elaborar diagramas para as mais diversas finalidades. Baseada na JavaScript Vector
Graphics Library, a mesma utilizada na elaborao 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.



9
Padro desenvolvido pela ISO responsvel por representar a codificao de caracteres do alfabeto latino, conhecido
tambm como Latin-1.
88
Como exemplos de ferramentas disponveis empregando a biblioteca Draw2d, esto 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 utilizao desta biblioteca,
justifica-se pela simples e rpida integrao em ambientes desenvolvidos com a biblioteca ExtJS e a
capacidade de inserir funcionalidades complexas sobre elementos visuais de forma rpida e simples.
4.3 ExtJS
Antes de iniciar o desenvolvimento dos mdulos propostos, foi realizado um estudo sobre a
biblioteca ExtJS a fim de avaliar a possibilidade de migrao da verso adotada na ferramenta para
a ltima verso disponvel (verso 2.2). Entre as principais evolues encontradas nesta verso,
podem-se citar a existncia de novos componentes, a realizao de melhorias na estrutura da
biblioteca, permitindo uma maior rapidez (de desenvolvimento e de performance) e ainda correes
de falhas existentes nas verses anteriores. Porm, as melhorias realizadas na estrutura da biblioteca
inviabilizaram o seu uso, pois implicaram em alteraes na forma de codificar os componentes, o
que, por sua vez, consumiria grande parte do tempo disponvel para o desenvolvimento deste
projeto.
4.4 Layout
Para iniciar as alteraes da ferramenta, foram modificados alguns elementos bsicos da
interface, com o objetivo de melhorar a usabilidade da ferramenta, compreender o funcionamento e
a forma de operao da biblioteca ExtJS.
Como exemplo mais notvel destas alteraes, pode-se citar o menu principal (Figura 37),
atualizado atravs do plugin Accordion Panel (Sakalos, 2008), que alm de manter o padro de
interface da ferramenta permite: (i) realizar pesquisas entre as opes digitando no campo
Pesquisar qualquer parte do texto que indique a ao desejada; e (ii) expandir e retrair os painis
existentes atravs dos botes superiores do menu.
89

Figura 37. Novo menu da WebCASE em comparao com o menu da
verso anterior.


90
5 APRESENTAO DA FERRAMENTA
As modificaes e os novos mdulos desenvolvidos so descritos e elencados juntamente
com os requisitos e regras de negcio a que se referem, para demonstrar a realizao das atividades
previstas na etapa de projeto.
A seo 5.1 apresenta os resultados obtidos da elaborao do mdulo para modelagem dos
diagramas de atividades. Na seo 5.2 descrito o cadastro dos tipos de requisitos utilizado tanto no
cadastro de requisitos para identificao e atribuio dos identificadores, quanto nas matrizes de
rastreabilidade. Na seo 5.3 apresentado o mdulo para especificao de requisitos e regras de
negcio. A seo 5.4 descreve o mdulo para aprovao de requisitos na perspectiva do cliente, a
seo 5.5 descreve as matrizes de rastreabilidade responsveis pelo gerenciamento dos requisitos e
por fim na seo 5.6 so apresentadas as modificaes dos mdulos j presentes na primeira verso
da WebCASE.
5.1 Mdulo diagrama de atividades
Para a implementao do mdulo de diagrama de atividades, foi utilizada a biblioteca
Draw2d (seo 4.2), formada por diversos elementos visuais e funcionalidades que proporcionam
maior usabilidade para o usurio.
A incluso de um novo diagrama feita atravs da criao de um pacote de diagrama de
atividades (RF 04, RN 08), quanto realizao do relacionamento entre os elementos do diagrama
(RN 07), utilizaram-se trs algoritmos de representao fornecidos pelo Draw2d, curva normal,
bezier e manhatten, facilitando a disposio e representao das conexes entre os elementos,
conforme apresentado na Figura 38.
91

Figura 38. Diferentes formas de representao de relacionamento no diagrama de atividades.
O diagrama de atividades conta ainda com a opo de alinhar e movimentar os elementos de
acordo com a matriz de linhas apresentada ao fundo do diagrama, bastando para isso selecionar a
opo alinhar a grade (Figura 39) atravs do menu exibido pelo boto esquerdo do mouse.

Figura 39. Menu popup com opes para facilitar a manipulao dos elementos
A adio de elementos ao diagrama realizada atravs de aes de arrastar e soltar (dragn
drop), tornando o seu uso similar a outras ferramentas para elaborao de diagramas. Mesmo no
tendo sido previsto durante a etapa de modelagem, dois novos elementos foram adicionados este
diagrama (RN 05), bifurcao e unio (descritos na seo 2.3). Optou-se por incluir estes elementos
dada sua importncia durante a criao de diagramas de atividades e a facilidade de implementao
obtida pela biblioteca Draw2d, que no 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 Atividade
10
),
que permite organizar as atividades de maneira lgica, sem afetar o fluxo das atividades (RN 19). A
criao destas reas no diagrama feita da mesma forma que a adio dos elementos, bastando
arrastar e soltar sobre o diagrama, permitindo inserir uma descrio e personalizar a cor de fundo
para facilitar a separao de responsabilidades (Figura 40).

Figura 40. Separao de responsabilidades atravs do particionamento de atividades.
O relacionamento entre dois elementos realizado atravs dos conectores representados por
pequenos crculos (i.e., portas de conexo), arrastando a porta de origem at a porta de destino
(Figura 41).



10
Traduo 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 condies de
guarda e mensagem de transio para o prximo elemento, estas informaes 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 exceo do n inicial que no pode receber
ligaes de outros elementos (RN 16) e s pode existir um elemento no diagrama (RN 06), e o n
final que somente recebe ligaes de outros elementos (RN 17), porm pode existir em mais
quantidade (RN 06).
94

Figura 42. Cadastro de informaes de relacionamento do diagrama de atividades.
Para editar um elemento do diagrama basta executar um duplo clique ou selecionar o boto
existente ao lado do elemento. A tela exibida apresentada na Figura 43 e permite informar a
descrio e observao do elemento juntamente com histrico de alteraes realizadas. Os
histricos esto relacionados alterao de informaes e no a cada movimentao feita sobre o
diagrama reduzindo a presena de informaes desnecessrias.
95

Figura 43. Tela para edio de elemento do diagrama de atividades.
5.2 Especificao de Requisitos e Regras de Negcio
Seguindo o conceito utilizado para visualizao dos elementos, os requisitos e regras de
negcio de um projeto so armazenados em pacotes (RF 01, RN 10), que permitem agrupar e exibir
as informaes em forma de listagem. Estes pacotes contam com a opo de exibir dados de forma
sumarizada ou completa alm de conter diversas opes de filtros (e.g., por nome ou atributos),
facilitando a busca de informaes em diferentes nveis de detalhamento (Figura 44).

Figura 44. Diversas opes 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 aps realizar uma insero ou alterao verificada a
96
unicidade do identificador dentro do projeto. A Figura 45 apresenta o formulrio utilizado para
cadastrar os requisitos.

Figura 45. Tela de cadastro de requisito.
Tratando-se da colaborao de usurios, foi utilizado o mesmo conceito para edio dos
casos de uso j presente na verso 1.0 da ferramenta, atravs de um bloqueio para o solicitante com
tempo limite de 5 minutos ou at as alteraes serem salvas, liberando novamente para outro
usurio realizar novas modificaes.
possvel manter as categorias de requisitos (Figura 46) de forma organizada e centralizada
para todos os projetos atravs do cadastro de tipos de requisitos (RN 14), realizado pelo
administrador do sistema (RF 02, RN 03). Segundo a definio proposta inicialmente, somente os
requisitos no-funcionais estariam relacionados a uma categoria, para no limitar o escopo optou-se
por manter as categorias (RN 01) entre os requisitos funcionais, requisitos no-funcionais e regras
de negcio, assim todos os identificadores podem ser adaptados conforme a necessidade.
97

Figura 46. Cadastro de categorias de requisitos.
5.2.1 Aprovao de Requisitos
Aps realizar o cadastro de um requisito, o analista deve liber-lo para aprovao por parte
do cliente (RF 05). O conceito utilizado o mesmo existente para a aprovao de casos de uso,
onde o cliente acessa o sistema atravs de um mdulo especfico e realiza a aprovao/reprovao,
podendo ainda inserir um comentrio a respeito de sua escolha (Figura 47).

Figura 47. Tela para aprovao/reprovao de requisitos pelo cliente.
98
O histrico das informaes permanece salvo at o momento da aprovao do cliente, onde
um novo histrico gerado caso existam alteraes posteriores a sua escolha. Neste histrico so
armazenadas a descrio, observao, informaes adicionais e comentrios do cliente sobre o
requisito, juntamente com a data e o responsvel pela alterao.
5.3 Matriz de Rastreabilidade
Atravs das matrizes de rastreabilidade possvel realizar o relacionamento entre requisitos
funcionais, regras de negcio e casos de uso de forma bidirecional (RF 03, RN 02, RN 09, RN 12).
Na modelagem proposta estes relacionamentos estavam restritos a trs formas (RF x UC, RF x RN,
RF x RF), porm optou-se por permitir relacion-los entre si (RF, RN, UC), possibilitando verific-
las em diferentes vises.
Outro fator analisado durante a elaborao das matrizes de rastreabilidade foi quanto
visualizao do relacionamento entre dois elementos. Como exemplo, na ferramenta Enterprise
Architect a descrio presente nos elementos verticais estava limitada a um tamanho especfico,
dificultando a ampliao e visualizao das informaes (Figura 49).

Figura 48. Comparaco 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
informaes de relacionamento em cada clula da matriz, fornecendo uma melhor usabilidade e
facilidade na utilizao (Figura 49).

Figura 49. Visualizao entre relacionamentos na matriz de rastreabilidade.
5.4 Alteraes realizadas na verso 1.0
Nesta seo so apresentadas as modificaes realizadas para integrar e adaptar os mdulos
da ferramenta WebCASE existentes na verso inicial, mantendo suas caractersticas iniciais de
acordo com as metas estabelecidas neste projeto, obtendo como resultado, a ferramenta em suas
condies normais de funcionamento.
5.4.1 Casos de Uso
Foi adicionada uma nova aba que permite realizar o relacionamento entre requisitos
funcionais, regras de negcio e casos de uso (RN 04, RN 13). Sua estrutura assemelha-se ao padro
utilizado em uma matriz de rastreabilidade com a diferena 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 implementao da verso 1.0, um projeto dentro da ferramenta pode conter
diversos pacotes responsveis por agrupar os elementos de acordo com as necessidades e assim
facilitar a localizao das informaes. 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 Importao XMI
Aps concluir o desenvolvimento dos novos mdulos, foi iniciada a adaptao do
importador de arquivos XMI a fim de aceitar os novos elementos existentes na verso 2.0 da
ferramenta.
Sua modelagem clara e simples permitiu adicionar os novos elementos sem realizar grandes
alteraes em sua estrutura geral, tornando esta tarefa rpida 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 importao de um
projeto contendo os trs tipos de pacotes, ambos importaram os dados mapeados no documento
XML corretamente.
Na fase em que se encontra o importador possvel importar os diagramas de casos de uso
(verso 1.0), requisitos e regras de negcio (RF 06) formado por sua descrio, observao, 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, deciso,
unio/bifurcao) e os particionamentos de atividades definidos na UML.
Caso ocorra a existncia de elementos que no fazem parte do escopo deste projeto, estes
elementos so ignorados durante a importao e no afetam ou causam erros durante a leitura dos
arquivos XMI.
5.4.3.1 Estrutura de importao
Para facilitar a compreenso dos novos elementos importados esta seo apresenta as
marcaes utilizadas dos arquivos XMI gerados pela ferramenta Enterprise Architect utilizando a
especificao 2.1 da XMI. Os elementos relacionados s funcionalidades da verso 1.0 encontram-
se documentadas no TCC do autor da verso inicial da ferramenta WebCASE, Vagner Rech.
Da mesma forma que os diagramas de caso de uso esto inseridos dentro da marcao
packagedElement, os diagramas de atividades e pacotes de requisitos so formados pela mesma
estrutura. A diferenciao entre os elementos encontrados so definidos atravs do atributo xmi:type
descritos abaixo na Tabela 1.

Valor Descrio
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 associao 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 deciso 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 bifurcao/unio em um diagrama de
atividades.
Tabela 1. Tabela de novos elementos utilizados na importao XMI.
As informaes geomtricas, posicionamento de elementos e atributos especficos de cada
diagrama, encontram-se inseridas na seo xmi:extension de forma semelhante a existente nos
diagramas de casos de uso.
104
6 TESTES E VALIDAO
Os resultados dos testes aplicados para validao da ferramenta so apresentados neste
captulo e tem como objetivo avaliar seu funcionamento em condies normais de uso.
Segundo Dijkstra (1972 apud GOLDMAN; KON, 2004), a realizao de testes uma
maneira eficaz de detectar a presena de erros, porm insuficiente para demonstrar a sua total
ausncia. Outro motivo para a realizao de testes, est na tentativa sistemtica 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
possveis falhas e garantir a integrao entre os mdulos da verso inicial da ferramenta. Aps a
concluso das atividades de programao, foi elaborado um formulrio com questes relacionadas
usabilidade e conformidade com os requisitos e regras de negcio (Apndice 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 stimo perodo do
curso de Cincia da Computao na Universidade do Vale do Itaja. Para facilitar a compreenso e
focar nos objetivos de validao e conformidade, foi feita uma breve apresentao da ferramenta
aos envolvidos descrevendo a forma de execuo do teste, onde cada pessoa acessaria o servidor de
aplicao da ferramenta WebCASE atravs de um usurio permitindo criar seu projeto de forma
individual. A escolha deste grupo de testes justifica-se pelo grau de conhecimento dos usurios
sobre o tema abordado neste trabalho, o que permitiu avaliar a ferramenta sobre diferentes vises.
Os resultados coletados foram tabulados em uma planilha para possibilitar a anlise das
informaes atravs de grficos e comentrios realizados pelos alunos (Apndice C).
O grfico da Figura 52 apresenta os resultados de eficcia para avaliar se a ferramenta
atendeu ou no os requisitos propostos juntamente com o nmero de erros (Eficincia) detectados
em cada mdulo durante a realizao dos testes.
105
Eficcia
5
3
6
5
6
1.1 Requisitos 1.2 Casos de Uso 1.3 Matriz de
Rastreabilidade
1.4 Diagrama de
Atividades
1.5 Aprovao de
Requisitos pelo
Cliente
Sim No Eficincia(Erros)

Figura 52.Grfico apresentando a relao de eficcia e erros dos mdulos desenvolvidos.
6.1 Resultados de Usabilidade
Avaliando os resultados obtidos de informaes de usabilidade, foi observada uma boa
eficincia na utilizao da ferramenta onde apenas no existiu completa satisfao na ocorrncia de
falhas, algumas relacionadas a funes pertinentes a primeira verso da ferramenta, visto que os
testes aplicados eram formados por tarefas de avaliao da integrao.
A usabilidade do mdulo para gerenciamento de requisitos obteve uma boa eficincia, foram
sugeridas melhorias quanto disposio de alguns elementos na interface para torn-la mais
intuitiva. Os principais problemas encontrados estavam relacionados realizao de pesquisas onde
alguns filtros no buscavam as informaes corretamente.
Durante a criao de um pacote a rvore do projeto no era atualizada automaticamente,
dando a impresso que a mesma no havia sido criada, fazendo com que o usurio adicionasse um
novo pacote. Apesar de no fazer parte do escopo do trabalho, foram corrigidas algumas falhas
juntamente com a atualizao automtica da rvore aps a criao de um pacote.
No mdulo de relacionamento para casos de uso, ocorreram apenas alguns erros ao filtrar as
informaes e durante o relacionamento de elementos, visto que ocorria uma falha ao liberar o
elemento para edio.
106
Para avaliar a usabilidade da matriz de rastreabilidade, foi solicitada aos usurios a criao
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 limitaes dependendo do tamanho da descrio dos elementos das
colunas. De acordo com as respostas, a matriz possui boa usabilidade e permite uma boa
visualizao do relacionamento entre os elementos.
No diagrama de atividades, foi verificada uma boa usabilidade contendo apenas algumas
falhas de relacionamento entre os elementos, solucionada atravs da anlise de dados coletados dos
projetos criados durante o teste que facilitaram a sua deteco e posterior correo.
Os testes de aprovao de requisitos foram executados apenas por alguns usurios com
acesso a uma conta do tipo cliente, onde durante a aprovao do requisito o software se comportou
de forma inesperada em alguns casos, impossibilitando descobrir a falha ocorrida durante o teste,
mas que foram corrigidas aps analisar as informaes coletadas.
6.2 Conformidade dos requisitos e regras de negcio
Em relao aos testes de conformidade, duas regras de negcio (RN 07 e RN 16), no
haviam sido atendidas devido a problemas encontrados no diagrama de atividades, sendo estas
corrigidas e testadas novamente.
Como a escala utilizada para avaliao era entre um e cinco, todos os itens que obtiveram
nota inferior metade (trs) foram reavaliados, para tentar reduzir ao mximo o nmero de erros. A
Figura 53 e Figura 54, apresentam os resultados de avaliao de conformidade dos requisitos e
regras de negcio. Como a implementao da importao de arquivos XMI (RF 07) ainda estava
para ser concluda quando os testes foram executados, sua validao no foi realizada pelos
testadores, sendo este o motivo pelo qual a coluna referente ao RF7 no possui informaes no
grfico da Figura 54.


107
Conformidade Requisitos Funcionais
0
1
2
3
4
5
6
7
8
No Atende
Parcialmente
Mdio
Atende
Completamente
No Disponvel
No Atende 0 0 0 0 0 0 0 0
Parcialmente 0 0 1 0 1 0 0 0
Mdio 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
No Disponvel 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.Grfico apresentando a conformidade dos requisitos funcionais.

Conformidade Regras de Negcio
0
2
4
6
8
10
No Atende
Parcialmente
Mdio
Atende
Completamente
No Disponvel
No 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
Mdio 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
No Disponvel 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.Grfico apresentando a conformidade das regras de negcio.
108
6.3 Teste de compatibilidade com navegadores
Os testes foram realizados em dois dos principais navegadores, Internet Explorer verso 6 e
Firefox verso 2 e 3, alm 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 utilizao de recursos de memria, em que o nvel chegou a
ser 50% inferior comparado ao Firefox. O navegador Internet Explorer, por sua vez, comportou-se
de maneira inesperada em algumas situaes, sendo necessria atualizao da pgina para
continuar o uso da ferramenta.
Ao analisar a taxa de transferncia dos dados entre cliente e servidor atravs de uma
conexo de 300 Kbps, observou-se um alto trfego na rede. Tendo isto em vista, foram pesquisadas
formas de reduzir o tamanho dos arquivos transferidos.
A primeira alternativa testada foi a diminuio de cdigo JavaScript (Minify), que realiza a
remoo de caracteres desnecessrios (e.g., espaos, tabulaes, comentrios) e a reduo do nome
de variveis, funes e classes sem modificar suas funcionalidades. Esta alternativa til
principalmente por linguagens interpretadas que so 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 atravs da ativao do mdulo Deflate do servio Apache.
Este mdulo permite compactar o arquivo antes de sua transmisso pela rede, reduzindo, em alguns
casos, o tamanho e a taxa de transferncia em mais de 50%. Os testes foram visualizados atravs do
plugin firebug disponvel no navegador Firefox e demonstraram uma reduo de aproximadamente
60% conforme apresentado na Figura 55.

Figura 55.Comparao da taxa de transferncia com a ativao do modulo deflate no Apache.


109
7 CONCLUSES
Este trabalho teve como objetivo realizar a evoluo da ferramenta WebCASE, adicionando
recursos para facilitar a anlise e gerenciamento de projetos de software. Os novos conceitos
inseridos serviram para ajudar a consolidar a WebCASE como ferramenta didtica, principalmente
por seus diferenciais que, se mantidos atravs de uma evoluo gradual, podero torn-la completa
para o uso na engenharia de software.
Para a primeira fase deste trabalho (TCC I), foi realizado um estudo da documentao e das
tecnologias utilizadas em sua primeira verso, com intuito de verificar seu funcionamento. Na
fundamentao terica (Captulo 2), foram abordados os tpicos relacionados engenharia de
software, processos da engenharia de requisitos e os conceitos pertinentes elaborao de
diagramas de atividades seguindo a notao da UML.
Na parte de projeto (Captulo 3), foram elencados e documentados os requisitos e regras de
negcios necessrios para o desenvolvimento das novas funcionalidades. Todos os diagramas
existentes na modelagem do projeto foram atualizados e suas divergncias corrigidas para facilitar
sua compreenso por outros pesquisadores.
Aps a concluso da documentao, foram pesquisadas atualizaes da biblioteca ExtJS,
para garantir a compatibilidade em possveis projetos futuros. Porm, a nova verso impactou em
mudanas que inviabilizariam a migrao devido ao grande nmero de converses necessrias.
Na etapa de desenvolvimento (Captulo 4), inicialmente foram alterados alguns elementos
bsicos de interface e realizadas pequenas correes que facilitaram a compreenso da biblioteca
ExtJS. Durante a implementao, foi necessrio estudar conceitos pertinentes a orientao a objetos
em JavaScript e a notao JSON, utilizada para realizar a troca de informaes entre o cliente e o
servidor.
No desenvolvimento do mdulo de elaborao de diagrama de atividades, procurou-se tomar
cuidado quanto usabilidade fornecida para o usurio e manter certa similaridade a outras
ferramentas disponveis no mercado. Aps pesquisar diferentes sites para aplicaes RIA,
descobriu-se uma poderosa biblioteca, a Draw2d, capaz de resolver os problemas relacionados
criao de elementos visuais. Como a criao destes elementos no feita de forma nativa pelo
navegador, a utilizao de uma biblioteca de suporte permite focar os esforos nas regras da
110
aplicao, abstraindo a complexidade envolvida e facilitando a manuteno do sistema. Algumas
dvidas encontradas na utilizao desta biblioteca foram sanadas atravs de contato direto com o
responsvel pelo desenvolvimento, Andra Herz, que auxiliou na resoluo 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 aplicao dos testes, foi
solicitado para alguns usurios um feedback a respeito da ferramenta, sendo exaltada por alguns
testadores a capacidade que as novas bibliotecas possuem em transformar as aplicaes web
similares s aplicaes stand alone.
Avaliando a situao em que o trabalho se encontra, conclui-se que os objetivos propostos
foram contemplados dentro das especificaes estabelecidas na fase conceitual e prtica, atravs de
pesquisas e absoro de novos conhecimentos que permitiram executar um projeto de extenso
sobre uma ferramenta previamente modelada, bem codificada e documentada alm de suprir as
necessidades de: projeto, gerncia, desenvolvimento, documentao, validao e testes que so o
alicerce de formao para um analista de sistemas, cientista da computao, 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
Aps finalizar os novos mdulos da ferramenta WebCASE e realizar diversas pesquisas
sobre tecnologias para a internet, foi possvel observar o surgimento de novas tendncias que
permitem executar tarefas antes limitadas a aplicaes stand alone.
Para permitir o aprimoramento da ferramenta seguindo a tendncia das tecnologias
utilizadas, sugere-se como atividades iniciais a atualizao e migrao da biblioteca ExtJS para a
sua nova verso, avaliando a possibilidade em se utilizar alguns dos Wrappers existentes em PHP
ou Java (e.g., ExtPHP, PHP-Ext, Ext-GWT) que facilitariam a criao dos principais componentes,
reduzindo o tempo gasto na codificao de cdigos e a migrao para futuras verses da biblioteca.
Outra recomendao a alterao do diagrama de casos de uso para utilizar a biblioteca
Draw2d, que alm de melhorar a usabilidade e facilitar a manuteno, permite desenvolver novos
componentes de forma bastante rpida.
111
Essas alteraes podem ser consideradas perifricas no ponto de vista da pesquisa cientfica,
porm evolues da ferramenta no sentido de incluir outros diagramas necessrios para a
modelagem de um software, como diagramas de classes, diagramas Entidade-Relacionamento e
demais artefatos presentes na UML, podero agregar valores a ferramenta, ampliar a sua utilizao
acadmica e at mesmo profissional.
Fica como sugesto a utilizao do framework Symfony para padronizar e organizar a
estrutura das requisies e do projeto em mdulos relacionados. Desenvolvido de acordo com o
padro arquitetural MVC, permite implementar funcionalidades orientadas a objetos e utilizar uma
camada ORM (Object Role Modeling) para abstrao de acesso a dados (e.g., Propel, Doctrine).
Atravs de uma camada ORM possvel acessar as informaes do modelo relacional na forma de
objetos, livre de conceitos relacionados a banco de dados especficos, garantindo maior
portabilidade em caso de migrao para outros SGBDs.



112
REFERNCIAS BIBLIOGRFICAS

ALECRIM, Emerson. Conhecendo o servidor apache, 2006. Disponvel em:
<http://www.infowester.com/servapach.php>. Acesso em: 16 mai. 2008.
BASTOS, R.M. Modelos de caso de uso - Diagrama de atividades, [200-?]. Disponvel 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. Disponvel em:
<http://www.mysqlbrasil.com.br/?q=node/3>. Acesso em: 20 abr. 2008.
BRODSKY, S. XMI Opens Application Interchange, 1999 Disponvel em:
<www.cin.ufpe.br/~aad/garbage/xmiwhite0399.pdf>. Acesso em: 20 abr. 2008.
BUGHI, C. H. Observatrio Virtual sobre a biodiversidade marinha no Brasil baseado em
conceito WebGIS. Dissertao (mestrado em Cincia e Tecnologia Ambiental) - Centro de
Cincias Tecnolgicas da Terra e do Mar, Universidade do Vale do Itaja, Itaja, 2007.
CAPPELLI, C., SANTORO, F. Modelagem de processos e engenharia de requisitos, 2005.
Disponvel em: <twiki.dcc.ufba.br/pub/Residencia/MaterialModuloBP2/MPN-Aula6b.pdf>. Acesso
em: 28 mai. 2008.
CASTRO, J. Gerenciamento de Requisitos, 2000. Disponvel em:
<http://www.creupiapostilas.hpg.ig.com.br/erenciamentomudanca.ppt>. Acesso em: 23 mai. 2008.
COLOSSI, N., QUEIROZ E. G., CONSENTINO, A. Mudanas no contexto do ensino superior
do Brasil: Uma tendncia ao ensino colaborativo, 2001. Disponvel em:
<http://www.pp.ufu.br/Cobenge2001/trabalhos/CPI008.pdf>. Acesso em: 13 mar. 2008.
COSTA, C. J. Desenvolvimento para web, [200-?]. Disponvel em:
<http://books.google.com.br/books?id=Jn6dTDF-wcsC>. Acesso em: 16 mai. 2008
CYSNEIROS, L.M. Requisitos No-funcionais: Da Elicitao ao Modelo Conceitual, 2008.
Disponvel 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 Disponvel em: <
www.dextra.com.br/empresa/artigos/php.htm>. Acesso em: 20 abr. 2008.
FERNANDES, D. B. Anlise de sistemas orientada ao sucesso: Por que os projetos atrasam? So
Paulo: Cincia Moderna, 2005.
113
FILHO, P., Wilson de Pdua. Engenharia de Software: Fundamentos, Mtodos e Padres. 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. Disponvel 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.
Disponvel 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
aplicaes colaborativas, 2002. Disponvel 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. Disponvel 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. Coleo Shaum.
HERZ, A. Open-jACOB Draw2D, 2008. Disponvel 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. Disponvel 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. Disponvel em: <
inf.upf.br/pos/bd/CaseTools4.pdf >. Acesso em: 05 mai. 2008.
KRUCHTEN, P. Introduo ao RUP - Rational Unified Process. 5. ed. Rio de Janeiro: Cincia
Moderna, 2003.
LARMAN, C. Utilizando UML e Padres. 2. ed. Porto Alegre: Bookman, 2004.
LIMA, E.; BOECKMANN, G.; MONTEIRO, M.; SILVA, M; SAMPAIO, S.R. UML Unified
Modeling Language, 2000. Disponvel 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, Califrnia: OReilly & Associates, 2006.
MARTINS, L.E.G. Engenharia de requisitos, 2001. Disponvel em:
<http://www.unimep.br/~lgmartin/ER_Aula7.ppt>. Acesso em: 27 mai. 2008.
MAZZOLA, V.B. Engenharia de Software. Disponvel em:
<http://www.inf.ufsc.br/~jbosco/ii/IIcap6.doc>. Acesso em: 01 abr. 2008
MEDEIROS, E. Desenvolvendo software com UML Definitivo. So Paulo: Pearson Makron
Books, 2004.
MOOCK, Colin. Essential ActionScript 3.0. Sebastopol, Califrnia: OReilly & Associates, 2007.
PERRY, Bruce. Ajax Hacks. Sebastopol, Califrnia: OReilly & Associates, 2006.
PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prtica. 2. ed. Rio de Janeiro:
Campus, 2001.
PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prtica. So Paulo: Prentice Hall,
2004.
PICHILIANI, M.C., HIRATA C.M. Uma ferramenta de software livre para apoiar a
construo 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 especificao de requisitos de software observando
IEEE-830-1998 e RUP. Trabalho de concluso de curso (Graduao em Cincia da Computao)
Centro de Cincias Tecnologias da Terra e do Mar, Universidade do Vale do Itaja, Itaja, 2005.
RAMOS L; STRECHT P. Aplicao de Reverse Engineering: Java para UML. [200-?].
Disponvel 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
concluso de curso (Graduao em Cincia da Computao) Centro de Cincias Tecnologias da
Terra e do Mar, Universidade do Vale do Itaja, Itaja, 2007.
REFSNES DATA, Browser Statistics. 2008. Disponvel em:
<http://www.w3schools.com/browsers/browsers_stats.asp>. Acesso em: 15 nov. 2008.
REZENDE, D.A. Engenharia de Software e Sistemas de Informao. Rio de Janeiro: Brasport,
1999.
115
SAKALOS, J. Sakis Extensions, Plugins and Know-How, 2008. Disponvel em:
<http://www.extjs.eu>. Acesso em: 10 set. 2008.
SANTOS, F., VARGAS K., ABREU, C. Rastreabilidade de requisitos atravs da web, 2004.
Disponvel 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. Disponvel em: <http://www.cin.ufpe.br/~tar/trabalhos/graduacao.htm>. Acesso em: 15 mar.
2008.
SOARES, A.L. FARIA J.P. Engenharia de Requisitos, Especificao e Documentao.
Disponvel em: <http://paginas.fe.up.pt/~jpf/teach/ERSS/erss-documentacao.ppt>. Acesso em: 20
mai. 2008.
SOMMERVILLE, I. Engenharia de Software. 8 ed. So Paulo: Prentice Hall, 2007.
STREIBEL, Martins. Implementando Web Services. Trabalho de concluso de curso (Curso de
Especializao em Web e Sistemas de Informao) Instituto de Informtica, Universidade Federal
do Rio Grande do Sul, Porto Alegre, 2005.
TECHTERMS. Standalone. 2008. Disponvel em:
<http://www.techterms.com/definition/standalone>. Acesso em: 17 dez. 2008.
UNESP. O processo de engenharia de requisitos. 2006. Disponvel 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. Disponvel 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, Califrnia: Apress, 2006.










116





APNDICE A
DOCUMENTO DE MODELAGEM DO SISTEMA
118
A DETALHAMENTO DE CASOS DE USO
Nesta seo so detalhados os casos de uso adicionados a modelagem da ferramenta
WebCASE. Na Figura 56 apresentado o novo caso de uso UC 02.03 responsvel por permitir o
cadastro de categorias de requisitos.
Mdulo Administrador

uc PCT 02 -- Mdulo Administrador
Analista
(from PCT 03 -- Mdul o anal i sta)
Administrador
UC02.01 - Cadastra
Administradores e
Analistas
UC02.02 - Gerencia
proj etos
UC02.03 - Cadastra
categoria de
requisitos

Figura 56. Casos de uso do mdulo administrador.
A.1 UC 02.03 MANTER CATEGORIA DE REQUISITOS
Permite ao administrador manter as categorias dos requisitos e regra de negcio, definindo a
abreviao do elemento. Ex: Segurana, usabilidade, implementao, hardware, etc.
Relaes
RF 02. O sistema dever permitir cadastrar categorias para os requisitos no-funcionais;
e
RN 03. O administrador ser responsvel por cadastrar as categorias de requisitos e
regras de negcio que estaro disponveis para todos os projetos.

119
Mdulo 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, porm foram modificados para se
adequar s novas funcionalidades. As relaes apresentadas referem-se aos requisitos e regras de
negcio da nova verso.
uc PCT 03 -- Mdulo analista
Usurio
(fromPCT 01 -- Mdul o usurio)
Analista
UC03.01 - Desenha
diagrama
UC03.02 - Abre
proj eto
UC03.03 - Detalha
casos de uso
UC03.05 - Inicia bate-
papo
UC03.06 - Importa
diagrama de
instncia XMI
UC03.04 - Gerencia
Pacotes
UC03.07 - Cadastra
Cliente
UC03.08 - Mantm
Requisito
UC03.09 - Desenha
diagrama de
atividades
Os UC em amarel o (03.03 e 03.06)
i ndi cam casos de uso j exi stentes
mas que foram modi ficados para
contempl ar as novas
funcional i dades da verso atual
deste documento.
UC03.10 - Gera
matriz de
rastreabilidade

Figura 57. Casos de uso do mdulo analista.
A.2 UC 03.03 DETALHAR CASOS DE USO
Permite ao analista selecionar um caso de uso e iniciar sua modelagem adicionando cenrios
e observaes ao elemento. Quando um caso de uso j se encontrar em edio por um usurio, os
demais apenas podero ler as informaes de detalhamento contidas no elemento at que este seja
liberado.
Na nova verso permite ao analista relacionar um caso de uso a um ou mais requisitos
funcionais, regras de negcio ou casos de uso.

120
Relaes
RN 04. Um caso de uso poder ser relacionado com requisitos funcionais, casos de uso e
regras de negcio.
A.3 UC 03.06 IMPORTAR DIAGRAMA DE INSTNCIA XMI
Permite ao analista selecionar um arquivo XMI gerado pelo Enterprise Architect e importar
os diagramas de casos de uso.
Na nova verso da ferramenta sero importados tambm os requisitos e diagramas de
atividades do Enterprise Architect.
Relaes
RF 06. O sistema dever permitir ao analista importar requisitos de uma instncia XMI
gerada pelo Enterprise Architect; e
RF 07. O sistema dever permitir ao analista importar um diagrama de atividades de uma
instncia XMI gerada pelo Enterprise Architect.
A.4 UC 03.08 MANTER REQUISITO
Permite ao analista cadastrar um requisito de acordo com seu tipo funcional, no funcional
ou regra de negcio, determinar sua prioridade, status, estabilidade e dificuldade.
Relaes
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 negcio;
RN 01. Um requisito dever ser do tipo funcional, no funcional ou regra de negcio;
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 negcio 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, ao, n de deciso, bifurcao e realizar o relacionamento dos
elementos entre si.
Relaes
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, aes, desvio e bifurcao (fork)
RN 06. Um diagrama de atividades deve conter apenas um n inicial e vrios ns finais;
RN 07. Um elemento do diagrama de atividades poder se relacionar a mais de um
elemento, com exceo do n inicial;
RN 08. Um diagrama de atividades deve estar inserido dentro de um pacote;
RN 15. Um elemento do diagrama de atividades no pode se relacionar com ele mesmo;
RN 16. Um elemento n inicial do diagrama de atividades no poder receber ligao de
outros elementos;
RN 17. Um elemento n final do diagrama de atividades no poder realizar ligao com
outros elementos;
RN 18. Todos os elementos de um diagrama de atividades sero associados pela ligao
"controle de fluxo" possuindo informaes de condio de guarda e mensagem de transio;
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 Negcio e realizar o relacionamento entre estes artefatos (linha x coluna)
permitindo avaliar e analisar possveis implicaes que possam existir no projeto.
122
Relaes
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 Negcio 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.
Mdulo Cliente
Na figura 45 apresentado o modelo de casos de uso do cliente com a adio de um novo
caso de uso UC 04. 02, responsvel por aprovar ou reprovar um caso de uso.
uc PCT 04 -- Mdulo cliente
Usurio
(from PCT 01 -- Mdul o usuri o)
Cliente
UC04.01 - Aprova
casos de uso
UC04.02 - Aprova
requisito

Figura 58. Casos de uso do mdulo 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
Relaes
RF 05. O sistema dever permitir ao cliente aprovar ou rejeitar um requisito.
B DICIONRIO DE DADOS
O dicionrio de dados apresentado na seqncia, apresenta a situao atual aps realizar a
implementao das novas funcionalidades na ferramenta.
B.1 ENTIDADE WC_CONSTRAINT
Esta entidade permite armazenar as pr-condies e ps-condies de um caso de uso. Cada
condio pode estar relacionada com apenas um nico caso de uso.
Quadro 2. Entidade wc_constraint.
Atributo Definio do atributo Tipo
constraint_id Identificador nico da condio. int
fk_historical_elementId Identificador nico do elemento UML. int
constraint_mode
Define o tipo da condio podendo assumir os seguintes
valores:
0: Pr-condio; e
1: Ps-condio.
int
constraint_scope Texto com a descrio a condio. 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 Definio 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: Associao;
1: Generalizao;
2: Exteno;
3: Incluso; e
4: Controle de Fluxo.
int
link_style Estilo da conexo, manhatten, normal ou bezier int
source_port Porta origem de conexo int
target_port Porta destino de conexo Int
guard Condio de guarda varchar(200)
weight Mensagem de transio text

B.3 ENTIDADE WC_SCENARIO
Esta entidade define um cenrio para um caso de uso. Um cenrio pode estar relacionado
com apenas um nico caso de uso.
Quadro 4. Entidade wc_scenario.
Atributo Definio do atributo Tipo
scenario_id Identificador nico do cenrio. int
fk_historical_element_id
Identificador nico do elemento UML (caso de uso)
relacionado com o cenrio.
int
scenario_name Nome do cenrio varchar(45)
scenario_mode
Define o tipo de cenrio assumindo os seguintes
valores:
0: Cenrio principal;
1: Cenrio alternativo; e
2: Cenrio de exceo.
int
scenario_scope Texto com o fluxo do cenrio. text

B.4 ENTIDADE WC_ELEMENT
Entidade responsvel por armazenar os elementos existentes nos pacotes de um projeto.
125
Quadro 5. Entidade wc_element.
Atributo Definio 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 criao do elemento. date
element_state
Status do elemento. Os valores assumidos pode m ser:
0: Em elaborao;
1: Aguardando aprovao do cliente;
2: Aprovado pelo cliente; e
3: Rejeitado pelo cliente;
int
session_time
Define o tempo que a seo do usurio 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 Negcio;
3: N Inicial;
4: Atividade;
5: N Final;
6 e 7: Bifurcao/Unio;
8: Deciso; e
9: Particionamento de Atividade.

int
element_ea_id
Armazena o identificador em caso de importao por
arquivo XMI
varchar(45)

B.5 ENTIDADE WC_HISTORICAL_ELEMENT
Esta entidade permite armazenar um histrico de alteraes 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 Definio do atributo Tipo
h_element_id Identificador nico do histrico do elemento. int
fk_element_id Identificador nico do elemento pai. int
h_element_scope Descrio do elemento. text
h_last_change_user Nome do usurio que alterou o elemento. varchar(45)
h_last_change Data da ltima alterao do elemento. date
h_element_state
Status do elemento. Os valores assumidos podem ser:
0: Em elaborao;
1: Aguardando aprovao 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 Posio na coordenada Y em pixel do elemento. int
h_element_left Posio na coordenada X em pixel do elemento. int
h_element_ea_id
Armazena o identificador em caso de importao 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 Definio 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 importao 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 Definio do atributo Tipo
project_id Identificador nico do projeto. int
project_name Define o nome do projeto. varchar(45)
project_scope Contm um texto descrevendo o projeto. int

B.8 ENTIDADE WC_USER
Esta entidade permite armazenar usurios do sistema. Os usurios 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 Definio do atributo Tipo
user_id Identificador nico para usurio. int
user_name Nome do usurio. varchar(45)
user_login Identificador de usurio. varchar(45)
user_password Senha do usurio varchar(45)
user_mail E-mail do usurio. varchar(45)
user_fone Telefone do usurio. int
user_mode
Define o tipo de usurio. Os valores possveis so:
0: Administrador
1: Analista
2: Cliente
int

B.9 ENTIDADE WC_PROJECT_HAS_WC_USER
Entidade que relaciona os usurios 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 Definio do atributo Tipo
fk_project_id Identificador nico do projeto. int
fk_user_id Identificador do usurio int

B.10 ENTIDADE WC_CLIENT_COMMENT
Esta entidade permite armazenar comentrios de clientes para um caso de uso.
Quadro 11. Entidade wc_client_comment.
Atributo Definio do atributo Tipo
fk_user_id Identificador nico do cliente. int
fk_historical_element_id Identificador nico do elemento UML. int
client_comment Comentrio do cliente text
client_comment_date Data de criao do registro Date


Abaixo so 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 Definio 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 possveis so:
1: Baixa;
2: Mdia; e
3: Alta.
int
requirement_difficulty
Dificuldade de implementao do requisito. Os valores
possveis so:
1: Baixa;
2: Mdia; e
3: Alta.
int
requirement_stability
Estabilidade do requisito. Os valores possveis so:
1: Estvel; e
2: No estvel.
int
requirement_status
Status do requisito. Os valores possveis so:
1: Implementado;
2: Obrigatrio;
3: Proposto; e
4: Vlido.
int
requirement_observation Observao do requisito int


B.12 ENTIDADE WC_HISTORICAL_REQUIREMENT
Entidade responsvel por armazenar o histrico dos requisitos.
Quadro 13. Entidade wc_historical_requirement.
Atributo Definio do atributo Tipo
h_element_id Identificador nico do histrico do elemento. int
fk_element_id Identificador nico do elemento pai. int
h_requirement_scope Descrio do elemento. text
h_last_change_user Nome do usurio que alterou o elemento. varchar(45)
h_last_change Data da ltima alterao do elemento. date
h_requirement_state
Status do elemento. Os valores assumidos podem ser:
0: Em elaborao;
1: Aguardando aprovao do cliente;
2: Aprovado pelo cliente; e
3: Rejeitado pelo cliente;
int
h_element_ea_id
Armazena o identificador em caso de importao por
arquivo XMI
varchar(45)


B.13 ENTIDADE WC_REQUIREMENT_CATEGORY
Esta entidade permite armazenar as categorias de requisitos no-funcionais.
Quadro 14. Entidade wc_requirement_category.
Atributo Definio 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 Abreviao ou nome curto da categoria. text
requirement_mode
Tipo de requisito
1: Requisito Funcional;
2: Requisito No-Funcional; e
3: Regra de Negcio.
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 Definio do atributo Tipo
fk_element_source_id Elemento Origem int
fk_element_target_id Elemento Destino int
checked Informa se os elementos esto ou no relacionados int

C REQUISITOS DA VERSO 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
instncia XMI gerada pelo Enterprise Architect;
RF 11: O sistema dever permitir ao analista comunicar-se com os demais analistas atravs
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 usurios atualizarem seu perfil (senha, dados
pessoais).
REGRA DE NEGCIO
RN 01: Um caso de uso ou ator poder ser editado por apenas um analista em um mesmo
momento;
RN 02: Quando em edio, um caso de uso dever ficar disponvel como somente leitura
para os demais analistas;
RN 03: Os esteritipos de Incluso ( include ) e Extenso ( extend ) devem ocorrer
apenas entre casos de uso;
RN 04: Associaes devem ocorrer apenas entre atores e casos de uso;
RN 05: Generalizaes 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 aps ser liberado por um
analista.
REQUISITOS NO 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
atravs de identificador de usurio e senha; e
RNF 05: O sistema dever ser compatvel com a verso 2.1 da XMI gerada pelo Enterprise
Architect 6.5.
133






APNDICE B
DOCUMENTO DE TESTES
134
Documento de teste da ferramenta WebCASE v2.0

Ambiente para teste

Os diagramas fornecidos no anexo devero ser utilizados para gui-lo durante os testes da
ferramenta. Aconselha-se o preenchimento dos testes de usabilidade durante a criao dos
diagramas.


1. Usabilidade

O presente teste destina-se a verificar o grau de usabilidade da ferramenta WebCASE elaborado
no mbito do Trabalho de Concluso de Curso do aluno Haissam Yebahi.

Gradao das respostas: 1 (Muito fcil)
2 (Fcil)
3 (Dificuldade mdia)
4 (Difcil)
5 (Muito Difcil)

1.1 Requisitos
Eficincia Dificuldade Observaes
Descrio
Eficcia
(Sim/No)
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 negcio

Tarefa 4. Cadastrar
um requisito no-
funcional

Tarefa 5. Alterar um
requisito/regra de
negcio

Tarefa 6. Excluir um
requisito/regra de
negcio

Tarefa 7. Pesquisar
um requisito/regra de
negcio no pacote

Tarefa 8. Filtrar
requisitos por tipo

Tarefa 9. Filtrar
requisitos por

135
informaes
adicionais
Tarefa 10. Liberar
requisito para
aprovao pelo cliente



1.2 Casos de Uso
11


Eficincia Dificuldade Observaes
Descrio
Eficcia
(Sim/No)
No. de
erros
1 2 3 4 5
Tarefa 1. Selecionar
requisitos e/ou regras
de negcio a serem
relacionados ao caso
de uso

Tarefa 2. Relacionar
requisito e/ou regras
de negcio ao caso de
uso

Tarefa 3. Remover
relacionamento entre
caso de uso e
requisitos/regras de
negcio

Tarefa 4. Filtrar
requisitos e/ou regras
de negcio
relacionados ao caso
de uso.



1.3 Matriz de rastreabilidade

Eficincia Dificuldade Observaes
Descrio
Eficcia
(Sim/No)
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 mdulo de Casos de Uso corresponde a primeira verso da ferramenta, por isso, dever ser analisado somente a
integrao do Caso de uso com o mdulo 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 atravs do
painel visvel sobre a
clula 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

Eficincia Dificuldade Observaes
Descrio
Eficcia
(Sim/No)
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 deciso ao
diagrama

Tarefa 5. Relacionar o
elemento deciso a
elementos Atividades.

Tarefa 6. Adicionar a
condio de guarda ao
fluxo. (selecionar o

137
relacionamento entre
dois elementos).
Tarefa 7. Adicionar
um elemento
bifurcao ao
diagrama.

Tarefa 8. Alterar
elemento do diagrama.

Tarefa 9. Excluir
elemento do diagrama.

Tarefa 10. Adicionar
particionamento ao
diagrama

Tarefa 11. Alterar
informaes do
particionamento



1.6 Aprovao de Requisito pelo cliente
(Entrar no sistema com o usurio: cliente, senha: cliente, abrir o pacote e aprovar/rejeitar o
requisito)

Eficincia Dificuldade Observaes
Descrio
Eficcia
(Sim/No)
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. Avaliao de Conformidade

A avaliao 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 (no atende) a 5 (atende plenamente). Caso no consiga avaliar por
questes de nvel de acesso, avalie o requisito como N.D (No Disponvel)

2.1 Atendimento aos requisitos funcionais

Requisito Avaliao
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 negcio;

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 negcio

Regras de Negcio Avaliao
RN 01. Um requisito dever ser do tipo funcional, no funcional ou regra de
negcio;

RN 02. Uma matriz de rastreabilidade deve realizar o rastreamento entre Requisitos
Funcionais, Regras de Negcio e Casos de Uso;

RN 03. O administrador ser responsvel por cadastrar as categorias de requisitos
no funcionais que estaro disponveis para todos os projetos;

RN 04. Um caso de uso poder ser relacionado com requisitos funcionais, casos de
uso e regras de negcio;

RN 05. Um diagrama de atividades poder conter os seguintes elementos: n inicial,
n final, atividades, aes, desvios e bifurcao (fork);

RN 06. Um diagrama de atividades deve conter apenas um n inicial e vrios ns
finais.

RN 07. Um elemento do diagrama de atividades poder se relacionar a mais de um
elemento, com exceo 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 negcio dever estar relacionado a uma categoria.
RN 15. Um elemento do diagrama de atividades no pode se relacionar com ele
mesmo;

RN 16. Um elemento n inicial do diagrama de atividades no poder receber
ligao de outros elementos;

RN 17. Um elemento n final do diagrama de atividades no poder realizar ligao
com outros elementos;

RN 18. Todos os elementos de um diagrama de atividades sero associados pela
ligao "controle de fluxo".e

RN 19. Um pacote de diagrama de atividades pode conter particionamentos de
atividades.



3. Sugestes

Espao reservado para que voc escreva as crticas e/ou sugestes em relao ao uso da ferramenta
WebCASE.
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
140
Diagrama de atividades

Abre proj eto
Entrar no Si stema
Cri ar pacote? Cria pacote requisitos
Abrir pacote
Cadastrar Requisito
Li berar para
aval i ao?
Libera requisito para
avaliao
Sai do si stema
Enviar email para cliente
Alterar 'status' do
requisito
Sai do sistema
[Si m]
[Si m]
[Nao]


141
Diagrama de Casos de Uso

Gerente
UC 01.1 Manter
Usurios do Sistema
Atendente
UC 01.2 Manter
Clientes
UC 01.3 Visualizar
Histrico
i ncl ude




Requisitos funcionais

custom 2.2.1 Requisitos Funcionais
RF 01. O sistema dever permi ti r ao admini strador cadastrar novos admi ni stradores.
RF 02. O sistema dever permi ti r ao admini strador cadastrar novos anal i stas.
RF 03. O sistema dever permi ti r ao anal ista cadastrar novos cl i entes.
RF 04. O sistema dever permi ti r ao anal ista defi ni r o(s) cl i ente(s) de um proj eto.



Requisitos no-funcionais

custom 2.2.2 Requisitos No Funcionais
RNF 01.O sistema deve ser compatvel com o Mozi l l a Fi refox e Internet Expl orer.
RNF 02. O si stema dever rodar em um servi dor com i nterpretador PHP.
RNF 03. O si stema deve util i zar banco de dados MySQL.
RNF 04. O acesso as funci onal i dades do si stema dever ser fei ta com um control e de acesso atravs de l ogin e senha.


Regras de negcio

custom 2.2.3 Regras de Negcio
RN 01. Um caso de uso ou ator poder ser edi tado por apenas um colaborador em um mesmo momento.
RN 03. Os esteri ti pos de Incl uso ( i ncl ude ) e Extenso ( extend ) devem ocorrer apenas entre casos de uso.
RN 02. Quando em edi o, um caso de uso dever ficar di sponvel como somente l ei tura para os demai s col aboradores.
RN 04. Associaes devem ocorrer apenas entre atores e casos de uso.
RN 05. General izaes devem ocorrer entre elementos (casos de uso e atores) do mesmo ti po.

143















APNDICE C
RESULTADOS DOS TESTES

RESULTADOS


1. Avaliao de Usabilidade

Dificuldade
1.1 Requisitos Eficcia Num. Erros 1 2 3 4 5
Sim No Eficincia Muito Fcil Fcil Mdio Difcil Muito Difcil
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 Eficcia 1 2 3 4 5
Sim No Eficincia Muito Fcil Fcil Mdio Difcil Muito Difcil
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 Eficcia 1 2 3 4 5
Sim No Eficincia Muito Fcil Fcil Mdio Difcil Muito Difcil
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 Eficcia 1 2 3 4 5
Sim No Eficincia Muito Fcil Fcil Mdio Difcil Muito Difcil
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 Aprovao de Requisitos Eficcia 1 2 3 4 5
Sim No Eficincia Muito Fcil Fcil Mdio Difcil Muito Difcil
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
No
Sim 10 11 11 11 10 11 11 11 10 9
No 1 0 0 0 0 0 0 0 1 1
Taref a
1
Taref a
2
Taref a
3
Taref a
4
Taref a
5
Taref a
6
Taref a
7
Taref a
8
Taref a
9
Taref a
10
Usabilidade 1.2 Casos de Uso
0
2
4
6
8
10
12
Sim
No
Sim 11 11 10 8
No 0 1 1 2
Taref a 1 Taref a 2 Taref a 3 Taref a 4
Usabilidade 1.3 Matriz de Rastreabilidade
0
5
10
15
Sim
No
Sim 10 11 10 10 9 10
No 1 0 1 1 2 1
Taref a 1 Taref a 2 Taref a 3 Taref a 4 Taref a 5 Taref a 6

Usabilidade 1.4 Diagrama de Atividades
0
2
4
6
8
10
12
Sim
No
Sim 10 10 10 9 10 10 10 10 10 10 10
No 0 0 0 1 1 0 0 0 0 0 0
Taref a
1
Taref a
2
Taref a
3
Taref a
4
Taref a
5
Taref a
6
Taref a
7
Taref a
8
Taref a
9
Taref a
10
Taref a
11
Usabilidade 1.5 Aprovao de Requisitos
0
1
2
3
4
5
6
7
Sim
No
Sim 6 5 5
No 1 2 2
Taref a 1 Taref a 2 Taref a 3