Do Diagrama de Fluxo de Dados ao Use Case

Alessandro Botelho Bovo1,2, Renato Balancieri1,2, Sandra Ferrari2

1

Grupo Stela Universidade Federal de Santa Catarina (UFSC)

Rua Lauro Linhares, 2123, bloco B, 2 andar 88036-002 Florianpolis SC
2

Programa de Ps-Graduao em Engenharia de Produo

Universidade Federal de Santa Catarina (UFSC)

{abbovo,renato}@stela.ufsc.br, sandraferrari@terra.com.br
Abstract. This article has the objective of giving a brief view about two of the
most used methodologies of development of systems: the structured method for
analysis and design of software development and the objects oriented method.
The main features of the tools used to the modeling of systems that use of these
methods for its development are presented. Inside of the possible, its intended
to make a matching between them, aiming at, inside of the defined target, to
show the advantages and disadvantages of its use, given the existing
conditions. Finally, some points of view that can contribute for extend the
debate concerning the application of modeling tools, considering the analysis
method used, are presented.
Keywords: diagrams, modeling, tools, use cases, DFD, UML, objects
oriented.
Resumo. Este artigo tem como objetivo dar uma rpida viso sobre duas das
mais utilizadas metodologias de desenvolvimento de sistemas: o mtodo
estruturado para anlise e projeto de desenvolvimento de software e o mtodo
orientado a objetos. So apresentadas as principais caractersticas das
ferramentas utilizadas para a modelagem de sistemas que fazem uso desses
mtodos para o seu desenvolvimento. Pretende-se, dentro do possvel, dadas
s condies existentes, fazer uma comparao entre elas, visando, dentro do
escopo definido, mostrar as vantagens e desvantagens do seu uso. Por fim,
so apresentados alguns pontos de vistas que podem contribuir para a
ampliao do debate acerca da aplicao de ferramentas de modelagem,
considerando o mtodo de anlise utilizado.
Palavras-chave: diagramas, modelagem, ferramentas, use cases, DFD, UML,
orientado a objetos.

1. Introduo
Este trabalho contm uma pequena abordagem sobre dois dos mais utilizados mtodos
para anlise utilizados no desenvolvimento de sistemas.
Visando atender ao propsito estabelecido, os assuntos so abordados de modo
a possibilitar a contextualizao do assunto a ser desenvolvido, bem como a obteno
do objetivo pretendido.

Na Seo 2 feita uma breve apresentao do mtodo de anlise estruturada

para o desenvolvimento de sistemas; a Seo 2.1 so enfatizadas as caractersticas das
ferramentas utilizadas para a modelagem de sistemas que utilizam a anlise estruturada
para o seu desenvolvimento e, na Seo 2.1.1 h uma descrio sobre o diagrama de
fluxo de dados, uma das mais utilizadas ferramentas de modelagem. A Seo 3
apresenta uma viso do mtodo de anlise orientado a objetos e seus componentes
fundamentais, enquanto que a Seo 3.1 as ferramentas de modelagem orientadas a
objeto so abordadas de maneira resumida e com pouca profundidade. A Seo 4
apresenta a UML, uma linguagem unificada de modelagem, considerada um padro e
reconhecida mundialmente. Na Seo 5 apresentada uma comparao entre as
ferramentas de modelagem utilizadas nos mtodos de anlise estruturada e orientado a
objetos, visando, dentro do escopo definido, mostrar os pontos fortes e fracos de sua
utilizao e, finalmente, Seo 6 contm as observaes resultantes da realizao deste
trabalho e aponta os problemas resultantes da proliferao de ferramentas de
modelagem que dificultam o estabelecimento de um padro nico de modelagem,
independente do processo de desenvolvimento utilizado e, conseqentemente, a
proposio de ferramentas CASE, para dar suporte aos desenvolvedores, em todas as
atividades do processo de desenvolvimento de software.

2. Mtodo de Anlise Estruturada

