Embed Size (px)
DESCRIPTION
Citation preview
RAFAEL PIMENTA TUVO
JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR
ERCOLAB
Um ambiente colaborativo para elicitação de requisit os baseado em
casos de uso
SALVADOR
2007
RAFAEL PIMENTA TUVO
JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR
ERCOLAB
Um ambiente colaborativo para elicitação de requisit os baseado em
casos de uso
Monografia apresentada por Rafael Pimenta
Tuvo e José Adauto de Oliveira Junior como
requisito parcial para aprovação na disciplina
Projeto Final.
Orientador: Profº Antonio Cláudio P. Neiva
SALVADOR
2007
CERTIFICADO
Certifico que a presente memória, ERCOLAB - Um ambiente colaborativo para auxiliar a
elicitação de requisitos baseado em casos de uso, foi realizada sob minha direção por
RAFAEL PIMENTA TUVO E JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR,
constituindo o Projeto Final de Curso do Bacharelado em Informática da Universidade
Católica do Salvador - UCSal.
Salvador, 30 de Dezembro de 2007.
Antônio Cláudio Neiva
Curso de Bacharelado em Informática
Universidade Católica do Salvador
Salvador
30/12/2007
DEDICATÓRIA
“Dedico este trabalho a minha mãe Yara Menezes Pimenta por todo o incentivo durante
a empreitada e a minha namorada Luana por nunca me deixar desanimar”.(Rafael
Pimenta)
“Dedico esse trabalho a minha mãe Maria da Glória Brito Sapucaia e a meu pai José
Adauto Oliveira de Menezes, que sempre estiveram e estão presentes em toda a minha
caminhada, me orientando e fazendo com que eu me tornasse o homem que sou hoje,
a minha namorada Ingrid Daiane, que mesmo nos momentos onde eu achava que nada
iria dar certo, estava alí incentivando, me enchendo assim de garra para lutar, e ao
novo amigo, Rafael Pimenta, que lutou a todos os instantes comigo em busca do nosso
crescimento” . (Adauto Júnior)
AGRADECIMENTOS
Agradecemos a Deus por mais esta etapa e esperamos que ainda nos
aconteçam muitas outras. Agradecemos a todos os nossos amigos, sem exceção, que,
direta ou indiretamente, de alguma forma, contribuíram para a construção desse
projeto. Aos colegas de trabalho que gastaram inúmeras horas a fim de nos ajudar com
os problemas deste. Ao nosso orientador Cláudio Neiva que sempre nos incentivou e
apontou o melhor caminho a ser tomado para conclusão deste projeto. Em especial,
agradecemos a dona Glória, por suportar os dias e noites de incomodo durante a
elaboração desse projeto e fazer de tudo para tornar o trabalho menos desgastante. E
aos que acharam que não daria certo, nos estimulando assim a superar mais este
desafio.
RESUMO
Sabe-se que um dos maiores problemas no desenvolvimento de software é a escolha
equivocada dos seus requisitos e também que a colaboração aumenta a comunicação
e a interação entre as pessoas. O objetivo deste trabalho é mostrar que a colaboração
pode ser eficiente quando aplicada a ferramentas de levantamento de requisitos de
software uma vez que aproxima os analistas minimizando assim a ocorrência de idéias
controversas e estimula a discursão sobre o projeto. Para exemplificar, foi desenvolvido
o ERCOLAB, um ambiente onde é possível estabelecer a comunicação entre seus
membros de variadas formas, através de seus módulos, e definir colaborativamente os
casos de uso que irão compor o sistema, influenciado pelos conceitos de coordenação,
cooperação e comunicação, base da colaboração.
Palavras chaves: Engenharia de Software, colaboração, requisitos, casos de uso,
comunicação
ABSTRACT
A biggest problems in software development is the wrong choice of their requirements. The
theory of collaboration increases the communication and interaction between people. The
objective of this work is to show that cooperation can be effective when applied to tools of
Software Engineering since it brings together analysts thus minimizing the occurrence of
controversial ideas and encourages debate on the project. To illustrate, has developed the
ERCOLAB, an environment where it is possible to define collaboratively the use cases that will
compose the system, influenced by the concepts of coordination, cooperation and
communication, the basis of cooperation.
Keywords: Software Engineering, collaboration, requirements, use cases, communication
LISTA DE FIGURAS
Figura 1 – Diagrama do Modelo de Colaboração 3C.... .............................................14
Figura 3 – Relação Memória do Grupo X Colaboração.. ...........................................16
Figura 4 – Exemplo de Diagrama de Casos de Uso ..... .............................................26
Figura 5 – Diagrama de caso de uso do portal. ...... ...................................................30
Figura 6 - Tela de Gerenciamento dos Módulos do XOO PS.....................................31
Figura 7 - Tela do Módulo de Projeto para Cadastro do Casos de Uso...................33
Figura 8 – Trigger para criação da categoria ......................... ....................................33
Figura 9 - Tela com o caso de uso “Emprestar Fita” cadastrado, como exemplo .35
Figura 11 – Tela de diálogo sobre o caso de uso ”Em prestar Fita” no fórum........37
Figura 12 – Chat do Sistema ........................ ...............................................................38
Figura 13 – Exemplo de email utilizado no portal ... ..................................................39
Figura 14 – Módulo de Notícias..................... ..............................................................40
Figura 15 – Modelo de Dados do Sistema............. .....................................................41
Figura 16 – Tela de avaliação da contribuição do si stema.......................................42
LISTA DE ABREVIATURAS
AJAX - Asynchronous JavaScript and XML
CRC – Cooperative Requirements Capture
JAD – Joint Application Development
PD – Participatory Design
PHP - Hypertext Preprocessor
QFD – Quality Function Deployment
SQL – Structure Query Language
UML – Unified Modeling Language
XOOPS - eXtensible Object Oriented Portal System
SUMÁRIO
INTRODUÇÃO ..........................................................................................11
2. FUNDAMENTAÇÃO TEÓRICA ........................... .................................13
2.1 Colaboração .....................................................................................13 2.1.1. Elementos da Colaboração ........................................................14
2.1.1.1 Comunicação ......................................................................14 2.1.1.2 Coordenação.......................................................................17 2.1.1.3 Cooperação..........................................................................18
2.2 Requisitos.........................................................................................18 2.2.1 Fase de Levantamento de Requisitos ........................................20
2.2.1.1 Problemas da Fase de Levantamento de Requisitos............20
2.3 Casos de Uso...................................................................................22 2.3.1 Especificação de Casos de Uso .................................................22 2.3.2 Diagramas de Caso de Uso........................................................25
3. ERCOLAB......................................... ....................................................27
3.1 Identificação do Problema ................................................................27
3.2 Objetivo do Sistema .........................................................................28
3.3 Definição da linguagem e arquitetura do portal.................................29
3.4 Módulos do Sistema .........................................................................32
3.5 Modelo de Dados .............................................................................40
3.6 Avaliação da Ferramenta..................................................................42
CONCLUSÃO .......................................... .................................................44
REFERÊNCIAS.........................................................................................46
11
INTRODUÇÃO
A maneira de trabalhar da sociedade é revolucionada por tecnologia e dá
suporte às formas de relacionamento humano. A criação de espaços compartilhados de
trabalho propicia o trabalho colaborativo distribuído e descentralizado (FUKS, 2002).
Entretanto, softwares colaborativos, chamados de groupware, só começaram
a surgir efetivamente em meados dos anos oitenta (ROSA, 2005). O desenvolvimento e
a usabilidade de ferramentas colaborativas ainda são dificultados por sua ampla
disciplinaridade. É custoso produzir um software que seja simples e tenha o dinamismo
necessário à interação entre as várias áreas do conhecimento.
O objetivo deste projeto é mostrar que a colaboração, quando aplicada
ferramentas de levantamento de requisitos de software, pode aumentar a produtividade
do trabalho, uma vez que aproxima os analistas e aumenta a percepção do trabalho
como um todo.
Para dar suporte a esse objetivo, será desenvolvido um ambiente que,
durante a produção de software, auxilie na especificação de casos de uso, de forma
colaborativa, ou seja, que vários analistas de sistemas possam contribuir para um
mesmo documento, fazendo um trabalho em conjunto. Portanto, será disponibilizada
uma área de trabalho compartilhada para tal atividade, levando em consideração os
princípios da colaboração e da engenharia de software.
O capítulo 2 desta monografia discorrerá sobre o conceito de colaboração e
estruturas envolvidas em sistemas colaborativos, base para o entendimento do trabalho
em grupo.
No capitulo 3, serão abordados os conceitos e as características dos
requisitos de software. Uma breve explanação sobre algumas fases do processo de
desenvolvimento de software também será encontrada.
12
O capitulo 4 encerra a fundamentação teórica explicando o que são casos de
uso e todas as características que os compõem.
O capitulo 5 apresenta o projeto, falando da sua estrutura, seus módulos e
descrevendo a colaboração dentro do ambiente proposto.
A conclusão do projeto segue ao final, fazendo uma análise dos resultados.
13
2. FUNDAMENTAÇÃO TEÓRICA 2.1 Colaboração
Como o aumento das demandas e do volume de trabalho nas organizações
cresce a cada dia, a maneira de se trabalhar acabou por receber um novo foco. O
trabalhador sempre acostumado a tarefas vindas de cima para baixo na hierarquia
pouco se comunicava e grande parte das suas tarefas era resolvida de forma individual
(FUKS, 2002). Até meados dos anos oitenta, o auxilio informatizado para a
comunicação e resolução de problemas envolvendo varias pessoas era reduzido
(ROSA,2005).
Em contrapartida, as pessoas da área de informação têm a facilidade de
trabalhar em equipe e de evoluir juntamente com os procedimentos inerentes as suas
tarefas (FUKS, 2002). Existe a comunicação constante em busca de tudo que possa
auxiliar na execução de suas atribuições. Muitas dessas envolvem outras áreas do
conhecimento e grupos aparecem para discutir e solucionar os percalços que vão
aparecendo. A antiga idéia de individualidade das empresas se rende ao espírito de
equipe e à realização de trabalhos em grupo a todo o momento.
Em ambientes cooperativos podem-se produzir melhores resultados que
individualmente (FRANCO, 2003). Dessa forma, um membro pode suprir a falta do
outro, promovendo uma ajuda mútua e equilibrando o conhecimento. É possível
também o surgimento de idéias e vários caminhos para a solução dos diversos
problemas, discutindo e, em comum acordo, tomar a decisão mais apropriada a cada
um deles.
Contudo, como sugere Fuks (2003), “colaborar demanda um esforço
adicional de coordenação dos seus membros”. A coordenação é necessária para que
toda essa cooperação entre os membros seja aproveitada com a maior eficiência
possível. Todo grupo tem suas divergências e essa coordenação vem para tratá-las e
administrá-las de forma a atingir um bom nível de satisfação dentro da equipe.
14
2.1.1. Elementos da Colaboração
O modelo 3C para sistemas colaborativos, proposto em 1991 por (ELLIS
apud FUKS, 2004), baseia-se no tripé cooperação, comunicação e coordenação, sobre
uma determinada percepção do problema, para em grupo chegar a uma solução. O
diagrama apresentado na figura 1 ilustra os três conceitos inter-relacionados:
Figura 1 – Diagrama do Modelo de Colaboração 3C (GEROSA, 2005)
2.1.1.1 Comunicação
No processo de colaboração, não basta apenas que a mensagem seja
enviada pelo emissor e recebida pelo receptor, o mesmo entendimento por ambas as
partes é de grande importância. Uma distorção dela pode causar diferentes
interpretações, dificultando a soma dos seus esforços nas tarefas (FUKS ,2002).
A forma mais comum de realizar a comunicação é face a face mas quando
isso não é possível outros canais de comunicação podem ser utilizados como bate-
papos, e-mails, entre outros. Independente do método, o recebimento da mensagem
está sujeito ao canal de percepção que liga o emissor e o receptor (ROSA, 2005).
Ellis et. al. (1991) propõe uma classificação para as formas de comunicação
baseados na taxonomia espaço-tempo, onde o espaço determina a localização física
dos participantes (local ou distribuída) e o tempo determina o momento em que os
participantes trabalham (síncrono ou assíncrono) e é, sem dúvida, a mais aceita entre
15
todas as classificações conhecidas. Exemplos de sistemas síncronos distribuídos são
os editores multi-usuários de tempo real e teleconferências; de interação síncrona tem-
se as ferramentas de revisão de documentos; de interação assíncrona distribuída,
correio eletrônico, sistemas de workflow (ANTILLANCA ; FULLER, 1996). A figura 2
apresenta a matriz Espaço x Tempo proposta:
Figura 2 – Matriz Espaço X Tempo (ANTILLANCA, 2006?)
Marcio Rosa (2005) afirma em seu trabalho que existe uma forte ligação
entre o conhecimento formal e informal gerados durante a interação dos membros do
grupo, onde artefatos são produzidos e informações são geradas durante a interação
(idéias surgidas, mensagens trocadas, pontos de vista defendidos, etc) sendo que
ambos são importantes para a construção da memória do grupo. A falta de uma
memória do grupo freqüentemente leva a reuniões e discursões sobre temas já
abordados, caracterizando assim uma baixa produtividade. “Os membros do grupo
alcançam o conhecimento compartilhado com o auxilio dos conhecimentos
armazenados na memória do grupo.” (DIAS apud ROSA, 2005).
A figura 3 mostra as relações entre a memória do grupo e os elementos da
colaboração.
16
Figura 3 – Relação Memória do Grupo X Colaboração (ARAUJO apud ROSA , 2005)
Com a comunicação, compromissos são gerados ( WINOGRAD ; FLORES
apud FUKS , 2002) e é preciso uma coordenação para que eles sejam realizados e
também para que haja a união dos trabalhos individuais de cada um. Tal coordenação
garante a excelência nos prazos estabelecidos, mantém o foco no objetivo e evita
desperdício de empenho durante os trabalhos (FUKS,2002).
É necessário citar sobre a importância da percepção em trabalhos
colaborativos. A percepção pode ser conceituada como “ter conhecimento, ter ciência
das atividades do grupo, das atividades que influenciarão no trabalho como um todo“,
(PINHEIRO, 2000). Ela se refere tanto a identificação e localização dos outros membros
de um sistema colaborativo quanto ao que compete a eles, que atividades eles estão
realizando e já realizaram anteriormente. Sem ela, os membros do grupo não sabem
em que contexto estão atuando, dificultando a visão de como suas atividades
individuais podem ser unidas aos outros resultados do resto do grupo. A percepção é
um ato individual sendo que uma mesma informação pode ser percebida de forma
diferente pelos vários membros do grupo (ROSA, 2005).
17
2.1.1.2 Coordenação
Segundo Karl Marx, “Colaboração são múltiplos indivíduos trabalhando
juntos de maneira planejada no mesmo processo de produção ou processos de
produção diferentes mas conectados” (citado em (FUKS, 2002)). Coordenar é, antes de
tudo, planejar. Fazer o planejamento da delegação de tarefas é uma ação importante
na coordenação, evitando assim que membros realizem tarefas redundantes ou
conflitantes entre si.
Mas, além disso, a coordenação passa também pelo gerenciamento durante
a execução das tarefas e pela documentação dos trabalhos após elas terminarem. O
planejamento é a preparação da colaboração, é a identificação dos objetivos, definição
das tarefas focando nesse objetivo, escolha dos membros e de suas respectivas
atividades, etc... Ao final, tem-se a análise, avaliação e documentação das mesmas,
detalhando o processo desde o inicio. Entretanto a parte fundamental é mesmo o
gerenciamento das ações. O ambiente vai sendo alterado e as ações precisam
acompanhar essas mudanças, tornando essa fase extremamente dinâmica e
trabalhosa, exigindo comunicação e cooperação a todo tempo para sua eficiência,
novamente explanado por Fuks (2002).
Em alguns casos, os próprios participantes se encarregam de coordenar, ou
melhor, não há uma coordenação explícita para administrar as tarefas, simplesmente
porque as características delas não exigem uma, por exemplo, um chat. O dito
protocolo social e a habilidade dos participantes se encarregam da moderação das
tarefas mas isso é definido pelo desenvolvedor do sistema. Já em outros casos, são
necessários robustos mecanismos de coordenação. Sistemas de fluxo de trabalho são
bons exemplos (FUKS ; GEROSA, 2002).
18
Como os participantes colaboram a todo tempo, idéias antagônicas podem e
devem acabar ocorrendo nos trabalhos em grupo. A coordenação deve tratar esses e
todos os outros tipos de conflito que por ventura ocorram, por exemplo, demasiada
competição entre os componentes, definição exata do que compete a quem, etc (FUKS;
GEROSA, 2002).
2.1.1.3 Cooperação
Cooperação é a operação conjunta dos membros do grupo no espaço
compartilhado visando a realização das tarefas gerenciadas pela coordenação (FUKS,
H., et al, 2002). Cooperação é se ajudar mutuamente, trocar idéias, organizar o
pensamento, discutir e produzir em grupo um documento com o auxilio da coordenação
e da comunicação.
Todo tipo de cooperação em um sistema deve ser arquivado de alguma
forma. Assim, ao final do trabalho colaborativo existe um catálogo com tudo o que foi
feito, discutido e decidido. “O registro da informação visa aumentar o entendimento
entre as pessoas, reduzindo a incerteza (relacionada com a ausência de informação) e
a equivocidade (relacionada com a ambigüidade e com a existência de informações
conflitantes)” (DAFT ; LENGEL, 1986). Essa forma de registro pode ser útil caso esse
trabalho sirva de base para um outro, caso alguma coisa dê errado posteriormente ou
aconteça algum reconhecimento pelo que foi realizado.
2.2 Requisitos
A complexidade dos problemas que os engenheiros de software tem que
solucionar, muitas vezes, é muito grande. É complicado estabelecer com precisão tudo
que um sistema deve fazer. Chama-se de requisito a descrição das funções e as
restrições que um sistema terá; já todo o trabalho em cima dele (levantamento, análise,
documentação e verificação) chama-se de engenharia de requisitos (SOMMERVILLE,
2003).
19
Zanlorenci e Burnett (2001), Sommerville, entre outros autores, dividem os
requisitos em funcionais e não funcionais.
Funcionais: São declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas especificas e como deve se comportar em determinadas situações. Não Funcionais: São as restrições sobre os serviços ou as funções do sistema. Sommerville (2003).
Exemplos de limitações não funcionais são valores para tempo de resposta,
espaço em disco, entre outros.
Segundo (THAYER apud BELGAMO, 2000), as fases da Engenharia de
Requisitos são: elicitação, análise, especificação, verificação e gerenciamento. A
elicitação é o processo através do qual clientes e usuários são questionados por um
desenvolvedor para falarem “o quê” o software deve fazer (ou seja, os requisitos). A
análise é o processo onde são analisadas as necessidades dos clientes e usuários para
se chegar na definição dos requisitos de software. A especificação é o processo de
criação de um documento no qual estão definidos todos os requisitos analisados. A
verificação é o processo que busca assegurar que a especificação de requisitos de
software está em concordância com os requisitos elicitados e analisados nas fases
anteriores, ou seja, estão de acordo com o desejo do cliente. O gerenciamento: é o
planejamento e controle da atividade de elicitação, especificação, análise e verificação
dos requisitos.
Na verdade, antes da elicitação existe ainda uma breve fase chamada
Estudo de Viabilidade. Para Sommerville (2003), ela consiste num rápido e objetivo
estudo procurando responder a questões como: o sistema colabora para os objetivos
da organização? Mesmo com as restrições de prazo e custos o sistema poderá ser
implementado com tecnologia recente? Poderá ele ser integrado com outros sistemas já
implantados na empresa? Assim um relatório é gerado e os resultados apontam se
realmente vale a pena começar o processo de desenvolvimento do sistema.
20
2.2.1 Fase de Levantamento de Requisitos
Na fase de levantamento de requisitos, os analistas de sistemas trabalham
junto aos usuários que terão, de alguma forma, influência sobre o sistema
(stakeholders), a fim de definir o domínio da aplicação, qual a performance exigida pelo
sistema, que interfaces serão necessárias, restrições legais, de hardware, etc..., sugere
Somerville.
“O levantamento de requisitos é uma fase que compreende o período em que o engenheiro de requisitos procura entender o problema e a necessidade do usuário. Esta é uma atividade multidisciplinar, pois lida com aspectos sociais e humanos de forma tão intensa quanto com os aspectos técnicos” (FREITAS, Danilo, 2007).
Ainda segundo Sommerville, a descoberta tardia de falhas no documento de
requisitos pode levar a enormes custos relacionados ao retrabalho para corrigi-las,
quando a fase de desenvolvimento já está em andamento ou quando o sistema já está
em operação. O custo de se reparar um erro e alterar o sistema, proveniente de um
equívoco de requisitos, é muito maior do que erros de projeto e implementação.
Estudos realizados por BOEHM (apud CYSNEIROS , 2001) indicam que, após o
sistema implementado, as despesas com erros em requisitos de software chegam a ser
20 vezes maiores que qualquer outro erro em outra fase. Isso porque o projeto e a
implementação do sistema devem ser redesenhados e os testes novamente realizados.
Por este motivo é importante executar de maneira criteriosa essa atividade.
2.2.1.1 Problemas da Fase de Levantamento de Requis itos
Christel e Kang (1992) descrevem 3 grupos para classificar problemas na
fase de levantamento de requisitos:
• Problemas de Escopo : Quando as fronteiras do sistema ainda não estão
bem definidas, os requisitos podem fornecer muita ou pouca informação.
Pode acontecer também de haver perda do foco do sistema com informações
desnecessárias, mais profundas e técnicas que o exigido em tal momento.
21
• Problemas de Compreensão : Os próprios usuários do sistema muitas vezes
não sabem do que precisam. Existem usuários de várias áreas e formações,
ou seja, muitos pontos de vista diferentes. Até mesmo entre o analista e os
usuários existe esse desentendimento, havendo assim requisitos conflitantes,
ambíguos e instáveis.
• Problemas de Volatilidade : Os requisitos mudam muito do inicio ao fim do
projeto. E essas mudanças são necessárias para não tornar partes do
sistema obsoletas, incompletas ou até inúteis. A cada mudança suas
conseqüências precisam ser avaliadas.
Além dessas 3 classificações ainda existem mais 2 grandes blocos de
problemas (FAULK apud FREITAS, 2007):
• Problemas Acidentais : São aqueles provenientes da falta de organização e
planejamento sobre o que precisa ser construído. Por exemplo, pouca
dedicação na coleta de informações dos usuários, descrição superficial dos
requisitos obtidos e pressa para o início da fase de implementação
(MARTINS apud FREITAS , 2007).
• Problemas Essenciais : São aqueles inerentes à elicitação de requisitos. Por
exemplo, a dificuldade de comunicação entre os analistas e os usuários e a
mudanças constantes dos requisitos (MARTINS apud FREITAS, 2007).
Percebe-se que os problemas acidentais podem ser evitados aplicando
corretamente as fases da engenharia de requisitos.
Visando minimizar e até eliminar os impactos dos problemas nesta fase,
algumas técnicas para elicitação de requisitos foram difundidas e abordadas por
Belgamo: Observação, Entrevista, Análise de Protocolo, JAD (Joint Application
Development), PD (Participatory Design), QFD (Quality Function Deployment), CRC
(Cooperative Requirements Capture), Prototipação, Cenários.
22
2.3 Casos de Uso
Os casos de uso foram propostos inicialmente pelo cientista da computação
sueco Ivar Hjalmar Jacobson em sua metodologia de desenvolvimento de sistemas
orientados a objetos, e ele define caso de uso como sendo uma “descrição de um
conjunto de seqüências de ações, inclusive variantes, que um sistema executa para
produzir um resultado de valor observável por um ator” [BOOCH, 2000]. Posteriormente
eles foram incorporados a UML (Unified Modeling Language) onde seu uso se tornou
extremamente freqüente na identificação dos requisitos de sistema.
Os objetivos dos casos de uso são decidir e descrever os requisitos
funcionais do sistema, apresentar com clareza e consistência o que o sistema irá fazer
e permitir descobrir os requisitos funcionais das classes e operações do sistema,
sugere Macoratti (2004). É importante enfatizar que os casos de uso irão descrever o
comportamento do sistema e não como ele será construído.
2.3.1 Especificação de Casos de Uso
Um dos componentes dos casos de uso são os atores. Um ator representa a
figura de um ser humano, de algum dispositivo de hardware ou de algum outro sistema
que interaja com o sistema. Embora se utilize dos atores para compor a modelagem,
eles não fazem parte, de fato, do sistema. São agentes externos a ele. (BOOCH;
RUMBAUGH; JACOBSON, 2000). Exemplos de atores são clientes, usuários,
computadores, impressoras, entre outros.
É importante também entender o que é o fluxo de eventos dos casos de uso.
A descrição dos casos de uso precisa ser suficientemente clara para que alguém de
fora do desenvolvimento do sistema possa compreendê-lo. É fundamental a separação
entre a visão externa e interna da construção do sistema. O fluxo de eventos deve
incluir quando e como o caso de uso inicia e termina, como se dá a interação com os
23
atores e definir qual o fluxo principal e os possíveis fluxos alternativos do
comportamento (BOOCH; RUMBAUGH ; JACOBSON , 2000).
Booch, Rumbaugh e Jacobson (2000), propõem o exemplo a seguir,
adaptado, no contexto de um caixa eletrônico, para apresentar o que são os fluxos de
eventos básicos e fluxos alternativos a ele:
1. Fluxo de Eventos Principal:
O caso de uso inicia quando o sistema pede ao cliente seu número de
identificação pessoal, o PIN. O cliente pode, neste momento, digitar o PIN
através do teclado do caixa. Após digitá-la, o cliente confirma a entrada
apertando o botão Enter no teclado. O sistema então verifica a validade do PIN
do cliente. Caso seja válido, o sistema permite acesso ao sistema, finalizando o
caso de uso.
2. Fluxo de Eventos Alternativo:
Se o cliente entrar com o número PIN inválido, o caso de uso é reiniciado. Se
isso ocorrer 3 vezes seguidas, a transação é cancelada e o cliente tem seu
acesso ao sistema bloqueado por 1 minuto.
3. Fluxo de Eventos Alternativo:
O cliente pode cancelar a transação a qualquer momento pressionando a tecla
Cancelar, reiniciando o caso de uso.
Para cada uma dessas variações do fluxo de eventos é dado o nome de
cenário. Segundo Furlan (1998), um cenário é “uma narrativa de uma parte do
comportamento global do sistema” e uma coleção completa de cenários é usada para
especificar completamente o sistema. Furlan faz a seguinte analogia para evidenciar tal
dependência: ”os cenários estão para os casos de uso assim como as instancias estão
para as classes”.
O simples exemplo de um caso de uso (adaptado) “Comprar refrigerante”
(BLAHA, 2006), a seguir, explica como agrupar comportamentos normais e anormais
24
num único caso de uso pode ajudar a garantir que todos os possíveis cenários sejam
trabalhados em conjunto:
Caso de Uso: Comprar refrigerante
Resumo : O cliente recebe da máquina de venda um refrigerante após o cliente
pagar e escolher qual refrigerante deseja.
Atores : Cliente
Precondições : A máquina está esperando que o dinheiro seja inserido
Descrição : O estado de espera da máquina é iniciado e a mensagem “Insira
moedas” é mostrada no visor da máquina. Um cliente insere moedas na
máquina. A máquina mostra o valor inserido e acende no painel quais são
os produtos que podem ser comprados com aquele valor. O cliente aperta
um dos botões, escolhendo seu pedido. A máquina libera o produto
escolhido e, se o valor inserido for maior que o valor do produto, devolve o
troco ao cliente.
Exceções :
1. Cancelado: Se o botão de cancelamento for apertado antes do item ser
escolhido a máquina devolve o dinheiro ao cliente e reinicia o estado
de espera.
2. Em falta: Se o produto que o cliente escolheu estiver em falta, a
mensagem “Este item está em falta” é mostrada no visor. A máquina
continua a aceitar moedas e aceitar outra escolha do cliente.
3. Quantia insuficiente: Se o item escolhido for mais caro do que o valor
inserido pelo cliente, a mensagem “Você precisa de mais R$ XX para
comprar este item”, onde XX é a quantidade de dinheiro que falta para
a compra do produto. A máquina continua a aceitar moedas e aceitar
outra escolha do cliente.
4. Não há troco: Se o cliente inseriu uma quantidade suficiente de
moedas para comprar o produto mas a máquina não tem o troco
necessário a mensagem “Não há troco suficiente” é mostrada no visor.
25
A máquina continua a aceitar moedas e aceitar outra escolha do
cliente.
Pós-condições : A máquina está esperando que o dinheiro seja inserido.
2.3.2 Diagramas de Caso de Uso
A UML possui uma representação gráfica para os casos de uso e o exemplo
da figura 4 ilustra essa representação. Os diagramas de casos de uso são um dos
cinco diagramas disponíveis na UML para modelagem de aspectos dinâmicos de
sistemas. Eles mostram o conjunto de casos de uso, os atores e seus relacionamentos
(os outros diagramas são o de atividades, de gráficos de estados, de sequências e de
colaboração).
“Os diagramas de casos de uso são importantes para visualizar, especificar e
documentar o comportamento de um elemento”, (BOOCH; RUMBAUGH ; JACOBSON ,
2000). Eles tornam os sistemas e subsistemas acessíveis e compreensíveis por
permitirem uma visão externa de como esses elementos podem ser utilizados no
contexto. Entretanto, é importante salientar também que os diagramas não são
estritamente necessários para o andamento do projeto.
Os casos de uso são representados pelos nomes dentro das elipses. Um
retângulo engloba os casos de uso para um sistema que irá interagir com os atores
listados na parte externa, representados pelos bonecos com o nome do ator abaixo ou
adjacentes ao boneco. O nome do sistema pode acompanhar o retângulo que o
representa. As linhas conectam os atores aos casos de uso.
26
Figura 4 – Exemplo de Diagrama de Casos de Uso
27
3. ERCOLAB
O projeto consiste em desenvolver um ambiente que auxilie aos analistas de
sistemas durante as fases de levantamento e elicitação de requisitos em um projeto de
software com o auxilio de módulos colaborativos que irão estabelecer a comunicação e
a percepção entre os membros que o utilizam focando no desenvolvimento dos casos
de uso.
O ERCOLAB é baseado no XOOPS (eXtensible Object Oriented Portal
System), um sistema para criação de sites dinâmicos, distribuído em código aberto, e
desenvolvido na linguagem PHP (Hypertext Preprocessor) orientada a objetos,
utilizando banco de dados MySql. O XOOPS foi escolhido pela facilidade de
implementação, instalação, manutenção e manipulação dos seus componentes.
Todos os módulos utilizados no ambiente são componentes independentes
e mas sofreram alterações em sua implementação para que atendessem as
características desejadas. Com isso eles passaram a “conversar” entre si, dando mais
dinamismo e interatividade dentro do ERCOLAB.
3.1 Identificação do Problema
Um dos grandes problemas hoje nas empresas de software é o
estabelecimento correto dos requisitos que devem ser atendidos num software a ser
desenvolvido. Um documento de requisitos mal elaborado pode comprometer os prazos
e custos de desenvolvimento do produto de software, como dito anteriormente.
Os requisitos são expressos na forma de casos de uso na grande maioria
dos sistemas. Ao fim do processo de levantamento, o software é desenvolvido
fundamentado no documento de casos de uso gerado, sendo ele a base para a
construção do sistema.
28
A dificuldade de comunicação entre os envolvidos no processo é uma das
principais causas deste problema (BORTOLI ; PRICE, 2000), fazendo com que os
requisitos necessários sejam mal interpretados ou passem despercebidos e
conseqüentemente trazendo insatisfação ao usuário com o produto recebido por não
atender suas exigências e necessidades reais.
Para minimizar este problema, foi idealizado um ambiente comum aos os
analistas de sistemas que aumentasse a interação e permitisse a participação
colaborativa entre eles e assim construíssem, juntos, um mesmo documento de
requisitos. Como ele proporcionará o debate e a discursão entre os membros, este
documento estará menos sujeito a problemas de interpretação.
3.2 Objetivo do Projeto
O objetivo do projeto é fornecer um ambiente de trabalho aos analistas de
sistemas onde eles possam interagir e cooperar entre si para definir os casos de uso
que irão compor o sistema. O ERCOLAB deverá permitir o registro dos casos de uso e
agilizar o processo de elicitação deles, uma vez que o ambiente é o mesmo para todos
os analistas e toda a equipe tem acesso aos dados registrados podendo assim
compartilhar conhecimento.
Uma área compartilhada de trabalho a todos os analistas cria uma
proximidade entre os membros desta equipe, onde todos podem visualizar como vai a
evolução dos trabalhos de uma maneira geral. Aplica-se assim o conceito de
percepção, discutido no capitulo 2, onde a equipe tem ciência do andamento do projeto
como um todo, inclusive discutindo e participando dos vários aspectos dele.
A coordenação está inserida no ambiente no momento em que quem define
quais casos de uso irão definitivamente compor o documento de requisitos é o
coordenador projeto, definido pelo administrador do sistema. É ele também que delega
as permissões e autoriza o acesso dos analistas ao portal.
29
A comunicação é incentivada com a utilização de um fórum de discussão
(para dar apoio à comunicação offline) sobre dúvidas e sugestões no desenrolar da
produção dos casos de uso e um chat para que os analistas on-line durante o processo
possam interagir e dar mais dinamismo e rapidez ao trabalho, além de uma caixa de
mensagens para cada membro do portal. Todos os registros desses componentes irão
compor a memória do projeto.
Sendo assim, o ERCOLAB se propõe a dar um suporte necessário aos
analistas para que, de variadas formas, possam se relacionar durante o processo de
desenvolvimento de software (mais especificamente, das fases de levantamento e
elicitação de requisitos) e definir qual o melhor documento de requisitos para
fundamentar o sistema.
3.3 Definição da linguagem e arquitetura do portal Como citado anteriormente, o PHP foi escolhido como linguagem para
desenvolvimento do portal. Esta linguagem possui grande compatibilidade com o banco
de dados MySql. Ambas são ferramentas open source, o que ajudou bastante na
difusão do seu uso em conjunto.
Durante o desenvolvimento do ERCOLAB foi utilizada a ferramenta
phpMyAdmin para manipulação da base de dados MySql. Também de código aberto,
ela permite uma administração do banco MySql através de uma interface web. A partir
dela é possível criar, alterar e excluir tabelas do banco de dados, adicionar, remover e
editar campos das tabelas, executar códigos SQL e manipular campos chaves.
O XOOPS é um modelo de portal e pode ser utilizado nas várias áreas do
conhecimento, portanto a personalização dele cabe ao desenvolvedor de acordo com
as necessidades do negócio. Durante a pesquisa deste projeto, não foi encontrado um
30
módulo específico para casos de uso para ser instalado no portal então havia duas
possibilidades a fazer: criar um módulo para tal ou alterar um módulo existente e
adaptar ao sistema. A segunda alternativa foi escolhida, já que seria a mais simples de
se trabalhar e traria o resultado esperado no que se propõe o projeto.
A figura 5 apresenta o diagrama de casos de uso do sistema. Nele podem-se
visualizar as relações entre os requisitos funcionais do portal bem como os atores que
trabalharão nele.
System
Adminstrador do Sistema
Coordenador de Equipe
Analista de Sistemas
Manter Coordenador
Definir Permissões
Criar Notícia
Criar Projeto
Manter Caso de UsoCriar Fórum
Autorizar acesso
Solicitar acesso
Manter Módulos
<<include>>
Participar do chat
Utilizar Caixa de Emails
<<extend>>
<<extend>>
Figura 5 – Diagrama de caso de uso do portal.
31
A arquitetura do XOOPS possui as seguintes características: linguagem PHP
com banco de dados MySql, voltado também para implementação de portais
coorporativos, seus componentes (módulos) podem ser instalados e desinstalados e
ativados e desativados de forma extremamente simples. Nele ainda podem-se
personalizar os perfis dos usuários e os temas e a possibilidade de troca de mensagens
diretamente entre os usuários (existe uma caixa de entrada para cada um). Por esses
motivos ele foi escolhido como base para a implementação do sistema. A figura 6
apresenta a tela de gerenciamento dos módulos do XOOPS:
Figura 6 - Tela de Gerenciamento dos Módulos do XOOPS
É importante salientar que todos os módulos instalados são independentes
entre si, porém foi necessário que os módulos tivessem uma comunicação para facilitar
o trabalho dos analistas. Todos os vínculos entre eles foram feitos via triggers no banco
de dados.
32
3.4 Módulos do Sistema
O módulo de projeto, disponível em www.xoops.pr.gov.br , foi instalado por
ser essencial ao sistema aqui proposto. Nele é possível criar um projeto descrevendo
seu nome, descrição, suas datas de início e fim e definir quem serão os membros
cadastrados que terão acesso ao projeto.
Havia uma funcionalidade chamada “Criar Tarefa” onde era possível, como o
próprio nome sugere, criar uma nova tarefa para determinado projeto. Essa opção foi
alterada para “Criar Caso de Uso”, onde os membros que possuem tal permissão
podem criar casos de uso para o projeto. Sua implementação foi alterada para que
fosse possível cadastrar os casos de uso com todos os seus campos (Nome,
Descrição, Atores, Fluxo Básico de Eventos, Pré-Condições, Pós-Condições,
Exceções).
É possível ainda definir o esforço, em horas, que será designado para o
término do caso de uso. Neste módulo de projeto, ao criar um novo projeto, é disparada
uma trigger que cria uma categoria na tabela do módulo de fórum. A figura 7 apresenta
o módulo de projeto já alterado para o cadastro dos casos de uso e a figura 8 a trigger
implementada para a criação da categoria.
33
Figura 7 - Tela do Módulo de Projeto para Cadastro do Casos de Uso
Figura 8 – Trigger para criação da categoria
Ao escolher a opção “Editar” (Figura 9), será disponibilizada para o analista a
tela de edição do caso de uso em que se está trabalhando. Neste momento, é arbitrada
34
uma cor para este usuário e qualquer alteração que ele fizer no caso de uso será
automaticamente salva com a cor definida para o analista. Se em uma próxima sessão,
um outro analista desejar editar o caso de uso, uma cor diferente será atribuída a ele e
suas alterações também terão a respectiva cor. Dessa forma, qualquer pessoa que
visualize o caso de uso irá perceber que ele foi composto por analistas diferentes. Na
parte inferior da tela existirá uma legenda indicando o analista e sua respectiva cor.
Existe um controle onde apenas um analista poderá editar um determinado caso de uso
por vez. Caso um segundo analista tente editar o caso de uso no mesmo momento em
que outro o esteja fazendo, uma mensagem será exibida negando o acesso. A figura 9
mostra essa tela de edição com as cores e a legenda identificando os analistas.
Pode-se perceber na figura 9 as opções “Visualizar”, “Editar” e “Histórico”. O
Ajax1 (Asynchronous JavaScript and XML) foi utilizado para abrir as páginas com essas
opções sem a necessidade de carregar todo o conteúdo da página, dando assim mais
dinamismo e rapidez em sua utilização.
Ainda no módulo de projeto, ao clicar em “Criar Caso de Uso” uma outra
trigger é disparada, adicionando na categoria do fórum anteriormente criada um item
com o nome do caso de uso, onde é possível a todos os analistas discutir sobre o caso
de uso. Esse vínculo automático com o fórum, e a discursão dentro dele, geram
registros que podem servir posteriormente para compor a memória do projeto, sendo
possível, por exemplo, verificar quem fez qual alteração e por que. A figura 10
apresenta a trigger usada:
1 Técnica utilizada pelos browsers para fazer pedidos ao servidor sem ter que recarregar toda a página
35
Figura 9 - Tela com o caso de uso “Emprestar Fita” cadastrado, como exemplo
36
Figura 10 – Trigger que cria um item sobre o caso de uso no fórum
A figura 11 apresenta a tela do fórum onde foi criado um item para discussão
sobre um caso de uso “Emprestar Fita”, um exemplo para a ilustração.
37
Figura 11 – Tela de diálogo sobre o caso de uso ”Emprestar Fita” no fórum
38
Um outro módulo instalado foi o de chat. Ele permite que os analistas que
estejam on-line no portal em determinado momento possam conversar e trocar idéias
sobre o projeto. Assim como o fórum, o chat foi customizado para que esteja vinculado
especificamente a um projeto. Assim, toda a conversa que aconteça no chat será
também um registro a ser salvo e utilizado quando necessário. É também um suporte a
comunicação síncrona do sistema. A figura 12 mostra a tela do chat.
Figura 12 – Chat do Sistema
Outra funcionalidade do ERCOLAB é a troca de e-mails entre os usuários.
Ela não é um módulo instalado como os demais e sim uma estrutura do próprio XOOPS
que serve para estabelecer a comunicação entre os membros. A figura 13 apresenta a
39
tela de um e-mail como exemplo. Na parte inferior da figura, do lado esquerdo, podem-
se observar os usuários on-line no portal no momento, com seus nomes logo abaixo.
Ao clicar em um dos usuários dessa lista, abre-se a tela para envio de e-mail ao
mesmo.
Figura 13 – Exemplo de email utilizado no portal
Há ainda um módulo de notícias que exibe a todos os membros do portal
mensagens e notificações da empresa. Apenas os coordenadores poderão criar
notícias e enviá-las. Elas podem ser enviadas a determinados grupos de analistas e
não necessariamente a todos os membros. A figura 14 mostra o funcionamento do
módulo de notícias.
40
Figura 14 – Módulo de Notícias
3.5 Modelo de Dados
O modelo de dados do ERCOLAB é apresentado de acordo com a figura 15.
O modelo de dados completo contém 57 tabelas, isso porquê a estrutura do XOOPS já
vem com diversas tabelas, além das que são criadas com a instalação dos módulos e
com as adicionais, caso sejam necessárias. Neste modelo, são apresentadas 19
tabelas que são mais importantes para ilustrar a estrutura do projeto e o relacionamento
entre os módulos do sistema. Estas tabelas suportam as principais funcionalidades do
sistema, como, por exemplo:
• A tabela xoops_ws_use_case foi criada para armazenar todas as
informações do template de casos de uso. Nela estão presentes os campos
use_case_id, task_id e project_id, que compõem a chaves da tabela, sendo
que use_case_id é a chave primaria e as duas últimas chaves estrangeiras,
além de outros atributos abstraídos da figura.
41
• A tabela xoops_bbbex_forums é criada com a instalação do módulo de fórum
e foi editada para que obtivesse informações do caso de uso e da categoria a
que está associado. A chave primária é composta pelo campo forum_id e as
chaves estrangeiras pelos campos cat_id e task_id, além de outros atributos
abstraídos da figura. A inserção nessa tabela é baseada na criação dos
casos de uso, isto é, cada vez que um analista cria um caso de uso é
inserido um registro, vinculando assim os fóruns aos casos de uso.
Figura 15 – Modelo de Dados do Sistema
42
3.6 Avaliação da Ferramenta
Para realizar a avaliação da solução proposta neste projeto, foi desenvolvido
um ambiente que possibilita o trabalho colaborativo durante a definição dos casos
de uso em um projeto de software.
Sua implementação procurou minimizar as principais deficiências encontradas
em ferramentas colaborativas, como aponta a pesquisa feita recentemente por uma
firma de consultoria especializada em ferramentas colaborativas2, a Avanade,
como, por exemplo, a falta de integração entre as aplicações colaborativas, que
frustra os usuários finais.
Outra deficiência apontada foi a dificuldade de mensuração das contribuições
num ambiente colaborativo em números concretos. O ERCOLAB procura fazer essa
quantificação, ainda que de forma bastante simples, como mostra a figura 16. É
uma mensuração quantitativa da colaboração a partir das contribuições no fórum do
ERCOLAB, mas não qualitativa que seria o ideal.
Figura 16 – Tela de avaliação da contribuição do sistema
2 http://cio.uol.com.br/gestao/2007/10/10/idgnoticia.2007-10-10.9894265708/
43
O ERCOLAB possui uma limitação com relação ao browser utilizado. Ele se
comportou perfeitamente quando foi utilizado o Mozilla Firefox versão 2.0, porém
quando utilizado com o Microsoft Internet Explorer versão 7.0 ocorre um problema com
a atribuição das cores, usada no módulo de projeto. Caso um segundo analista tente
inserir um texto em meio a um outro já criado por outro analista, o Internet Explorer 7
altera toda a cor do texto já existente para a nova cor do analista atual que está
editando o caso de uso, dando uma falsa impressão de que todo o texto foi criado por
ele.
44
CONCLUSÃO
Neste trabalho foi apresentado um ambiente que irá auxiliar no levantamento
e elicitação de requisitos durante o processo de produção de software. Para tanto a
ferramenta permite a especificação de casos de uso através da Colaboração
(Coordenação, Comunicação e Cooperação) entre os analistas de sistemas envolvidos
num dado projeto. Desta forma os mesmos podem interagir durante o processo,
aumentando a produtividade e a qualidade das informações geradas e obtidas.
O portal foi desenvolvido sobre o XOOPS, um modelo de portal, onde são
implantados módulos que irão compor a ferramenta, dando suporte a interação online e
offline aos analistas.
No processo de desenvolvimento do portal foram customizados os módulos
de fórum, chat, notícias e projeto para que fosse possível a cooperação entre seus
usuários. Foi implementado, no módulo de projeto, um template para que os analistas
possam especificar casos de uso durante a construção de um produto de software. A
colaboração pode ser explicitada através do portal à medida que é possível visualizar
quem fez e quando foi feita cada alteração nos casos de uso, pois esse histórico é
armazenado e sua exibição utiliza cores para diferenciar as contribuições de cada
analista.
Dentre os problemas enfrentados durante a construção deste projeto, pode-
se destacar a falta de interação entre os módulos. Não havia relação entre eles, pois
são componentes independentes. Desta forma, foi necessário alterá-los para que a
essa comunicação acontecesse, fazendo com que trabalhassem em conjunto para
auxiliar o trabalho dos analistas. O histórico em cores também foi um desafio a ser
superado, tomando grande parte do tempo de desenvolvimento.
Conclui-se que a colaboração pode ser muito útil quando aplicada a um
projeto de software. Ela elimina as fronteiras entre os analistas, aumentando a
45
interatividade entre eles e a eficiência do trabalho como um todo. Neste projeto, a
colaboração foi utilizada num sistema de auxilio à elicitação de requisitos, incentivando
a comunicação e a cooperação entre os analistas para elaborar os casos de uso de um
projeto de software.
Como projetos futuros, pode-se implementar uma área que possibilite a
criação, de forma colaborativa, de diagramas da UML (de casos de uso, de atividades,
de gráficos de estados, de seqüências e de colaboração). O suporte a voz e imagem
também seria um importante acréscimo ao portal, tornando mais versátil a
comunicação. Uma área onde os stakeholders pudessem também debater sobre o
sistema poderia minimizar o problema da má interpretação dos requisitos.
46
REFERÊNCIAS ANTILLANCA, Hector; FULLER, David, [1996?]. Sistemas síncronicos cara-a-cara: requisitos, problemas y resultados . Disponível na Internet: www.diinf.usach.cl/ArchivosSubidos%5C17620041627143erECHC%2095%20HAE.pdf.
BELGAMO, Anderson. Estudo Comparativo Sobre as Técnicas de Elicitação de Requisitos de Software . Artigo. 2000. Disponível na Internet: http://www.niee.ufrgs.br/SBC2000/eventos/ctic/ctic002.pdf. Acesso em 15/09/2007.
BLAHA, Michael; RUMBAUGH, James. Modelagem e Projetos Baseados em Objetos com UML 2 . Tradução: Daniel Vieira. Rio de Janeiro. Editora Elsevier. 2006.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML - Guia do Usuário . Tradução: Fabio Freitas da Silva. Rio de Janeiro. Editora Campus. 2000.
BORGES, Marcos. R. S.; PINO, José A.; SALGADO, Ana C. 2000. Requirements for Shared Memory in CSCW Applications . 10th Anual Workshop on Information Technologies and Systems. Australia. Disponível na Internet: http://equipe.nce.ufrj.br/mborges/publicacoes/DBSCW%20COOPIS.doc.
BORTOLI, Lis Ângela de; E PRICE, Ana Maria de Alencar. O uso de workflow para apoiar a elicitação de requisitos . 2000. Universidade Federal do Rio Grande do Sul.
CHRISTEL, M. G.; KANG, K. C. Issues in Requirements Elicitation, Technical Report Software Engineering Institute . 1992. Disponível na Internet: http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf. Acesso em 28/09/2007.
CYSNEIROS, Luiz Marcio. Requisitos Não Funcionais: Da Elicitação ao Modelo Conceitual . 2001. Disponível na Internet: http://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdf. Acesso em 01/10/2007.
DAFT, R.L.; LENGEL, R.H. (1986) Organizational information requirements, media richness and structural design , Organizational Science, 32/5: Pág. 554-571
ELLIS, C. A.; GIBBS, S.J.; REIN, G.L. Groupware: Some issues and experiences. Communications of the ACM , New York, v.34, n.1, Jan. 1991.
FRANCO, Fabio Vilela.. COLAB - Ferramenta Colaborativa para Co-autoria de Textos via Web . 2003. Monografia. Centro Universitário do Triangulo (UNIT), Uberlândia-MG.
FREITAS, Danilo Pestana de; BORGES, Marcos R. S.; ARAÚJO, Renata Mendes de. Colaboração e Negociação na Elicitação de Requisito s. [2007?] Disponível na
47
Internet: http://kuainasi.ciens.ucv.ve/ideas07/documentos/articulos_ideas/Articulo74.pdf. Acesso em 15/09/2007
FUKS, Hugo.; RAPOSO, Alberto B.; GEROSA, Marco Aurélio. Engenharia de Groupware: Desenvolvimento de Aplicações Colaborati vas. XXI Jornada de Atualização em Informática, Anais do XXII Congresso da Sociedade Brasileira de Computação, V2, Cap. 3. 2002.
FUKS, Hugo.; RAPOSO, Alberto B. ; GEROSA, Marco Aurélio. Do Modelo de Colaboração 3C à Engenharia de Groupware , 2003. Simpósio Brasileiro de Sistemas Multimídia e Web – Webmidia 2003, Salvador-BA.
FUKS, Hugo. (Org.). Suporte à Coordenação e à Cooperação em uma Ferrame nta de Comunicação Textual Assíncrona: Um Estudo de Cas o no Ambiente AulaNet . 2004. Anais do Workshop Brasileiro de Tecnologias para Colaboração 13-14 de Outubro, Ribeirão Preto-SP . Disponível na Internet: http://www.les.inf.puc-rio.br/groupware
FURLAN, José Davi. Modelagem de Objetos através da UML: Análise e Dese nho Orientados a Objeto . São Paulo. Makron Books. 1998.
GEROSA, Marco Aurélio. et. al. Componentes Baseados no Modelo 3C para o Desenvolvimento de Ferramentas Colaborativas , 2005. Anais do 5º Workshop de Desenvolvimento Baseado em Componentes, Juiz de Fora-MG, Disponível na Internet: http://www.les.inf.puc-rio.br/groupware
LARMAN, Craig. Utilizando UML e padrões: Uma introdução à analise e ao projeto orientados a objetos . Tradução: Luiz A. Meirelles Salgado. Porto Alegre – RS. Editora Bookman. 2000
MACORATTI, José Carlos. Modelando Sistemas em UML - Casos de Uso . 2004. Disponível na Internet: http://www.imasters.com.br/artigo/2753/uml/modelando_sistemas_em_uml_-_casos_de_uso/. Acesso em 03/10/2007.
NOGUEIRA, Admilson. Casos de Uso (Cenários) . 2006. Disponível na Internet: http://www.imasters.com.br/artigo/3811/uml/casos_de_uso_cenarios/. Acesso em 03/10/2007.
OLIVEIRA, Carla. Sistemas Colaborativos . 2006. Disponível na Internet: http://cursoyai.googlepages.com/sistemasColaborativos.pdf, acesso em 12/09/2007.
PINHEIRO, Manuele Kirsch. Mecanismo de suporte à percepção em ambientes cooperativos . Porto Alegre: PPGC da UFRGS, 2000.
48
ROSA, Márcio. Groupware: um caminho para a cooperação . 2005. Disponível na Internet: http://www.frb.br/ciente/2005.1/BSI/ciente_v.1_bsi.rosa.pdf. Acesso em: 01/09/2007.
SOMMERVILLE, Ian. Engenharia de Software . 6ª Edição. Cap. 5 e 6. 2003
Zanlorenci, Edna Pacheco; Burnett, Robert Carlisle. 2001. Requisitos funcionais e não-funcionais, as duas faces da moeda aplicáveis à engenharia de software . Disponível na Internet: http://www.pr.gov.br/batebyte/edicoes/2001/bb115/requisitos.htm. Acesso em 02/10/2007
![Como Tudo Começou - Adauto Lourenço [Completo] (1)](https://img.document.onl/doc/110x75/55721243497959fc0b9052ac/como-tudo-comecou-adauto-lourenco-completo-1.jpg)
