UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO

WEBCASE –...
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO

WEBCASE –...
AGRADECIMENTOS
Admito que não foi nada fácil chegar até esta fase, diversas foram as barreiras, falta de recursos,
restand...
SUMÁRIO
1 INTRODUÇÃO .................................................................................... 10
1.1 PROBLEMAT...
5 Apresentação da Ferramenta.............................................................. 90
5.1 MÓDULO DIAGRAMA DE ATIVI...
LISTA DE ABREVIATURAS
AJAX
API
CASE
CGI
CSS
DOM
ER
DER
ERS
FTP
HTML
HTTP
IEEE
IIS
JSON
JSP
LGPL
ODBC
OMG
PDF
PHP
POP
RAD
R...
LISTA DE FIGURAS
Figura 1. Cadastro de administradores/analistas. ...........................................................
Figura 47. Tela para aprovação/reprovação de requisitos pelo cliente. .............................................97
Figu...
RESUMO
YEBAHI, Haissam. WebCASE - Ferramenta Colaborativa para Especificação de Requisitos e
Modelagem de Diagramas de Ati...
ABSTRACT
A software is composed by many activities that allow assess it progress and guarantee all tasks
involved to solve...
1 INTRODUÇÃO
O aprimoramento de técnicas relacionadas ao gerenciamento de projetos, tem sido
fortemente discutido nas mais...
dentro do prazo estipulado. Entre os fatores de insucesso, merecem destaque a má especificação e a
modificação dos requisi...
Segundo Rech (2007), o objetivo da ferramenta WebCASE consiste em suprir algumas
necessidades relacionadas à colaboração e...
Uma forma de verificar se os requisitos de software encontram-se contemplados pelos casos
de uso é através da rastreabilid...
1.2.2

Objetivos Específicos

•

Pesquisar e analisar soluções similares de ferramentas de modelagem;

•

Analisar e compr...
Metodologia
Para a realização do presente projeto, sua estrutura foi dividida em seis grandes etapas
listadas abaixo:
•

L...
•