At o final da dcada de 70, a grande maioria dos projetos de desenvolvimento de
sistemas comeava pela criao de um documento elaborado pelo analista de sistemas,
contendo uma descrio textual sobre o que ele entendia ser os requisitos do usurio.
Esses documentos muitas vezes denominados de especificao funcional padeciam de
alguns problemas: eram monolticos e, portanto, de difcil compreenso, uma vez que
era necessria toda a especificao funcional, para poder compreend-la; eram
redundantes, dado que a mesma informao era muitas vezes repetida em diversas
partes diferentes do documento, tornando difcil a sua atualizao e reviso,
conduzindo a um problema grave de inconsistncia; eram ambguos, pois o
detalhamento dos requisitos do usurio podia ser interpretado de modo distinto pelo
analista de sistemas, pelo projetista, pelo programador e pelo prprio usurio; eram de
difcil manuteno, posto que a especificao funcional quase sempre era obsoleta no
final do processo de desenvolvimento do sistema, o que muitas vezes ocorria no final
da fase de anlise, devido aos motivos anteriormente explicitados.
Esses problemas provocaram uma reao da comunidade de engenharia de
software que levou percepo de que a atividade de desenvolvimento de sistema
compreendesse especificaes funcionais que fossem grficas, particionadas e de
redundncia mnima conforme visto em Yourdon (1992).
Para DeMarco (1989) a anlise tradicional de sistemas, caracterizada por
especificaes macias e pesadas comeou a se modificar no final da dcada de 70,
dando lugar a uma nova abordagem denominada anlise estruturada, que dizia respeito
fundamentalmente a um novo tipo de especificao funcional, a especificao
estruturada.
O termo anlise estruturada foi popularizado por DeMarco (1989) quando
ento introduziu e nomeou smbolos grficos que possibilitariam ao analista criar
modelos de fluxo de informao, sugeriu uma heurstica para o uso desses smbolos e

sugeriu que um dicionrio de dados e narrativas de processamento pudesse ser usado

como complemento aos modelos de fluxo de informao.
Segundo DeMarco (1989) a anlise estruturada a utilizao das seguintes
ferramentas: diagrama de fluxo de dados, dicionrio de dados, portugus estruturado,
tabelas e rvores de deciso. A utilizao dessas ferramentas de maneira efetiva
contribuiria grandemente para a soluo ou minimizao dos problemas inerentes fase
de anlise (problemas de comunicao, a natureza varivel dos requisitos do sistema,
falta de ferramentas adequadas, problemas no documento de especificao funcional,
dentre outros).
A anlise estruturada, como todos os mtodos de anlise de requisitos de
software, uma atividade de construo de modelos. Utilizando uma notao que
prpria ao mtodo de anlise estruturada, possvel criar modelos que retratem o fluxo
e o contedo da informao (dado e controle), divide-se o sistema em parties
funcionais e comportamentais e descreve-se a essncia do que deve ser construdo
conforme pode ser verificado em Pressman (1995).
Dentre os muitos benefcios obtidos com a utilizao de uma metodologia
estruturada para anlise e projeto de sistemas, pode-se destacar:
?

os usurios obtm uma idia mais clara do sistema proposto, por meio dos
diagramas de fluxo de dados lgico do que a obtida atravs de narrativa de texto
e fluxogramas de sistemas fsicos;

a apresentao do sistema em termos de fluxo de dados lgicos evidencia malentendidos e pontos controversos mais cedo do que normalmente o caso;

as interfaces entre o sistema a ser desenvolvido e os sistemas automatizados

e/ou rotinas manuais, j existentes, so mostradas de modo bem claro pelo
diagrama de fluxo de dados e, a necessidade de documentar os detalhes dos
fluxos de dados do dicionrio de dados fora uma definio clara dessa
interface nos estgios iniciais;

supresso de duplicao de esforo, pelo uso do modelo lgico; e

a utilizao de dicionrio de dados para guardar os itens do glossrio,

economiza tempo na resoluo de problemas relacionados atribuio de
nomes iguais para designar diferentes coisas ou diferentes nomes para designar
a mesma coisa.

2.1. Caractersticas das Ferramentas de Modelagem

As caractersticas que segundo Yourdon (1992), as ferramentas de modelagem devem
ter so as seguintes: ser grficas, com adequado detalhamento textual de apoio; permitir
que os sistemas sejam visualizados de forma subdividida, na modalidade top-dow; ter
redundncias mnimas; ajudar no prognstico do comportamento do sistema; e ser
transparente para o leitor.
A maioria das ferramentas de modelagem apia-se em grficos. O uso de
grficos no obrigatrio em um modelo de sistema, mas justificvel a utilizao de
grficos ao invs de narrativas de texto, porque uma figura pode englobar uma imensa
quantidade de informaes de forma concisa e compacta, o que no significa que uma
figura possa descrever, necessariamente, tudo sobre um sistema.

Para Yourdon (1992), normalmente, os grficos so usados para identificar os

componentes de um sistema e as interfaces entre eles, as demais informaes so
apresentadas em documentos textuais de apoio.
Outro aspecto importante de uma boa ferramenta de modelagem a aptido
para retratar um sistema de forma subdividida top-dow, o que extremamente
importante quando se trata de modelar sistemas grandes e complexos, uma vez que essa
abordagem permite fornecer uma viso geral de alto nvel de uma parte do modelo
(principais componentes de alto nvel e interfaces do sistema) bem como uma viso das
partes subseqentes do modelo, enfocando informaes sobre componentes detalhados
de baixo nvel do sistema.
2.1.1 O Diagrama de Fluxo de Dados
O diagrama de fluxo de dados (DFD) a principal ferramenta de planejamento para um
sistema de informao conforme Gane (1988), e amplamente utilizado no mtodo de
anlise e projeto estruturado, pois ele mostra a fronteira do sistema e, muito
importante porque o nico documento que mostra todas as relaes entre os dados
(armazns e fluxos de dados) e os processos e funes que transformam esses dados.
O diagrama de fluxo de dados uma ferramenta de modelagem que permite que
um sistema seja visto como uma rede de processos assncronos e funcionais,
interligados por fluxos de dados e repositrios de armazenamento de dados. uma das
mais utilizadas ferramentas de modelagem de sistemas, principalmente para sistemas
nos quais as funes do sistema sejam mais importantes e mais complexas que os dados
manipulados pelo sistema. Em um sistema no qual os relacionamentos entre os dado
sejam mais importantes que as funes, pode-se dar menos importncia aos DFDs e
concentrar esforos no desenvolvimento de diagramas de entidades-relacionamento.
Como alternativa, se o comportamento tempo-dependente do sistema suplantar todos os
outros aspectos, os diagramas de transio de estado so a melhor opo. Deve-se,
porm, entender que as ferramentas acima se apresentam como alternativas, podendo
ser utilizadas como opes complementares durante o processo de modelagem, no
sendo, portanto, mutuamente exclusivas.
O primeiro componente de um DFD denominado processo, tambm
conhecido com bolha, funo e transformao. O processo mostra como uma ou mais
entradas so transformadas em sada. Atravs dos processos possvel representar
todas as funes de um sistema. Na maioria dos modelos de DFD, o nome do processo
descreve o que o processo faz, em alguns casos, conter o nome de uma pessoa ou de
um grupo de pessoas (ex: um departamento, ou diviso de uma empresa), ou um
computador, ou um dispositivo mecnico, para descrever quem ou o que executa o
processo, ao invs de descrever acerca do processo.
O fluxo de dados, outro componente do DFD, utilizado para mostrar o
movimento de fragmentos ou pacotes de informaes de um ponto a outro do sistema.
O fluxo de dados representa uma estrutura de dados dinmica, enquanto que os
depsitos de dados, ou armazns de dados, representam uma estrutura de dados
esttica.
O exame de fluxos de dados que entram e saem de um depsito de dados,
provoca questionamentos, a saber, (dentre outros): o fluxo representa um nico pacote,
mltiplos pacotes, partes de pacotes, partes de um ou de vrios pacotes? O fluxo de