Pesquisa do padrão para gerenciamento de objetos e troca de informações baseadas no
padrão XML (Extensible Markup Langu...
•

Testes de integração com as funcionalidades existentes, através da definição e aplicação
de um estudo de caso para cert...
O sétimo e último capítulo apresenta as conclusões, dificuldades encontradas durante o
desenvolvimento e sugestões para tr...
2 FUNDAMENTAÇÃO TEÓRICA
Neste capitulo são estudados e analisados os conceitos envolvidos no projeto de acordo com
a propo...
A ferramenta WebCASE possui opções diferenciadas de acordo com o tipo de usuário
autenticado (cliente, analista e administ...
Figura 1. Cadastro de administradores/analistas.

2.1.1.2

Desenhar e detalhar diagramas de casos de uso
Módulo principal ...
Em relação ao nível de detalhamento (Figura 3), é possível inserir informações sobre cada
caso de uso como cenários, obser...
Figura 4. Gerenciamento de projetos.

2.1.1.4

Bate Papo (chat)
A ferramenta conta com um sistema de chat para facilitar a...
Figura 5. Chat agregado a ferramenta WebCASE.

2.1.1.5

Importação de arquivos XMI
A importação de diagramas de caso de us...
Figura 6. Aprovação de Casos de Uso pelo cliente.

2.1.2

Modelo conceitual e estrutura física do banco de dados
Uma impor...
Figura 7. Modelo de classes original da ferramenta WebCASE.
Fonte: Rech (2007).

A seguir são descritas as classes present...
encontram-se

implementadas

tanto

do

lado

servidor

através

do

arquivo

wcObject.class.php quanto do lado cliente at...
permitem realizar as funções de acordo com o perfil de acesso de cada usuário.
Encontra-se implementada no lado servidor a...
por tratar as operações realizadas em um pacote como movimentação de elementos na
tela (e.g. drag and drop), redimensionam...
Figura 9. Framework para conexão ao banco de dados da ferramenta WebCASE.
Fonte: Rech (2007).
•

wcDBConfig: Classe respon...
•

wcDBQuery: Classe responsável por executar as instruções SQL, é formada por dois
métodos, um para realizar consultas e ...
modelo lógico, esta entidade conta com um campo identificador (package_ea_id), utilizado
nos caso de importação de um arqu...
2.1.3

Tecnologias
Projetada para ser executada na plataforma web, independente do sistema operacional, a

ferramenta WebC...
Figura 11. Comunicação entre cliente servidor através de um navegador Web.
Fonte: Adaptado de STREIBEL (2005).

2.1.3.2

L...
•

O suporte a grande variedade de SGBDs (Sistema Gerenciador de Banco de Dados)
permite que o servidor de aplicação comun...
2.1.3.3

Banco de dados
O armazenamento das informações da ferramenta WebCASE é feito utilizando-se o SGBD

relacional MyS...
•

Suporte a programação diretamente no SGBD como stored procedures, funções, triggers
(i.e., gatilhos disparados automati...
•

Recuperação de dados assíncronos utilizando um objeto JavaScript denominado
XMLHttpRequest; e

•

Apresentação dos dado...
Figura 12. Exemplo de comunicação utilizando AJAX
Adaptado de: GARRETT (2005)

Umas das formas alternativas presentes para...
Atualmente encontra-se na versão 2.1 e está presente na licença comercial ou sob as
condições da licença LGPL (Lesser Gene...
Figura 14. Código para a geração de uma tabela utilizando a biblioteca ExtJS.
Adaptado de: VEDOVELLI (2007)

2.1.3.7

Form...
Para Brodsky (1999) a diversidade de ferramentas disponíveis para projetos de software é de
extrema importância, pois perm...
2.1.4

Considerações sobre a Ferramenta
Com o estudo realizado sobre a ferramenta WebCASE foi possível avaliar a forma em ...
Requisitos Projeto
3%
7%

Codificação
10%

Testes de
Aceitação
57%

Testes da
Unidade
23%

Figura 16. Distribuição dos cus...
Mesmo não existindo um modelo ideal, é necessário realizar um estudo entre as diferentes
abordagens a fim de encontrar o m...
planejamento minucioso e completo para melhorar o desempenho de um projeto (PETERS;
PEDRYCZ, 2001).
Sommerville (2007) apo...
2.2.1.1

Requisitos Funcionais
Os requisitos funcionais (RF) descrevem através de uma linguagem clara e escrita às

funçõe...
•

Requisitos externos: Requisitos voltados aos fatores externos do software, como a
interoperabilidade com softwares de o...
Apesar da importância de definir corretamente as regras de negócio, sua compreensão pode
ser acompanhada de diversos confl...
tarefa deverá ser realizada, avaliando suas origens e separando suas características, para permitir
que novas habilidades ...
2.2.3.1

Estudo de viabilidade
Na maioria dos projetos de software, deve-se inicialmente realizar um estudo das

necessida...
Os stakeholders, segundo Sommerville (2007), são todas as pessoas envolvidas que possuem
influência direta ou indireta sob...
•

Pontos de vista de iteração: Responsáveis por representar todas as pessoas envolvidas
direta ou indiretamente com o sis...
Na Figura 18 é apresentado um exemplo de diagrama de caso de uso para um sistema de
controle de usuários. Neste modelo exi...
•

Restrições de operação, definição do ambiente em que o sistema será executado e
integração com outros sistemas.

Ao rea...
Característica da ERS
•

Correta: Uma ERS está correta se, e somente se, todos os requisitos atendem as
necessidades do so...
•

Verificável: Toda ERS deve ser verificável, ou seja, se um requisito puder ser testado
com um custo efetivo através de ...
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades
Upcoming SlideShare
Loading in...5
×

WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades

1,361

Published on

A ferramenta WebCASE foi desenvolvidapara auxiliar as etapas iniciais da engenharia de software através da elaboração de diagramas decasos de uso e permitir a interação e colaboração entre os responsáveis.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,361
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

WebCASE - Ferramenta Colaborativa para Especificação de Requisitos eModelagem de Diagramas de Atividades

  1. 1. UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO WEBCASE – FERRAMENTA COLABORATIVA PARA ESPECIFICAÇÃO DE REQUISITOS E MODELAGEM DE DIAGRAMAS DE ATIVIDADES Área de Engenharia de Software por Haissam Yebahi Carlos Henrique Bughi, M.Sc. Orientador Itajaí (SC), novembro de 2008
  2. 2. UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO WEBCASE – FERRAMENTA COLABORATIVA PARA ESPECIFICAÇÃO DE REQUISITOS E MODELAGEM DE DIAGRAMAS DE ATIVIDADES Área de Engenharia de Software por Haissam Yebahi Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Carlos Henrique Bughi, M.Sc. Itajaí (SC), novembro de 2008
  3. 3. AGRADECIMENTOS Admito que não foi nada fácil chegar até esta fase, diversas foram as barreiras, falta de recursos, restando como único suporte o apoio de pessoas que sem dúvida foram essenciais ao longo desses cinco anos. Em primeiro lugar agradeço a Deus, por ter me guiado diante de tantas dúvidas mesmo quando a esperança parecia não ser suficiente e hoje fica como uma grande experiência de vida. Aos meus pais, Abdala Yebahi e Doralina Comelli, por toda educação e ensinamentos que me tornaram a pessoa que sou. A professora Adriana Gomes Alves por auxiliar e permitir a realização dos testes durante sua aula que tiveram grande importância para verificar o funcionamento da nova versão da WebCASE. Ao professor Rudimar Luis Scaranto Dazzi, a professora Anita Maria Fernandez da Rocha e a Marlei Salete Antunes, que me ajudaram desde o início da faculdade. Ao meu orientador Carlos Henrique Bughi, por confiar na minha capacidade e orientar durante este ano, com diversas contribuições motivações e cobranças que tornam possível a realização deste projeto. A família dos meus grandes amigos Jean Rauwers, “Pai João”, Dalva Rauwers, Daniel Hasse, Janete Hasse e Hari Hasse, que me auxiliaram e que hoje considero parte da minha família, afinal tiveram que me agüentar por um bom tempo. Ao futuro aluno do curso de Ciência da Computação, Bruno Hasse, me ajudando em alguns testes e me apoiando nos momentos de loucura, hoje já ciente de tudo aquilo que irá passar. Ao meu amigo Rafael Rauber, pelo auxilio na criação de imagens utilizadas no design da ferramenta WebCASE. As demais pessoas, amigos professores, avaliadores que apoiaram e contribuíram para a realização deste projeto com idéias, sugestões e críticas. ii
  4. 4. SUMÁRIO 1 INTRODUÇÃO .................................................................................... 10 1.1 PROBLEMATIZAÇÃO ................................................................................... 13 1.1.1 Formulação do Problema ............................................................................... 13 1.1.2 Solução Proposta ............................................................................................. 13 1.2 OBJETIVOS ...................................................................................................... 13 1.2.1 Objetivo Geral ................................................................................................. 13 1.2.2 Objetivos Específicos ...................................................................................... 14 METODOLOGIA ..................................................................................................... 15 1.3 ESTRUTURA DO TRABALHO ..................................................................... 17 2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 19 2.1 ANÁLISE TÉCNICA DA FERRAMENTA WEBCASE .............................. 19 2.1.1 Funcionalidades............................................................................................... 19 2.1.2 Modelo conceitual e estrutura física do banco de dados............................. 25 2.1.3 Tecnologias ...................................................................................................... 33 2.1.4 Considerações sobre a Ferramenta ............................................................... 43 2.2 ENGENHARIA DE SOFTWARE ................................................................... 43 2.2.1 Requisitos de Software ................................................................................... 45 2.2.2 Engenharia de Requisitos............................................................................... 49 2.2.3 Processos da Engenharia de Requisitos ........................................................ 50 2.2.4 Gerenciamento de requisitos.......................................................................... 58 2.3 DIAGRAMA DE ATIVIDADES...................................................................... 63 2.4 ANÁLISE DE FERRAMENTAS SIMILARES ............................................. 67 2.4.1 Enterprise Architect 6.5 ................................................................................. 68 2.4.2 CONTROLA.................................................................................................... 69 2.4.3 ArgoUML......................................................................................................... 71 2.4.4 SPRES – Ferramenta Case para Especificação de Requisitos. .................. 72 2.4.5 Análise comparativa entre as ferramentas................................................... 74 3 PROJETO ............................................................................................. 76 3.1 MODELAGEM DE NEGÓCIO E FUNCIONALIDADES .......................... 76 3.1.1 Requisitos......................................................................................................... 76 3.1.2 Casos de uso..................................................................................................... 79 3.1.3 Diagrama de classes ........................................................................................ 81 3.1.4 Diagrama Entidade-Relacionamento............................................................ 83 3.1.5 Diagrama de atividades .................................................................................. 85 4 IMPLEMENTAção.............................................................................. 87 4.1 4.2 4.3 4.4 BANCO DE DADOS ......................................................................................... 87 DRAW2D............................................................................................................ 87 EXTJS................................................................................................................. 88 LAYOUT ............................................................................................................ 88 iii
  5. 5. 5 Apresentação da Ferramenta.............................................................. 90 5.1 MÓDULO DIAGRAMA DE ATIVIDADES .................................................. 90 5.2 ESPECIFICAÇÃO DE REQUISITOS E REGRAS DE NEGÓCIO........... 95 5.2.1 Aprovação de Requisitos ................................................................................ 97 5.3 MATRIZ DE RASTREABILIDADE .............................................................. 98 5.4 ALTERAÇÕES REALIZADAS NA VERSÃO 1.0...................................... 100 5.4.1 Casos de Uso .................................................................................................. 100 5.4.2 Pacotes............................................................................................................ 101 5.4.3 Importação XMI ........................................................................................... 101 6 TESTES E VALIDAÇÃO ................................................................. 104 6.1 RESULTADOS DE USABILIDADE............................................................. 105 6.2 CONFORMIDADE DOS REQUISITOS E REGRAS DE NEGÓCIO ..... 106 6.3 TESTE DE COMPATIBILIDADE COM NAVEGADORES .................... 108 7 CONCLUSÕES .................................................................................. 109 7.1 TRABALHOS FUTUROS.............................................................................. 110 REFERÊNCIAS BIBLIOGRÁFICAS ................................................. 112 A DETALHAMENTO DE CASOS DE USO...................................... 118 B DICIONÁRIO DE DADOS............................................................... 123 C REQUISITOS DA VERSÃO 1.0 ...................................................... 131 iv
  6. 6. LISTA DE ABREVIATURAS AJAX API CASE CGI CSS DOM ER DER ERS FTP HTML HTTP IEEE IIS JSON JSP LGPL ODBC OMG PDF PHP POP RAD RF RIA RN RUP RNF SAX SGBD SQL SMTP TCC UML UNIVALI W3C XHTML XMI XML Asynchronous JavaScript And XML Application Programming Interface Computer Aided Software Engineering Common Gateway Interface Cascading Style Sheets Document Object Model Entidade Relacionamento Diagrama Entidade Relacionamento Especificação de Requisitos de Software File Transfer Protocol Hyper Text Markup Language Hyper Text Transfer Protocol Institute of Electrical and Electronics Engineers Internet Information Service JavaScript Object Notation Java Server Pages Lesser General Public License Open Database Connectivity Object Management Group Portable Document Format Hypertext Preprocessor Post Office Protocol Rapid Application Development Requisitos Funcionais Rich Internet Applications Regras de Negócio Rational Unified Process Requisitos Não-funcionais Simple API for XML Sistema Gerenciador de Banco de Dados Structured Query Language Simple Mail Transfer Protocol Trabalho de Conclusão de Curso Unified Modeling Language Universidade do Vale do Itajaí World Wide Web Consortium eXtensible Hyper Text Markup Language XML Metadata Interchange Extensive Markup Language v
  7. 7. LISTA DE FIGURAS Figura 1. Cadastro de administradores/analistas. ...............................................................................21 Figura 2. Exemplo de um diagrama de casos de uso. ........................................................................21 Figura 3. Tela de detalhamento de um caso de uso............................................................................22 Figura 4. Gerenciamento de projetos. ................................................................................................23 Figura 5. Chat agregado a ferramenta WebCASE. ............................................................................24 Figura 6. Aprovação de Casos de Uso pelo cliente............................................................................25 Figura 7. Modelo de classes original da ferramenta WebCASE........................................................26 Figura 8. Exemplo de código para inserir informações no banco de dados.......................................27 Figura 9. Framework para conexão ao banco de dados da ferramenta WebCASE. ..........................30 Figura 10. Modelo ER da ferramenta WebCASE. .............................................................................31 Figura 11. Comunicação entre cliente servidor através de um navegador Web.................................34 Figura 12. Exemplo de comunicação utilizando AJAX.....................................................................39 Figura 13. Tabela de dados criada com a biblioteca ExtJS................................................................40 Figura 14. Código para a geração de uma tabela utilizando a biblioteca ExtJS. ...............................41 Figura 15. Pontes entre diferentes ferramentas e empresas. ..............................................................42 Figura 16. Distribuição dos custos envolvidos em projetos de Software...........................................44 Figura 17. Etapas presentes no processo de engenharia de requisitos. ..............................................50 Figura 18. Exemplo de um diagrama de caso de uso. ........................................................................53 Figura 19. Cobertura do gerenciamento de requisitos nas etapas da engenharia de requisitos..........59 Figura 20. Exemplo de matriz de rastreabilidade entre requisitos. ....................................................63 Figura 21. Diagrama de atividades representando uma pesquisa em um sistema de buscas. ............64 Figura 22. Representação de uma atividade ou ação. ........................................................................65 Figura 23. Representação de um estado inicial (esquerda) e um estado final (direita)......................65 Figura 24. Representação de uma transição por uma seta..................................................................65 Figura 25. Elemento de decisão com dois fluxos (sim/não). .............................................................66 Figura 26. Bifurcação em um diagrama de atividades. ......................................................................66 Figura 27. Particionamento separando as atividades de acordo com o tipo de usuário. ....................67 Figura 28. Especificação de requisitos no Enterprise Architect 6.5...................................................68 Figura 29. Exemplo de diagrama de atividades gerado no Enterprise Architect 6.5. ........................69 Figura 30. Tela principal da ferramenta CONTROLA. .....................................................................70 Figura 31. Matriz de rastreabilidade criada pela ferramenta CONTROLA. ......................................71 Figura 32. Ferramenta Colaborativa ArgoUML. ...............................................................................72 Figura 33. ERS modelada na Ferramenta SPRES..............................................................................73 Figura 34. Modelo de classes modificado da ferramenta WebCASE. ...............................................82 Figura 35. Modelo ER modificado da ferramenta WebCASE...........................................................84 Figura 36. Diagrama de atividades com as novas funcionalidades integradas. .................................86 Figura 37. Novo menu da WebCASE em comparação com o menu da versão anterior. ..................89 Figura 38. Diferentes formas de representação de relacionamento no diagrama de atividades.........91 Figura 39. Menu popup com opções para facilitar a manipulação dos elementos.............................91 Figura 40. Separação de responsabilidades através do particionamento de atividades......................92 Figura 41. Relacionamento entre dois elementos conectando entre duas portas. ..............................93 Figura 42. Cadastro de informações de relacionamento do diagrama de atividades. ........................94 Figura 43. Tela para edição de elemento do diagrama de atividades.................................................95 Figura 44. Diversas opções de filtros em um pacote de requisitos. ...................................................95 Figura 45. Tela de cadastro de requisito. ...........................................................................................96 Figura 46. Cadastro de categorias de requisitos. ................................................................................97 vi
  8. 8. Figura 47. Tela para aprovação/reprovação de requisitos pelo cliente. .............................................97 Figura 48. Comparacão entre a matriz de rastreabilidade da Enterprise Architect (esquerda) e WebCASE (direita). ...................................................................................................................98 Figura 49. Visualização entre relacionamentos na matriz de rastreabilidade. ...................................99 Figura 50. Relacionamento de um caso de uso com outros elementos. ...........................................100 Figura 51. Nova tela do cadastro de Pacotes....................................................................................101 Figura 52.Gráfico apresentando a relação de eficácia e erros dos módulos desenvolvidos.............105 Figura 53.Gráfico apresentando a conformidade dos requisitos funcionais. ...................................107 Figura 54.Gráfico apresentando a conformidade das regras de negócio..........................................107 Figura 55.Comparação da taxa de transferência com a ativação do modulo deflate no Apache. ....108 Figura 56. Casos de uso do módulo administrador. .........................................................................118 Figura 57. Casos de uso do módulo analista. ...................................................................................119 Figura 58. Casos de uso do módulo cliente......................................................................................122 vii
  9. 9. RESUMO YEBAHI, Haissam. WebCASE - Ferramenta Colaborativa para Especificação de Requisitos e Modelagem de Diagramas de Atividades. Itajaí, 2008. 149 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2008. O ciclo de vida de um software é formado por diversas atividades que permitem avaliar seu progresso e garantir a realização das tarefas envolvidas na solução de um problema. Manter as informações organizadas em um ambiente de trabalho compartilhado facilitam o gerenciamento e rastreamento das mudanças em um projeto. Como resultados é possível negociar compromissos, melhorar estimativas de prazo, além de diminuir falhas, aumentando a satisfação do cliente e da empresa responsável pelo projeto. Através das ferramentas CASE (Computer Aided Software Engineering – Engenharia de Software Auxiliada por Computador), é possível realizar as atividades envolvidas nos processos de engenharia de software em um nível de especificação maior, com ênfase na análise, qualidade e produtividade de um projeto. Sua utilização permite facilitar o entendimento humano e a comunicação, onde a técnica empregada para a representação deve ser capaz de expor e simplificar as etapas envolvidas no processo, incluindo informações para seu aprimoramento e real utilização. Seguindo este conceito, a ferramenta WebCASE foi desenvolvida para auxiliar as etapas iniciais da engenharia de software através da elaboração de diagramas de casos de uso e permitir a interação e colaboração entre os responsáveis. Tendo em vista que a versão inicial da WebCASE contemplava uma parte dos processos existentes durante a modelagem de um software, este projeto apresenta a extensão e evolução da ferramenta através da inclusão e integração de três novas funcionalidades: (i) permitir a especificação de requisitos (requisitos funcionais, não-funcionais e regras de negócio), (ii) elaboração de diagramas de atividades e (iii) a geração de matrizes de rastreabilidade entre requisitos funcionais, casos de uso e regras de negócio. A ferramenta conta ainda com um módulo para importação de arquivos XMI (XML-based Metadata Interchange – Intercâmbio de metadados baseado em XML) gerados pela ferramenta Enterprise Architect 6.5, tornando rápida a migração de informações entre estas aplicações. Entre os diferenciais da ferramenta WebCASE pode-se citar a utilização de recursos open-source que reduzem custos tanto no desenvolvimento, utilização e principalmente pelo fato de ser uma ferramenta desenvolvida para a plataforma Web. A execução e desenvolvimento deste projeto de pesquisa justificam-se por contemplar diversas áreas da Ciência da Computação (e.g., Programação, Engenharia de Software, Banco de Dados) e por possibilitar a evolução de um projeto acadêmico de grande importância, não somente pela inclusão de conceitos até então ausente em ferramentas CASE, mas também como um instrumento de auxílio à disciplina de Engenharia de Software. Palavras-chave: Requisitos de software. Diagrama de atividades. Matriz de rastreabilidade. viii
  10. 10. ABSTRACT A software is composed by many activities that allow assess it progress and guarantee all tasks involved to solve the main problem. Keep information organized in a shared environment, making it easier to manage and track changes. As results it’s possible to negotiate compromises, improve estimates of term and also reduce failures and increase satisfaction both for client and company responsible for the project. The CASE Tools allow perform the activities involved in the software process in a higher specification level with emphasis on analysis and project with more quality and productivity. Using Cases tools facilitates human understanding and communication where the technique employed for representation must be able to explain and simplify all the steps involved in the process by stakeholders, including information for their improvement and real use. The WebCASE tool was developed with the purpose to give support for software engineering through the construction of use case plus the part of interaction and collaboration among stakeholders, with communication through chat rooms. Once the WebCASE tool embraces only part of the processes of software modeling, this paper's proposal is to evolve the tool through the inclusion and integration of three new features, as means to permit the specification of requirements, activity diagrams and relationship matrix between requirements and use cases. WebCASE also includes a module to import XMI (XML-based Metadata Interchange) files, generated by the Enterprise Architect 6.5 Tool, making fast the import of information between these tools. Among the differentials of WebCASE can site the use of open source resources that reduce the cost both in development and use, because it’s a tool developed to the Web platform.The execution and development of this research project are justified for reaching many Computer Science areas, such as Programming and Software Engineering, as well as for allowing the evolution of an important academic project, not only due to the inclusion of concepts as yet absent in CASE tools, but also because it is a support instrument to the Software Engineering subject. Keywords: Software requirements. Activities diagram. Traceability matrix. ix
  11. 11. 1 INTRODUÇÃO O aprimoramento de técnicas relacionadas ao gerenciamento de projetos, tem sido fortemente discutido nas mais diversas áreas relacionadas à engenharia de software. Segundo Fernandes (2005), um dos principais fatores para a obtenção de sucesso no desenvolvimento de software, está em realizar uma boa documentação e especificação dos problemas a serem solucionados. Para isto é necessário que um software passe por uma análise detalhada, dividindo-o em subproblemas de forma organizada a fim de encontrar os requisitos necessários para seu pleno funcionamento. Para Gustafson (2003), um software possui um ciclo de vida formado por atividades seqüenciais denominadas milestones, onde são produzidos diversos artefatos (e.g., contratos, avaliações, códigos fontes, documentação para os usuários) com a finalidade de avaliar o progresso de desenvolvimento do sistema. Seguindo estes conceitos é possível analisar sua natureza e complexidade, para mais tarde sintetizar os módulos definidos com maior clareza e menor probabilidade de reestruturação durante o desenvolvimento. Como vantagens podem-se citar a redução de custos na gestão dos recursos necessários e a estimativa de prazos dentro de um limite tolerável de tempo, existindo maior satisfação para o cliente e equipe responsável pelo projeto (PFLEEGER, 2004). Pesquisas realizadas nesta área comprovaram que uma boa engenharia e documentação, resultam em produtos melhor sucedidos e menos propícios a falhas, mesmo existindo um aumento no tempo necessário para seu planejamento (ibidem). De acordo com Pfleeger (2004) uma maneira eficiente de determinar os requisitos é identificar seus casos de uso, já que estes elementos estão fortemente interligados. Para Braude (2005 apud Rech, 2007) um caso de uso descreve de forma simplificada as variadas ações de uma tarefa dentro de uma aplicação específica, definindo as ações necessárias com base nas diversas condições encontradas para sua realização. A etapa de identificação dos casos de uso pode ser auxiliada pela elaboração de diagramas de atividades, que servem para demonstrar o fluxo dos processos existentes em sistemas. Conforme citado por Jacquart (2004), o Standish Group, grupo responsável por realizar investigações de aplicações críticas, conduziu pesquisas na área de projetos de software em mais de 350 empresas e em mais de 8000 projetos. Estas pesquisas apontaram que cerca de 30% dos projetos eram abandonados antes mesmo de terem sido concluídos e apenas 16% eram entregues
  12. 12. dentro do prazo estipulado. Entre os fatores de insucesso, merecem destaque a má especificação e a modificação dos requisitos durante a etapa de modelagem. Quatrani (2000) apresenta um conceito sobre a importância de uma boa definição em um projeto, denominado de Triângulo do Sucesso. Para que um projeto seja bem sucedido é necessário definir três pontos que devem estar fortemente atrelados entre si: processo, notação e ferramenta. O processo define a parte responsável pela correta compreensão do problema, a notação é responsável pela comunicação entre os envolvidos no processo e a ferramenta atua como um quadro de comunicação, permitindo analisar e descrever os processos necessários. Atualmente as empresas e responsáveis por projetos de software adotam o uso de ferramentas CASE (Computer-Aided Software Engineering – Engenharia de Software Auxiliada por Computador). Estas ferramentas fazem uso de elementos gráficos e linguagem padrão, normalmente a UML (Unified Modeling Language – Linguagem de Modelagem Unificada), para projetar softwares de forma completa (PFLEEGER, 2004). A utilização de ferramentas CASE tem como característica facilitar a compreensão e a comunicação, onde a técnica empregada para representação das informações deve ser capaz de expor e simplificar as etapas envolvidas no processo (SILVA; ROCHA, 1998). Quatrani (2000) aponta a interação entre os envolvidos (e.g., desenvolvedores, analistas, clientes) como tarefa fundamental realizada desde o início do projeto, definindo como os problemas e processos serão resolvidos, transformando-os em operações realizadas pelo computador através de um software. Com a internet novos conceitos surgiram para a comunicação e realização de tarefas, de forma descentralizada e geograficamente distribuída, denominada modelo de comunicação colaborativa (COLOSSI; QUEIROZ; CONSENTINO, 2001). Este modelo permite que a interação entre as pessoas continue de forma produtiva, existindo cooperação e coordenação por parte dos participantes em um espaço de trabalho compartilhado, através da negociação de compromissos e conhecimento (GEROSA; RAPOSO; FUKS, 2002). As ferramentas existentes no mercado para modelagem de sistemas, nem sempre possuem uma maneira simples e flexível de realizar o compartilhamento das informações entre os envolvidos em um projeto de software. Como alternativa a este cenário, o acadêmico do curso de Ciência da Computação da Universidade do Vale do Itajaí, Vagner Rech, desenvolveu uma ferramenta CASE em seu trabalho de conclusão de curso no ano de 2007. Como característica principal, a ferramenta denominada WebCASE reúne a parte de comunicação e planejamento de projetos de software em um único ambiente (RECH, 2007). 11
  13. 13. Segundo Rech (2007), o objetivo da ferramenta WebCASE consiste em suprir algumas necessidades relacionadas à colaboração entre usuários e analistas durante a modelagem de um sistema através da Internet, para acelerar os processos de correção e aceitação por parte do cliente. A WebCASE foi desenvolvida com o propósito de auxiliar a engenharia de software através da documentação de diagramas de casos de uso contendo atores, cenários, pré-condições, póscondições, histórico de atualizações, comunicação entre os usuários, através de salas de bate papo (chats) e aprovação dos casos de uso pelos clientes. Sua utilização estende-se como uma ferramenta de apoio ao ensino da disciplina de Engenharia de Software, para permitir uma melhor visão do negócio e facilitar a compreensão dos diagramas de caso de uso, visto que muitas das ferramentas existentes no mercado possuem alto custo para aquisição. Sabendo-se que a versão inicial da ferramenta WebCASE contempla somente uma das etapas existentes na modelagem de software, a proposta deste trabalho consiste na evolução da ferramenta através da inclusão de três novos módulos: (i) módulo para especificação de requisitos (requisitos funcionais, não-funcionais e regras de negócio); (ii) módulo para elaboração de diagrama de atividades; e (iii) módulo para geração de matriz de rastreabilidade entre: requisitos funcionais, casos de uso e regras de negócio; Através da especificação dos requisitos e regras de negócio, é possível descrever as principais funcionalidades e recursos de um software, definindo o que ele poderá fazer além de relacionar suas restrições e aspectos pertinentes ao negócio (SOMMERVILLE, 1997 apud QUIRINO, 2005). Os requisitos podem ser divididos em dois grupos: (i) os funcionais que descrevem as funcionalidades do software, o que ele irá executar; e (ii) os não-funcionais, utilizados para descrever aspectos relacionados às necessidades envolvidas em relação aos usuários e equipamentos (e.g., usabilidade, desempenho, confiabilidade, hardware, segurança) (CONALLEN, 2003 apud QUIRINO, 2005). A elaboração de um diagrama de atividade tem como objetivo demonstrar o fluxo seqüencial das ações em um processo do sistema, possibilitando de maneira alternativa expressar como, quando e onde elas acontecem. Sua representação é feita utilizando-se elementos gráficos visuais, entre os principais podem ser citados os estados iniciais, estados finais, atividades e elementos de decisão que permitem decidir um fluxo alternativo para uma determinada ação (LIMA et al., 2000). 12
  14. 14. Uma forma de verificar se os requisitos de software encontram-se contemplados pelos casos de uso é através da rastreabilidade entre estes elementos. Utilizando as matrizes de rastreabilidade é possível visualizar o relacionamento entre os componentes do projeto (e.g., requisitos funcionais, não-funcionais, regras de negócio, casos de uso) (KOTONYA; SOMMERVILLE 1997 apud QUIRINO, 2005). 1.1 PROBLEMATIZAÇÃO 1.1.1 Formulação do Problema Tratando-se de projetos de software, a utilização de ferramentas CASE colaborativa para auxiliar de forma eficiente a produção de sistemas, possui diversos fatores a favor, já que muitas das etapas existentes podem ser executadas pelos envolvidos durante o processo. Existem hoje no mercado, diversas ferramentas disponíveis para a elaboração de diagramas de atividades e para a especificação de requisitos, porém o acesso descentralizado e em tempo real permanece um tanto quanto ausente, pois muitas vezes as informações necessitam ser desmembradas da ferramenta em que foram projetadas, para posteriormente serem avaliadas pelas equipes envolvidas. 1.1.2 Solução Proposta A execução e desenvolvimento deste projeto de pesquisa justificam-se por contemplar diversas áreas da Ciência da Computação, como Programação e Engenharia de Software, bem como por possibilitar a evolução de um projeto acadêmico de grande importância não somente pela inclusão de conceitos ausentes na ferramentas, mas também como um instrumento de auxílio à disciplina de Engenharia de Software. 1.2 OBJETIVOS 1.2.1 Objetivo Geral Integrar novas funcionalidades à ferramenta WebCASE, para permitir a especificação de requisitos, modelagem de diagramas de atividades e geração de matrizes de rastreabilidade entre os elementos (requisitos funcionais, regras de negócio e casos de uso). 13
  15. 15. 1.2.2 Objetivos Específicos • Pesquisar e analisar soluções similares de ferramentas de modelagem; • Analisar e compreender o funcionamento da ferramenta WebCASE; • Pesquisar os conceitos e tecnologias necessárias à continuidade do projeto; • Estudar os conceitos relacionados ao gerenciamento, especificação e processos da engenharia de requisitos; • Estudar a notação UML com ênfase nos diagramas de atividades; • Determinar os requisitos exigidos pelo sistema; • Realizar a modelagem conceitual do sistema; • Implementar o sistema; • Módulo para modelagem de Diagrama de Atividades; • • Atividades; • Bifurcação (fork); e • • Nó inicial e final; Nó de decisão. Módulo para especificação de requisitos, e regras de negócio; • • Status/Prioridade/Estabilidade/Dificuldade; • Cadastro de tipos de requisito; e • • Descrição Requisito/Identificadores; Aprovação/Rejeição pelo cliente. Matriz de Rastreabilidade • • • Rastreabilidade entre requisitos funcionais, regras de negócio e casos de uso; Importação de informações geradas pela ferramenta Enterprise Architect versão 6.5 através da especificação XMI 2.1 (XML-based Metadata Interchange – Intercâmbio de metadados baseado em XML) para diagramas de atividades e requisitos de software. Testar e validar a implementação do sistema através de um caso de teste aplicado aos alunos da disciplina de engenharia de software do curso de Ciência da Computação da UNIVALI, para validar a usabilidade de todas as funcionalidades e conformidade dos requisitos e regras de negócio; e • Documentar o desenvolvimento e os resultados alcançados. 14
  16. 16. Metodologia Para a realização do presente projeto, sua estrutura foi dividida em seis grandes etapas listadas abaixo: • Levantamento bibliográfico: Estudo das funcionalidades a serem adicionadas na ferramenta, a fim de contemplar os requisitos propostos. Os conceitos envolvidos no projeto são documentados nesta etapa, para permitir maior clareza e viabilizar sua conclusão. • Fundamentação sobre os processos envolvidos na engenharia de requisitos, juntamente com a relação das funcionalidades já presentes na ferramenta WebCASE e estudo das características presentes na especificação de software segundo o padrão IEEE 830-1998; • Fundamentação teórica sobre gerenciamento, mudanças de requisitos e metodologias aplicadas ao rastreamento de requisitos de software através das matrizes de rastreabilidade; • Fundamentação teórica sobre a estrutura e elementos presentes nos diagramas de atividades definidos pela UML; e • Pesquisa de ferramentas similares existentes no mercado com as novas funcionalidades propostas, para permitir melhor comparação e especificação dos requisitos seguindo características presentes em ferramentas CASE. • Análise Técnica: Estudo da ferramenta WebCASE com o objetivo de compreender seu funcionamento, verificando as necessidades para se adaptar ao requisitos deste projeto e analisando as tecnológicas envolvidas no ambiente proposto, suas particularidades e compatibilidades. • Execução da ferramenta, estudo da documentação e códigos fontes disponíveis; • Estudo das tecnologias utilizadas na ferramenta: JSON (JavaScript Object Notation – Notação de Objetos em JavaScript), framework Ext JS, JavaScript, PHP e MySQL; e 15
  17. 17. • Pesquisa do padrão para gerenciamento de objetos e troca de informações baseadas no padrão XML (Extensible Markup Language – Linguagem de Marcação Extendida) em ferramentas de modelagem UML através da especificação XMI. • Levantamento de Requisitos e Modelagem: Definição dos requisitos e funcionalidades da ferramenta proposta. • Definição dos requisitos e regras de negócio necessário para contemplar o funcionamento do sistema proposto; • Modelagem UML do sistema seguindo as metodologias apresentadas em livros. A análise deverá abranger a especificação e componentes de software necessários para adicionar os módulos propostos no escopo do trabalho. Para isto serão modelados e alterados se preciso, os casos de uso, diagramas de classe e diagramas de atividades; e • Alteração do modelo ER (Entidade Relacionamento) para o banco de dados com o objetivo de se adaptar às novas funcionalidades da ferramenta. • Desenvolvimento: Desenvolvimento do sistema, ou seja, alteração da solução existente, que posteriormente passará por testes e validação. • Alteração da estrutura do banco de dados, adicionando novas tabelas para suprir as necessidades do sistema; e • Implementação dos módulos propostos de acordo com a definição dos requisitos. Todo o desenvolvimento deve seguir a modelagem realizada e as funcionalidades descritas no escopo do trabalho. • Testes e Validação: Realização de testes e validações sobre a solução proposta, verificando suas funcionalidades e corrigindo-as caso seja necessário. • Realização de testes das novas funcionalidades com alunos do curso de Ciência da Computação da UNIVALI, que estejam cursando uma das disciplinas de engenharia de software. Serão avaliados os novos serviços implementados, analisando se os mesmos alcançaram os resultados esperados; e 16
  18. 18. • Testes de integração com as funcionalidades existentes, através da definição e aplicação de um estudo de caso para certificar-se que a ferramenta executa suas funções inicialmente propostas nesta nova versão. • Documentação: Ao longo do projeto são registrados os passos executados desde o levantamento do problema, a fundamentação teórica, a proposta de uma nova solução, o desenvolvimento, testes, validações, os resultados finais e conclusões. Essa documentação deve permitir que outros pesquisadores possam compreender a solução, acrescentar novas funcionalidades em versões futuras e efetuar os mesmos experimentos e testes feitos para sua validação. 1.3 Estrutura do trabalho No primeiro capítulo é apresentada uma introdução sobre o projeto, objetivos e a devida importância na área de Ciência da Computação, como uma ferramenta para facilitar o estudo da engenharia de software e auxiliar analistas de sistema nas etapas iniciais em projetos de software. No segundo capítulo (Fundamentação Teórica), são definidos os principais conceitos relacionados ao projeto, tecnologias e funcionalidades presentes na fase atual da ferramenta WebCASE, conflitos encontrados entre o modelo teórico e implementação para facilitar a compreensão das etapas descritas, além de ser realizado um estudo sobre algumas ferramentas similares disponíveis. O terceiro capítulo (Projeto) descreve as fases envolvidas no desenvolvimento das novas funcionalidades à ferramenta WebCASE, sua documentação, diagramas de atividade da UML, requisitos e regras de negócio, diagrama de classes e modelo ER do banco de dados com a nova estrutura contendo as modificações realizadas para suprir as necessidades da nova versão. No quarto (Implementação) e quinto (Apresentação da Ferramenta) capítulo são apresentados os resultados obtidos durante a implementação dos módulos propostos, descrevendo o as funcionalidades implementadas. O sexto capítulo apresenta os resultados dos testes aplicados com alunos do curso de Ciência da Computação para avaliar a usabilidade e conformidade dos requisitos e verificar o funcionamento da ferramenta nos principais navegadores. 17
  19. 19. O sétimo e último capítulo apresenta as conclusões, dificuldades encontradas durante o desenvolvimento e sugestões para trabalhos futuros que possam aprimorar e expandir as funcionalidades presentes na ferramenta. 18
  20. 20. 2 FUNDAMENTAÇÃO TEÓRICA Neste capitulo são estudados e analisados os conceitos envolvidos no projeto de acordo com a proposta inicial e assim servir como base para seu desenvolvimento. A seção 2.1 apresenta um estudo técnico sobre a ferramenta WebCASE, suas funcionalidades e tecnologias utilizadas. Na seção 2.2 são apresentados os problemas e motivações da necessidade de gerenciar projetos de software, a definição de requisitos, a engenharia de requisitos abordando seus quatro processos, algumas das principais técnicas utilizadas no reconhecimento de requisitos e as principais características propostas pelo padrão IEEE 830-1998 para especificação de requisitos. Na seção 2.3 são apresentados os fundamentos sobre diagramas de atividades da UML juntamente com a notação dos seus elementos. Por fim, na seção 2.4, são exemplificadas algumas ferramentas CASE disponíveis no mercado, com as características presentes no foco deste trabalho através de uma tabela comparativa. 2.1 Análise técnica da Ferramenta WebCASE Com o propósito de analisar e compreender a ferramenta WebCASE, realizou-se um estudo de seu funcionamento, documentação, funcionalidades presentes na versão inicial, integração dos novos objetivos com os já existentes, além da modelagem conceitual e tecnologias utilizadas no desenvolvimento. Esta análise visa verificar as possíveis implicações e modificações necessárias para atender as necessidades dos novos módulos propostos que estarão presentes ao final deste projeto. 2.1.1 Funcionalidades Desenvolvida para auxiliar no processo de modelagem de casos de uso em projetos de software, a ferramenta WebCASE permite que desenvolvedores, analistas e clientes, interajam de forma descentralizada e colaborativa em um projeto durante as etapas iniciais de elaboração, mantendo um histórico de atualizações e permitindo trabalhar de forma concorrente sobre um mesmo projeto (RECH, 2007). 19
  21. 21. A ferramenta WebCASE possui opções diferenciadas de acordo com o tipo de usuário autenticado (cliente, analista e administrador). As seções seguintes foram baseadas no trabalho de conclusão de curso do acadêmico Vagner Rech e apresentam as funcionalidades presentes na ferramenta em sua versão inicial (RECH, 2007). 2.1.1.1 Perfil de usuário O controle de acesso e realizado por nível de usuário divididos em três categorias, cada qual com suas devidas permissões. • Administrador: É o perfil com maior número de funcionalidades dentro do sistema. Permite consultar, cadastrar, alterar e excluir administradores e analistas (Figura 1), gerenciar projetos e definir os analistas responsáveis pelos mesmos. Um administrador pode executar as funcionalidades presentes no perfil Analista, mas não do perfil Cliente; • Analista: Grupo de usuários que podem abrir projetos, adicionar e remover pacotes, cadastrar clientes, modelar e desenhar diagramas de casos de uso com seu respectivo detalhamento, além de permitir importar diagramas de casos de uso da ferramenta Enterpise Architect versão 6.5 através de arquivos XMI na versão 2.1; e • Cliente: Este é o perfil de usuário com o menor número de funcionalidades disponíveis, entre suas ações estão à aprovação e rejeição de casos de uso, realização de anotações e participação no sistema de bate papo presente na ferramenta. 20
  22. 22. Figura 1. Cadastro de administradores/analistas. 2.1.1.2 Desenhar e detalhar diagramas de casos de uso Módulo principal do sistema (Figura 2) permite aos analistas de um projeto criar os diagramas inserindo casos de uso, atores e realizar a associação entre os elementos (associação, generalização, inclusão e extensão). Figura 2. Exemplo de um diagrama de casos de uso. 21
  23. 23. Em relação ao nível de detalhamento (Figura 3), é possível inserir informações sobre cada caso de uso como cenários, observações, condições e a liberação para aprovação pelo cliente. Existe na ferramenta um controle que permite a edição de um caso de uso por apenas um analista simultaneamente até que o mesmo seja liberado. Figura 3. Tela de detalhamento de um caso de uso. 2.1.1.3 Gerenciar Projetos Permite aos usuários com perfil administrador adicionar novos projetos ou excluir projetos existentes. Conforme apresentado na Figura 4, no momento da inclusão de um novo projeto, é possível definir quais serão os analista já cadastrados, que participarão do projeto, podendo ainda para um analista participar de diversos projetos. 22
  24. 24. Figura 4. Gerenciamento de projetos. 2.1.1.4 Bate Papo (chat) A ferramenta conta com um sistema de chat para facilitar a comunicação entre os usuários, sem a necessidade de utilizar um sistema externo. Este fator é relevante já que a colaboração é uma das características presentes na WebCASE. A Figura 5 apresenta a tela do chat que permite aos usuários da ferramenta WebCASE, acessar o sistema de bate papo, visualizar e trocar mensagens (on-line). As mensagens enviadas ficam armazenadas mantendo um histórico das conversas realizadas. 23
  25. 25. Figura 5. Chat agregado a ferramenta WebCASE. 2.1.1.5 Importação de arquivos XMI A importação de diagramas de caso de uso de outras ferramentas é feito através do módulo de importação utilizando arquivos no padrão XMI 2.1. Atualmente existe apenas suporte para importação de arquivos gerados pela ferramenta Enterprise Architect na versão 6.5, sendo esta restrição mantida neste projeto. 2.1.1.6 Aprovação de casos de uso Após um caso de uso ter sido liberado por um analista, é permitido ao cliente acessar um dos projetos em que se encontra cadastrado e assim aprovar ou rejeitar o caso de uso, adicionando se preciso um comentário para o analista (Figura 6). 24
  26. 26. Figura 6. Aprovação de Casos de Uso pelo cliente. 2.1.2 Modelo conceitual e estrutura física do banco de dados Uma importante etapa na análise da ferramenta consiste no estudo das classes e estrutura do banco de dados presente na primeira versão ( Figura 7). Na seqüência é apresentado um breve detalhamento do modelo de diagrama de classes da ferramenta, com o objetivo de identificar sua utilização. 25
  27. 27. Figura 7. Modelo de classes original da ferramenta WebCASE. Fonte: Rech (2007). A seguir são descritas as classes presentes no modelo proposto por Rech (2007) desenvolvidas tanto do lado cliente utilizando-se a linguagem JavaScript quanto do lado servidor através da linguagem PHP. • wcObject: Responsável por definir os atributos e métodos comuns a todas as demais classes existentes no modelo. Entre as operações possíveis estão: inserir, atualizar, remover, listar informações de acordo com o objeto. Na Figura 8, um objeto do tipo wcElement é criado conforme o parâmetro passado ao método setTable na linha 12 e seus atributos enviados na linha 14 para o método insert da classe wcObject, responsável por gravar as informações no banco de dados. Isto permite que através de uma única classe qualquer ação possa ser realizada no meio de persistência. Estas classes 26
  28. 28. encontram-se implementadas tanto do lado servidor através do arquivo wcObject.class.php quanto do lado cliente através do arquivo object.js; Figura 8. Exemplo de código para inserir informações no banco de dados. • wcElement: Para qualquer elemento adicionado a um pacote a classe wcElement herdada da classe wcObject é responsável por representar as características básicas de um elemento como descrição, dimensões, posicionamento na tela. Encontra-se implementada do lado cliente no arquivo package.js, contendo os métodos comuns de manipulação de elementos do pacote (e.g., caso de uso, atores), permitindo posicionar, redimensionar e gravar os atributos para cada elemento. No modelo de classes atual existem apenas duas classes especialistas de wcObject dentro do arquivo package.js já que somente casos de uso e atores estão presentes na ferramenta e representadas por wcUseCase e wcActor; • wcUseCase: Responsável por definir um caso de uso que necessariamente deve estar presente em um projeto. • wcActor: Representar um ator dentro de um pacote, onde todas as suas propriedades são herdadas de wcElement e não possui informações adicionais. Em sua implementação existem métodos específicos para adicionar e renomear um ator. • wcUser: Classe herdada da classe wcObject é responsável por definir um usuário do sistema formada por atributos que definem as principais características presentes nos três tipos de usuários da ferramenta (administrador, analista e cliente) e os métodos que 27
  29. 29. permitem realizar as funções de acordo com o perfil de acesso de cada usuário. Encontra-se implementada no lado servidor através do arquivo wcUser.class.php para permitir pesquisar e controlar as informações de um usuário no banco de dados e no lado cliente implementada no arquivo user.js, responsável por criar as requisições que serão encaminhadas para o servidor de aplicação; • wcAdministrator: Classe especialista de wcUser responsável por definir as operações de um administrador do sistema como, manter projetos, cadastrar e definir os analistas do mesmo. Conforme a modelagem inicial, encontra-se implementada somente do lado cliente no arquivo adm.js, porém ao invés de estender da classe wcAnalyst de acordo com o modelo esta estendendo da classe wcUser; • wcAnalyst: Classe especialista de wcUser, é responsável por adicionar funcionalidades aos analistas de um projeto, permitindo desenhar, detalhar casos de uso e cadastrar clientes em um projeto. Encontra-se implementada somente no lado cliente no arquivo analyst.js; • wcClient: Classe especialista de wcUser responsável por representar um cliente do sistema, possui a funcionalidade de aprovar, rejeitar e comentar os casos de uso de um projeto vinculado a este cliente pelo analista. Encontra-se implementada no lado cliente no arquivo client.js; • wcProject: Classe responsável por representar um projeto criado na ferramenta, como também herda da classe wcObject possuindo um único atributo para armazenar a descrição de um projeto. Permite adicionar pacotes, definir clientes e analistas presentes em um projeto. Implementada do lado servidor através da classe wcProject.class.php, é responsável por criar objetos que serão inseridos no banco de dados, já no lado cliente encontra-se modelada no arquivo project.js, que possui todas as funcionalidades relacionadas aos projetos; • wcPackage: Permite representar um pacote ou adicionar novos pacotes e casos de uso a um projeto. A existência de subpacotes não é necessária, mas para poder inserir casos de uso e atores é necessário que exista ao menos um pacote. Esta classe encontra-se implementada do lado cliente através do arquivo package.js que possui todas as operações possíveis em um pacote. Nesta classe existem diversas funções responsáveis 28
  30. 30. por tratar as operações realizadas em um pacote como movimentação de elementos na tela (e.g. drag and drop), redimensionamento, relacionamento entre elementos, criação e remoção do pacote, etc; • wcConstraint: Classe responsável por representar as pré-condições e pós-condições de um caso de uso. Encontra-se desenvolvida no lado cliente dentro do arquivo analyst_dialogs.js, entre seus métodos estão montar e exibir as telas para cadastro de condições de um caso de uso; • wcScenario: Representa um cenário presente em um caso de uso, também possui um atributo para adicionar uma descrição e outro para informar o tipo de cenário (e.g., principal, alternativo, exceção) e está implementada dentro do arquivo analyst_dialogs.js contendo os métodos para exibir e cadastrar a tela de cenários de um caso de uso; e • wcLink: Classe responsável por representar e definir o tipo de conexão pelo atributo mode (e.g., associação, inclusão, exceção) entre dois objetos da classe wcElements. Sua implementação no lado cliente foi realizada dentro do arquivo package.js que possui como funcionalidades, desenhar, remover, verificar o tipo de conexão entre os elementos e adicionar um texto informando o tipo de conexão representada. A classe de importação e tratamento de arquivos XMI encontra-se implementada, porém não referenciada dentro do modelo de classes da ferramenta WebCASE. Representada pelo arquivo wcXMI.class.php no lado servidor, é responsável por tratar o arquivo escrito em XML e inserir as informações no banco de dados para serem acessadas através de um projeto; Segundo Rech (2007) um framework de persistência de dados foi desenvolvido com o objetivo de acelerar e facilitar manutenções nos processos de consulta ao banco de dados, utilizando os conceitos de orientação a objeto, o framework é formado por seis classes, apresentadas no diagrama da Figura 9 e descritas abaixo: 29
  31. 31. Figura 9. Framework para conexão ao banco de dados da ferramenta WebCASE. Fonte: Rech (2007). • wcDBConfig: Classe responsável por armazenar as informações de conexão com o banco de dados como usuário, senha, host e database; • wcDBConnection: Classe responsável por realizar a conexão com o banco de dados utilizado pela ferramenta WebCASE, possui funções para abrir, fechar e selecionar a conexão ativa com o banco de dados; • wcFields: Classe que salva os campos retornado de uma consulta ao banco de dados ou os campos que serão inseridos através de um comando insert ou update; 30
  32. 32. • wcDBQuery: Classe responsável por executar as instruções SQL, é formada por dois métodos, um para realizar consultas e outro para inserir, remover e editar informações no banco de dados; e • wcMySQL: Classe que realiza a conexão com o banco de dados MySQL. Na Figura 10 é apresentado o DER (Diagrama Entidade Relacionamento) do banco de dados da ferramenta WebCASE, onde a descrição das tabelas geradas é exemplificada na seqüência. Figura 10. Modelo ER da ferramenta WebCASE. Fonte: Rech (2007). • wcPackage: Armazena os pacotes ou subpacotes existentes em um projeto para permitir modelar um diagrama de casos de uso na ferramenta. Apesar de não estar presente no 31
  33. 33. modelo lógico, esta entidade conta com um campo identificador (package_ea_id), utilizado nos caso de importação de um arquivo XMI; • wcElement: Armazena os elementos da UML (para a fase atual existem os casos de uso e atores) de um diagrama de caso de uso. O campo identificador (element_ea_id), utilizado em uma importação de arquivo XMI, encontrava-se presente somente no modelo físico do banco de dados; • wcProject: Entidade que armazena os projetos cadastrados na ferramenta, é formado pelo nome e descrição do projeto; • wcProjectHasWcUser: Entidade gerada a partir da relação de wcProject e wcUser, permite relacionar um usuário do sistema a vários projetos; • wcUser: Entidade responsável por armazenar as informações dos usuários com acesso ao sistema, como analistas, clientes e administradores; • wcLink: Armazena o relacionamento e tipos de associação (e.g., associação, inclusão, extensão) utilizados entre casos de uso e atores; • wcClientComment: Armazena os comentários realizados pelos clientes em um caso de uso juntamente com a data da realização do mesmo. No modelo lógico, esta entidade possui uma chave estrangeira para a entidade wcElement, porém no modelo físico do banco de dados encontra-se relacionada à entidade wcHistoricalElement; • wcHistoricalElement: Armazena informações de quem e quando realizou modificações nos elementos (casos de uso e atores). Quando um caso de uso é aprovado, um novo histórico é gerado, mantendo um histórico das modificações realizadas no seu escopo. • wcConstraint: Armazena as pré-condições e pós-condições dos casos de uso. Cada condição, relaciona-se somente a um caso de uso e é formada pelo tipo da condição e a respectiva descrição; e • wcScenario: Define um cenário pertencente a um único caso de uso, armazenando o nome do cenário, tipo e descrição. 32
  34. 34. 2.1.3 Tecnologias Projetada para ser executada na plataforma web, independente do sistema operacional, a ferramenta WebCASE foi desenvolvida utilizando-se de tecnologias modernas e conceitos recentes, (e.g., Web 2.0, RIA (Rich Internet Applications – Aplicações Ricas para Internet)). Para acessar o sistema é necessário apenas um computador conectado ao servidor de aplicação e um navegador web como o Firefox (2.0 ou superior) ou Internet Explorer (5.5 ou superior). Navegadores web ou Web Browsers são aplicações executadas em um computador (cliente), que permitem exibir conteúdos dinâmicos de páginas disponibilizadas em outros computadores (servidores). Seu acesso pode ser realizado de duas formas, através de uma rede local ou através de conexões remotas pela internet, que utilizam como meio de comunicação um protocolo de transferência de hipertexto (COSTA, [200-?]). São explicadas, na seqüência, as tecnologias utilizadas no desenvolvimento da ferramenta, tanto do lado cliente quanto do lado servidor. Vale ressaltar que a maioria das soluções presentes são open-source1 e de grande utilização e aceitação pelos desenvolvedores com foco em aplicações web. 2.1.3.1 Servidor Web Para permitir a comunicação entre cliente e servidor de aplicação (Figura 11), foi utilizado o servidor Web Apache2, responsável por disponibilizar o sistema através da internet ou intranet. Este serviço utiliza-se do protocolo HTTP (Hypertext Transfer Protocol – Protocolo de Transferência de Hipertexto) para responder as requisições dos usuários, além de permitir a execução de aplicações CGI (Common Gateway Interface - Interface Comum de Saída) e linguagens de scripts, como PHP (Hypertext Preprocessor) e JSP (Java Server Pages) (ALECRIM, 2006). 1 Software de utilização livre e sem custos com liberdade para adaptação e distribuição de cópias, permitindo também modificar o código-fonte e disponibilizar de forma gratuita para toda a comunidade com o objetivo de beneficiar a todos os usuários e desenvolvedores. (SEABRA, 2007) 2 Disponível em: http://www.apache.org 33
  35. 35. Figura 11. Comunicação entre cliente servidor através de um navegador Web. Fonte: Adaptado de STREIBEL (2005). 2.1.3.2 Linguagem de programação A linguagem de programação adotada, o PHP3 (Hypertext Preprocessor) versão 5.0, consiste em uma linguagem de script interpretada no lado servidor, que permite disponibilizar conteúdos dinâmicos e interagir com os usuários através de formulários presentes nas páginas web, conforme o esquema apresentado na Figura 11 (COSTA, [200-?]). Como diferenciais presentes no PHP em relação a algumas outras linguagens para a Web, podem-se citar (DEXTRA SISTEMAS, 2008): • Disponível para os mais diversos sistemas operacionais existentes (e.g., Windows, Mac OS, Linux, Solaris). Atualmente é suportado pelos principais servidores de aplicação (e.g., Apache, IIS (Microsoft Internet Information Service), Xitami, Netscape); 3 Disponível em: http://www.php.net/ 34
  36. 36. • O suporte a grande variedade de SGBDs (Sistema Gerenciador de Banco de Dados) permite que o servidor de aplicação comunique-se com os principais e mais diversos bancos de dados existentes no mercado como PostgreSQL, MySQL, Oracle, Interbase, SQL Server e suporte ao padrão ODBC (Open Database Connectivity - Padrão Aberto de Conexões a Bancos de Dados), que permite acessar diferentes tipos de bancos de dados através de uma interface padrão; • Possui diversas bibliotecas para facilitar a leitura e escrita de arquivos textos, além de ser compatível com os principais padrões de interpretadores XML propostos pelo W3C4 (World Wide Web Consortium – Comitê Organizador da Web), como SAX (Simple Api for XML – API Simples para XML) e DOM (Document Object Model – Modelo de Documento Objeto); • A programação pode ser realizada tanto de forma procedural e seqüencial (procedimentos e funções), ou através da programação orientada a objeto (suportada nas versões mais recentes a partir do PHP 5.0), que permite desenvolver os mais diversos frameworks de aplicações RAD (Rapid Application Developlment – Desenvolvimento Rápido de Aplicações), além de permitir a integração com outras linguagens de programação como JAVA e .NET; • A geração de arquivos em PDF (Portable Document Format – Formato de Documento Portátil), manipulação de imagens, criação de animações dinâmica (i.e., on the fly) em flash, envio de e-mails e compactação de arquivos, é feita de forma simples com uma grande quantidade de funcionalidades; e • Possui suporte a diversos protocolos de comunicação como HTTP, POP (Post Office Protocol – Protocolo de Transferência de Mensagens), SMTP (Simple Mail Transfer Protocol – Protocolo de Transferência Simples do Correio), FTP (File Transfer Protocol – Protocolo de Transferência de Arquivos) até em níveis mais baixos como a abertura direta de sockets, que permite interagir com qualquer outro protocolo. 4 Disponível em: http://www.w3.org 35
  37. 37. 2.1.3.3 Banco de dados O armazenamento das informações da ferramenta WebCASE é feito utilizando-se o SGBD relacional MySQL versão 5.0 na versão open-source. Entre os principais motivos para o sucesso deste banco de dados estão à velocidade, confiabilidade e facilidade de utilização (MySQL BRASIL, 2008). Suas principais características são abordadas a seguir (MySQL BRASIL, 2008): • Todas as consultas realizadas pelo MySQL são feitas utilizando-se a linguagem SQL (Structured Query Language - Linguagem Estrutural de Consulta) definida pelo padrão ANSI/ISO SQL; • Possui grande portabilidade, desenvolvido em C e C++ é composto por diversas APIs (Application Programming Interface – Interface de Programação de Aplicativos) disponíveis nas mais diversas linguagens como Java, Eiffel, PHP, Ruby e Python, para permitir adicionar novas funcionalidades e ferramentas de suporte a este SGBD; • Suporte a multithreads, fornece mecanismos de armazenamento, controle transacional e não transacional, integridade referencial através de chaves primárias e estrangeiras, realização de consultas, atualização de dados, inserção, remoção, criação de índices para acelerar consultas. Conta ainda com um sistema de privilégios e senhas que podem ser baseadas em estações e máquinas; • Suporte a prepared statement, permite realizar consultas mais rapidamente de forma otimizada, modificando-se apenas os parâmetros. Isto ocorre devido à existência de três etapas durante a sua preparação: análise, reestruturação e execução. Utilizando-se esta funcionalidade é possível que as etapas de análise e reestruturação sejam executadas uma única vez e não sempre que a consulta é executada; • Completo suporte e ampla biblioteca de operadores, funções para manipulação de informações e subconsultas, desenvolvida de forma otimizada para se obter grande ganho em performance. Recursos para criações de views (i.e., tabelas de visualização de informações, baseadas em campos de uma ou mais tabelas), além de permitir adicionar funções de agrupamento (e.g., somatório, média, máximo, mínimo); e 36
  38. 38. • Suporte a programação diretamente no SGBD como stored procedures, funções, triggers (i.e., gatilhos disparados automaticamente após a ocorrência de um evento (e.g., inserção de dados em uma tabela)). 2.1.3.4 Interface gráfica e comunicação cliente servidor Como atrativo da ferramenta WebCASE em relação a outros sistemas web, pode-se citar a adoção do conceito RIA5. Termo utilizado pela primeira vez em 2001 pela Macromedia para definir aplicações web que seguem o estilo de aplicações stand-alone6, com alto nível de interação com o usuário (MACROMEDIA, 2003). Para tal, aplicações RIA extrapolam o padrão tradicional da Web, baseado em simples formulários HTML (Hyper Text Markup Language - Linguagem de Marcação de Hipertexto), transferindo para o cliente boa parte da implementação lógica e deixando para o servidor apenas a tarefa de conexão e manipulação de banco de dados, (MOOCK, 2007; WOOLSTON, 2006). 2.1.3.5 AJAX Um dos maiores responsáveis pelo aumento da popularidade de aplicações web com interfaces ricas foi, além da evidente necessidade de diminuir a diferença entre aplicações web e aplicações stand-alone, a popularização do AJAX (Asynchronous JavaScript And XML - XML e JavaScript Assíncrono) (BUGHI, 2007). O AJAX não pode ser considerado uma linguagem de programação, nem uma nova tecnologia, a melhor maneira de definir AJAX, segundo Mahemoff (2006), é a mistura de tecnologias providas por navegadores, como JavaScript e XML, através de solicitações assíncronas de informação. Conforme Perry (2006), as tecnologias necessárias para a utilização do AJAX são: • JavaScript, linguagem de programação embutida em páginas web que permite a criação de conteúdo dinâmico interpretada pelo navegador no lado cliente; • Modelo de representação de XML em forma de objetos manipuláveis por uma linguagem através da utilização do padrão DOM; 5 Alguns autores adotam o termo Web 2.0 para definir aplicações web com interfaces ricas (WOOLSTON, 2006) Aplicações denominadas auto-suficientes, que não dependem de softwares adicionais ou sistema operacional específico para serem executadas (TECHTERMS, 2008) 6 37
  39. 39. • Recuperação de dados assíncronos utilizando um objeto JavaScript denominado XMLHttpRequest; e • Apresentação dos dados baseadas em padrões utilizando XHTML (eXtensible Hyper Text Markup Language - Linguagem de Marcação de Hipertexto Extensível) e CSS (Cascading Style Sheets – Folhas de Estilo em Cascata). O principal componente do AJAX, o XMLHttpRequest foi implementado pela Microsoft como um objeto ActiveX do navegador Internet Explorer 5, na seqüência, o projeto Mozilla implementou uma solução compatível com o ActiveX, porém funcionando de maneira nativa para o navegador. Com o objetivo de padronizar a forma como os navegadores realizariam requisições assíncronas, o W3C incluiu o XMLHttpRequest na especificação DOM nível 3 (MAHEMOFF, 2006). Conforme apresentado na Figura 12, o funcionamento de uma aplicação que faz uso do AJAX (e conseqüentemente XMLHttpRequest) consiste em: 1. Requisição inicial pelo navegador; 2. A página completa é obtida pelo servidor (incluindo o motor AJAX) e enviada para o navegador; 3. Todas as requisições seguintes são realizadas através de chamadas de funções ao motor AJAX; 4. O motor AJAX realiza uma chamada via XmlHttpRequest ao servidor; 5. O servidor processa e envia a resposta em formato XML; e 6. O motor AJAX processa a resposta do servidor, atualiza os elementos necessários ou realiza operações com os novos dados provenientes do servidor. 38
  40. 40. Figura 12. Exemplo de comunicação utilizando AJAX Adaptado de: GARRETT (2005) Umas das formas alternativas presentes para a comunicação por AJAX entre cliente e servidor na ferramenta WebCASE é a tecnologia JSON, que ao contrário da forma usual onde as informações são transportadas como texto ou XML, elas são transmitidas e lidas como objetos JavaScript. 2.1.3.6 Biblioteca ExtJS Além do AJAX e JSON, a ferramenta WebCASE faz uso de uma biblioteca desenvolvida em JavaScript denominada ExtJS7. Voltada para a camada de apresentação, a biblioteca ExtJS permite criar e adicionar diversos componentes semelhantes aos presentes em aplicações standalone (e.g., janelas, árvores, painéis, formulários, botões, arraste de elementos). 7 Disponível em: http://www.extjs.com 39
  41. 41. Atualmente encontra-se na versão 2.1 e está presente na licença comercial ou sob as condições da licença LGPL (Lesser General Public License – Menor Licença Pública Geral). Na Figura 13 é apresentada uma tabela (grid) com dados formatados e diversas propriedades atribuídas de maneira simples utilizando a biblioteca ExtJS. O código utilizado para a geração desta tabela encontra-se disponível na Figura 14 e é apresentado na seqüência. Figura 13. Tabela de dados criada com a biblioteca ExtJS Fonte: VEDOVELLI (2007) Inicialmente deve ser criado um objeto do tipo Ext.grid.Grid (linha 31), onde todas as propriedades e atributos são passados como parâmetro na forma de objeto JavaScript no construtor do GridPanel. A definição das colunas é feita com um objeto do tipo Ext.grid.ColumnModel (linha 22), para cada coluna deve-se informar seu título (header), largura (width), se a mesma pode ser ordenada (sortable), o tipo e formato dos dados que serão apresentados. Para este exemplo foi utilizada uma estrutura auxiliar para armazenar o tipo de dado (i.e., monetário, datas, textos) de cada coluna da tabela (linhas 13 a 17). Alguns atributos adicionais podem ser informados como forçar a apresentação total dos dados na tela (forceFit), título (title), largura da tabela (width) e se a mesma será renderizada dentro de um iframe (renderTo). 40
  42. 42. Figura 14. Código para a geração de uma tabela utilizando a biblioteca ExtJS. Adaptado de: VEDOVELLI (2007) 2.1.3.7 Formato de troca de documentos Para permitir a integração da ferramenta WebCASE com outras ferramentas CASE existentes, foi adotado o padrão XMI, desenvolvido pela OMG8(Object Management Group – Grupo de Gerenciamento de Objetos) com o objetivo de padronizar o transporte de componentes entre aplicações através do XML. 8 Organização de padrões reconhecida internacionalmente, a estrutura da OMG é baseada em dois aspectos: (1) Domínios que representam diversas áreas tecnológicas, como telecomunicação, comércio eletrônico, simulação e transporte; (2) e as plataformas que trabalham na especificação de tecnologias como a UML, MOF e XMI. (BRODSKY, 1999) 41
  43. 43. Para Brodsky (1999) a diversidade de ferramentas disponíveis para projetos de software é de extrema importância, pois permite que novas metodologias sejam propostas para facilitar os negócios. Uma das vantagens em se utilizar o XML se deve a facilidade existente para a compreensão e leitura humana (RAMOS e STRECHT, [200-?]). Conforme Ramos e Strecht ([200-?]), XMI é um padrão aberto baseado em XML proposto para o intercâmbio de informações e representação de metamodelos entre aplicações de modelagem e desenvolvimento de software (e.g., versão, representação de modelos, relacionamento entre elementos). Alguns exemplos incluem: (i) ferramentas de desenvolvimento (e.g., C++, Java); (ii) ferramentas de modelagem, design, orientação a objetos e UML (e.g., Enterprise Architect, Rational Rose); e (iii) Bancos de Dados e Data Warehouses (e.g., Oracle 8i,Visual Warehouse), além de repositórios e geradores de relatórios e documentação (BRODSKY, 1999). A recomendação da OMG para a utilização do padrão XMI, tem como objetivo permitir as empresas participantes colaborar e disponibilizar um canal de comunicação, importação e exportação de informações entre as ferramentas (Figura 15). Na situação atual da XMI, cada software deve saber a respeito das funções de outras ferramentas, permitindo criar pontes para clientes que necessitam compartilhar informações entre as ferramentas. Figura 15. Pontes entre diferentes ferramentas e empresas. Fonte: Adaptado de Brodsky (1999). 42
  44. 44. 2.1.4 Considerações sobre a Ferramenta Com o estudo realizado sobre a ferramenta WebCASE foi possível avaliar a forma em que se encontra sua modelagem e implementação, proporcionando uma melhor visão e identificação de possíveis limitações que possam existir durante a alteração e adição das novas funcionalidades. Algumas discrepâncias relacionadas ao modelo ER e ao modelo de classes são apresentadas e corrigidas no capitulo 3. Como o objetivo principal deste trabalho está relacionado à adição de novas funcionalidades, só será feita a correção de falhas se ocorrerem problemas na nova versão. 2.2 Engenharia de Software Engenharia de software é a área de ciência da computação que lida com a construção de sistemas de software, sejam eles grandes ou complexos que precisam ser construídos por uma equipe ou equipes de engenheiros. Normalmente, estes sistemas de softwares existem em várias versões, e são utilizados durante vários anos (GHEZZI; JAZAYERI ; MANDRIOLI, 1991). Desde a idéia inicial até a entrega para o cliente, um software pode passar por mudanças para corrigir defeitos, reforçar funcionalidades e retirar recursos obsoletos para se adequar a um novo ambiente de trabalho (PFLEEGER, 2004). Um estudo realizado por Davis ([s.d.] apud PETERS; PEDRYCZ, 2001) apresentado na Figura 16, relata uma distribuição dos principais custos envolvidos para detectar e corrigir erros em um projeto de software, onde a existência de falhas tende a diminuir de acordo com os esforços atribuídos às etapas de pré-projeto, ou seja, quanto mais claro for o projeto, menores serão os custos envolvidos na manutenção e maior será a sua qualidade. 43
  45. 45. Requisitos Projeto 3% 7% Codificação 10% Testes de Aceitação 57% Testes da Unidade 23% Figura 16. Distribuição dos custos envolvidos em projetos de Software. Fonte: Adaptado de Peters; Pedrycz (2001). Através da engenharia de software, diversas abordagens para o desenvolvimento surgem a fim de tentar resolver estes problemas, dando origem aos modelos universais de processo de software (PETERS; PEDRYCZ, 2001). Para Mazzola (2008) os seguintes fatores devem ser considerados no processo de gerência de projeto: • O desenvolvimento de software na maioria dos casos não possui um planejamento inicial das suas funcionalidades, tornando obscuro, possíveis obstáculos que somente seriam encontrados após o início da execução do projeto. Como conseqüências a remodelagem, a perda de tempo e o aumento nos custos poderiam estar presentes, impedindo uma avaliação das metodologias empregadas no desenvolvimento; • A insatisfação é quase sempre uma das principais características resultantes ao final do projeto, isto se deve a alguns fatores como a falta de comunicação entre os envolvidos e o cliente, para definir o escopo do sistema; e • Como resultado de uma má especificação de software, o aumento no custo total, a falta de segurança e a alta manutenção, acabam fazendo com que o projeto seja descontinuado, causando prejuízos desenvolvimento quanto para os clientes. 44 tanto para as empresas envolvidas no
  46. 46. Mesmo não existindo um modelo ideal, é necessário realizar um estudo entre as diferentes abordagens a fim de encontrar o mais adequado às necessidades de um projeto, onde cada processo é formado por técnicas e ferramentas que visam facilitar sua compreensão e acelerar o processo de documentação e análise seguindo seus conceitos (PFLEEGER, 2004). Sommerville (2007) aponta quatro atividades comuns entre os diversos processos de engenharia de software existentes: • A especificação de software ou engenharia de requisitos: Tendo descrito as ações do software, é necessário definir os serviços e restrições para seu funcionamento, tornando esta atividade uma etapa crítica, já que possibilita influenciar as etapas posteriores de desenvolvimento; • O projeto e implementação: Desenvolvimento e codificação do software atendendo as especificações e requisitos; • Validação de software: Tanto durante o desenvolvimento quanto na finalização do projeto, o software deve ser testado a fim de garantir a qualidade do produto desenvolvido; e • Evolução de software: Permite que o software seja mutável e adaptável as necessidades do cliente. 2.2.1 Requisitos de Software Para Fernandes (2005) os requisitos de software definem propriedades que devem ser executadas pelo sistema, expressam características e restrições do ponto de vista da satisfação das necessidades do usuário, a fim de fornecer controle e suporte a uma tarefa específica. Filho (2001 apud QUIRINO, 2005), afirma que os critérios de aceitação de um produto estão ligados aos requisitos funcionais do sistema, pois definem as diversas propriedades e funções realizadas pelo mesmo. A necessidade de especificar os requisitos é proporcional ao tamanho do sistema, ou seja, quanto maior à complexidade envolvida, maior a necessidade de realizar uma especificação mais detalhada, aumentando a dificuldade do processo. Através dos requisitos, toda funcionalidade comportamental e não comportamental pode ser descrita e avaliada. Muitas das etapas e técnicas envolvidas são abordadas pela engenharia de requisitos, onde diversos paradigma e arquiteturas são apresentados a fim de realizar um 45
  47. 47. planejamento minucioso e completo para melhorar o desempenho de um projeto (PETERS; PEDRYCZ, 2001). Sommerville (2007) aponta duas formas de especificar requisitos. Diferenciadas pelo nível de abstração de sua descrição, permite abranger diversos tipos de leitores e assim facilitar a comunicação em grupo: • Requisitos de usuário: Utilizam linguagem mais clara e diagramas, exprimindo as idéias das funcionalidades, restrições a serem desempenhadas e os serviços que serão executadas pelo software; e • Requisitos de sistema: São mais formais e possuem menor abstração, descritos através de uma linguagem mais precisa e com maior detalhamento. São utilizados principalmente por engenheiros de software, arquitetos de sistema e desenvolvedores de software. Entre os principais desafios envolvidos no trabalho de determinar os requisitos, estão os de encontrar, comunicar e documentar de forma clara, os aspectos necessários às capacidades e condições do sistema, tanto para o cliente como a equipe envolvida no projeto (LARMAN, 2004). De forma resumida os requisitos de software podem ser divididos em requisitos funcionais, não-funcionais e regras de negócio (requisitos de domínio) (CYSNEIROS, 2008). A distinção entre um requisito funcional e um requisito não-funcional pode não ser simples, onde um requisito funcional está relacionado a algum tipo de transformação a ser realizada internamente no software, enquanto que um requisito não-funcional está relacionado à como esta transformação irá se comportar ou que qualidade deverá possuir (EAGLE, 1995; CHUNG, 2000 apud CYSNEIROS 2008). Qualquer que seja a classificação, os requisitos são formados por um conjunto de atributos que definem suas características principais (e.g., prioridade, status, descrição) e demais informações que possam vir a ser necessárias (SANTOS; VARGAS; ABREU, 2004). 46
  48. 48. 2.2.1.1 Requisitos Funcionais Os requisitos funcionais (RF) descrevem através de uma linguagem clara e escrita às funções que o sistema deverá realizar, geralmente são específicos a cada software projetado (SOMMERVILLE, 2007). Já para Pfleeger (2004) um requisito funcional é responsável por descrever a interação e comportamento existente entre o sistema e o ambiente, levando em consideração a ocorrência de uma ação ou estímulo. Quirino (2005) define um requisito funcional como uma descrição das atividades executadas de acordo com as entradas e saídas executadas em resposta a uma ação externa ao sistema. 2.2.1.2 Requisitos Não-funcionais Ao contrário dos requisitos funcionais os requisitos não-funcionais (RNF) estão relacionados às propriedades de funcionamento (e.g. confiabilidade, tempo de resposta, portabilidade, desempenho) e não as funções específicas do sistema. A importância de um RNF é oposta à de um RF onde muitas vezes existe uma maneira alternativa de se executar determinada tarefa. Já a omissão ou falha de um RNF pode comprometer o funcionamento e tornar o sistema inútil. (SOMMERVILLE, 2007). Outros fatores relacionados aos requisitos não-funcionais são as necessidades de software, hardware, linguagens de programação utilizadas, recursos financeiros e demais características que não estão relacionadas às funcionalidades do software (ibidem). Para Pfleeger (2004) um requisito não-funcional representa limitações e restrições que possam existir e que possam interferir na solução final do sistema. Entre os tipos de RNF propostos por Sommerville (2007) estão: • Requisitos de produto: Ligados ao comportamento, geralmente são relacionados ao desempenho, poder de processamento, confiabilidade, tolerância à falhas, portabilidade e usabilidade; • Requisitos organizacionais: Relacionados às políticas impostas pela organização do cliente, alguns exemplos incluem linguagem de programação e sistema operacional; e 47
  49. 49. • Requisitos externos: Requisitos voltados aos fatores externos do software, como a interoperabilidade com softwares de outras organizações e interfaces de comunicação. Com a existência de diversas categorias de RNF, Conallen (2003 apud Quirino, 2005), classifica os requisitos não-funcionais em: • Usabilidade: Relacionados principalmente a interação software x usuário. Permite que sejam definidos, como por exemplo, as telas do sistema que devem ser projetadas a fim de facilitar sua utilização; • Desempenho: Descrevem os fatores relacionados ao tempo de resposta do software. Abrangem tanto a parte de sistemas operacionais, quanto à parte de hardware utilizada pelo software; • Confiabilidade: Em sistemas críticos esta é uma característica essencial, define restrições quanto ao seu total funcionamento e tolerância à falhas, além de definir questões relacionadas à recuperação de informações; • Segurança: Definem aspectos necessários à proteção das informações do software como níveis e políticas internas da empresa para acesso aos dados; • Hardware: Apontam os requisitos e especificações de hardware, necessários ao funcionamento do software; e • Implantação: Definem aspectos a serem verificados durante a instalação e treinamento do sistema, a fim de garantir seu correto funcionamento. 2.2.1.3 Regras de Negócio Para a execução de tarefas por um software, é necessário que normas e restrições sejam definidas para atender corretamente a determinadas necessidades do negócio. Para Sommerville (2007) as regras de negócio (RN), ou requisitos de domínio, são restrições ou especificações que serão executados por uma tarefa e não como ela será executada. Já para Ross (2003 apud BUGHI, 2007) as regras de negócio são como diretivas que influenciam ou guiam o comportamento dos negócios em um sistema e são formalizadas através de uma linguagem declarativa. 48
  50. 50. Apesar da importância de definir corretamente as regras de negócio, sua compreensão pode ser acompanhada de diversos conflitos originados dos processos envolvidos na gerência de negócio e de sistemas de informação de suporte, principalmente com as mudanças dos processos ao longo dos anos (ALENQUER, 2002 apud QUIRINO, 2005). Quirino (2005) aponta o processo de definição das regras de negócio como uma atividade realizada por um analista de negócios e não pelos responsáveis em mapear os requisitos do sistema devido ao maior entendimento nos processos envolvidos. 2.2.2 Engenharia de Requisitos Uma das etapas existente na maioria dos processos da engenharia de software responsável por definir os objetivos, escopo e descrição dos requisitos é a engenharia de requisitos. Focada na análise e documentação dos problemas envolvidos em um projeto, permite avaliar o contexto e viabilidade das necessidades organizacionais do cliente (PETERS; PEDRYCZ, 2001). Para Sommerville (2007) os seguintes componentes estão envolvidos na parte de análise de requisitos: • Ambiente: formado por usuários do sistema, máquinas, serviços e operações de software, possuem a importância de especificar como e de que forma as tarefas serão executadas; • Itens produzidos: descrevem as necessidades envolvidas no processamento, consumo e produção do sistema; • Funções: descrevem as funções executadas por pessoas e máquinas, necessárias para realizar um determinado serviço; e • Modos de operação: métodos utilizados, formas de produção e quando as operações acontecem. Rezende (1999) apresenta a comunicação e a capacitação como fatores essenciais durante a análise de requisitos devido à possibilidade de haver conflitos com exigências apontadas por outros envolvidos no processo, já que este problema tende a aumentar com a complexidade das tarefas. Para facilitar e melhorar a capacidade de análise de sistemas, Silva e Rocha (1998) apontam a necessidade de realizar a interação entre os envolvidos, definindo “o que” e “como” determinada 49
  51. 51. tarefa deverá ser realizada, avaliando suas origens e separando suas características, para permitir que novas habilidades gerenciais sejam propostas e novos modelos de processos sejam definidos. 2.2.3 Processos da Engenharia de Requisitos A criação e atualização de um documento contendo a relação de todos os requisitos é parte fundamental e objetivo principal do processo existente na engenharia de requisitos (SOMMERVILLE, 2007). Conforme descrito por Sommerville (2007), o processo de definição de requisitos pode ser dividido em quatro subprocessos (Figura 17) relacionados à avaliação da utilidade e adequação para a empresa: (i) estudo de viabilidade; (ii) análise e elicitação de requisitos; (iii) especificação; e (iv) validação do software. Figura 17. Etapas presentes no processo de engenharia de requisitos. Fonte: Adaptado de UNESP (2006). Estas etapas estão inseridas em um processo evolutivo e contínuo ao longo do ciclo de vida do software, já que na prática as alterações nos requisitos podem se tornar constantes, necessitando gerenciar estas mudanças para obter ao final de cada etapa um artefato reunindo as informações coletadas. 50
  52. 52. 2.2.3.1 Estudo de viabilidade Na maioria dos projetos de software, deve-se inicialmente realizar um estudo das necessidades e avaliar como o software auxiliará nos processos da empresa através de resultados obtidos em relatórios. Assim é possível verificar se sua elaboração é capaz de atingir os objetivos desejados ou se será necessário realizar alterações de orçamentos, escopo e prazos anteriormente definidos (SOMMERVILLE, 2007). Ainda como fontes de estudo, é necessário verificar se o sistema poderá ser implementado utilizando a tecnologia atual, dentro do orçamento existente e se poderá ser integrado a outros sistemas já em operação (UNESP, 2006). Para Sommerville (2007), a realização de um estudo de viabilidade é formada basicamente por perguntas, coleta e avaliação de informações, abordando quais seriam as contribuições oferecidas à solução proposta, ou seja, se as respostas não forem satisfatórias, deve-se recomendar o não prosseguimento do desenvolvimento, restando como conclusão que o software não irá agregar valores reais para a empresa. Entre as pessoas envolvidas no estudo de viabilidade, podem ser citados, gerentes de departamento, funcionários, especialistas em tecnologia e demais pessoas familiarizadas com os processos e regras de negócio. Alguns questionamentos básicos, segundo UNESP (2006), são: • Existem problemas nos processos utilizados atualmente? Qual o impacto causado se o sistema não fosse implementado? • Como o sistema auxiliará as atividades do cotidiano? • Que tecnologias e habilidades serão necessárias à implementação do sistema? Estão dentro das restrições definidas de custo e prazo? 2.2.3.2 Elicitação e análise de requisitos Como segunda etapa, os engenheiros de software e a equipe técnica realizam reuniões com os clientes e stakeholders com a finalidade de descobrir maiores detalhes sobre o domínio da aplicação, desempenho e hardware necessários. 51
  53. 53. Os stakeholders, segundo Sommerville (2007), são todas as pessoas envolvidas que possuem influência direta ou indireta sobre os requisitos do sistema, com isto diversos problemas são encontrados devido a várias razões: • Normalmente os usuários e stakeholders possuem requisitos conflitantes e freqüentemente não sabem definir exatamente o que desejam que o sistema realize, expressando as funcionalidades em termos gerais; • Utilizam linguagem natural e conhecimento implícito do trabalho que dificultam a identificação dos requisitos, necessitando definir os pontos em comum e avaliar quem são as potenciais fontes de requisitos; e • Como o ambiente econômico e negócios são dinâmicos, os requisitos são modificados naturalmente, além de existirem fatores políticos que podem ser influenciados durante o processo de análise. 2.2.3.3 Especificação de Requisitos Parte do processo responsável por definir e traduzir as informações coletadas durante o levantamento de requisitos, que compreende e define os serviços exigidos para fornecer uma base estável para o projeto do software (SOMMERVILLE, 2007). Esta etapa pode ser considerada uma das mais críticas, já que a má especificação pode resultar em erros nos estágios posteriores. Algumas técnicas podem ser utilizadas para especificar os requisitos de software, que variam de acordo com a necessidade e com as melhores abordagens para identificar e facilitar sua obtenção. 2.2.3.3.1 Levantamento baseado em ponto de vista Através de entrevistas realizadas com diferentes stakeholders, é possível identificar as perspectivas, classificando e descobrindo os conflitos entre as fontes de requisitos. Estas entrevistas consistem na formulação de perguntas sobre o sistema utilizado e o sistema a ser desenvolvido (SOMMERVILLE, 2007). Ainda para Sommerville (2007), basicamente os pontos de vista podem ser divididos em três grupos genéricos: 52
  54. 54. • Pontos de vista de iteração: Responsáveis por representar todas as pessoas envolvidas direta ou indiretamente com o sistema fornecendo detalhes a respeito das características e interfaces; • Pontos de vista indiretos: Representam os stakeholders que não utilizam o sistema, mas acabam por influenciar seus requisitos e restrições organizacionais; e • Pontos de vista de domínio: Representam características e restrições de domínio que acabam influenciando os requisitos do sistema. 2.2.3.3.2 Casos de uso Para Larman (2004), um caso de uso nada mais é que uma forma de aplicar e descrever um requisito que será realizado pelo software, além de serem mecanismos centrais para a descoberta e definição de outros requisitos do sistema. Sua finalidade é expressar a maneira com que elementos externos interagem com as funcionalidades disponíveis no sistema. Os diagramas de casos de uso são elementos textuais da UML, geralmente representados em forma de diagramas, para permitir uma melhor visualização e entendimento. Para Medeiros (2004) um caso de uso é uma atividade responsável por representar a execução de determinada tarefa em um software através do relacionamento e interação entre os casos de uso e atores. Figura 18. Exemplo de um diagrama de caso de uso. 53
  55. 55. Na Figura 18 é apresentado um exemplo de diagrama de caso de uso para um sistema de controle de usuários. Neste modelo existe um ator, o administrador do sistema, que possui acesso a duas funcionalidades principais representadas pelos casos de uso UC 02.01, para manipular e cadastrar usuários e o caso de uso UC 02.02, para gerenciar grupos de usuários. O UC 02.03 possui a funcionalidade de manipular permissões para o grupo de usuários e está relacionado através de uma extensão ao UC 02.02. Para Booch, Rumbaugh e Jacobson (2006) um caso de uso define um comportamento específico esperado pelo sistema, sem levar em consideração as ações e aspectos necessários a sua implementação dentro do software. Para Larman (2004), existe uma forte relação entre os requisitos funcionais e os casos de uso. A principal diferença é que os casos de uso descrevem de forma mais detalhada como uma ação será executada pelo software durante a implementação, sendo este um dos principais mecanismos utilizados em diversos processos de software, para a descoberta e definição de requisitos. 2.2.3.4 Documentação Durante as fases da engenharia de requisitos, armazenar e organizar as informações são tarefas extremamente importantes, pois permite utilizá-las como documento oficial da especificação do sistema para clientes, desenvolvedores e usuários (PETERS; PEDRYCZ, 2001). Denominada de Especificação de Requisitos de Software (ERS) são escritas utilizando uma linguagem natural variando o grau de detalhamento de acordo com o público alvo podendo incluir diagramas, tabelas e demais artefatos para facilitar seu entendimento (SOARES; FARIA, 2008). Segundo Peters e Pedrycz (2001), a ERS é responsável por descrever as propriedades, restrições e funções executadas dentro de um produto de software, geralmente são escritas durante todo o processo de engenharia de requisitos. Para Soares e Faria (2008) os seguintes tópicos são encontrados em um documento de ERS: • Visão geral do sistema, benefícios do desenvolvimento, glossário com termos técnicos; • Definição dos serviços, requisitos, propriedades do sistema; e 54
  56. 56. • Restrições de operação, definição do ambiente em que o sistema será executado e integração com outros sistemas. Ao realizar a descrição dos requisitos devem ser observados os seguintes fatores (PETERS; PEDRYCZ, 2001): • Funcionalidade: As tarefas que o software deverá realizar, suas funções e estados; • Interface externa: Interação do software com o ambiente, pessoas, hardware e outros software; • Desempenho: Velocidade, disponibilidade, tempo de resposta; • Atributos: Portabilidade, rastreabilidade, manutenibilidade, qualidade, estabilidade, segurança; e • Restrições: Padrões de qualidade, linguagens de codificação, recursos, orçamento, ambiente. 2.2.3.4.1 Especificação de requisitos de software segundo IEEE 830-1998 Dentre as diversas abordagens e modelos disponíveis para serem utilizados como modelo de ERS, destaca-se a especificação proposta pelo IEEE (Institute of Electrical and Electronics Engineers - Instituto dos Engenheiros Elétricos e Eletrônicos), responsável por definir boas práticas para a especificação de requisitos proveniente de resultados obtidos de diversos processos da engenharia de software (PETERS; PEDRYCZ, 2001). Esta subseção foi escrita baseada na recomendação proposta pelo IEEE, foram extraídos do documento as principais características que devem estar presentes na especificação de requisitos, para servir como base na modelagem e desenvolvimento desta atividade na ferramenta WebCASE. Considerando algumas das informações necessárias que devem estar presentes no escopo da ERS abaixo são detalhadas de maneira sucinta, explicando o porquê de sua utilização (IEEE, 1998). 55
  57. 57. Característica da ERS • Correta: Uma ERS está correta se, e somente se, todos os requisitos atendem as necessidades do software, podendo ser avaliada pelos usuários se ela está correta e reflete os objetivos (ibidem). • Sem ambigüidade: Nenhum requisito deve possuir mais de uma interpretação e que no mínimo cada requisito é descrito utilizando um único termo. Uma forma de representar os requisitos é através da utilização de ferramentas para auxiliar sua descrição através de uma linguagem própria onde muitas vezes são utilizados diagramas para auxiliar este processo (ibidem). • Completa: Uma especificação somente poderá ser dita completa se todos os seus requisitos significantes estiverem disponíveis, até mesmo os relacionados à performance, funcionalidades e interfaces externas (ibidem). • Consistência: Para que uma ERS seja considerada consistente é necessário que ela não possua conflito com outros requisitos, por exemplo, um requisito informa que um estado “a” deve ser seguido por um estado “b”, já em outro requisitos a ocorrência de “a”ou “b” podem acontecer simultaneamente (ibidem). • Classificação por importância e estabilidade: Em uma ERS os requisitos devem conter indicadores particulares de importância e estabilidade. Como nem sempre os requisitos possuem a mesma importância, alguns podem ser especiais, essenciais ou críticos, enquanto outros podem ser apenas desejáveis, sendo esta diferença clara e explícita. Já na classificação por necessidade um requisito pode ser distinguido de três formas: (i) Essencial: definem implicações que afetam diretamente o sistema e se não cumpridos podem acarretar na sua não utilização; (ii) Condicional: responsáveis por melhorar e adicionar características ao software, mas não farão que ele seja rejeitado; e (iii) Opcional: características que podem não ter tanta importância e servem para aprimorar ou adicionar funcionalidades presentes na ERS (ibidem). • Estabilidade: A estabilidade pode ser expressa com base no número de modificações esperadas, na experiência e conhecimento de eventos que possam afetar a organização (e.g., funções, pessoas que possam interferir em um requisito) (ibidem).
  58. 58. • Verificável: Toda ERS deve ser verificável, ou seja, se um requisito puder ser testado com um custo efetivo através de uma pessoa ou máquina e não for ambíguo, então ele estará cumprindo a especificação do produto. Alguns requisitos que não podem ser verificados incluem “funcionamento adequado”, “boa interface humana”, “deve ocorrer usualmente” já que teoricamente o teste de qualidade é impossível por existirem fatores externos (e.g., configuração de software, hardware, rede) que podem afetar seu perfeito funcionamento (ibidem). • Modificável: Toda e qualquer modificação deverá ser fácil, completa e consistente mantendo a estrutura proposta. Para isto é necessário haver coerência e uma maneira fácil de organizar os requisitos (e.g., índices, tabelas, cruzamentos explícitos), e assim verificar que não existem requisitos redundantes e em conflito, garantindo a propriedade modificável a ERS. Vale lembrar que redundâncias nem sempre são erros, mas podem acarretar erros facilmente (ibidem). • Rastreável: Para que uma ERS seja rastreável, deverá existir uma maneira clara e fácil para referenciar cada requisito em futuras modificações e aprimoramentos na documentação. Basicamente existem duas formas de realizar um rastreamento, uma através de referências para os requisitos anteriores e outra através da atribuição de um nome ou identificador único para cada requisito (ibidem). Preparação conjunta da ERS Clientes e fornecedores nem sempre estão capacitados a escrever uma especificação de software sozinhos, assim, é necessário trabalhar em conjunto para definir e concordar com as funcionalidades propostas pelo software e permitir que uma documentação bem estruturada e facilmente entendida seja criada (ibidem). Evolução da ERS Como nem sempre é possível descobrir completamente os detalhes nas fases iniciais do projeto, é necessário que a evolução da ERS avance juntamente com o progresso do software, documentando as modificações e deficiências que possam surgir com os novos requisitos. Duas considerações importantes nesta etapa devem ser consideradas: (i) os requisitos devem ser especificados completamente e na hora em que são descobertos, se por algum motivo estiverem incompletos devem ser marcados para revisões posteriores; e (ii) um processo de modificação 57

×