dados no informa sobre prompts de entradas e nem responde perguntas de sada. Essas
e outras questes envolvem detalhes procedimentais e o DFD no trata desses aspectos.
Embora algumas das perguntas procedimentais possam ser respondidas pelo
exame dos rtulos dos fluxos, nem todos os detalhes so evidentes. Para saber tudo o
que se quer sobre um fluxo que parte de um depsito, tem-se que examinar os detalhes
a especificao de processos do processo ao qual o fluxo est interligado.
H um detalhe procedimental do qual se pode ter certeza: o depsito passivo e
os dados no transitam a partir dele pelos fluxos a menos que um processo os solicite
explicitamente. Existe outro detalhe procedimental que pressuposto, por conveno:
um depsito no se altera quando um pacote de informaes se movimenta a partir dele
por um fluxo descrito em Yourdon (1992).
Outro componente do DFD o terminador. Os terminadores representam as
entidades externas com as quais o sistema se comunica. Existem trs aspectos
importantes a serem considerados sobre terminadores: 1) eles so externos ao sistema
que est sendo modelado; os fluxos que interligam os terminadores aos diversos
processos (ou depsitos) representam a interface entre o sistema e o mundo externo; 2)
como conseqncia, nem o analista e nem o projetista de sistemas esto em condies
de modificar o contedo de um terminador ou o modo como o terminador funciona; e
3) qualquer relacionamento existente entre terminadores no mostrado no DFD, caso
haja relacionamentos entre terminadores e for essencial que o analista de sistema os
modele para documentar de forma correta os requisitos do sistema, ento, por
definio, os terminadores so realmente parte do sistema e devem ser modelados como
processo na viso de Yourdon (1992).
Uma maneira prtica de referenciar os processos de um DFD numerar cada
bolha. O importante quando se utilizar numerao, ser consistente no modo como se
atribui os nmeros e ter claro que a numerao dos processos no presume seqncia
de execuo, ainda que uma certa seqncia possa ser deduzida pela presena ou
ausncia de dados. A numerao til na identificao dos processos e servem como
base para o esquema de numerao hierrquico, quando do processo de decomposio
do DFD em nveis inferiores.
O propsito de um DFD modelar corretamente as funes que um sistema
deve executar e as interaes entre elas. Uma das maneiras de tornar um DFD geral
mais compreensivo e diminuir sua complexidade modelar um DFD geral em uma
srie de nveis, de modo que cada nvel oferea sucessivamente mais detalhes sobre
uma parte do nvel que lhe seja superior.
Para Yourdon (1992), um erro considerar o DFD como nica ferramenta de
modelagem. Est claro que um DFD, sem outras ferramentas adicionais de modelagem,
praticamente no tem valor.
Segundo Pressman (1995), a anlise estruturada, o mais utilizado dos mtodos
de modelagem de requisitos, faz uso de modelos como o primeiro elemento de uma
representao grfica para um sistema automatizado. Usando como base os diagramas
de fluxo de dados e de controle, o analista particiona as funes que transformam os
fluxos de dados. A seguir, cria um modelo comportamental, usando o diagrama de
transio de estado, e desenvolve um modelo de contedo de dados com um dicionrio
de requisitos (tambm chamado dicionrio de dados), ferramenta proposta como uma

gramtica quase formal para descrever o contedo de objetos definidos durante a

anlise estruturada.
A modelagem de dados, cuja notao o diagrama de entidade-relacionamento,
usada em aplicaes que envolvem grande volume de dados e pode ser aplicada como
uma ferramenta complementar durante a anlise estruturada.

3. Mtodo de Anlise Orientado a Objetos

No final da dcada de 1980, o paradigma orientado a objeto comeava a amadurecer
numa abordagem poderosa e prtica para desenvolvimento de software. A partir da a
anlise orientada a objeto vem fazendo um firme progresso como mtodo de anlise de
requisitos como complemento a outros mtodos de anlise. Ao invs de examinar um
problema usando o clssico modelo de fluxo de informao ou um modelo derivado
exclusivamente de estruturas de informao hierrquicas, a anlise orientada a objetos
introduz uma srie de novos conceitos na viso de Pressman (1995).
Os mtodos de anlise de requisitos de software orientados a objetos
possibilitam que o analista modele um problema ao representar classes, objetos,
atributos e operaes como os componentes primordiais de modelagem. A abordagem
orientada a objetos combina classificao de objetos, herana de atributos e
comunicao de mensagens no contexto de uma notao de modelagem.
A essncia da anlise e do projeto orientados a objetos enfatizar a
considerao de um domnio de problema e uma soluo lgica, segundo a perspectiva
de objetos.
De acordo com Pressman (1995) importante considerar que o uso de anlise
orientada a objeto pode levar a uma prototipagem efetiva e a tcnicas de engenharia de
software evolucionrias. Os objetos especificados e implementados em um projeto em
desenvolvimento podem ser catalogados em uma biblioteca. Os objetos so
inerentemente reusveis e, com o passar do tempo, a biblioteca de objetos reusveis
crescer. Ao utilizar a anlise orientada a objetos para o desenvolvimento de novos
projetos, o analista poder utilizar-se dos objetos j existentes durante a anlise, o que
reduzir substancialmente o tempo dedicado especificao e, um prottipo do sistema
especificado pode ser criado e revisado pelo cliente/usurio.
Os objetos modelam quase todos os objetos identificveis do domnio de
problemas: entidades externas, coisas, ocorrncias, papis, unidades organizacionais,
lugares e estruturas. Outro aspecto importante que objetos encapsulam tanto dados
como processo.
Segundo Thiry (2001), conceitualmente, uma classe entendida como um
conjunto de objetos que possuem caractersticas similares (atributos), comportamentos
comuns (operaes), relacionamentos comuns com outros objetos (agregaes e
associaes) e semntica comum.
Um objeto um componente do mundo real que mapeado para o domnio de
software. No contexto de sistemas computadorizados, um objeto (instncia de uma
classe) tipicamente um produtor ou consumidor de informaes ou um item de
informao. Um membro (objeto) de uma classe herda todos os atributos definidos
para a classe. Todo objeto de uma classe pode ser modificado por operaes (aes
aplicadas para mudar os atributos de um objeto ou realizar aes sobre um objeto). Um

objeto (e todos os objetos em geral) encapsula dados (valores dos atributos que
identificam um objeto). O encapsulamento representa o empacotamento do objeto,
ocultando seu estado e a implementao de suas operaes. De acordo com Thiry
(2001), o estado de um objeto representa uma das provveis condies em que o objeto
pode existir bem como representa os valores das propriedades de um determinado
objeto em um dado momento. Encapsulamento possibilita que toda informao
empacotada sob um determinado nome, pode ser reusada como uma especificao ou
componente de programa.
Conforme consta em Pressman (1995), quando um objeto representado
graficamente, ele se compe de uma estrutura de dados e processos particulares,
denominados operaes que podem transformar a estrutura de dados. As operaes
contm construes procedimentais e de controle que podem ser invocadas por uma
mensagem uma solicitao para que o objeto execute uma de suas operaes.

4. UML
Uma srie de diferentes ferramentas de modelagem tem sido sugerida para a anlise
orientada a objetos. Todas utilizam os conceitos de orientao a objetos, mas cada uma
introduz sua prpria notao, heurstica e filosofia.
As metodologias para anlise e projeto de sistemas provavelmente continuaro
a definir mtodos, modelos e processos de desenvolvimento visando a construo
efetiva de sistemas de software e, atualmente, podem faz-lo, usando uma linguagem
comum a UML.
Para Craig (2000), a Linguagem de Modelagem Unificada (UML), uma
notao (incluindo sua semntica) j aceita como padro que utiliza conceitos
orientados a objetos para modelagem de sistemas. uma linguagem para especificar,
visualizar e construir artefatos de sistemas.
A UML padroniza artefatos e notao, mas no define um processo-padro de
desenvolvimento de software e, dentre as razes para isso, tem-se que: a idia
aumentar sua aceitao como uma notao de modelagem padro sem se comprometer
com um determinado processo de desenvolvimento, dado que existe uma variao
significativa sobre o que constitui um processo apropriado.
A UML compreende um conjunto de diagramas, referenciados a seguir, que
propiciam a sua aplicao e a obteno dos resultados dentro do nvel de qualidade a
que se prope: diagrama de classe, de atividade, de componentes, de deployment, de
seqncia, de colaborao, de estados e de use case.
De acordo com Booch (2000) a UML independente de processo, porm, para
se obter o mximo proveito de suas potencialidades, necessrio que um processo seja:
orientado a casos de usos, centrado em arquitetura, iterativo e incremental.
Para Craig (2000), um diagrama de classes ilustra as especificaes para as
classes de software e de interfaces de uma aplicao, associaes e atributos; interfaces,
com suas operaes e constantes; mtodo, informao sobre o tipo do atributo;
navegabilidade e dependncias.
Para Booch (2000) um diagrama de atividade essencialmente um grfico de
fluxo, mostrando o fluxo de controle de uma atividade para outra e, um diagrama de

componentes uma apresentao grfica da viso esttica de implementao de um

sistema que mostra a organizao e as dependncias existentes entre um conjunto de
componentes.
Na concepo de Fowler (2000) um diagrama de deployment mostra as relaes
fsicas entre componentes de hardware e software no sistema implementado.
Segundo Thiry (2001) um diagrama de seqncia mostra a interao de objetos
organizada no tempo; o diagrama de colaborao mostra a interao de objetos no
contexto dos objetos e suas ligaes; os diagramas de estados so utilizados para
modelar o comportamento de um objeto e, os diagramas de use case so construdos
para possibilitar a visualizao dos relacionamentos entre atores e use cases.
Para o propsito deste trabalho, ser enfatizado o diagrama de use case, o qual
ser abordado a seguir.
4.1. Use Case
Conforme Booch (2000) um sistema interage com atores humanos ou qualquer outro
agente externo que se utilizam desse sistema para algum propsito e, esses atores
esperam que o sistema se comporte conforme o esperado. Um caso de uso especifica o
comportamento de um sistema ou de parte de um sistema e descreve um conjunto de
seqncias de aes, incluindo variantes realizadas pelo sistema para produzir um
resultado observvel do valor de um ator.
Ainda segundo Booch (2000) os casos de uso podem ser aplicados para captar o
comportamento desejado do sistema em desenvolvimento, sem a necessidade de
especificar como esse comportamento implementado. Os casos de uso fornecem uma
maneira para que os desenvolvedores, os especialistas do domnio e os usurios finais
tenham uma compreenso comum sobre o problema. Um caso de uso representa um
requisito funcional do sistema como um todo. Serve tambm, para ajudar a validar a
arquitetura e para realizar a verificao do sistema medida que este evolui durante seu
desenvolvimento.
Um caso de uso descreve um conjunto de seqncias, cada uma representando a
interao de itens externos ao sistema (atores) com o prprio sistema. Esses
comportamentos, na realidade so funes em nvel de sistema utilizadas para
visualizar, especificar, construir e documentar o comportamento previsto do sistema
durante a elicitao e anlise de requisitos.
Para Craig (2000) um caso de uso uma descrio textual de um processo do
domnio em uma empresa ou sistema em um formato estruturado. Constituindo-se,
portanto, em um documento narrativo que descreve a seqncia de eventos de um ator
(um agente externo) que usa um sistema para completar um processo. Na prtica, o
diagrama de caso de uso pode ser expresso em variados graus de detalhes, bem como
de comprometimentos com as decises de projeto, o que significa que o mesmo caso de
uso pode ser escrito em diferentes formatos e em diferentes nveis de detalhes.

5. Comparao entre a Anlise Estruturada e Orientada a Objetos

Um sistema (do mundo real ou de software) normalmente muito complexo, portanto,
necessrio decomp-lo em partes de forma a possibilitar sua compreenso e
administrar sua complexidade. Essas partes podem ser representadas como modelos

que descrevem e abstraem aspectos essenciais do sistema. Assim, importante criar,

durante a construo de software, modelos que organizam e comunicam os detalhes do
mundo real com o sistema ao qual est relacionado, bem como do sistema a ser
construdo. Esses modelos devem conter elementos coesos e fortemente relacionados.
Antes do advento do mtodo de anlise e projeto orientado a objetos, a
abordagem mais utilizada para a decomposio de um problema era o mtodo de
anlise e projeto estruturado, no qual o particionamento feito atravs de funes e
processos, tendo como resultado uma decomposio hierrquica de processos
compostos por sub-processos. A anlise e projeto orientados a objetos enfatizam a
decomposio do espao de um problema por objetos ao invs de funes. A Figura 3
mostra as diferentes vises de decomposio por meio dos mtodos de anlise e projeto
estruturado e orientado a objetos segundo Craig (2000).

Figura 3 Decomposio orientada a objetos versus orientada funo.

Existem diversas ferramentas de modelagem, que podem ser utilizadas para o

desenvolvimento de sistemas, baseado nos mtodos de anlise acima referenciados.
Com o propsito de atingir o objetivo proposto neste trabalho, ser feita uma
comparao apenas das principais ferramentas de modelagem dos dois mtodos de
anlise de requisitos abordados.
Na concepo de Craig (2000) a finalidade do diagrama de casos de uso
apresentar um tipo de diagrama de contexto, atravs do qual pode-se compreender
rapidamente quais so os atores externos a um sistema e como eles o utilizam.
No caso do DFD, as entidades externas (categorias lgicas de coisas ou pessoas
que representam a fonte ou destino de informao) so origem e/ou destino de
informaes estando, portanto, por definio, fora do sistema em considerao
conforme visto em Gane (1988).
Assim, tanto a aplicao de DFD como de diagramas de casos de uso envolve a
modelagem de contexto do sistema, pois ambos mostram a fronteira do sistema e as
entidades externas (atores no caso de use case) que interagem com o mesmo.
Desse modo, entende-se que um determinado processo do diagrama de fluxo de
dados (representa uma funo) de um sistema pode ser visto como um diagrama de

casos de uso e que as entidades externas do diagrama de fluxo de dados podem ser
mapeadas diretamente como atores em um diagrama de casos de uso.
Tanto o diagrama de fluxo de dados como de casos de uso possibilitam a viso
de aspectos funcionais do sistema.
Para Pressman (1995) o DFD possibilita que o engenheiro de software
desenvolva modelos do domnio da informao e do domnio funcional
simultaneamente. Quando o DFD refinado em nveis de detalhes, o analista executa
uma decomposio funcional implcita. Ao mesmo tempo, o refinamento do DFD
resulta em um refinamento dos dados medida que eles se movimentam atravs dos
processos.
A decomposio do DFD em nveis inferiores de detalhes similar criao de
vrios diagramas de casos de uso, dado que um diagrama de use case utilizado para
criar e refinar um conjunto de requisitos, o que em ambos os casos elimina a
complexidade e problemas de inconsistncia.
O DFD por si s no basta para realizar a modelagem de sistema baseados no
mtodo de anlise estruturada e deve ser usada em conjunto com outras ferramentas,
como o diagrama de entidade-relacionamento, para modelar os dados; o diagrama de
estados, para modelar o comportamento do sistema, e o dicionrio de dados, que
contm o contedo dos dados.
Similarmente, um diagrama de casos de uso no suficientemente poderoso
para modelar um sistema orientado a objetos em sua totalidade, tendo estreita relao
com os diagramas de seqncia e colaborao, dentre outros.
O DFD e o diagrama de casos de uso utilizam-se de narrativas de textos como
apoio especificao do processo.
Uma das crticas em relao ao DFD, diz respeito abordagem top-dow exigida
para a sua construo e manuteno.Para Pressman (1995) o DFD deve ser apresentado
aos usurios na modalidade top-dow, entretanto, no necessariamente verdadeiro que
o analista de sistema deva desenvolver os diagramas de fluxo de dados segundo essa
modalidade. A subdiviso de um DFD pode ser para cima (para criar DFD de nveis
mais elevados) e para baixo (para criar DFD de nveis mais baixos).
Para Booch (2000) um caso de uso descreve o que um sistema (ou um
subsistema, classe ou interface) faz, sem especificar como isso feito. Ele captura o
comportamento compreendido do sistema em desenvolvimento, sem precisar
especificar como esse comportamento implementado. Esse um fator importante para
isolar aspectos de anlise (comportamento do sistema) de aspectos referentes
implementao (como esse comportamento executado).
No DFD, embora alguns aspectos fsicos de implementao possam ser
visualizados, eles no so incentivados.
Kulak (2000) afirma que h uma pr-disposio na indstria para associar use case com
sistemas orientados a objetos, mas acredita que os casos de uso podem ser usados
facilmente para documentar requisitos de sistemas no orientados a objetos,
entendendo-os, inclusive como um grande modo de documentar quaisquer tipos de
sistemas. E defende tambm que os diagramas de fluxo de dados podem ser utilizados
para modelar sistemas baseados nos mtodos de anlise orientados a objetos.

6. Concluso
Constitui-se uma tarefa difcil e complexa a avaliao e, conseqentemente a
comparao, de ferramentas utilizadas na modelagem de sistemas que tm seu
desenvolvimento baseado em mtodos totalmente distintos.
A anlise estruturada, como todos os mtodos de anlise de requisitos de
software, uma atividade de construo de modelos que usando uma notao que
prpria ao mtodo de anlise estruturado, possibilita a construo de modelos que
retratam o fluxo e o contedo da informao.
A anlise orientada a objetos, por sua vez, ao invs de examinar um problema
usando o conhecido modelo de fluxo de informao e, ao introduzir novos conceitos,
possibilita que o analista modele um problema ao representar classes, objetos, atributos
e operaes como os componentes principais de modelagem.
Fica evidente que as duas abordagens acima referenciadas, examinam um
problema a partir de distintas vises e, conseqentemente, se utilizam de ferramentas
que sejam compatveis ao seu modo de enxergar o sistema a ser construdo e
possibilitem a criao de modelos que possam retratar o melhor possvel o problema e
sua soluo.
Acreditamos que muitos dos aspectos que dificultam a adoo de uma
determinada ferramenta de modelagem esto relacionados principalmente com o fato
de: 1) os analistas estarem acostumados a desenvolver sistemas utilizando um
determinado mtodo e, para a sua modelagem, utilizam ferramentas com caractersticas
voltadas a esse mtodo, resistindo a mudanas; 2) por no deterem conhecimento
suficiente para amparar tal mudana ou por simples preconceito (decorrncia de
desconhecimento) em relao adoo de um novo mtodo de anlise e a conseqente
aplicao de ferramentas que suportem as atividades previstas nesse mtodo.
Os usurios finais nem sempre tm conhecimentos suficientes que lhes
permitam opinar sobre a adoo (ou a migrao) de um determinado mtodo de anlise
de requisitos, ficando merc da opinio dos desenvolvedores (analistas e engenheiros
de software) que, apegados a abordagens antigas devido ao despreparo ou por
resistirem s inovaes, da rea de engenharia de software, contribuem para que as
empresas permanecem estagnadas.
Muitas empresas tm potencial e anseiam por mudanas que impliquem em
melhorias de seus produtos e do processo atravs dos quais seus produtos so
construdos, mas, por falta de orientao, acabam se acomodando aos mtodos e
ferramentas costumeiros.
A resistncia s mudanas, no um mito, uma realidade. Muitas vezes, o que
determina a escolha do mtodo de anlise do sistema a ser desenvolvido e as
ferramentas aplicadas para a sua modelagem, a experincia do analista e no a
natureza da aplicao ou os provveis benefcios que podem ser obtidos com a
utilizao de um mtodo que seja mais adequado ao problema para o qual se busca
soluo.
As contribuies dos profissionais e estudiosos da rea de engenharia de
software, no que tange aos mtodos de anlise de requisitos de software, trazem,
normalmente, em seu bojo, uma nova notao, o que implica em criar novas

ferramentas que possam suportar essas notaes. O esforo demandado no

desenvolvimento de software poderia ser minimizado com um conjunto de ferramentas
automatizadas para auxiliar as atividades de desenvolvimento, entretanto, dada
diversidade de notaes, torna-se difcil construo dessas ferramentas.
Ainda que os mtodos de anlise de requisitos estruturado e orientado a objetos
abordem o desenvolvimento de sistemas a partir de vises totalmente distintas,
entendemos que muitas das ferramentas de modelagem podem ser usadas por ambos,
tais como, diagramas de fluxo de dados, diagramas de entidade-relacionamento,
diagramas de estados e prototipagem, sem comprometer o resultado pretendido e o
nvel de qualidade desejado.
Como a rea de engenharia de software est em constante evoluo,
acreditamos que esse cenrio persistir imutvel, enquanto houver estudiosos buscando
dar contribuies que visem a melhoria dos mtodos de anlise de requisitos bem como
das ferramentas utilizadas para modelar os sistemas baseados nesses mtodos.
Est claro que o uso de um determinado mtodo de anlise e ferramentas
apropriadas de modelagem, no implica em garantia de elicitar correta, adequada e
completamente os requisitos do usurio. A capacidade de capturar os requisitos e
traduzi-los em uma representao que o usurio possa entender, depende
significativamente da experincia do analista na tarefa de desenvolvimento de sistemas
e de aplicao de ferramentas que possam dar suporte s suas atividades.

Referncias
Booch, G. et al. (2000) UML Guia do Usurio. Editora Campus, Rio de Janeiro.
DeMarco, T. (1989) Anlise Estruturada e Especificao de Sistemas. Editora Campus,
Srie Yourdon Press, Rio de Janeiro.
Fowler, M. e Scott, K. (2000) UML Essencial. 2 ed., Porto Alegre, Bookman.
Gane, C. (1988) Desenvolvimento Rpido de Sistemas. Livros Tcnicos e Cientficos
Editora LTDA, Rio de Janeiro.
Gane, C. e Ssarson, T. (1983) Anlise Estruturada de Sistemas. Livros Tcnicos e
Cientficos Editora LTDA, Rio de Janeiro.
Larman, C. (2000) Utilizando UML e Padres. Porto Alegre:Bookman.
Kulak, D. (2000) USE CASES Requirements in Context. ADDISON-WESLEY, New
York.
PRESSMAN, R. S. (1995) Engenharia de Software. MAKRON Books do Brasil, So
Paulo.
Thiry, M. e Salm Jr, J. (2001) Processo de Desenvolvimento de Software com UML, 2
perodo/2001. [disponvel on-line: http:// www.eps.ufsc.br/disc/procuml].
Yourdon, E. (1992) Anlise Estruturada Moderna. Editora Campus, Srie Yourdon
Press, Rio de Janeiro.